TCP 协议中 FLAG 的含义

TCP FLAG 标记

TCP标记和他们的意义如下所列：

• F：FIN - 结束；结束会话
• S：SYN - 同步；表示开始会话请求
• R：RST - 复位；中断一个连接
• P：PUSH - 推送；数据包立即发送
• A：ACK - 应答
• U：URG - 紧急
• E：ECE - 显式拥塞提醒回应
• W：CWR - 拥塞窗口减少

TCP连接的三次握手

一个虚拟连接的建立是通过三次握手来实现的，具体步骤如下：

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连接完成。

   注意： ACK 包就是仅 ACK 标记设为1的 TCP 包，需要注意的是当三次握手完成、连接建立以后，TCP 连接的每个包都会设置ACK位，这就是为何连接跟踪很重要的原因了。没有连接跟踪，防火墙将无法判断收到的 ACK 包是否属于一个已经建立的连接，一般的包过滤 (Ipchains) 收到 ACK 包时，会让它通过(这绝对不是个好主意)。而当状态型防火墙收到此种包时，它会先在连接表中查找是否属于哪个已建连接，否则丢弃该包。

TCP断开的四次挥手

四次握手用来关闭已建立的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 标记的包不是合法的包，并且通常被认为是恶意的 。

连接复位

四次握手不是关闭 TCP 连接的唯一方法。有时，如果主机需要尽快关闭连接 (或连接超时、端口或主机不可达)，RST (Reset) 包将被发送。

注意，由于 RST 包不是 TCP 连接中的必须部分，可以只发送 RST 包 (即不带 ACK 标记)，但在正常的 TCP 连接中 RST 包可以带 ACK 确认标记。

请注意 RST 包是可以不要接收方确认的?

无效的TCP标记

到目前为止，你已经看到了 SYN, ACK, FIN 和 RST 标记，另外，还有 PSH (Push) 和 URG (Urgent) 标记。

• 最常见的非法组合是 SYN/FIN 包，由于 SYN 包是用来初始化连接的，它不可能和 FIN 和 RST 标记一起出现，这是一个恶意攻击。
• 别的一些组合，例如 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 包。当你发现这些不正常的包时，肯定有人对你的网络不怀好意。

RST攻击

客户端 A 和服务器 B 之间建立了 TCP 连接，此时 C 伪造了一个 TCP 包发给 B，使 B 异常的断开了与 A 之间的 TCP 连接，就是 RST 攻击了。实际上从上面 RST 标志位的功能已经可以看出这种攻击如何达到效果了。

那么伪造什么样的 TCP 包可以达成目的呢？我们至顶向下的看。

假定 C 伪装成 A 发过去的包，这个包如果是 RST 包的话，毫无疑问，B 将会丢弃与 A 的缓冲区上所有数据，强制关掉连接。

如果发过去的包是 SYN 包，那么，B 会表示 A 已经发疯了（与OS的实现有关），正常连接时又来建新连接，B 主动向 A 发个 RST 包，并在自己这端强制关掉连接。

这两种方式都能够达到复位攻击的效果。似乎挺恐怖，然而关键是，如何能伪造成 A 发给 B 的包呢？这里有两个关键因素，源端口和序列号。

一个 TCP 连接都是四元组，由源IP、源端口、目标IP、目标端口唯一确定一个连接。所以，如果 C 要伪造 A 发给 B 的包，要在上面提到的 IP 头和 TCP 头，把源IP、源端口、目标IP、目标端口都填对。这里 B 作为服务器，IP 和端口是公开的，A 是我们要下手的目标，IP 当然知道，但 A 的源端口就不清楚了，因为这可能是 A 随机生成的。当然，如果能够对常见的 OS 如 windows 和 linux 找出生成 source port 规律的话，还是可以搞定的。

序列号问题是与滑动窗口对应的，伪造的 TCP 包里需要填序列号，如果序列号的值不在 A 之前向 B 发送时 B 的滑动窗口内，B 是会主动丢弃的。所以我们要找到能落到当时的 AB 间滑动窗口的序列号。这个可以暴力解决，因为一个 sequence 长度是32位，取值范围0-4294967296，如果窗口大小像上图中我抓到的 windows 下的65535的话，只需要相除，就知道最多只需要发65537 (4294967296 / 65535 = 65537) 个包就能有一个序列号落到滑动窗口内。RST 包是很小的，IP头＋TCP头也才40字节，算算我们的带宽就知道这只需要几秒钟就能搞定。

那么，序列号不是问题，源端口会麻烦点，如果各个操作系统不能完全随机的生成源端口，或者黑客们能通过其他方式获取到 source port，RST 攻击易如反掌，后果很严重。

RST攻击的防御

对付这种攻击通过防火墙简单设置就可以了。建议使用防火墙将进来的包带 RST 位的包丢弃就可以了。