章节大纲

  • 在Ubuntu操作系统中，有针对ICMP重定向攻击的防范措施。在 docker-compose.yml 文件中，我们已经关闭了这种防范措施，也就是允许容器接受ICMP重定向消息。
    // 在docker-compose.yml
sysctls:
  - net.ipv4.conf.all.accept_redirects=1

// 要开启防护，请将其值设置为0
# sysctl net.ipv4.conf.all.accept_redirects=0
     
    对于本任务，我们将从攻击者容器对受害者的容器发起攻击。当前的配置中，受害者将使用路由器容器（192.168.60.11）作为通往 192.168.60.0/24 网络的路由器。如果在受害者的容器上运行 ip route，我们将看到以下内容:
    # ip route
default via 10.9.0.1 dev eth0
10.9.0.0/24 dev eth0 proto kernel scope link src 10.9.0.5
192.168.60.0/24 via (*@\textbf{10.9.0.11}@*) dev eth0
     
    代码框架。 我们提供了一个代码框架，学生们需要在标记为 @@@ 的地方填入正确的值。
    #!/usr/bin/python3

from scapy.all import *

ip = IP(src = @@@,  dst = @@@)
icmp = ICMP(type=@@@, code=@@@)
icmp.gw = @@@

# ICMP 重定向包必须携带触发它的那个原始IP数据包。
ip2 = IP(src = @@@, dst = @@@)
send(ip/icmp/ip2/ICMP());
     
    验证。 ICMP重定向消息不会影响路由表，而是会改变路由缓存。路由缓存中的条目比路由表中的条目优先级高，会被先用，直到过期为止。请使用以下命令显示和清理缓存内容。

    // 显示路由缓存
# ip route show cache
192.168.60.5 via 10.9.0.111 dev eth0
    cache <redirected> expires 296sec

// 清理路由缓存
# ip route flush cache

    请在受害者的机器上进行traceroute操作，看看数据包是否被重定向。
    # mtr -n 192.168.60.5
     
    注意事项： 如果我们伪造重定向包，但受害者的机器在攻击期间没有发送过ICMP数据包，则该攻击将不会成功。这是因为操作系统内核会在接受ICMP重定向消息之前进行一些类型的检查。它会验证该ICMP重定向是否由其自身发出的数据包触发，即它会检查重定向包内的 ip2。这种检查的严格程度取决于操作系统。

    对于 Ubuntu 20.04，内核只是验证重定向包中的 ip2 是否与触发ICMP重定向的实际数据包的类型和目的 IP 地址匹配。然而，如果你在苹果机器上进行此实验，你的虚拟机版本可能是 Ubuntu 22.04 或更高版本，检查会更加严格。要确保伪造包中的 ip2 能够通过检查，最简单的方法是从受害者的机器中捕获一个数据包。不过这并不是必要的。鼓励学生们使用其他方法进行攻击。