rst包源代码（rst数据包）

本篇文章给大家谈谈rst包源代码，以及rst数据包对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、nmap使用求助
• 2、winpcap 能不能只捕获网卡收到的数据包,而不捕获网卡自己发送的数据包啊?
• 3、求syn扫描的源代码及操作系统探测的相关资料
• 4、用verilog编写源代码和测试程序

nmap使用求助

Nmap是一款网络扫描和主机检测的非常有用的工具。Nmap是不局限于仅仅收集信息和枚举，同时可以用来作为一个漏洞探测器或安全扫描器。它可以适用于winodws,linux,mac等操作系统

Nmap是一款非常强大的实用工具,可用于：检测活在网络上的主机（主机发现）检测主机上开放的端口（端口发现或枚举）检测到相应的端口（服务发现）的软件和版本检测操作系统，硬件地址，以及软件版本检测脆弱性的漏洞（Nmap的脚本）Nmap是一个非常普遍的工具，它有命令行界面和图形用户界面。本人包括以下方面的内容:介绍Nmap扫描中的重要参数操作系统检测Nmap使用教程Nmap使用不同的技术来执行扫描，包括：TCP的connect（）扫描，TCP反向的ident扫描，FTP反弹扫描等。所有这些扫描的类型有自己的优点和缺点，我们接下来将讨论这些问题。 Nmap的使用取决于目标主机,因为有一个简单的（基本）扫描和预先扫描之间的差异。我们需要使用一些先进的技术来绕过防火墙和入侵检测/防御系统，以获得正确的结果。下面是一些基本的命令和它们的用法的例子：扫描单一的一个主机，命令如下：

代码如下:

#nmap nxadmin.com#nmap 192.168.1.2

扫描整个子网,命令如下:

代码如下:

#nmap 192.168.1.1/24

扫描多个目标,命令如下：

代码如下:

#nmap 192.168.1.2 192.168.1.5

扫描一个范围内的目标,如下：

代码如下:

#nmap 192.168.1.1-100 (扫描IP地址为192.168.1.1-192.168.1.100内的所有主机)

如果你有一个ip地址列表，将这个保存为一个txt文件，和namp在同一目录下,扫描这个txt内的所有主机，命令如下：

代码如下:

#nmap -iL target.txt

如果你想看到你扫描的所有主机的列表，用以下命令:

代码如下:

#nmap -sL 192.168.1.1/24

扫描除过某一个ip外的所有子网主机,命令：

代码如下:

#nmap192.168.1.1/24-exclude192.168.1.1

扫描除过某一个文件中的ip外的子网主机命令

代码如下:

#nmap192.168.1.1/24-excludefilexxx.txt(xxx.txt中的文件将会从扫描的主机中排除)

扫描特定主机上的80,21,23端口,命令如下

代码如下:

#nmap-p80,21,23192.168.1.1

从上面我们已经了解了Nmap的基础知识，下面我们深入的探讨一下Nmap的扫描技术

Tcp SYN Scan (sS) 这是一个基本的扫描方式,它被称为半开放扫描，因为这种技术使得Nmap不需要通过完整的握手，就能获得远程主机的信息。Nmap发送SYN包到远程主机，但是它不会产生任何会话.因此不会在目标主机上产生任何日志记录,因为没有形成会话。这个就是SYN扫描的优势.如果Nmap命令中没有指出扫描类型,默认的就是Tcp SYN.但是它需要root/administrator权限.

代码如下:

#nmap -sS 192.168.1.1

Tcp connect() scan(sT)如果不选择SYN扫描,TCP connect()扫描就是默认的扫描模式.不同于Tcp SYN扫描,Tcp connect()扫描需要完成三次握手,并且要求调用系统的connect().Tcp connect()扫描技术只适用于找出TCP和UDP端口.

代码如下:

#nmap -sT 192.168.1.1

Udp scan(sU)顾名思义,这种扫描技术用来寻找目标主机打开的UDP端口.它不需要发送任何的SYN包，因为这种技术是针对UDP端口的。UDP扫描发送UDP数据包到目标主机，并等待响应,如果返回ICMP不可达的错误消息，说明端口是关闭的，如果得到正确的适当的回应，说明端口是开放的.

代码如下:

#nmap -sU 192.168.1.1

FINscan(sF)

有时候TcpSYN扫描不是最佳的扫描模式,因为有防火墙的存在.目标主机有时候可能有IDS和IPS系统的存在,防火墙会阻止掉SYN数据包。发送一个设置了FIN标志的数据包并不需要完成TCP的握手.

代码如下:

a href="mailto:root@bt:~#nmap-sF192.168.1.8"root@bt:~#nmap-sF192.168.1.8/a/p pStartingNmap5.51at2012-07-0819:21PKTNmapscanreportfor192.168.1.8Hostisup(0.000026slatency).Notshown:999closedportsPORTSTATESERVICE111/tcpopen|filteredrpcbind

FIN扫描也不会在目标主机上创建日志(FIN扫描的优势之一).个类型的扫描都是具有差异性的,FIN扫描发送的包只包含FIN标识,NULL扫描不发送数据包上的任何字节,XMAS扫描发送FIN、PSH和URG标识的数据包.

PINGScan(sP)

PING扫描不同于其它的扫描方式，因为它只用于找出主机是否是存在在网络中的.它不是用来发现是否开放端口的.PING扫描需要ROOT权限，如果用户没有ROOT权限,PING扫描将会使用connect()调用.

代码如下:

#nmap-sP192.168.1.1

版本检测(sV)

版本检测是用来扫描目标主机和端口上运行的软件的版本.它不同于其它的扫描技术，它不是用来扫描目标主机上开放的端口，不过它需要从开放的端口获取信息来判断软件的版本.使用版本检测扫描之前需要先用TCPSYN扫描开放了哪些端口.

代码如下:

#nmap-sV192.168.1.1

Idlescan(sL)

Idlescan是一种先进的扫描技术，它不是用你真实的主机Ip发送数据包，而是使用另外一个目标网络的主机发送数据包.

代码如下:

#nmap-sL192.168.1.6192.168.1.1

Idlescan是一种理想的匿名扫描技术,通过目标网络中的192.168.1.6向主机192.168.1.1发送数据，来获取192.168.1.1开放的端口

有需要其它的扫描技术，如FTPbounce（FTP反弹）,fragmentationscan（碎片扫描）,IPprotocolscan（IP协议扫描）,以上讨论的是几种最主要的扫描方式.

Nmap的OS检测（O）

Nmap最重要的特点之一是能够远程检测操作系统和软件，Nmap的OS检测技术在渗透测试中用来了解远程主机的操作系统和软件是非常有用的，通过获取的信息你可以知道已知的漏洞。Nmap有一个名为的nmap-OS-DB数据库，该数据库包含超过2600操作系统的信息。Nmap把TCP和UDP数据包发送到目标机器上，然后检查结果和数据库对照。

代码如下:

