Iptables

iptables 在 POSTROUTING 後丟棄數據包

  • February 4, 2015

我有一個惡意軟體分析環境,它將使用 InetSim 攔截到任意域和 Internet 服務的流量。我有一個沙箱,它的 DNS 伺服器設置為 InetSim 實例,InetSim 將使用自己的 IP 地址回答任何 DNS 查詢。

此設置適用於回調域名的惡意軟體,但如果它嘗試直接連接硬編碼的 IP 地址,我的惡意軟體環境就會錯過它。我正在嘗試使用 iptables 將任何出站流量重定向同一子網上的 InetSim 實例,但數據包似乎在網關機器上的某處被丟棄。

網路上有三台機器

  1. 網關(Ubuntu 14.04LTS,在 192.168.54.1 執行帶有僅主機介面 vboxnet0 的 VirtualBox)
  2. InetSim (VirtualBox VM, Remnux (Debian) Linux Distro, VBox host-only interface on eth0 at 192.168.54.2)
  3. 沙盒(VirtualBox VM、WinXPSP2、VBox 僅主機介面,位於 192.168.54.102)

我通常遵循netfilter NAT 文件中概述的指南,我的 iptables 規則如下所示。基本上規則是,

  1. 出站流量(不適用於 192.168.54.0/24 子網)發送到 192.168.54.1 的網關
  2. PREROUTING 將目標地址更改為 192.168.54.2 處的 InetSim 實例
  3. POSTROUTING 將源地址更改為網關 192.168.54.1

iptable 規則

$ sudo iptables -v -t nat -L
Chain PREROUTING (policy ACCEPT 17465 packets, 1818K bytes)
pkts bytes target     prot opt in     out     source               destination         
  24  1763 LOG        all  --  vboxnet0 any     anywhere            !192.168.54.0/24      LOG level debug prefix "[PREROUTE OUTBOUND]"
  41  2824 DNAT       all  --  vboxnet0 any     anywhere            !192.168.54.0/24      to:192.168.54.2

Chain INPUT (policy ACCEPT 14623 packets, 1341K bytes)
pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 74 packets, 4809 bytes)
pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 73 packets, 4749 bytes)
pkts bytes target     prot opt in     out     source               destination         
  17   984 LOG        all  --  any    any     192.168.54.0/24      192.168.54.2         LOG level debug prefix "[POSTROUTE Inetsim]"
  41  2513 SNAT       all  --  any    any     192.168.54.0/24      192.168.54.2         to:192.168.54.1

從數據包計數中可以看出,規則正在擷取流量。奇怪的是,當我在網關機器和 InetSim 機器上執行 tcpdump 時,我看到網關擷取的重寫數據包,但沒有來自 InetSim 機器擷取的此類數據包。

網關擷取

15:11:28.747298 ARP, Request who-has 192.168.54.1 tell 192.168.54.102, length 46
15:11:28.747305 ARP, Reply 192.168.54.1 is-at 0a:00:27:00:00:00, length 28
15:11:28.747471 IP 192.168.54.102.1041 > 2.3.4.5.80: Flags [S], seq 2061217349, win 65535, options [mss 1460,nop,nop,sackOK], length 0
15:11:28.747513 IP 192.168.54.1.1041 > 192.168.54.2.80: Flags [S], seq 2061217349, win 65535, options [mss 1460,nop,nop,sackOK], length 0

...SYN Repeated 2 more times...

15:11:33.748132 ARP, Request who-has 192.168.54.2 tell 192.168.54.1, length 28
15:11:33.748483 ARP, Reply 192.168.54.2 is-at 08:00:27:c7:4f:7c, length 28

InetSim 擷取

10:11:28.649243 ARP, Request who-has 192.168.54.1 tell 192.168.54.102, length 46
10:11:28.649253 ARP, Reply 192.168.54.1 is-at 0a:00:27:00:00:00, length 46
10:11:28.649363 IP 192.168.54.102.1041 > 2.3.4.5.80: Flags [S], seq 2061217349, win 65535, options [mss 1460,nop,nop,sackOK], length 0

