NPING NEW ECHO MODE PROPOSAL June 2010 Luis MartinGarcia (luis.mgarc@gmail.com) TABLE OF CONTENTS 0x01. Introduction 0x02. Input 0x03. Output 0x04. Results 0x05. Protocol == 0x01: INTRODUCTION == Troubleshooting routing and firewall issues is a common task nowadays. The scenario is generally that some network traffic should be flowing but isn't. The causes of problem can range from routing issues to network firewall to host-based firewalls to all sorts of other strange things. It is usually the "middle box" problem that is the hardest to find. Suppose there is some host with a TCP service listening that you can't connect to for an unknown reason. If a Nmap -sS scan doesn't show the port as open there are a multitude of possible problems. Maybe the SYN packet never made it because of some firewall in the middle. Maybe the SYN did make it but the SYN+ACK got dropped on it's way back to you. Maybe the TTL expired in transit but the ICMP message got blocked by another firewall before making it back to you. Maybe the SYN made it but some intermediate host forged a reset packet to snipe the connection before the SYN+ACK made it back to you. When things like the above are going on, it is often the case that one has to turn to Wireshark/tcpdump on one station and Nping on the other. However, this is usually difficult to coordinate, specially when the person at the remote host does not even know what an IP address is. To solve this problem, Nping will have a new mode, called "Echo mode" that will give it the power of a combination like hping + tcpdump. This echo mode turns Nping into a client/server application. One station runs Nping in server mode and the other in client mode. The way it works is: the Nping client performs an initial handshake with the server over some standard port (creating a side-channel). Then it notifies the server what packets are about to be sent. The server sets up a liberal BPF filter that captures those packets, and starts listening. When the server receives a packet it encapsulates it into a packet of our own protocol, the Nping Echo Protocol (NEP), and sends it back to the client. This would be essentially like running tcpdump on the remote machine and having it report back the packets you sent to it with Nping. By having the side-channel to talk to the server, things like NAT would become immediately apparent because you'd see your source IP (and sometimes port) change. Things like "packet shapers" that change TCP window sizes transparently between hosts would turn up. It would be easy to tell if the traffic is being dropped in transit and never gets to the box. It would also be easy to tell if the traffic does make it to the box but the reply never makes it back to you. In general, it would be like sending a postal package to someone and having them email you a photo of the package when they get it. If you think your packages are being abused by the parcel service then having someone on the other end to send information back is a great way to uncover what is going on. == 0x02: INPUT == From a user's perpective, this new mode would be set up from the command line. Here's a possible interface: SERVER Users may start the server, using the default parameters, running: nping --echo-server "Squemmish Ossifrage" where the parameter passed to the --echo-server argument is the passphrase that is used to derive encryption keys. Obvioulsy it would be possible to override defaults running something like: nping --echo-server "SquemmishOssifrage" --echo-port 9999 -vvv CLIENT Users would need to supply "--echo-client " and the usual parameters used in Nping's normal operation mode. For example, the next command tells nping to connect to the echo server at echo.insecure.org, and send one TCP-SYN packet to the echo server. nping --echo-client "SquemmishOssifrage" --tcp --flags syn --win 0 -c1 echo.insecure.org == 0x03: OUTPUT == About the output, Nping will print three types of packets: sent packets, received reply packets, and echoed packets received through the side channel. For captured packets, only the fields that differ from the original packet will be displayed. This makes it easier to spot the fields that changed in transit. Here's a sample output. SENT (0.0980s) TCP 192.168.1.99:33856 > 74.207.254.18:80 S ttl=64 id=60467 iplen=40 seq=1754993861 win=0 CAPT (0.4504s) TCP 10.1.2.158:33856 > 10.0.23.56:80 ttl=53 RCVD (0.1000s) TCP 74.207.254.18:80 > 192.168.1.99:33856 SA ttl=128 id=11746 iplen=44 seq=3230736912 win=16384 Output would be more detailed if verbosity mode is incremented. For example, the IP checksum, which is expected to change in virtually all cases (as it is recomputed in transit for every TTL decrement operation), would only be printed when the level of verbosity is higher than the default. Here's another example: SENT (0.0760s) TCP [192.168.1.99:33856 > 74.207.254.18:80 S seq=3835079997 ack=0 off=5 res=0 win=0 csum=0x807E urp=0] IP [ver=4 ihl=5 tos=0x00 iplen=40 id=63460 foff=0 ttl=64 proto=6 csum=0x2d6b] CAPT (0.4504s) TCP [10.1.2.158:33856 > 10.0.23.56:80 csum=34fd] [IP ttl=53 csum=f43d] RCVD (0.0850s) TCP [74.207.254.18:80 > 192.168.1.99:18367 SA seq=507544695 ack=3835079998 off=6 res=0 win=16384 csum=0x85F9 urp=0 ] IP [ver=4 ihl=5 tos=0x00 iplen=44 id=17102 foff=0 ttl=128 proto=6 csum=0xa27d] Note that the displayed time for the CAPT packet is higher than RCVD's. This is because Nping will hold the RCVD packet information until it gets the echoed packet. The reason for this behaviour is that it may be less confusing for end users to see the differences between the SENT and the CAPT packets if they are printed one after the other. Typically, network stacks will respond to SENT packets before the Nping Server has time to capture them, encapsulate them in a Nping Echo Protocol message and send them back to the client, so in order to display SENT and CAPT packets together, the RCVD output needs to be delayed for a bit. == 0x04: RESULTS == Apart from displaying the packets that were sent and the ones that were captured, Nping should, if possible, give hints about what may have happened in transit. For example, if the original source address does not match the source address of the received packet, Nping could inform that with high probability there is a NAT device close to the client. Nping could detect things like variation of TCP window size and warn about possible transparent proxies, etc. Starting Nping 0.5.30BETA1 ( https://nmap.org/nping ) at 2010-06-30 17:20 CEST SENT (0.0980s) TCP 192.168.1.99:33856 > 74.207.254.18:80 S ttl=64 id=60467 iplen=40 seq=1754993861 win=0 CAPT (0.4504s) TCP 10.1.2.158:33856 > 10.0.23.56:80 ttl=53 RCVD (0.1000s) TCP 74.207.254.18:80 > 192.168.1.99:33856 SA ttl=128 id=11746 iplen=44 seq=3230736912 win=16384 Packet Echo Analysis: |_Source IP and Destination IP differ: possible NAT device on both ends. |_TTL values differ by 11 units. Network distance between both hosts: 11 hops. Max rtt: 8.509ms | Min rtt: 8.509ms | Avg rtt: 8.509ms Raw packets sent: 1 (40B) | Rcvd: 1 (46B) | Lost: 0 (0.00%) Echoed packets recv: 1 (40B) | Lost: 0 (0.00%) Tx time: 0.00020s | Tx bytes/s: 202020.20 | Tx pkts/s: 5050.51 Rx time: 0.99984s | Rx bytes/s: 46.01 | Rx pkts/s: 1.00 Nping done: 1 IP address pinged in 1.08 seconds == 0x05: PROTOCOL == The side channel will be run over a custom application layer protocol called NEP, Nping Echo Protocol. The protocol itself is described in a separate document: "Nping Echo Protocol Specification", available from: The following flow diagram describes a typical client/server interaction. Please refer to the document cited above for more information. C S | | | TCP Handshake | Establish regular TCP |------------------------->| connection |<-------------------------| |------------------------->| | | | | | | Check that both | | understand each other | NEP Handshake and Auth | and authenticate the |<------------------------>| client |<------------------------>| |<------------------------>| | | | | | | Client tells the server | PacketType={IP/TCP/Syn} | which kind of packet is |------------------------->| going so send | | S | | | /* Server starts */ | | | /* capturing packets*/ | ServerReadyToGo | | /* here. */ Server indicates its |<-------------------------| | sniffing engine is | | | readty to capture the | C | | packet | | | | | | | | | | | | | | | | Client sends the pkt | | IP/TCP/Syn Packet | | via raw sockets | |---------------------------->| | | | | /* Server receives */ | | | /* the packet */ | Echo of the packet |....| Server echoes the |<-------------------------| packet via the NEP | | session they have. | . | | . | | . | | More raw pkt/echo | | exchanges | | . | | . | | . | | | | | | TCP Connection Close | TCP connection closed |<------------------------>| | |