![iptables 規則是否可以控制原始套接字封包?](https://rvso.com/image/776299/iptables%20%E8%A6%8F%E5%89%87%E6%98%AF%E5%90%A6%E5%8F%AF%E4%BB%A5%E6%8E%A7%E5%88%B6%E5%8E%9F%E5%A7%8B%E5%A5%97%E6%8E%A5%E5%AD%97%E5%B0%81%E5%8C%85%EF%BC%9F.png)
我使用的程式使用原始資料包模式產生一些 TCP 連線。假設我執行了這兩個命令:
/sbin/iptables -A INPUT -s 8.0.0.0/8 -j DROP
/sbin/iptables -A OUTPUT -d 8.0.0.0/8 -j DROP
可以安全地假設沒有資料包發送到該網路嗎?
答案1
不幸的是,它似乎不起作用。這是我檢查的方法。我們使用兩台伺服器 - 1.1.1.1 和 2.2.2.2。 1.1.1.1 將發送資料包,2.2.2.2 將偵聽。
首先,讓我們在 2.2.2.2 上設定嗅探:
➜ ~ sudo tcpdump -vv 'src 1.1.1.1'
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
現在,讓我們在連接埠 995 上向該 IP 發送資料包:
$ zmap --whitelist-file=<( echo 2.2.2.2 ) -p 995 -n 1
正如預期的那樣,我們在 2.2.2.2 上看到了來自 1.1.1.1 的流量:
11:18:49.330632 IP (tos 0x0, ttl 250, id 54321, offset 0, flags [none], proto TCP (6), length 40)
1.1.1.1.47495 > 2.2.2.2.pop3s: Flags [S], cksum 0x5e8a (correct), seq 4248475135, win 65535, length 0
11:18:49.331688 IP (tos 0x0, ttl 59, id 0, offset 0, flags [DF], proto TCP (6), length 40)
1.1.1.1.47495 > 2.2.2.2.pop3s: Flags [R], cksum 0x5e87 (correct), seq 4248475136, win 0, length 0
現在,讓我們嘗試在 1.1.1.1 上封鎖它並重複探測:
$ /sbin/iptables -A OUTPUT -d 2.2.2.2 -j DROP
$ zmap --whitelist-file=<( echo 2.2.2.2 ) -p 995 -n 1
不幸的是,我們看到了更多 tcpdump 數據。這意味著它不起作用。
我最終透過使用雲端提供者的防火牆功能在不同的層面解決了這個問題。