Eu tenho um ambiente de análise de malware que interceptará o tráfego para domínios arbitrários e serviços de Internet usando o InetSim. Eu tenho um sandbox que tem seu servidor DNS definido para a instância InetSim e InetSim responderá a qualquer consulta DNS com seu próprio endereço IP.
Essa configuração funciona bem para malwares que ligam de volta a um nome de domínio, mas se tentar se conectar diretamente a um endereço IP codificado, meu ambiente de malware não o fará. Eu estou tentando usar iptables para redirecionar qualquer tráfego de saída voltar para a instância InetSim na mesma sub-rede, mas os pacotes parecem estar caindo em algum lugar na máquina de gateway.
Existem três máquinas na rede
Geralmente, estou seguindo o guia descrito na documentação NAT do netfilter e minha As regras do iptables são assim. Basicamente as regras são,
regras de 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
Como você pode ver nas contagens de pacotes, as regras estão capturando tráfego. O mais estranho é quando eu executo o tcpdump na máquina do gateway, e na máquina InetSim, vejo os pacotes reescritos da captura do gateway, mas nenhum desses pacotes da captura da máquina InetSim.
Captura de gateway
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
Eu ativei o rastreamento e estas são as entradas em /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)
Todos os outros tráfegos e conexões funcionam como esperado, mas algo está acontecendo no gateway. Sim, o ip_forward está ativado. Eu sei que o tcpdump fica no meio do processo de roteamento, e não necessariamente captura o que está no fio, então parece que os pacotes estão sendo descartados em algum lugar entre as tabelas PREROUTING e POSTROUTING. Qualquer ajuda seria muito apreciada.
O problema aqui parece estar em como o VirtualBox emula uma interface de rede e / ou a pilha de rede. Consegui levantar outro VBox Guest, configurado como gateway dedicado, usando as mesmas regras do iptables, e consegui redirecionar o tráfego para um IP arbitrário para a minha instância InetSim local.
Para solucionar sua configuração, desative-a e teste cada parte individualmente.
Eu tenho um servidor de firewall (10.3.1.5), então eu adicionei o comando para pacotes para 1.2.3.4 em uma caixa interna 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
Este deve ser o mesmo que o seu ponto de partida, e agora a partir de uma máquina interna 10.3.1.129 (hp) eu posso pingar 1.2.3.4. O log no firewall mostra os pacotes:
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
E usando o tcpdump para exibir apenas os pacotes ICMP (tcpdump 'icmp [icmptype] = icmp-echo ou icmp [icmptype] = icmp-echoreply') Eu vejo o pacote em 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
Você deve conseguir chegar a esse ponto apenas com a linha PREROUTING na tabela nat - verifique se ela está funcionando antes de tentar a regra POSTROUTING.
Em seguida, adicionei as regras de 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
O que muda os pacotes da rede local para 10.3.1.140 (mil102) para parecer que eles estão vindo de 10.3.1.5 (firewall).
O arquivo de log agora mostra o ping passando:
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
e minha máquina de destino mil102 (10.3.1.140) agora mostra a origem dos pings sendo o firewall (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
Algumas notas sobre minha configuração - eth0 é a interface interna do firewall, eth1 a externa. Tanto o hp quanto o mil102 possuem apenas uma interface eth0.
Minha tabela nat existente tem algum roteamento - por isso usei comandos de inserção. Esta é a aparência da minha tabela original:
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
Por favor, ignore os timestamps nos logs - eu coletei dados para o exemplo depois que eu testei tudo.
O melhor conselho, se isso não estiver funcionando, é simplificar a configuração até você chegar a um ponto em que ela esteja funcionando como esperado e, em seguida, adicionar complexidade até que você quebre ou atinja a meta.