Назад | Перейти на главную страницу

iptables отбрасывает пакеты после POSTROUTING

У меня есть среда анализа вредоносных программ, которая будет перехватывать трафик к произвольным доменам и интернет-сервисам с помощью InetSim. У меня есть песочница, в которой DNS-сервер настроен на экземпляр InetSim, и InetSim ответит на любой DNS-запрос своим собственным IP-адресом.

Эта настройка хорошо работает с вредоносным ПО, которое обращается к доменному имени, но если оно пытается подключиться напрямую с жестко закодированным IP-адресом, моя вредоносная среда пропускает его. Я пытаюсь использовать iptables для перенаправления любого исходящего трафика назад к экземпляру InetSim в той же подсети, но кажется, что пакеты сбрасываются где-то на машине шлюза.

В сети три машины

  1. Шлюз (Ubuntu 14.04LTS, VirtualBox работает с интерфейсом только для хоста vboxnet0 на 192.168.54.1)
  2. InetSim (VirtualBox VM, Remnux (Debian) Linux Distro, интерфейс VBox только для хоста на eth0 на 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 изменяет адрес назначения на экземпляр InetSim по адресу 192.168.54.2
  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

Как видно из подсчета пакетов, правила улавливают трафик. Странно то, что когда я запускаю tcpdump как на машине шлюза, так и на машине InetSim, я вижу перезаписанные пакеты из захвата шлюза, но не вижу таких пакетов из захвата машины 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 Capture

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 эмулирует сетевой интерфейс и / или сетевой стек. Я смог установить еще одну гостевую VBox, настроенную как выделенный шлюз, используя те же правила iptables, и смог успешно перенаправить трафик на произвольный 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) я могу пинговать 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

Вы должны быть в состоянии добраться до этой точки с помощью только строки PREROUTING в таблице nat - убедитесь, что она работает, прежде чем пробовать правило 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 (брандмауэр).

В файле журнала теперь отображается прохождение проверки связи:

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):

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

Не обращайте внимания на временные метки в журналах - данные для этого примера я собрал после того, как все проверил.

Лучший совет, если это не работает, - упростить настройку до тех пор, пока вы не достигнете точки, в которой она работает, как ожидалось, а затем добавляйте сложность, пока вы не сломаете или не достигнете цели.