There is currently a bug in firefox 3 which causes it to crash with an XError BadAloc when you go to any page hosted on howtoforge.
This seems to be related to the image at http://howtoforge.com/themes/htf_glass/images/bg_header_bottom_left15.png. I suggest you don’t click on that link 🙂
Apparently this image is 10,000 pixels wide. It looks like this is probably a GTK issue since the same problem happended when I opened the image with evince!
I tried writing a greasemonkey script to get around this problem but it loads too late to avert the crash. So iptables to the rescue.
iptables -I OUTPUT -d howtoforge.com -m string –algo bm –to 70 –string “GET /themes/htf_glass/images/bg_header_bottom_left15.png” -j DROP
-I OUTPUT # Match packets levaing my laptop
-d howtoforge.com # Only packets going to howtoforge
-m string # Invoke the string matcher
--algo bm # Pick a matching algorithm
--to 70 # Only check the first 70 bytes of each packet
--string "GET /themes/htf_glass/images/bg_header_bottom_left15.png"
-j DROP # Drop the sucker
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 18.104.22.168
animal:~ johnf$ host inodes.org
inodes.org has address 22.214.171.124
animal:~ johnf$ sudo iptables -t nat -A PREROUTING -d 126.96.36.199 -j DNAT –to 188.8.131.52
Now for some testing, a ping looks normal
animal:~johnf$ ping www.bulletproof.net
PING www.bulletproof.net.au (184.108.40.206) 56(84) bytes of data.
64 bytes from 220.127.116.11: 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 18.104.22.168 > 22.214.171.124: icmp 64: echo request seq 1
16:35:25.301712 IP 126.96.36.199 > 188.8.131.52: 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.