Spoofing Source with Nmap

 



I love port scanning.  I love the practical usage of it when used by an administrator and I love that it tells a story about a network.  

In this article we will discuss spoofing source IP addresses in a port scan.  I will talk about the how and why we conduct scans like this.

How Do we Spoof an IP Address?


The above picture shows two scans one being a regular nmap scan and the second one with a spoofed source IP.  The spoof address was discovered in a separate scan, so it is real.  You can spoof IPs that are not real, but as you will see the justification for this is narrow.  You can get much better results if the source IP is real.

Scan 1:
#nmap -sS -T4 192.168.1.78

This is the most basic scan we can do.  It's called a stealth scan.  The scan came back with 2 ports open.  At the surface level this tells us only a little bit.  Many people will stop here but there is more going on with our target.

Scan 2:
#nmap -sS -T4 -S 192.168.1.79 -e eth0 192.168.1.78

Our next scan is where we see spoofing taking place.  What's happening here is that we are sending packets to our target machine and we putting in the packet that we are sending a source IP of a different machine.

Pretty straight forward right!?

It really is as easy as that and the value it provides is awesome.

Why Do We Spoof an IP Address?


Look again at the result from scan 2.  In addition to the original two open ports we have a new port that is "open", port 21.  That's good to know, our target is running an FTP server.

Why does this matter?  Why didn't it show up in the first scan?

We have learned something very important from this scan.  Our target has a FW in place.  Furthermore the FW is specifically designed to allow access from a certain machine.  The first scan didn't show port 21 as open because the FW dropped the packet.  It literally saw a SYN packet from the Kali machine and because the Kali IP address is not included in the FW rule it was dropped.  However when the FW saw a packet coming from an IP that is included in a rule it responded to the packet with a SYN-ACK.

Often when we are engaged in a pen-test we may not know the structure of the environment we are working in.  While gathering information you are sure to run into FWs.  Understanding how the FW is configured and what it allows/denies is important to finding a route past it.

FWs are not infallible.  They are a critical piece of infrastructure, learning about each FW is necessary for understanding how it works and inevitably discovering a weak point.

 



Popular Posts