InitiatingSYNStealthScanat10:21Scanninglocalhost(127.0.0.1)[1000ports]Discoveredopenport111/tcpon127.0.0.1CompletedSYNStealthScanat10:21,0.08selapsed(1000totalports)InitiatingOSdetection(try#1)againstlocalhost(127.0.0.1)RetryingOSdetection(try#2)againstlocalhost(127.0.0.1)

上面的例子清楚地表明，Nmap的首次发现开放的端口，然后发送数据包发现远程操作系统。操作系统检测参数是O（大写O）

Nmap的操作系统指纹识别技术：

设备类型（路由器，工作组等）运行（运行的操作系统）操作系统的详细信息（操作系统的名称和版本）网络距离（目标和攻击者之间的距离跳）

如果远程主机有防火墙，IDS和IPS系统，你可以使用-PN命令来确保不ping远程主机，因为有时候防火墙会组织掉ping请求.-PN命令告诉Nmap不用ping远程主机。

代码如下:

#nmap-O-PN192.168.1.1/24

以上命令告诉发信主机远程主机是存活在网络上的，所以没有必要发送ping请求,使用-PN参数可以绕过PING命令,但是不影响主机的系统的发现.

Nmap的操作系统检测的基础是有开放和关闭的端口，如果OSscan无法检测到至少一个开放或者关闭的端口，会返回以下错误：

代码如下:

Warning:OSScanresultsmaybeunreliablebecausewecouldnotfindatleast1openand1closedport

OSScan的结果是不可靠的，因为没有发现至少一个开放或者关闭的端口

这种情况是非常不理想的，应该是远程主机做了针对操作系统检测的防范。如果Nmap不能检测到远程操作系统类型，那么就没有必要使用-osscan_limit检测。

想好通过Nmap准确的检测到远程操作系统是比较困难的，需要使用到Nmap的猜测功能选项,–osscan-guess猜测认为最接近目标的匹配操作系统类型。

代码如下:

#nmap-O--osscan-guess192.168.1.1

下面是扫描类型说明

-sTTCPconnect()扫描：这是最基本的TCP扫描方式。connect()是一种系统调用，由操作系统提供，用来打开一个连接。如果目标端口有程序监听，connect()就会成功返回，否则这个端口是不可达的。这项技术最大的优点是，你勿需root权限。任何UNIX用户都可以自由使用这个系统调用。这种扫描很容易被检测到，在目标主机的日志中会记录大批的连接请求以及错误信息。

-sSTCP同步扫描(TCPSYN)：因为不必全部打开一个TCP连接，所以这项技术通常称为半开扫描(half-open)。你可以发出一个TCP同步包(SYN)，然后等待回应。如果对方返回SYN|ACK(响应)包就表示目标端口正在监听；如果返回RST数据包，就表示目标端口没有监听程序；如果收到一个SYN|ACK包，源主机就会马上发出一个RST(复位)数据包断开和目标主机的连接，这实际上有我们的操作系统内核自动完成的。这项技术最大的好处是，很少有系统能够把这记入系统日志。不过，你需要root权限来定制SYN数据包。

-sF-sX-sN秘密FIN数据包扫描、圣诞树(XmasTree)、空(Null)扫描模式：即使SYN扫描都无法确定的情况下使用。一些防火墙和包过滤软件能够对发送到被限制端口的SYN数据包进行监视，而且有些程序比如synlogger和courtney能够检测那些扫描。这些高级的扫描方式可以逃过这些干扰。些扫描方式的理论依据是：关闭的端口需要对你的探测包回应RST包，而打开的端口必需忽略有问题的包(参考RFC793第64页)。FIN扫描使用暴露的FIN数据包来探测，而圣诞树扫描打开数据包的FIN、URG和PUSH标志。不幸的是，微软决定完全忽略这个标准，另起炉灶。所以这种扫描方式对Windows95/NT无效。不过，从另外的角度讲，可以使用这种方式来分别两种不同的平台。如果使用这种扫描方式可以发现打开的端口，你就可以确定目标注意运行的不是Windows系统。如果使用-sF、-sX或者-sN扫描显示所有的端口都是关闭的，而使用SYN扫描显示有打开的端口，你可以确定目标主机可能运行的是Windwos系统。现在这种方式没有什么太大的用处，因为nmap有内嵌的操作系统检测功能。还有其它几个系统使用和windows同样的处理方式，包括Cisco、BSDI、HP/UX、MYS、IRIX。在应该抛弃数据包时，以上这些系统都会从打开的端口发出复位数据包。　

-sPping扫描：有时你只是想知道此时网络上哪些主机正在运行。通过向你指定的网络内的每个IP地址发送ICMPecho请求数据包，nmap就可以完成这项任务。如果主机正在运行就会作出响应。不幸的是，一些站点例如：microsoft.com阻塞ICMPecho请求数据包。然而，在默认的情况下nmap也能够向80端口发送TCPack包，如果你收到一个RST包，就表示主机正在运行。nmap使用的第三种技术是：发送一个SYN包，然后等待一个RST或者SYN/ACK包。对于非root用户，nmap使用connect()方法。在默认的情况下(root用户)，nmap并行使用ICMP和ACK技术。注意，nmap在任何情况下都会进行ping扫描，只有目标主机处于运行状态，才会进行后续的扫描。如果你只是想知道目标主机是否运行，而不想进行其它扫描，才会用到这个选项。

-sUUDP扫描：如果你想知道在某台主机上提供哪些UDP(用户数据报协议,RFC768)服务，可以使用这种扫描方法。nmap首先向目标主机的每个端口发出一个0字节的UDP包，如果我们收到端口不可达的ICMP消息，端口就是关闭的，否则我们就假设它是打开的。有些人可能会想UDP扫描是没有什么意思的。但是，我经常会想到最近出现的solarisrpcbind缺陷。rpcbind隐藏在一个未公开的UDP端口上，这个端口号大于32770。所以即使端口111(portmap的众所周知端口号)被防火墙阻塞有关系。但是你能发现大于30000的哪个端口上有程序正在监听吗?使用UDP扫描就能！cDcBackOrifice的后门程序就隐藏在Windows主机的一个可配置的UDP端口中。不考虑一些通常的安全缺陷，一些服务例如:snmp、tftp、NFS使用UDP协议。不幸的是，UDP扫描有时非常缓慢，因为大多数主机限制ICMP错误信息的比例(在RFC1812中的建议)。例如，在Linux内核中(在net/ipv4/icmp.h文件中)限制每4秒钟只能出现80条目标豢纱锏肾CMP消息，如果超过这个比例，就会给1/4秒钟的处罚。solaris的限制更加严格，每秒钟只允许出现大约2条ICMP不可达消息，这样，使扫描更加缓慢。nmap会检测这个限制的比例，减缓发送速度，而不是发送大量的将被目标主机丢弃的无用数据包。不过Micro$oft忽略了RFC1812的这个建议，不对这个比例做任何的限制。所以我们可以能够快速扫描运行Win95/NT的主机上的所有65K个端口。

-sAACK扫描：这项高级的扫描方法通常用来穿过防火墙的规则集。通常情况下，这有助于确定一个防火墙是功能比较完善的或者是一个简单的包过滤程序，只是阻塞进入的SYN包。这种扫描是向特定的端口发送ACK包(使用随机的应答/序列号)。如果返回一个RST包，这个端口就标记为unfiltered状态。如果什么都没有返回，或者返回一个不可达ICMP消息，这个端口就归入filtered类。注意，nmap通常不输出unfiltered的端口，所以在输出中通常不显示所有被探测的端口。显然，这种扫描方式不能找出处于打开状态的端口。

-sW对滑动窗口的扫描：这项高级扫描技术非常类似于ACK扫描，除了它有时可以检测到处于打开状态的端口，因为滑动窗口的大小是不规则的，有些操作系统可以报告其大小。这些系统至少包括：某些版本的AIX、Amiga、BeOS、BSDI、Cray、Tru64UNIX、DG/UX、OpenVMS、DigitalUNIX、OpenBSD、OpenStep、QNX、Rhapsody、SunOS4.x、Ultrix、VAX、VXWORKS。从nmap-hackers邮件3列表的文档中可以得到完整的列表。

-sRRPC扫描。这种方法和nmap的其它不同的端口扫描方法结合使用。选择所有处于打开状态的端口向它们发出SunRPC程序的NULL命令，以确定它们是否是RPC端口，如果是，就确定是哪种软件及其版本号。因此你能够获得防火墙的一些信息。诱饵扫描现在还不能和RPC扫描结合使用。

-bFTP反弹攻击(bounceattack):FTP协议(RFC959)有一个很有意思的特征，它支持代理FTP连接。也就是说，我能够从evil.com连接到FTP服务器target.com，并且可以要求这台FTP服务器为自己发送Internet上任何地方的文件！1985年，RFC959完成时，这个特征就能很好地工作了。然而，在今天的Internet中，我们不能让人们劫持FTP服务器，让它向Internet上的任意节点发送数据。如同Hobbit在1995年写的文章中所说的，这个协议"能够用来做投递虚拟的不可达邮件和新闻，进入各种站点的服务器,填满硬盘，跳过防火墙，以及其它的骚扰活动，而且很难进行追踪"。我们可以使用这个特征，在一台代理FTP服务器扫描TCP端口。因此，你需要连接到防火墙后面的一台FTP服务器，接着进行端口扫描。如果在这台FTP服务器中有可读写的目录，你还可以向目标端口任意发送数据(不过nmap不能为你做这些)。传递给-b功能选项的参数是你要作为代理的FTP服务器。语法格式为：-busername:password@server:port。除了server以外，其余都是可选的。如果你想知道什么服务器有这种缺陷，可以参考我在Phrack51发表的文章。还可以在nmap的站点得到这篇文章的最新版本。

通用选项这些内容不是必需的，但是很有用。

-P0在扫描之前，不必ping主机。有些网络的防火墙不允许ICMPecho请求穿过，使用这个选项可以对这些网络进行扫描。microsoft.com就是一个例子，因此在扫描这个站点时，你应该一直使用-P0或者-PT80选项。

-PT扫描之前，使用TCPping确定哪些主机正在运行。nmap不是通过发送ICMPecho请求包然后等待响应来实现这种功能，而是向目标网络(或者单一主机)发出TCPACK包然后等待回应。如果主机正在运行就会返回RST包。只有在目标网络/主机阻塞了ping包，而仍旧允许你对其进行扫描时，这个选项才有效。对于非root用户，我们使用connect()系统调用来实现这项功能。使用-PT来设定目标端口。默认的端口号是80，因为这个端口通常不会被过滤。

-PS对于root用户，这个选项让nmap使用SYN包而不是ACK包来对目标主机进行扫描。如果主机正在运行就返回一个RST包(或者一个SYN/ACK包)。

-PI设置这个选项，让nmap使用真正的ping(ICMPecho请求)来扫描目标主机是否正在运行。使用这个选项让nmap发现正在运行的主机的同时，nmap也会对你的直接子网广播地址进行观察。直接子网广播地址一些外部可达的IP地址，把外部的包转换为一个内向的IP广播包，向一个计算机子网发送。这些IP广播包应该删除，因为会造成拒绝服务攻击(例如smurf)。

winpcap 能不能只捕获网卡收到的数据包,而不捕获网卡自己发送的数据包啊?

esolutionProtocol）地址解析协议用于将计算机的网络地址（IP地址32位）转化为物理地址（MAC地址48位）[RFC826]。ARP协议是属于链路层的协议，在以太网中的数据帧从一个主机到达网内的另一台主机是根据48位的以太网地址（硬件地址）来确定接口的，而不是根据32位的IP地址。内核（如驱动）必须知道目的端的硬件地址才能发送数据。当然，点对点的连接是不需要ARP协议的。

ARP协议的数据结构：

typedefstructarphdr

{

unsignedshortarp_hrd;/*硬件类型*/

unsignedshortarp_pro;/*协议类型*/

unsignedchararp_hln;/*硬件地址长度*/

unsignedchararp_pln;/*协议地址长度*/

unsignedshortarp_op;/*ARP操作类型*/

unsignedchararp_sha[6];/*发送者的硬件地址*/

unsignedlongarp_spa;/*发送者的协议地址*/

unsignedchararp_tha[6];/*目标的硬件地址*/

unsignedlongarp_tpa;/*目标的协议地址*/

}ARPHDR,*PARPHDR;

为了解释ARP协议的作用，就必须理解数据在网络上的传输过程。这里举一个简单的PING例子。

假设我们的计算机IP地址是192.168.1.1，要执行这个命令：ping192.168.1.2。该命令会通过ICMP协议发送ICMP数据包。该过程需要经过下面的步骤：

1、应用程序构造数据包，该示例是产生ICMP包，被提交给内核（网络驱动程序）；

2、内核检查是否能够转化该IP地址为MAC地址，也就是在本地的ARP缓存中查看IP-MAC对应表；

3、如果存在该IP-MAC对应关系，那么跳到步骤9；如果不存在该IP-MAC对应关系，那么接续下面的步骤；

4、内核进行ARP广播，目的地的MAC地址是FF-FF-FF-FF-FF-FF，ARP命令类型为REQUEST（1），其中包含有自己的MAC地址；

5、当192.168.1.2主机接收到该ARP请求后，就发送一个ARP的REPLY（2）命令，其中包含自己的MAC地址；

6、本地获得192.168.1.2主机的IP-MAC地址对应关系，并保存到ARP缓存中；

7、内核将把IP转化为MAC地址，然后封装在以太网头结构中，再把数据发送出去；

使用arp-a命令就可以查看本地的ARP缓存内容，所以，执行一个本地的PING命令后，ARP缓存就会存在一个目的IP的记录了。当然，如果你的数据包是发送到不同网段的目的地，那么就一定存在一条网关的IP-MAC地址对应的记录。

知道了ARP协议的作用，就能够很清楚地知道，数据包的向外传输很依靠ARP协议，当然，也就是依赖ARP缓存。要知道，ARP协议的所有操作都是内核自动完成的，同其他的应用程序没有任何关系。同时需要注意的是，ARP协议只使用于本网络。

ARP协议的利用和相关原理介绍。

一、交换网络的嗅探

ARP协议并不只在发送了ARP请求才接收ARP应答。当计算机接收到ARP应答数据包的时候，就会对本地的ARP缓存进行更新，将应答中的IP和MAC地址存储在ARP缓存中。因此，在上面的假设网络中，B向A发送一个自己伪造的ARP应答，而这个应答中的数据为发送方IP地址是192.168.10.3（C的IP地址），MAC地址是DD-DD-DD-DD-DD-DD（C的MAC地址本来应该是CC-CC-CC-CC-CC-CC，这里被伪造了）。当A接收到B伪造的ARP应答，就会更新本地的ARP缓存，将本地的IP-MAC对应表更换为接收到的数据格式，由于这一切都是A的系统内核自动完成的，A可不知道被伪造了。

ARP欺骗的主要用途就是进行在交换网络中的嗅探。有关交换网络的嗅探不是本文的讨论内容。

二、IP地址冲突

我们知道，如果网络中存在相同IP地址的主机的时候，就会报告出IP地址冲突的警告。这是怎么产生的呢？

比如某主机B规定IP地址为192.168.0.1，如果它处于开机状态，那么其他机器A更

改IP地址为192.168.0.1就会造成IP地址冲突。其原理就是：主机A在连接网络（或更改IP地址）的时候就会向网络发送ARP包广播自己的IP地址，也就是freearp。如果网络中存在相同IP地址的主机B，那么B就会通过ARP来reply该地址，当A接收到这个reply后，A就会跳出IP地址冲突的警告，当然B也会有警告。

因此用ARP欺骗可以来伪造这个ARPreply，从而使目标一直遭受IP地址冲突警告的困扰。

三、阻止目标的数据包通过网关

比如在一个局域网内通过网关上网，那么连接外部的计算机上的ARP缓存中就存在网关IP-MAC对应记录。如果，该记录被更改，那么该计算机向外发送的数据包总是发送到了错误的网关硬件地址上，这样，该计算机就不能够上网了。

这里也主要是通过ARP欺骗进行的。有两种办法达到这样的目的。

1、向目标发送伪造的ARP应答数据包，其中发送方的IP地址为网关的地址，而MAC地址则为一个伪造的地址。当目标接收到该ARP包，那么就更新自身的ARP缓存。如果该欺骗一直持续下去，那么目标的网关缓存一直是一个被伪造的错误记录。当然，如果有些了解的人查看ARP-a，就知道问题所在了。

2、这种方法非常狠，欺骗网关。向网关发送伪造的ARP应答数据包，其中发送方的IP地址为目标的IP地址，而MAC地址则为一个伪造的地址。这样，网关上的目标ARP记录就是一个错误的，网关发送给目标的数据报都是使用了错误的MAC地址。这种情况下，目标能够发送数据到网关，却不能接收到网关的任何数据。同时，目标自己查看ARP-a却看不出任何问题来。

四、通过ARP检测混杂模式节点

在混杂模式中，网卡进行包过滤不同于普通模式。本来在普通模式下，只有本地地址的数据包或者广播（多播等）才会被网卡提交给系统核心，否则的话，这些数据包就直接被网卡抛弃。现在，混合模式让所有经过的数据包都传递给系统核心，然后被sniffer等程序利用。

通过特殊设计的ARP请求可以用来在一定程度上检测处于混杂模式的节点，比如对网络中的每个节点都发送MAC地址为FF-FF-FF-FF-FF-FE的ARP请求。对于网卡来说这不是一个广播地址（FF-FF-FF-FF-FF-FF），所以处于普通模式的节点就会直接抛弃该数据包，但是多数操作系统核心都认为这是一个广播地址，如果有一般的sniffer程序存在，并设置网卡为混杂模式，那么系统核心就会作出应答，这样就可以判断这些节点是否存在嗅探器了。

可以查看，很多基于ARP的攻击都是通过ARP欺骗实现的。至于ARP欺骗的防范，还是尽可能使用静态的ARP。对于WIN，使用arp-s来进行静态ARP的设置。当然，如果能够完全使用静态的IP+MAC对应，就更好了，因为静态的ARP缓存只是相对的。

当然，可以有一些方法来实现ARP欺骗的检测。设置一个ARP的嗅探器，其中维护着一个本地网络的IP-MAC地址的静态对应表，查看所有经过的ARP数据，并检查其中的IP-MAC对应关系，如果捕获的IP-MAC对应关系和维护的静态对应关系对应不上，那么就表明是一个欺骗的ARP数据包了。

一个ARP数据包发送程序源代码和编译好的EXE程序可以参考ARPSender程序。注意：需要先安装WinPcap。

协议分析六类常见错误

协议分析器是网络管理员库中最强有力的工具之一。它能将难处理、耗时长、让CEO们感到恼火甚至不得不重启所有机器的问题转变为能短时处理、易于在每周例行状态报告中反映的问题，为公司省下大量的时间与金钱。

然而，就像其它任何复杂工具一样，它必须被适当运用才能获得最大的效益。在使用协议分析器诊断网络故障时，应当尽量避免……

错误1分析器误置

正确放置分析器对快速诊断故障具有决定性作用。设想分析器是置于网络中的窗口，犹如建筑物窗口一般，视野的改变依赖于从哪个窗口看出去。从南面窗口望去是看不到建筑物北面高速公路上交通的拥挤状况的。在分析置于网络不当位置的分析器时，跟踪往往要花很长时间。那么，怎样正确放置分析器呢？我们可以举例说明。

以下为几个可能出现的问题及原因分析：

设想A：一台主机，服务器A，主机不能与其它任何主机通信。可能的原因：

1）服务器A没有正确配置；

2）服务器A配置的网卡出错；

3）服务器A所在局域网出了问题；

4）服务器A所在局域网段出错。

设想B：一台主机，服务器B，主机不能与远程网X中的任何一台主机通信；且局域网或其它远程网中的主机无任何故障（这就意味着问题不可能出现在服务器B或服务器B所在局域网段上）。

可能原因：

1）服务器B有关网络X的部分配置错误；

2）服务器B用于连接到网络X的路由器所在网段的连接出了问题；

3）服务器B所在局域网与网络X的一处或多处链接出了问题；

4）网络X用于连接到服务器B所在网络的路由器所在网段出了问题；

5）网络X出了问题。

设想C：一台主机，服务器C，主机不能与局域网中另一主机通信，但与网络中其它主机通信正常（这意味着问题不可能出现在服务器C或服务器C所在局域网段）。

可能的原因：

1）主机C错误配置；

2）主机C网卡出现故障；

3）主机C所在局域网段出了问题。

设想D：一台主机，服务器D，主机不能与一远程主机通信，但与服务器D所在局域网段的其它主机通信正常，到远程网或远程网自身的连接亦无故障。

可能原因：

1）主机D错误配置；

2）主机D网卡出错；

3）主机D所在局域网段出了问题。

这些问题当中个别的不用分析器也可诊断或排除。例如：设想A中的第三种情况，就能通过检查服务器A所在局域网的其它主机决定故障所在；设想D中的第二和第三种情况亦能通过这种方法确定（假设主机D能与局域网中其它主机通信）。

一台服务器或主机的错误配置通过检测很容易被发现。但另外一些问题，像网络或网段中的故障，就需要分析器来诊断。

在以上所有可能的设想中，一开始或许会将分析器置于离最有可能出现问题的主机或是怀疑有问题的网络、网段尽可能近的地方，但是如果未发现有意义的问题，得准备好移动分析器，要知道，在出现故障的位置被确定以前，所做的一切都是建立在猜想基础上的。在以上设想B的第三种情况中，服务器B所在局域网和网络X中都应该有分析器，至少分析器应该能够从一端被移动到另一端。

例如，一次故障中，一台服务器突然停止了工作。人们起初怀疑是站点人员对服务器实施了误操作所致，实际上跟踪器表明，是因为众多主机向服务器发送连接请求信息的同时服务器却没有响应，致使服务器死锁。

在花了几天时间来判断到底服务器出了什么问题后，被告知观察跟踪器，于是请求站点操作员将跟踪器从主机所在局域网（这里指设想B中第三种情况的网络X）移到服务器所在局域网。结果发现访问控制列表没有被正确添加到服务器所在局域网的路由器上，这份错误的访问控制列表过滤了所有来源于客户端主机所在网络的信息。假若当初多一些怀疑的话，就会发现在服务器所在局域网中根本就没见到过连接请求信息。因为没有同时查看网络两端的情况，致使站点很多天不能工作。

怎么知道跟踪器在网络的哪一端起作用呢？在跟踪器中，发自客户端主机的帧信息都具有实客户端所有的源MAC地址，与此同时，目标MAC地址则存放在路由器中。

不幸的是，问题变得越来越复杂，仅仅知道分析器连接于哪个网络还不够。当将一个局域网分解成多个部分时，首要的是去找到空闲Hub端口或同轴电缆的分接头，然而，在网络交换环境下，并不是仅仅将分析器接入交换设备的空闲端口就万事大吉了。

大多数交换设备都具备将特定端口指定为分接头或映像端口的能力，只是所用术语因交换设备制造厂商不同而有别。如果所有来自或发往特定端口的通信同样能发送到映像端口，这时只要将分析器连接到映像端口，所有设置即告完成。

但问题在于有些交换设备不能将两端口之间的通信发送到映像端口。举例说，在双工环境下，作为监控的连接之一部分的两台主机能同时发送信息，交换机也能接收每帧数据并将其传输到链接中的另外端口。但对于映像端口，必须对某一数据帧进行缓冲，如果这样处理了太多帧，缓冲区就会溢出，数据帧就会丢失，跟踪因此变得不可靠。更糟的是，根本就不知道是在跟踪不可靠的线索。

某些交换设备支持内部分析器功能，这类交换机本身能够俘获传向被跟踪对象的数据帧。这种功能部件的可靠性依赖于交换机的缓冲容量。在某些情况下，我们不得不选择映像端口或是内部分析器方式。但只要有可能，最好是将主机之一和分析器连接到Hub，并将Hub挂到交换机上。

为什么这么做呢？这是因为即使确信交换机有足够容量缓存所有数据帧，以至于映像端口或内部分析器不可能丢数据，跟踪仍然是不可靠的。例如，标准以太网中，一个处于交换机有故障端口的RJ45连接器每当交换机向服务器传输数据帧时都会创建交互式会话，交换机将此解释成为一次冲突并停止工作，当尝试16次之后数据帧就会撤消，但数据帧仍被发送到映像端口，因此跟踪器发现了数据帧并显示服务器响应失败。另一种情况是：不合规格的配线导致1%的数据帧破坏。如果将分析器与第一种情况（任何位置的数据帧都能传送）中提到的的主机一起挂到Hub，或者与第二种情况（网络中有被破坏的数据帧）中主机一起挂到Hub，接收交换机的端口会在未将数据帧发往映像端口之前就将它们撤消，跟踪器没有任何错误指示。当然，每当改变一种方式，都得冒一定风险来纠正可能出现的意外问题。如果RJ45连接器出现故障仅仅是因为没有在交换机端口将其固定好，那么只要将连接器重新插入Hub，故障或许也就不存在了，至少问题是得到了解决。

另外需要记住的是，对于交换设备，在其网段内每个端口都是有效的，因此当连接到服务器的交换端口未发现问题时，应将Hub（或分析器）移动到主机或路由器交换端口。

还有，注意不能将Hub挂到双工环境。有些分析器能以双工方式工作，这类分析器有两个以太网口和一个功能模块，功能模块将通信对分为两部分，并分别发送到每一以太网口，之后软件把从每个以太网口接收来的数据结合成单一的跟踪链。如果网络是双工环境，就需要这种分析器。

错误2过多的过滤

过滤功能允许协议分析器忽略某些数据帧，从而为感兴趣的帧腾出更多的俘获缓冲空间。如果能过滤来源于较高协议层的数据，如IP地址和端口号以至更高层数据，则分析器几乎很少需要基于源或目标MAC地址的过滤。然而，实际跟踪中通常出现的问题是过滤太多。

有一个站点出现过这样的故障：服务器与一特定客户端之间的连接出了问题，莫名其妙地断开了，其它客户端都没有任何问题。由于客户端与服务器处在同一子网，一旦发生断开现象，使客户端与服务器恢复连接的唯一办法是重新启动服务器。

这个站点安装了分析器，同时因为数据量大，配置了过滤器，只允许俘获两主机（基于MAC地址）之间的数据帧。前两天中没有发现问题，但在第三天问题出现了：跟踪表明服务器突然停止了发送多路会话和最后一次会话。当从服务器端ping客户端时，跟踪器显示服务器没有发送任何数据帧。站点操作员得出的结论是：TCP栈或操作系统出了问题。

于是请求另一次跟踪，这次没有使用过滤器。一天半以后俘获了另一事件：跟踪清楚表明服务器持续发送数据，而与此同时却再也没有得到应答。经过更深层挖掘，发现服务器数据帧的目标MAC地址突然改变了。

既然目标MAC地址不再与客户端的相匹配，那么第一次未使用过滤器的跟踪就不再俘获到MAC地址，同时表明服务器已停止了工作。另外发现就在地址改变之前，服务器无故收到带有为客户端IP地址配置的新MAC地址的ARP信息包，这导致服务器升级ARP缓存并向错误主机发送数据。

通过ARP数据帧的源MAC地址由无故发送ARP的主机向下跟踪，不知何故，主机居然同时配置了复用于客户端的静态IP地址和DHCP地址。当主机启动时，分配的是静态地址，这与服务器相冲突，于是调用DHCP，正确地址才配置上。

基于这一点可得出这样一个结论：用过滤器看似很有道理，但很多时候问题的根源往往以假象出现在过滤器之外，如果跟踪器没有表明问题的起因，过滤器应当关闭，或至少应当扩展一下，直至跟踪器确实查出原因。仅当所有过滤器都关闭后跟踪器仍无法查出问题起因，才可以得出结论——对网络已无计可施了。

错误3

俘获时帧太短

前面例子中表明，站点操作员使用过滤器是因为网络中数据量过大。分析器仅能俘获大约3分钟时间的数据，这使得站点操作员几乎不可能发现问题的发生并使分析器及时加以阻止以真正找到问题的起因。分析器能够俘获数据帧而没有将它们填入俘获缓冲区的时间长短取决于网络的速度、网络中帧的数量、帧的大小以及俘获缓冲区的大小。

几乎所有分析器都能控制俘获数据帧的大小，这在处理连接问题和不太高协议层问题时显得很有用。在通常情况下，只要俘获数据的第一个64字节也就足够了。因此，如果网络中所有帧都是1024字节而仅有3分钟俘获时间，那么仅俘获64字节将允许有超过30分钟的俘获时间。

错误4

触发器安装不正确

触发器告诉分析器执行某项操作，比如终止俘获。当等待问题发生而又不知道将何时发生时，触发器显得很有用。

安装触发器意味着没有必要随时以手动方式来控制分析器。触发器安装的最大问题往往是没有正确定义，这会大大延长解决问题的时间。

当然，应该详细知道怎样安装触发器，并且，若有可能，在使用之前进行测试。有时可以安装另一台分析器来发送触发数据帧，以确认俘获分析触发器已正确安装。

使用触发器带来的另一问题是，许多分析器允许设置将被预触发的俘获缓冲区的百分比。举例来说，可以指定50%的缓冲区在触发之前俘获，而另外50%的缓冲区在触发之后俘获。预触发的百分比通常是0、25、50、75或100。

如果预触发值设置不当，就有可能俘获不到足够的相关数据帧来诊断问题所在。预触发值有可能被错误设置是因为其默认设置对现行问题往往不适用：也许是因为未将针对前一问题的设置升级，也许是因为粗心的鼠标操作或错误按键。无论何种原因，一定要确认触发器已正确安装。

那么怎样来设置呢？通常是将预触发百分比设为100%，以知道是什么原因导致触发器关闭。

当然，只有当触发器在触发某事件时，它才处于关闭状态。过去使用过特殊的触发程序，它能测试状态，然后发送信息包，分析器可将此信息包用作触发器。测试状态可以是日志文件中的错误信息，或是上例中无法创建连接的情况。一般整个程序也就一百多行或稍长一些。

错误5

日期/时间设置不正确

没有正确设置分析器上的日期/时间看似一件小事，很多时候可能也确实是这样。然而，当处理广域网络中的问题时，有时同时运行两台分析器，网络每端一台，则正确设置日期/时间是相当有用的。

如果将两台分析器时钟设置相同，调整跟踪会变得更为容易。假定在一个例子中，通过发现通用帧并比较时间，会发现其中一台用了4小时37分，比另一台提前了15.7891秒，如果时钟设置同步误差在1到2秒，时间差距计算也就容易多了。

另外，如果需要费劲地随主机中的事件调整跟踪，由于基于时间包的同步是不可选的，则设置相同的日期/时间绝对具有实质意义。

错误6不理解协议

很多分析器具有“专家分析”功能，指的是它们能保持对信息的追踪，像序列号、时间信息、显示重传信息、冻结窗口、无应答状态等等。这类分析相当有用，但也有可能造成误导，尤其在分析器没有正确报错时。

举个例子，有一种情况：从一远程位置发来的远程登录会话无法建立，而发自局域工作站的远程登录会话却没有问题。于是站点操作人员在远程登录服务器所在的局域网挂一分析器，跟踪器表明从远程主机到远程登录服务器的数据帧没有报错；于是他们得出结论是操作系统故障。

另一位操作人员查看跟踪器发现，局域端远程登录会话连接到端口2323，而远程会话连接到端口23。另外，远程登录服务器响应远程连接请求的信息包包含了RST标志设置。

在这里，站点操作人员没有仔细查看TCP细节，因此没有意识到不同端口号和RST包的重要性，他们依赖来源于分析器的诊断信息，既然远程登录服务器的端口23没有安装，凭感觉猜想也认为是操作系统出了问题。然而，若站点工作人员了解TCP和远程登录，他们就会立即发现问题所在并能在5分钟内找到一个好的解决办法。

事实上是，他们等半天时间来安装跟踪器，结果失去了远程网上数目相当可观的客户。

求syn扫描的源代码及操作系统探测的相关资料

详解SYN Flood攻击原理与防范

SYN Flood是当前最流行的DoS(拒绝服务攻击)与DDoS(分布式拒绝服务攻击)的方式之一，它是利用TCP协议缺陷，发送大量伪造的TCP连接请求，从而使得被攻击方资源耗尽(CPU满负荷或内存不足)的攻击方式……

SYN Flood的基本原理

SYN Flood是当前最流行的DoS(拒绝服务攻击)与DDoS(分布式拒绝服务攻击)的方式之一，它是利用TCP协议缺陷，发送大量伪造的TCP连接请求，从而使得被攻击方资源耗尽(CPU满负荷或内存不足)的攻击方式，最终导致系统或服务器宕机。

在讨论SYN Flood原理前，我们需要从TCP连接建立的过程开始说起：

TCP与UDP不同，它是基于连接的，为了在服务端和客户端之间传送TCP数据，必须先建立一个虚拟电路，也就是TCP连接。也就是我们经常听说的TCP协议中的三次握手（Three-way Handshake），建立TCP连接的标准过程如下：

首先，客户端发送一个包含SYN标志的TCP报文，SYN即同步（Synchronize），同步报文会指明客户端使用的端口以及TCP连接的初始序号;

其次，服务器在收到客户端的SYN报文后，将返回一个SYN+ACK（即确认Acknowledgement）的报文，表示客户端的请求被接受，同时TCP初始序号自动加一。

最后，客户端也返回一个确认报文ACK给服务器端，同样TCP序列号被加一，到此一个TCP连接完成。

SYN Flood攻击正是利用了TCP连接的三次握手，假设一个用户向服务器发送了SYN报文后突然死机或掉线，那么服务器在发出SYN+ACK应答报文后是无法收到客户端的ACK报文的(第三次握手无法完成)，这种情况下服务器端一般会重试(再次发送SYN+ACK给客户端)并等待一段时间后丢弃这个未完成的连接，这段时间的长度我们称为SYN Timeout，一般来说这个时间是分钟的数量级(大约为30秒-2分钟)；一个用户出现异常导致服务器的一个线程等待1分钟并不会对服务器端造成什么大的影响，但如果有大量的等待丢失的情况发生，服务器端将为了维护一个非常大的半连接请求而消耗非常多的资源。我们可以想象大量的保存并遍历也会消耗非常多的CPU时间和内存，再加上服务器端不断对列表中的IP进行SYN+ACK的重试，服务器的负载将会变得非常巨大。如果服务器的TCP/IP栈不够强大，最后的结果往往是堆栈溢出崩溃。相对于攻击数据流，正常的用户请求就显得十分渺小，服务器疲于处理攻击者伪造的TCP连接请求而无暇理睬客户的正常请求，此时从正常客户会表现为打开页面缓慢或服务器无响应，这种情况就是我们常说的服务器端SYN Flood攻击(SYN洪水攻击)。

从防御角度来讲，存在几种的解决方法：

第一种是缩短SYN Timeout时间，由于SYN Flood攻击的效果取决于服务器上保持的SYN半连接数，这个值=SYN攻击的频度 x SYN Timeout，所以通过缩短从接收到SYN报文到确定这个报文无效并丢弃改连接的时间，例如设置为20秒以下，可以成倍的降低服务器的负荷。但过低的SYN Timeout设置可能会影响客户的正常访问。

第二种方法是设置SYN Cookie，就是给每一个请求连接的IP地址分配一个Cookie，如果短时间内连续受到某个IP的重复SYN报文，就认定是受到了攻击，并记录地址信息，以后从这个IP地址来的包会被一概丢弃。这样做的结果也可能会影响到正常用户的访问。

上述的两种方法只能对付比较原始的SYN Flood攻击，缩短SYN Timeout时间仅在对方攻击频度不高的情况下生效，SYN Cookie更依赖于对方使用真实的IP地址，如果攻击者以数万/秒的速度发送SYN报文，同时利用SOCK_RAW随机改写IP报文中的源地址，以上的方法将毫无用武之地。

SYN Flood是当前最流行的DoS(拒绝服务攻击)与DDoS(分布式拒绝服务攻击)的方式之一，它是利用TCP协议缺陷，发送大量伪造的TCP连接请求，从而使得被攻击方资源耗尽(CPU满负荷或内存不足)的攻击方式……

SYN Flooder源码解读

下面我们来分析SYN Flooder的程序实现。

首先，我们来看一下TCP报文的格式：

0 1 2 3 4 5 6

0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| IP首部 | TCP首部 | TCP数据段 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

图一 TCP报文结构

如上图所示，一个TCP报文由三个部分构成：20字节的IP首部、20字节的TCP首部与不定长的数据段，实际操作时可能会有可选的IP选项，这种情况下TCP首部向后顺延，由于我们只是发送一个SYN信号，并不传递任何数据，所以TCP数据段为空。TCP首部的数据结构为：

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| 十六位源端口号 | 十六位目标端口号 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| 三十二位序列号 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| 三十二位确认号 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| 四位 | |U|A|P|R|S|F| |

| 首部 |六位保留位 |R|C|S|S|Y|I| 十六位窗口大小 |

| 长度 | |G|K|H|T|N|N| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| 十六位校验和 | 十六位紧急指针 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| 选项(若有) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| 数据(若有) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

图二 TCP首部结构

根据TCP报文格式，我们定义一个结构TCP_HEADER用来存放TCP首部：

typedef struct _tcphdr

{

USHORT th_sport; //16位源端口

USHORT th_dport; //16位目的端口

unsigned int th_seq; //32位序列号

unsigned int th_ack; //32位确认号

unsigned char th_lenres; //4位首部长度+6位保留字中的4位

unsigned char th_flag; //2位保留字+6位标志位

USHORT th_win; //16位窗口大小

USHORT th_sum; //16位校验和

USHORT th_urp; //16位紧急数据偏移量

}TCP_HEADER;

通过以正确的数据填充这个结构并将TCP_HEADER.th_flag赋值为2(二进制的00000010)我们能制造一个SYN的TCP报文，通过大量发送这个报文可以实现SYN Flood的效果。但是为了进行IP欺骗从而隐藏自己，也为了躲避服务器的SYN Cookie检查，还需要直接对IP首部进行操作：

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| 版本 | 长度 | 八位服务类型 | 十六位总长度 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| 十六位标识 | 标志| 十三位片偏移 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| 八位生存时间 | 八位协议 | 十六位首部校验和 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| 三十二位源IP地址 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| 三十二位目的IP地址 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| 选项(若有) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| 数据 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

图三 IP首部结构

同样定义一个IP_HEADER来存放IP首部：

typedef struct _iphdr

{

unsigned char h_verlen; //4位首部长度+4位IP版本号

unsigned char tos; //8位服务类型TOS

unsigned short total_len; //16位总长度(字节)

unsigned short ident; //16位标识

unsigned short frag_and_flags; //3位标志位

unsigned char ttl; //8位生存时间 TTL

unsigned char proto; //8位协议号(TCP, UDP 或其他)

unsigned short checksum; //16位IP首部校验和

unsigned int sourceIP; //32位源IP地址

unsigned int destIP; //32位目的IP地址

}IP_HEADER;

然后通过SockRaw=WSASocket(AF_INET,SOCK_RAW,IPPROTO_RAW,NULL,0,WSA_FLAG_OVERLAPPED);

建立一个原始套接口，由于我们的IP源地址是伪造的，所以不能指望系统帮我们计算IP校验和，我们得在在setsockopt中设置IP_HDRINCL告诉系统自己填充IP首部并自己计算校验和：

flag=TRUE;

setsockopt(SockRaw,IPPROTO_IP,IP_HDRINCL,(char *)flag,sizeof(int));

IP校验和的计算方法是：首先将IP首部的校验和字段设为0(IP_HEADER.checksum=0),然后计算整个IP首部(包括选项)的二进制反码的和，一个标准的校验和函数如下所示：

USHORT checksum(USHORT *buffer, int size)

{

unsigned long cksum=0;

while(size 1) {

cksum+=*buffer++;

size -=sizeof(USHORT);

}

if(size ) cksum += *(UCHAR*)buffer;

cksum = (cksum 16) + (cksum 0xffff);

cksum += (cksum 16);

return (USHORT)(~cksum);

}

这个函数并没有经过任何的优化，由于校验和函数是TCP/IP协议中被调用最多函数之一，所以一般说来，在实现TCP/IP栈时，会根据操作系统对校验和函数进行优化。

TCP首部检验和与IP首部校验和的计算方法相同，在程序中使用同一个函数来计算。

需要注意的是，由于TCP首部中不包含源地址与目标地址等信息，为了保证TCP校验的有效性，在进行TCP校验和的计算时，需要增加一个TCP伪首部的校验和，定义如下：

struct

{

unsigned long saddr; //源地址

unsigned long daddr; //目的地址

char mbz; //置空

char ptcl; //协议类型

unsigned short tcpl; //TCP长度

}psd_header;

然后我们将这两个字段复制到同一个缓冲区SendBuf中并计算TCP校验和：

memcpy(SendBuf,psd_header,sizeof(psd_header));

memcpy(SendBuf+sizeof(psd_header),tcp_header,sizeof(tcp_header));

tcp_header.th_sum=checksum((USHORT *)SendBuf,sizeof(psd_header)+sizeof(tcp_header));

计算IP校验和的时候不需要包括TCP伪首部：

memcpy(SendBuf,ip_header,sizeof(ip_header));

memcpy(SendBuf+sizeof(ip_header),tcp_header,sizeof(tcp_header));

ip_header.checksum=checksum((USHORT *)SendBuf, sizeof(ip_header)+sizeof(tcp_header));

再将计算过校验和的IP首部与TCP首部复制到同一个缓冲区中就可以直接发送了：

memcpy(SendBuf,ip_header,sizeof(ip_header));

sendto(SockRaw,SendBuf,datasize,0,(struct sockaddr*) DestAddr,sizeof(DestAddr));

因为整个TCP报文中的所有部分都是我们自己写入的，操作系统不会做任何干涉，所以我们可以在IP首部中放置随机的源IP地址，如果伪造的源IP地址确实有人使用，并有地址帮定时，在接收到服务器的SYN+ACK报文后会发送一个RST报文(标志位为00000100)，通知服务器端不需要等待一个无效的连接；但如果这个伪造IP并没有绑定在任何的主机上，不会有任何设备去通知主机该连接是无效的，这就是我们所广泛应用的TCP协议的SYN洪水攻击，主机将不断重复发送回执，直到SYN Timeout时间后才能丢弃这个无效的半连接。所以当攻击者使用主机分布很稀疏的IP地址段进行伪装IP的SYN Flood攻击时，服务器主机承受的负荷会相当的高，根据测试，一台奔3 128MB+100Mbps的机器，使用经过初步优化的SYN Flooder程序可以以16,000包/秒的速度发送TCP SYN报文，这样的攻击力已经足以拖垮大部分WEB服务器了。

善于思考的用户会发现，想对SYN Flooder程序进行优化是很简单的，从程序构架来看，攻击时循环内的代码主要是进行校验和计算与缓冲区的填充，一般的思路是提高校验和计算的速度，甚至精明的开发者会用汇编代码编写校验和函数。实际上，还存在一种可以轻松实现优化而又不需要高深的编程技巧和数学知识，我们仔细研究了两个不同源地址的TCP SYN报文后发现，两个报文的大部分字段相同(比如目的地址、协议等等)，只有源地址和校验和不同，如果我们事先计算好大量的源地址与校验和的对应关系表，等计算完毕后，攻击程序就只需要单纯的组合缓冲区，用指针来直接操作缓冲区的特定位置，从事先计算好的对应关系表中读出数据，替换缓冲区相应字段。这种简单的工作完全取决于系统发送IP包的速度，与程序的效率没有任何关系，这样即使是CPU主频较低的主机也能快速的发送大量TCP SYN攻击包。如果考虑到缓冲区拼接的时间，甚至可以定义一个很大的缓冲区数组，填充完毕后再发送。

SYN Flood是当前最流行的DoS(拒绝服务攻击)与DDoS(分布式拒绝服务攻击)的方式之一，它是利用TCP协议缺陷，发送大量伪造的TCP连接请求，从而使得被攻击方资源耗尽(CPU满负荷或内存不足)的攻击方式……

SYN Flood攻击的监测与防御初探

对于SYN Flood攻击，特别是DDos，目前尚没有很好的监测和防御方法，不过如果系统管理员熟悉攻击方法和系统架构，通过一系列的设定，可以在最大程度上降低被攻击系统的负荷，不会对系统的正常工作造成无法挽回的影响。如果一台主机负荷突然升高甚至失去响应，使用Netstat 命令能看到大量SYN_RCVD的半连接，可以认定，这台主机遭到了SYN Flood攻击。

遭到SYN Flood攻击后，首先要做的是取证，通过在命令行下使用 Netstat ?Cn ?Cp tcp resault.txt记录目前所有TCP连接状态是必要的，如果有嗅探器或TcpDump之类的工具，详细记录TCP SYN报文会更有助于追查和防御，需要记录的字段有：源地址、IP首部中的标识、TCP首部中的序列号、TTL值（Time to Life，生存周期）等，这些信息虽然很可能是攻击者伪造的，但是用来分析攻击攻击程序不无帮助。特别是TTL值，如果大量的攻击包似乎来自不同的IP但是TTL值却相同，我们往往能推断出攻击者与我们之间的路由器距离，至少也可以通过过滤特定TTL值的报文降低被攻击系统的负荷，确保TTL值与攻击报文不同的用户就可以恢复正常访问。

对于Win2000系统，还可以通过修改注册表降低SYN Flood的危害，在注册表中作如下改动：

首先，打开regedit，找到[HKEY_LOCAL_MACHINE\Sytem\CurrentControlSet\Services\Tcpip\Parameters]

增加一个SynAttackProtect的键值，类型为REG_DWORD，取值范围是0-2，这个值决定了系统受到SYN攻击时采取的保护措施，包括减少系统SYN+ACK的重试的次数等，默认值是0(没有任何保护措施)，推荐设置为2;

增加一个TcpMaxHalfOpen的键值，类型为REG_DWORD，取值范围是100-0xFFFF，这个值是系统允许同时打开的半连接数，默认情况下windows2000是100，ADVANCED SERVER版本的windows 2000是500，这个值很难确定，取决于服务器TCP负荷的状况和可能受到的攻击强度。具体的值需要经过管理员的尝试测试/预测一下访问峰值时期的半连接打开量，以其作为参考设定TcpMaxHalfOpenRetried的值，需要保留一定的余量，然后再以TcpMaxHalfOpenRetried的1.25倍作为TcpMaxHalfOpen值，这样可以最大限度地发挥windows 2000自身的SYN攻击保护机制。

增加一个TcpMaxHalfOpenRetried的键值，类型为REG_DWORD，取值范围是80-0xFFFF，默认情况下windows2000是80，ADVANCED SERVERwindows2000是400，这个值决定了在什么情况下系统会打开SYN攻击保护。

我们来分析一下windows 2000的SYN攻击保护机制：正常情况下，windows 2000对TCP连接的三次握手有一个常规的设置，包括SYN Timeout时间、SYN-ACK的重试次数和SYN报文从路由器到系统再到Winsock的延时等，这个常规设置是针对系统性能进行优化的，所以可以给用户提供方便快捷的服务；一旦服务器受到攻击，SYN半连接的数量超过TcpMaxHalfOpenRetried的设置，系统会认为自己受到了SYN Flood攻击，此时设置在SynAttackProtect键值中的选项开始作用，SYN Timeout时间被减短，SYN-ACK的重试次数减少，系统也会自动对缓冲区中的报文进行延时，避免对TCP/IP堆栈造成过大的冲击，力图将攻击危害减到最低;如果攻击强度不断增大，超过了TcpMaxHalfOpen值，此时系统已经不能提供正常的服务了，更重要的是保证系统不会崩溃，所以系统将会丢弃任何超出TcpMaxHalfOpen值范围的SYN报文(应该是使用随机丢包策略)，保证系统的稳定性。

通过设置注册表防御SYN Flood攻击，采用的是被动的策略，无论系统如何强大，始终不能靠被动的防护支撑下去，下面我们来看看另外一种比较有效的方法。

我称这种策略为“牺牲”策略，基于SYN Flood攻击代码的一个缺陷，我们重新来分析一下SYN Flood攻击者的流程：SYN Flood程序有两种攻击方式，基于IP的和基于域名的，前者是攻击者自己进行域名解析并将IP地址传递给攻击程序，后者是攻击程序自动进行域名解析，但是它们有一点是相同的，就是一旦攻击开始，将不会再进行域名解析，我们就是要利用这一点，假设一台服务器在受到SYN Flood攻击后迅速更换自己的IP地址，那么攻击者仍在不断攻击的只是一个空的IP地址，并没有任何主机，而管理员只需将DNS解析更改到新的IP地址就能在很短的时间内恢复用户通过域名进行的正常访问，这种做法取决于DNS的刷新时间。为了迷惑攻击者，我们甚至可以放置一台“牺牲”服务器，对攻击数据流进行牵引。

同样的原因，在众多的负载均衡架构中，基于DNS解析的负载均衡本身就拥有对SYN Flood的免疫力，基于DNS解析的负载均衡能将用户的请求分配到不同IP的服务器主机上，攻击者的一次攻击永远只能是其中一台服务器，虽然说攻击者也能不断去进行DNS请求来持续对用户的攻击，但是这样增加了攻击者的攻击强度，同时由于过多的DNS请求，可以帮助管理员查找到攻击者的地址，这主要是由于DNS请求需要返回数据，而这个数据是很难被伪装的。

如今DDOS攻击仍然没有彻底的解决方案，但各个厂商都在考虑将负载均衡、流量牵引以及带宽控制等技术综合利用，配合不断生机的包分析能力，甚至虚拟技术，力求将SYN Flood攻击降到最低点。让用户和我拭目以待新产品和新技术的诞生。

用verilog编写源代码和测试程序

下面的代码我已经用modelsim仿真过了，没有问题。

module count(out,clk,rst); //源程序

input clk,rst;

output[3:0] out;

reg[3:0] out;

initial out=4'd0;

always @(posedge clk or negedge rst)

begin

if(!rst) out=4'd0;

else

begin

out=out+4'd1;

if(out==4'd1||out==4'd6||out==4'd8) out=out+4'd1;

if(out==4'd5) out=out+4'd2;

end

end

endmodule

`timescale 1ns/1ns //测试程序

`include "count.v"

module count_tp;

reg clk,rst;

wire[3:0] out;

parameter DELY=100;

count mycount(out,clk,rst);

always #(DELY/2) clk=~clk;

initial

begin

clk=0;rst=1;

#(DELY*5) rst=0;

#DELY rst=1;

#(DELY*20) $finish;

end

initial $monitor($time,,,"clk=%d rst=%d out=%d",clk,rst,out);

endmodule

关于rst包源代码和rst数据包的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。