主动信息收集的原理

1. OSI七层模型

基于ping命令的探测

ARP协议概述：ARP协议是“Address Resolution Protocol”（地址解析协议）的缩写。计算机通过ARP协议将IP地址转换成MAC地址。

1.ping-arping命令使用方法

  ttl:跳数
 # traceroute baidu.com //对路由进行跟踪(可渗透路由器)
 # arping 192.168.167.66 //可以返回ip地址的mac地址(链路层地址)

2.使用netdiscover和fping进行探测局域网中的机器

主动模式：
    # netdiscover -i eth0 -r 192.168.167.0/24 
被动模式：
    # netdiscover -p
# fping -ag 192.168.167.0/24

3.TCP三次握手四次挥手原理和抓包过程

4. tcpdump抓包查看三次握手过程

TCP连接状态详解：

服务器端：LISTEN：侦听来自远方的TCP端口的连接请求

客户端：SYN-SENT：在发送连接请求后等待匹配的连接请求

服务器端：SYN-RECEIVED：在收到和发送一个连接请求后等待对方对连接请求的确认

客户端/服务器端：ESTABLISHED：代表一个打开的连接

    无法用ping做实验来查看三次握手，因为ping不是基于tcp协议实现的;
    ssh、http才是基于tcp协议的
    # tcpdump -c 3 -i eth0 -n port 22 (这个22号端口既是客户端22号端口也是服务端的22号端口)
    # ssh 8.130.27.140(阿里云服务器ip)

监听eth0网卡，并且只抓前3个包: 能看到这些信息说明到这里三次握手已完成,这些信息是服务器sshd发送来的数据信息: 查看三次握手信息:

19:02:17.348032 IP 192.168.167.67.52832 > 8.130.27.140.22: Flags [S], seq 2584787333, win 64240, options [mss 1460,sackOK,TS val 1244627605 ecr 0,nop,wscale 7], length 0
19:02:17.404564 IP 8.130.27.140.22 > 192.168.167.67.52832: Flags [S.], seq 1363528272, ack 2584787334, win 28960, options [mss 1360,sackOK,TS val 17527440 ecr 1244627605,nop,wscale 7], length 0
19:02:17.404658 IP 192.168.167.67.52832 > 8.130.27.140.22: Flags [.], ack 1, win 502, options [nop,nop,TS val 1244627662 ecr 17527440], length 0
3 packets captured
4 packets received by filter
0 packets dropped by kernel

注：Flags[S]中的S表示SYN标志位为1

从这些信息中可以发现第三个包中的ack的值是1而不是seq+1，为什么？

因为client主机返回ACK，包序号为ack=1，这是相对序号，如果需要看绝对序号，tcpdump加上-S参数，加上以后的三次握手信息:

19:17:54.013712 IP 192.168.167.67.60988 > 8.130.27.140.22: Flags [S], seq 2548827868, win 64240, options [mss 1460,sackOK,TS val 1245564271 ecr 0,nop,wscale 7], length 0
19:17:54.075573 IP 8.130.27.140.22 > 192.168.167.67.60988: Flags [S.], seq 2470835589, ack 2548827869, win 28960, options [mss 1360,sackOK,TS val 18464116 ecr 1245564271,nop,wscale 7], length 0
19:17:54.075651 IP 192.168.167.67.60988 > 8.130.27.140.22: Flags [.], ack 2470835590, win 502, options [nop,nop,TS val 1245564333 ecr 18464116], length 0
3 packets captured
7 packets received by filter
0 packets dropped by kernel

基于Nmap的扫描方式

1. 使用nmap进行半连接扫描

# nmap -sn 192.168.167.0/24 //-sn参数表示只ping扫描，不进行端口扫描

nmap扫描类型主要有TCP的全连接扫描(三次握手完整走完了)（会在被扫描机器留下记录），半连接扫描(不走第三次握手)（不会留下记录）

RST(reset)表示复位,用来异常的关闭连接，断开的更快(不用四次挥手)

# nmap -sS 114.114.114.114 -p 80,81,21,25,110,443 //-p表示端口 //半连接扫描
# nmap -sS 114.114.114.114 -p 1-1000 //扫描1到1000所有端口

以我的云服务器为例子:

2.插一个实际案例

12306.cn开放这么多端口是实在奇怪,可以看到返回来的ip地址为116.162.181.152

对12306.cn进行nslookup:

发现12306.cn的cname的一个ip地址恰好为116.162.181.152，而12306.cn的cname为12306.cn.wsglb0.com，查询子域名知道这是一个cdn加速公司，由此可推断116.162.181.152是cdn加速公司的一个加速节点。所以如果要对116.162.181.152的这些open端口进行渗透，实际上渗透的是cdn的加速节点服务器（根据cdn加速原理，该加速节点服务器上应该有12306.cn源服务器的镜像？），而并不是12306.cn的源服务器。

3.使用nc扫描端口

ctrl + shift + t 可以快速再打开一个终端

alt + 1/2/3/4 切换终端窗口

nc : netcat

nc -nv -w 1 -z 192.168.167.1 1-100

nc参数：
-n   直接使用IP地址，而不通过域名服务器

-v   显示指令执行过程。

-w 表示超时时间

-z  表示使用0输入/输出模式，只在扫描通信端口时使用。

DDOS攻击防御-SYN Flood

SYN洪水攻击概述：SYN洪水攻击主要源于： tcp协议的三次握手机制

SYN洪水攻击的过程：

在服务端返回一个确认的SYN-ACK包的时候有个潜在的弊端，如果发起的客户是一个不存在的客户端，那么服务端就不会接到客户端回应的ACK包。

这时服务端需要耗费一定的数量的系统内存来等待这个未决的连接(因为服务端不知道包是因为网络的原因丢失还是因为对方根本不存在)，直到等待超关闭，才能释放内存。

如果恶意者通过通过ip欺骗，发送大量SYN包给受害者系统，导致服务端存在大量未决的连接并占用大量内存和tcp连接，从而导致正常客户端无法访问服务端，这就是SYN洪水攻击的过程。

1.用hping3进行SYN Flood洪水攻击

   # hping3 -c 1000 -d 120 -S  -p 80 --flood --rand-source 192.168.1.63
       
    -c 1000 = 发送的数据包的数量。

    -d 120 = 发送到目标机器的每个数据包的大小。单位是字节

    -S = 只发送SYN数据包。

    -p 80 = 目的地端口(80是WEB端口)。你在这里可以使用任何端口。

    --flood = 尽可能快地发送数据包，不需要考虑显示入站回复。洪水攻击模式。

    --rand-source = 使用随机性的源头IP地址。
    
   
   在被攻击的服务器上:# netstat  -antup | grep 80 查看服务器被攻击状态

2.用hping3进行SYN Flood洪水攻击时遇到的一些问题

1.对局域网内的服务器与对局域网外的服务器(公网上的服务器):

都是有效果的。但只有在局域网中,--rand-source才有效。一旦经过路由器，到了公网，--rand-source就会失效，服务器上显示的请求全都是来自真正的ip

不知道为什么对我阿里云上的服务器不起效果，难道因为阿里云自带防syn flood的策略？

2.ping不通的问题再次出现

问题：两个虚拟机是桥接模式，并且都能ping通百度(外网)，也能ping通主机(局域网)。但是主机却ping不通两个虚拟机了(局域网)

主动信息收集