iptables отбрасывает пакеты после POSTROUTING
У меня есть вредоносная аналитическая среда, которая прервет трафик к произвольному использованию доменов и интернет-сервисов InetSim. У меня есть песочница, которой установили ее сервер DNS на экземпляр InetSim, и InetSim ответит на любой запрос DNS со своим собственным IP-адресом.
Эта установка работает хорошо на вредоносное программное обеспечение, которое перезванивает к доменному имени, но если это пытается соединиться непосредственно с трудным кодированным IP-адресом, моя вредоносная среда пропускает его. Я пытаюсь использовать iptables для перенаправления любого исходящего трафика назад к экземпляру InetSim на той же подсети, но пакеты, кажется, становятся отброшенными где-нибудь на машине шлюза.
В сети существует три машины
- Шлюз (Ubuntu 14.04LTS, выполняя VirtualBox с интерфейсом только для хоста vboxnet0 в 192.168.54.1)
- InetSim (VirtualBox VM, Remnux (Debian) Дистрибутив Linux, VBox интерфейс только для хоста на eth0 в 192.168.54.2)
- Песочница (VirtualBox VM, WinXPSP2, VBox интерфейс только для хоста в 192.168.54.102)
Я обычно следую руководству, обрисованному в общих чертах в netfilter документации NAT, и мои правила iptables похожи на это. В основном правила,
- Исходящий трафик (НЕ предназначенный для 192.168.54.0/24 подсети) отправляется на шлюз в 192.168.54.1
- PREROUTING изменяет адрес назначения на экземпляр InetSim в 192.168.54.2
- 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
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 Guest, настроенный как выделенный шлюз, используя те же правила 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 (лс) могу пинговать 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
Не обращайте внимания на временные метки в журналах - данные для этого примера я собрал после того, как все протестировал.
Лучший совет, если это не работает, - упростить настройку пока вы не достигнете точки, в которой все работает, как ожидалось, а затем добавляйте сложность, пока не сломаете или не достигнете цели.