web-dev-qa-db-ja.com

iptablesはPOSTROUTING後にパケットをドロップします

InetSimを使用して任意のドメインやインターネットサービスへのトラフィックを傍受するマルウェア分析環境があります。 DNSサーバーがInetSimインスタンスに設定されているサンドボックスがあり、InetSimは独自のIPアドレスを使用してDNSクエリに応答します。

この設定は、ドメイン名にコールバックするマルウェアに対してはうまく機能しますが、ハードコードされたIPアドレスに直接接続しようとすると、マルウェア環境はそれを見逃します。 iptablesを使用して、アウトバウンドトラフィックbackを同じサブネット上のInetSimインスタンスにリダイレクトしようとしていますが、パケットがどこかにドロップされているようです。ゲートウェイマシン。

ネットワーク上に3台のマシンがあります

  1. ゲートウェイ（Ubuntu 14.04LTS、192.168.54.1でホスト専用インターフェースvboxnet0を使用してVirtualBoxを実行）
  2. InetSim（VirtualBox VM、Remnux（Debian）Linuxディストリビューション、192.168.54.2のeth0上のVBoxホスト専用インターフェイス）
  3. サンドボックス（VirtualBox VM、WinXPSP2、192.168.54.102のVBoxホスト専用インターフェイス）

私は通常、 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テーブルの間のどこかにドロップされているようです。どんな助けでも大歓迎です。

iptablesnatvirtualboxubuntu-14.04kernel-modules
3
Matt

ここでの問題は、VirtualBoxがネットワークインターフェイスやネットワークスタックをエミュレートする方法にあるようです。同じiptablesルールを使用して、専用ゲートウェイとして構成された別のVBoxゲストを立ち上げることができ、トラフィックを任意のIPからローカルのInetSimインスタンスに正常にリダイレクトすることができました。

1
Matt

セットアップのトラブルシューティングを行うには、セットアップを取り除き、各パーツを個別にテストします。

ファイアウォールサーバー（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）から1.2.3.4にpingを実行できます。ファイアウォールのログには、パケットが表示されます。

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）は、ファイアウォール（10.3.1.5）であるpingのソースを表示します。

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の両方に1つのインターフェース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

ログのタイムスタンプは無視してください。すべてをテストした後、例のデータを収集しました。

これが機能しない場合の最善のアドバイスは、期待どおりに機能するポイントに到達するまでセットアップを単純化し、目標を達成するか、目標に到達するまで複雑さを追加することです。

0
Ed King