...SYN Repeated 2 more times...

10:11:33.650248 ARP, Request who-has 192.168.54.2 tell 192.168.54.1, length 46
10:11:33.650266 ARP, Reply 192.168.54.2 is-at 08:00:27:c7:4f:7c, length 28

我已啟用跟踪,這些是以下條目/var/log/syslog

kernel: [22504.635493] TRACE: raw:PREROUTING:policy:2 IN=vboxnet0 OUT= MAC=0a:00:27:00:00:00:08:00:27:0b:26:95:08:00 SRC=192.168.54.102 DST=2.3.4.5 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=141 DF PROTO=TCP SPT=1046 DPT=80 SEQ=3347741723 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B401010402) 
kernel: [22504.635504] TRACE: nat:PREROUTING:rule:1 IN=vboxnet0 OUT= MAC=0a:00:27:00:00:00:08:00:27:0b:26:95:08:00 SRC=192.168.54.102 DST=2.3.4.5 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=141 DF PROTO=TCP SPT=1046 DPT=80 SEQ=3347741723 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B401010402) 
kernel: [22504.635508] [PREROUTE OUTBOUND]IN=vboxnet0 OUT= MAC=0a:00:27:00:00:00:08:00:27:0b:26:95:08:00 SRC=192.168.54.102 DST=2.3.4.5 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=141 DF PROTO=TCP SPT=1046 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0 
kernel: [22504.635512] TRACE: nat:PREROUTING:rule:2 IN=vboxnet0 OUT= MAC=0a:00:27:00:00:00:08:00:27:0b:26:95:08:00 SRC=192.168.54.102 DST=2.3.4.5 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=141 DF PROTO=TCP SPT=1046 DPT=80 SEQ=3347741723 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B401010402) 
kernel: [22504.635532] TRACE: filter:FORWARD:policy:1 IN=vboxnet0 OUT=vboxnet0 MAC=0a:00:27:00:00:00:08:00:27:0b:26:95:08:00 SRC=192.168.54.102 DST=192.168.54.2 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=141 DF PROTO=TCP SPT=1046 DPT=80 SEQ=3347741723 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B401010402) 
kernel: [22504.635536] TRACE: nat:POSTROUTING:rule:1 IN= OUT=vboxnet0 SRC=192.168.54.102 DST=192.168.54.2 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=141 DF PROTO=TCP SPT=1046 DPT=80 SEQ=3347741723 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B401010402) 
kernel: [22504.635538] [POSTROUTE Inetsim]IN= OUT=vboxnet0 SRC=192.168.54.102 DST=192.168.54.2 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=141 DF PROTO=TCP SPT=1046 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0 
kernel: [22504.635541] TRACE: nat:POSTROUTING:rule:2 IN= OUT=vboxnet0 SRC=192.168.54.102 DST=192.168.54.2 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=141 DF PROTO=TCP SPT=1046 DPT=80 SEQ=3347741723 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B401010402)

所有其他流量和連接都按預期工作,但網關中發生了一些事情。是的,ip_forward 已啟用。我知道 tcpdump 位於路由過程的中間,並且不一定擷取線路上的內容,因此數據包似乎在 PREROUTING 和 POSTROUTING 表之間的某處被丟棄。任何幫助將不勝感激。

這裡的問題似乎與 VirtualBox 如何模擬網路介面和/或網路堆棧有關。我能夠使用相同的 iptables 規則建立另一個 VBox Guest,配置為專用網關,並且能夠成功地將流量重定向到任意 IP 到我的本地 InetSim 實例。

要對您的設置進行故障排除,請將其剝離並單獨測試每個部分。

我有一個防火牆伺服器(10.3.1.5),所以我將命令添加到 1.2.3.4 的數據包到內部框 10.3.1.140(mil102):

