I have a malware analysis environment that will intercept traffic to arbitrary domains and Internet services using InetSim. I have a sandbox that has its DNS server set to the InetSim instance, and InetSim will answer any DNS query with its own IP address.
This setup works well for malware that calls back to a domain name, but if it attempts to connect directly with a hard coded IP address, my malware environment misses it. I'm attempting to use iptables to redirect any outbound traffic back to the InetSim instance on the same subnet, but packets appear to be getting dropped somewhere on the gateway machine.
There are three machines on the network
- Gateway (Ubuntu 14.04LTS, running VirtualBox with host-only interface vboxnet0 at 192.168.54.1)
- InetSim (VirtualBox VM, Remnux (Debian) Linux Distro, VBox host-only interface on eth0 at 192.168.54.2)
- Sandbox (VirtualBox VM, WinXPSP2, VBox host-only interface at 192.168.54.102)
I am generally following the guide outlined in the netfilter NAT documentation, and my iptables rules look like this. Basically the rules are,
- Outbound traffic (NOT intended for the 192.168.54.0/24 subnet) is sent to the gateway at 192.168.54.1
- PREROUTING changes the destination address to the InetSim instance at 192.168.54.2
- POSTROUTING changes the source address to the Gateway at 192.168.54.1
iptable rules
$ 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
As you can see from the packet counts, the rules are catching traffic. The weird thing is when I run tcpdump on both the gateway machine, and the InetSim machine, I see the rewritten packets from the gateway's capture, but no such packets from the InetSim machine's capture.
Gateway Capture
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
I've enabled trace and these are the entries in /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)
All other traffic and connections work as expected, but something is happening in the gateway. Yes, ip_forward is enabled. I know tcpdump sits in the middle of the routing process, and doesn't necessarily capture what's on the wire, so it seems like the packets are getting dropped somewhere between the PREROUTING and POSTROUTING tables. Any help would be greatly appreciated.