Posts tagged IP spoofing

mask

My attempts with IP Spoofing – Revisited

Sep 22nd

Posted by Gili Nachum in network

5 comments

One upon a time (Jan 2009) I’ve written this post, basically saying that you’re not likely to be able to spoof IP address over the Internet.
Turns out I was dead wrong!

It happened so the very experienced Mr Filipe, from Brazil, came across the post and left me a comment saying that Spoofing over the internet is quiet possible.
I replied surprised, and after a number of comments ping-pongs, we started chatting online, and Felipe had agreed to give me a live spoofing demo:
On my end, I’ve configured my home router to forward TCP/UDP packets to my desktop, where I ran a wireshark network capture to monitor any incoming packets.
Then Felipe sent a burst of packets from random IP source addresses. Proving me that IP spoofing over the Internet is a reality indeed.

(What do you think? Isn’t this kind of stuff is what makes the Internet so amazingly wonderful? two people from two different parts of the world, united by joint interest and kindness :) )

So, Thank you Filipe!

A few notes on why spoofing might *not* work:

  1. According to Filipe, the recipient’s ISP is much more likely to block the spoofed packet, than the sender’s ISP. For example if the recipient’s ISP see a bogon source IP.
    That’s a bit counter-intuitive, because, assuming the ISPs really do care about preventing spoofing, it’s a very easy job for the sender’s ISP to tell if the packet’s source IP is one of the IPs that it handed out to customers, or moreover, to the particular customer (sender).
  2. If you are behind a NAT device, then any source address you are planning to use (be it spoofed or real) will be overwritten by the NAT anyway, so make sure you are on a real public IP.
  3. No reason to get excited. TCP spoofing is very limited as you won’t make it across the TCP handshake, because the recipients will send their ACK,SYN response to the spoofed IP, which you probably don’t have much control over.
    In a LAN things are a bit different, if you can manipulate the recipient’s ARP table to think that the spoofed IP MAC address is yours. I haven’t dag deep.

Feel free to comment.

, , , , ,
Visualization of the various routes through a portion of the Internet. Took it from Wikipedia.

My attempts with IP Spoofing

Jan 23rd

Posted by Gili Nachum in network

15 comments

Why did I wanted to spoof source IP addresses? and why did I failed? Here’s the story before you:

————
UPDATE Sep/2010: Dear Filipe (see comments below) had proven to me that spoofing over the internet is indeed possible, read all about it on the continuation post: My attempts with IP Spoofing – Revisited. Now back to the original story:
————

When customers install our product, they often forget to setup firewall rules to accept incoming connections from public IM (instant messaging) providers. Without the firewall rules in place the product does not function properly, of course, and the customer rushes to open a support trouble ticket. Troubleshooting to pinpoint the problem to a missing firewall rule isn’t trivial. When we try to validate whether the customer defined the required firewall rule, we need the external entity (that we have no control on) to open a connection to the customer’s IP, but the external entity will only do so following the successful completion of a handshake sequence that must be initiated by the customer (consider for example: XMPP Dial-Back mechanism), since this handshake by itself is prone to failures, you can see how reproducing the problem is a combursum process.

I started looking for a simple, independent, and reliable, troubleshooting procedure that would be able to give a clear-cut answer to whether or not the customer defined the firewall correctly.
Here’s what I’ve concocted:

  1. Assume that the customer IP is 1.1.1.1 and they were suppose to configure their firewall to allow incoming connections from 2.2.2.2.
  2. I’ll send a single TCP SYN packet (the 1st of the standard three messages TCP handshake) from my computer (say it’s IP is 9.9.9.9), but I’ll spoof the IP datagram’s source address field to be 2.2.2.2 instead of what normally should have been my actual machine address (9.9.9.9).
  3. I’ll ask the customer to run a network sniffer on the IM Gateway machine. Waiting for the single packet to arrive at the destination socket.
  4. If the sniffer had recorded the incoming IP message, then it means that the firewall is setup correctly and the problem is else where.
    But, If the sniffer didn’t record any incoming SYN packet, then we shell blame the firewall guys.

Pretty simple, eh? Now, in order to spoof the TCP SYN packet I needed a something that could generate and send raw IP packets, since you can’t just fiddle with the source IP address if you choose to ride on the good’ol TCP/IP stack. I found this IP spoofing perl script on the net, and it does the job.

Visualization of the various routes through a portion of the Internet. Took it from Wikipedia.

Visualization of the various routes through a portion of the Internet. Took it from Wikipedia.

I did my first test on the office LAN, I sent a message from machine (IP 9.9.9.9) to to machine 1.1.1.1 claiming the message source was 2.2.2.2, it worked! Machine 1.1.1.1 registered an incoming packet from 2.2.2.2.
It seems that the office router went along with the scam, perhaps it thought that the machine switched IP it IP, or the DHCP server went crazy, or that it’s ARP cache is just stall.

In the next test I tried sending the packet over the Internet, I tried sending a packet to my home computer from the office, with a source IP of some foreign entity, to my dismay, it never got to my home computer. Other IP variations didn’t work either.
My guess is that some router along the way noticed that it’s getting a packet with a source IP address that the part of the network it is looking can’t can’t possibly generate (imagine CIDR based ACLs), and that caused it to immediately drop the packet. This failure caused me to give up on the whole spoofing troubleshooting procedure idea.

Some thoughs about what I’ve seen:

  1. Evidently, It’s quite trivial to spoofe IP addresses on a LAN.
  2. Spoofing  IP addresses over the Internet doesn’t seem to be trivial.
  3. A side note: If the customer has a reverese proxy, or any form of entity that delegates TCP handshakes, deployed before the actual IM Gateway machine, then the procedure is not applicable, as the first TCP SYN message will never reach the IM Gateway machine.
  4. I would assume that the closer you inject the packet into the Internet backbone blood stream, the better the chances of not getting a rejection of the spoofed packet. The backbone routers communicate with many difference parts of the network, and might not have rational of where certain packates should be coming from or not.
    IP Packets tend to travel in different routes, making it harder to judge what IP CIDR is ligit from each fellow router.
  5. I’m guessing that the biggest problem for spoofing is the first or the second router (the ISP’s), since the ISP knows exactly what is your assinged address. Thereby knowning that the packet is spoofed.
  6. If any one knows a better method of spoofing source IP, please step forward and share your secret :)
, , ,