mirror of
https://github.com/nmap/nmap.git
synced 2025-12-06 04:31:29 +00:00
223 lines
11 KiB
Plaintext
223 lines
11 KiB
Plaintext
|
|
|
|
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 <passphrase>" 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 <mss 1460>
|
|
|
|
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 <mss 1460>] 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 <mss 1460>
|
|
|
|
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:
|
|
<https://nmap.org/svn/nping/nping-dev/EchoProtoRFC.txt>
|
|
|
|
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 |<------------------------>|
|
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|