iptables -t nat -A PREROUTING -i eth0 -d 1.2.3.4  -j LOG
iptables -t nat -A PREROUTING -i eth0 -d 1.2.3.4  -j DNAT --to 10.3.1.140

這應該與您的起點相同,現在從內部機器 10.3.1.129 (hp) 我可以 ping 1.2.3.4。防火牆上的日誌顯示數據包:

Feb  3 15:42:54 firewall kernel: [7052380.506166] IN=eth0 OUT= MAC=00:0c:29:64:b1:4a:00:22:64:f7:b4:b8:08:00 SRC=10.3.1.129 DST=1.2.3.4 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=27456 DF PROTO=ICMP TYPE=8 CODE=0 ID=922 SEQ=1

並使用 tcpdump 僅顯示 ICMP 數據包(tcpdump ‘icmp

$$ icmptype $$= icmp-echo 或 icmp$$ icmptype $$= icmp-echoreply’) 我在 mil102 (10.3.1.140) 上看到了數據包:

16:42:55.161125 IP hp > mil102: ICMP echo request, id 922, seq 1, length 64
16:42:55.161185 IP mil102 > hp: ICMP echo reply, id 922, seq 1, length 64

您應該能夠只使用 nat 表中的 PREROUTING 行來達到這一點——在嘗試 POSTROUTING 規則之前驗證它是否正常工作。

然後我添加了 POSTROUTING 規則:

iptables -t nat -I POSTROUTING 1 -d 10.3.1.140 -s 10.3.1.0/24 -j LOG
iptables -t nat -I POSTROUTING 2 -d 10.3.1.140 -s 10.3.1.0/24 -j SNAT --to 10.3.1.5

這會將來自本地網路的數據包更改為 10.3.1.140 (mil102),使其看起來像是來自 10.3.1.5(防火牆)。

日誌文件現在顯示 ping 通過:

Feb  3 15:40:33 firewall kernel: [7052239.848022] IN=eth0 OUT= MAC=00:0c:29:64:b1:4a:00:22:64:f7:b4:b8:08:00 SRC=10.3.1.129 DST=1.2.3.4 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=21950 DF PROTO=ICMP TYPE=8 CODE=0 ID=32310 SEQ=1
Feb  3 15:40:33 firewall kernel: [7052239.848081] IN= OUT=eth0 SRC=10.3.1.129 DST=10.3.1.140 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=21950 DF PROTO=ICMP TYPE=8 CODE=0 ID=32310 SEQ=1

我的目標機器 mil102 (10.3.1.140) 現在顯示 ping 的來源是防火牆 (10.3.1.5):

16:40:35.639037 IP firewall > mil102: ICMP echo request, id 32310, seq 2, length 64
16:40:35.639110 IP mil102 > firewall: ICMP echo reply, id 32310, seq 2, length 64

關於我的設置的一些注意事項——eth0 是防火牆上的內部介面,eth1 是外部介面。hp 和 mil102 都只有一個介面 eth0。

我現有的 nat 表有一些路由到 - 這就是我使用插入命令的原因。這是我原來的 nat 表的樣子:

Chain PREROUTING (policy ACCEPT 37 packets, 2362 bytes)
pkts bytes target     prot opt in     out     source               destination
1444 73980 DNAT       tcp  --  eth1   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:81 to:10.3.1.129:81

Chain INPUT (policy ACCEPT 18 packets, 1222 bytes)
pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 6 packets, 420 bytes)
pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination
   5   420 ACCEPT     all  --  *      eth1    0.0.0.0/0            172.20.20.0/24
116M 7439M MASQUERADE  all  --  *      eth1    0.0.0.0/0            0.0.0.0/0

請忽略日誌上的時間戳——我在測試完所有內容後為範例收集了數據。

如果這不起作用,最好的建議是簡化設置,直到你達到它按預期工作的程度,然後增加複雜性,直到你打破或達到目標。

引用自:https://serverfault.com/questions/664637