Nping
Sunday 21st February, 2010 17:19 Comments: 0
Apologies in advance for the geeky post, but Nping 0.1BETA3 has finally made it into (the SVN version of) Nmap. I decided to give it a spin on Windows, and it seems to work okay. With support for things like IPv6, I think this tool will quickly replace similar tools (such as hping) as the defacto packet crafting application.
Here are a few examples (and some simplified explanations) against a router that has TCP port 80 open.
>nping --tcp -p 80 --flags syn --ttl 2 192.168.1.1
Starting Nping 0.1BETA3 ( http://nmap.org/nping ) at 2010-02-21 17:05 GMT Standard Time
SENT (0.0310s) TCP 192.168.1.16:53734 > 192.168.1.1:80 S ttl=2 id=53648 iplen=40 seq=2700778359 win=1480
RCVD (1.0000s) TCP 192.168.1.1:80 > 192.168.1.16:53734 SA ttl=64 id=0 iplen=44 seq=3178978663 win=5840 <mss 1460>
SENT (1.0630s) TCP 192.168.1.16:53734 > 192.168.1.1:80 S ttl=2 id=45552 iplen=40 seq=2700778359 win=1480
This shows Nping sending a SYN request to the router. The router has port 80 open, so it returns a SYN ACK, to show that it's received our initial SYN and to say it's okay to continue the TCP handshake.
>nping --tcp -p 80 --flags syn,ack --ttl 2 192.168.1.1
Starting Nping 0.1BETA3 ( http://nmap.org/nping ) at 2010-02-21 17:05 GMT Standard Time
SENT (0.0320s) TCP 192.168.1.16:29897 > 192.168.1.1:80 SA ttl=2 id=47721 iplen=40 seq=3973183360 win=1480
RCVD (1.0000s) TCP 192.168.1.1:80 > 192.168.1.16:29897 R ttl=255 id=0 iplen=40 seq=4279075109 win=0
SENT (1.0630s) TCP 192.168.1.16:29897 > 192.168.1.1:80 SA ttl=2 id=53693 iplen=40 seq=3973183360 win=1480
This shows Nping sending a SYN ACK to the router, except this time the router never saw an initial SYN and doesn't expect the traffic for this open port. So it send a RST to reset the connection. Some firewalls in the past have been configured to silently drop SYN packets so you're not sure if there's anything there; but if you send a SYN ACK you can sometimes get the firewall to return a RST, giving away the fact there's something there.
>nping --tcp -p 80 --flags syn,ack,rst --ttl 2 192.168.1.1
Starting Nping 0.1BETA3 ( http://nmap.org/nping ) at 2010-02-21 17:05 GMT Standard Time
SENT (0.0470s) TCP 192.168.1.16:3950 > 192.168.1.1:80 SRA ttl=2 id=54975 iplen=40 seq=3973559584 win=1480
SENT (1.0620s) TCP 192.168.1.16:3950 > 192.168.1.1:80 SRA ttl=2 id=54655 iplen=40 seq=3973559584 win=1480
SENT (2.0620s) TCP 192.168.1.16:3950 > 192.168.1.1:80 SRA ttl=2 id=47824 iplen=40 seq=3973559584 win=1480
SENT (3.0620s) TCP 192.168.1.16:3950 > 192.168.1.1:80 SRA ttl=2 id=61647 iplen=40 seq=3973559584 win=1480
This shows Nping sending a really dodgy looking packet. You normally have flags such as RST or SYN and sometimes things like SYN ACK. You should never see a real packet with the SYN ACK and RST flags all set (the SYN says you want to establish the connection; the RST says you want to break the connection). Because the packet is so messed up, the router doesn't even bother sending a reply, it simply drops the malformed packet.
Anyway, that's a quick guide to creating packets with Nping. Most importantly to me, it seems to work okay on Windows 7. If anyone wants to use it, you'll have to download the code from SVN and compile it; but hopefully a new stable release will be out in a little while (with some interesting new scripts, and a few bugfixes).
Here are a few examples (and some simplified explanations) against a router that has TCP port 80 open.
>nping --tcp -p 80 --flags syn --ttl 2 192.168.1.1
Starting Nping 0.1BETA3 ( http://nmap.org/nping ) at 2010-02-21 17:05 GMT Standard Time
SENT (0.0310s) TCP 192.168.1.16:53734 > 192.168.1.1:80 S ttl=2 id=53648 iplen=40 seq=2700778359 win=1480
RCVD (1.0000s) TCP 192.168.1.1:80 > 192.168.1.16:53734 SA ttl=64 id=0 iplen=44 seq=3178978663 win=5840 <mss 1460>
SENT (1.0630s) TCP 192.168.1.16:53734 > 192.168.1.1:80 S ttl=2 id=45552 iplen=40 seq=2700778359 win=1480
This shows Nping sending a SYN request to the router. The router has port 80 open, so it returns a SYN ACK, to show that it's received our initial SYN and to say it's okay to continue the TCP handshake.
>nping --tcp -p 80 --flags syn,ack --ttl 2 192.168.1.1
Starting Nping 0.1BETA3 ( http://nmap.org/nping ) at 2010-02-21 17:05 GMT Standard Time
SENT (0.0320s) TCP 192.168.1.16:29897 > 192.168.1.1:80 SA ttl=2 id=47721 iplen=40 seq=3973183360 win=1480
RCVD (1.0000s) TCP 192.168.1.1:80 > 192.168.1.16:29897 R ttl=255 id=0 iplen=40 seq=4279075109 win=0
SENT (1.0630s) TCP 192.168.1.16:29897 > 192.168.1.1:80 SA ttl=2 id=53693 iplen=40 seq=3973183360 win=1480
This shows Nping sending a SYN ACK to the router, except this time the router never saw an initial SYN and doesn't expect the traffic for this open port. So it send a RST to reset the connection. Some firewalls in the past have been configured to silently drop SYN packets so you're not sure if there's anything there; but if you send a SYN ACK you can sometimes get the firewall to return a RST, giving away the fact there's something there.
>nping --tcp -p 80 --flags syn,ack,rst --ttl 2 192.168.1.1
Starting Nping 0.1BETA3 ( http://nmap.org/nping ) at 2010-02-21 17:05 GMT Standard Time
SENT (0.0470s) TCP 192.168.1.16:3950 > 192.168.1.1:80 SRA ttl=2 id=54975 iplen=40 seq=3973559584 win=1480
SENT (1.0620s) TCP 192.168.1.16:3950 > 192.168.1.1:80 SRA ttl=2 id=54655 iplen=40 seq=3973559584 win=1480
SENT (2.0620s) TCP 192.168.1.16:3950 > 192.168.1.1:80 SRA ttl=2 id=47824 iplen=40 seq=3973559584 win=1480
SENT (3.0620s) TCP 192.168.1.16:3950 > 192.168.1.1:80 SRA ttl=2 id=61647 iplen=40 seq=3973559584 win=1480
This shows Nping sending a really dodgy looking packet. You normally have flags such as RST or SYN and sometimes things like SYN ACK. You should never see a real packet with the SYN ACK and RST flags all set (the SYN says you want to establish the connection; the RST says you want to break the connection). Because the packet is so messed up, the router doesn't even bother sending a reply, it simply drops the malformed packet.
Anyway, that's a quick guide to creating packets with Nping. Most importantly to me, it seems to work okay on Windows 7. If anyone wants to use it, you'll have to download the code from SVN and compile it; but hopefully a new stable release will be out in a little while (with some interesting new scripts, and a few bugfixes).