Matt came to me with an interesting problem at Bulletproof this week. We have a dedicated hosting customer who talks to an external application for e-commerce. The IP for this was going to change but they needed to do to some testing before the switch. As usual with most enterprise applications, the hostname was hard coded. 🙁
Matt suggested we do some DNS poisoning or do some transparent proxying using squid or similar. While these would have worked they required firewall changes through three levels of firewalls and extra infrastructure.
So I turned to an evil solution, iptables. 🙂 Most people use DNAT on the inbound connection from the Internet to their internal private network to port forward to internal servers, or perform one-to-one NAT mappings. There is nothing stopping you using it the other way around.
Lets say that every time someone browses to http://bulletproof.net we want them to hit http://inodes.org instead. All you need to do is use DNAT to translate one IP address into the other.
animal:~ johnf$ host bulletproof.net
bulletproof.net has address 188.8.131.52
animal:~ johnf$ host inodes.org
inodes.org has address 184.108.40.206
animal:~ johnf$ sudo iptables -t nat -A PREROUTING -d 220.127.116.11 -j DNAT –to 18.104.22.168
Now for some testing, a ping looks normal
animal:~johnf$ ping www.bulletproof.net
PING www.bulletproof.net.au (22.214.171.124) 56(84) bytes of data.
64 bytes from 126.96.36.199: icmp_seq=1 ttl=241 time=198 ms
but a tcpdump looks like
animal:~johnf$ sudo tcpdump -ni eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
16:35:25.099510 IP 188.8.131.52 > 184.108.40.206: icmp 64: echo request seq 1
16:35:25.301712 IP 220.127.116.11 > 18.104.22.168: icmp 64: echo reply seq 1
Of course if anyone needs to try and debug this they are going to have a really fun time working out what is going on. 🙂
If you want to test this yourself you can do it on your own machine using the OUTPUT chain instead of PREROUTING.
2 Replies to “iptables evilness”
You are an evil, evil, man.
You sound like somebody who understands about iptables,
so I thought you could advice on the following.
I am running iptables firewall for my home network and I know how to do all the normal things: forwarding external http requests to my internal webserver, etc. Yet I can’t manage to do the following non-standard trick, which I planned as a joke. Here is what I need to happen: when my friend tries to use my internal host to reach his favorite website, I forward the IP to my own internal webserver and serve him my fake version of the page. Sounds like an easy thing for iptables – use PREROUTING chain to forward the IP of the targeted website to the IP of my dedicated webserver on the inside. So far this did not work for me: internal hosts do loose connection with the target website, but my internal webserver is not getting any requests and browser request times out. Here is what I have added to my rc.firewall script:
$IPTABLES -t nat -A PREROUTING -i eth1 -p tcp -d 22.214.171.124 –dport 80 -j DNAT –to-destination 192.168.8.3:80
$IPTABLES -A FORWARD -i eth1 -p tcp -d 192.168.8.3 –dport 80 -j ACCEPT
where eth1 connects to my internal LAN 192.168.8.0/24 and 126.96.36.199 is the web address that I need forwarded to my fake server. What am I missing?