The "Echo Mode" is a novel technique implemented by Nping which
lets users see how network packets change in transit, from the
host where they originated to the target machine. Basically, the
Echo mode turns Nping into two different pieces: the Echo server
and the Echo client. The Echo server is a network service that
has the ability to capture packets from the network and send a
copy ("echo them") to the originating client through a side TCP
channel. The Echo client is the part that generates such network
packets, transmits them to the server, and receives their echoed
version through a side TCP channel that it has previously
established with the Echo server.
This scheme lets the client see the differences between the
packets that it sends and what is actually received by the
server. By having the server send back copies of the received
packets through the side channel, things like NAT devices become
immediately apparent to the client because it notices the changes
in the source IP address (and maybe even source port). Other
devices like those that perform traffic shaping, changing TCP
window sizes or adding TCP options transparently between hosts,
turn up too.
The Echo mode is also useful for troubleshooting routing and
firewall issues. Among other things, it can be used to determine
if the traffic generated by the Nping client is being dropped in
transit and never gets to its destination or if the responses are
the ones that don't get back to it.
Internally, client and server communicate over an encrypted and
authenticated channel, using the Nping Echo Protocol (NEP), whose
technical specification can be found in
https://nmap.org/svn/nping/docs/EchoProtoRFC.txt
The following paragraphs describe the different options available
in Nping's Echo mode.
--ec
passphrase, --echo-client
passphrase (Run Echo client)
This option tells Nping to run as an Echo client. passphrase
is a sequence of ASCII characters that is used used to
generate the cryptographic keys needed for encryption and
authentication in a given session. The passphrase should be a
secret that is also known by the server, and it may contain
any number of printable ASCII characters. Passphrases that
contain whitespace or special characters must be enclosed in
double quotes.
When running Nping as an Echo client, most options from the
regular raw probe modes apply. The client may be configured
to send specific probes using flags like --tcp
, --icmp
or
--udp
. Protocol header fields may be manipulated normally
using the appropriate options (e.g. --ttl
, --seq
,
--icmp-type
, etc.). The only exceptions are ARP-related
flags, which are not supported in Echo mode, as protocols
like ARP are closely related to the data link layer and its
probes can't pass through different network segments.
--es
passphrase, --echo-server
passphrase (Run Echo server)
This option tells Nping to run as an Echo server. passphrase
is a sequence of ASCII characters that is used used to
generate the cryptographic keys needed for encryption and
authentication in a given session. The passphrase should be a
secret that is also known by the clients, and it may contain
any number of printable ASCII characters. Passphrases that
contain whitespace or special characters must be enclosed in
double quotes. Note that although it is not recommended, it
is possible to use empty passphrases, supplying --echo-server
""
. However, if what you want is to set up an open Echo
server, it is better to use option --no-crypto
. See below for
details.
--ep
port, --echo-port
port (Set Echo TCP port number)
This option asks Nping to use the specified TCP port number
for the Echo side channel connection. If this option is used
with --echo-server
, it specifies the port on which the server
listens for connections. If it is used with --echo-client
, it
specifies the port to connect to on the remote host. By
default, port number 9929 is used.
--nc
, --no-crypto
(Disable encryption and authentication)
This option asks Nping not to use any cryptographic
operations during an Echo session. In practical terms, this
means that the Echo side channel session data will be
transmitted in the clear, and no authentication will be
performed by the server or client during the session
establishment phase. When --no-crypto
is used, the passphrase
supplied with --echo-server
or --echo-client
is ignored.
This option must be specified if Nping was compiled without
openSSL support. Note that, for technical reasons, a
passphrase still needs to be supplied after the --echo-client
or --echo-server flags, even though it will be ignored.
The --no-crypto flag might be useful when setting up a public
Echo server, because it allows users to connect to the Echo
server without the need for any passphrase or shared secret.
However, it is strongly recommended to not use --no-crypto
unless absolutely necessary. Public Echo servers should be
configured to use the passphrase "public" or the empty
passphrase (--echo-server "") as the use of cryptography does
not only provide confidentiality and authentication but also
message integrity.
--once
(Serve one client and quit)
This option asks the Echo server to quit after serving one
client. This is useful when only a single Echo session wants
to be established as it eliminates the need to access the
remote host to shutdown the server.
--safe-payloads
(Zero application data before echoing a packet)
This option asks the Echo server to erase any application
layer data found in client packets before echoing them. When
the option is enabled, the Echo server parses the packets
received from Echo clients and tries to determine if they
contain data beyond the transport layer. If such data is
found, it is overwritten with zeroes before transmitting the
packets to the appropriate Echo client.
Echo servers can handle multiple simultaneous clients running
multiple echo sessions in parallel. In order to determine
which packet needs to be echoed to which client and through
which session, the Echo server uses an heuristic algorithm.
Although we have taken every security measure that we could
think of to prevent that a client receives an echoed packet
that it did not generate, there is always a risk that our
algorithm makes a mistake and delivers a packet to the wrong
client. The --safe-payloads option is useful for public echo
servers or critical deployments where that kind of mistake
cannot be afforded.
The following examples illustrate how Nping's Echo mode can be
used to discover intermediate devices.
Example 2. Discovering NAT devices
# nping --echo-client "public" echo.nmap.org --udp
Starting Nping ( https://nmap.org/nping )
SENT (1.0970s) UDP 10.1.20.128:53 > 178.79.165.17:40125 ttl=64 id=32523 iplen=28
CAPT (1.1270s) UDP 80.38.10.21:45657 > 178.79.165.17:40125 ttl=54 id=32523 iplen=28
RCVD (1.1570s) ICMP 178.79.165.17 > 10.1.20.128 Port unreachable (type=3/code=3) ttl=49 id=16619 iplen=56
[...]
SENT (5.1020s) UDP 10.1.20.128:53 > 178.79.165.17:40125 ttl=64 id=32523 iplen=28
CAPT (5.1335s) UDP 80.38.10.21:45657 > 178.79.165.17:40125 ttl=54 id=32523 iplen=28
RCVD (5.1600s) ICMP 178.79.165.17 > 10.1.20.128 Port unreachable (type=3/code=3) ttl=49 id=16623 iplen=56
Max rtt: 60.628ms | Min rtt: 58.378ms | Avg rtt: 59.389ms
Raw packets sent: 5 (140B) | Rcvd: 5 (280B) | Lost: 0 (0.00%)| Echoed: 5 (140B)
Tx time: 4.00459s | Tx bytes/s: 34.96 | Tx pkts/s: 1.25
Rx time: 5.00629s | Rx bytes/s: 55.93 | Rx pkts/s: 1.00
Nping done: 1 IP address pinged in 6.18 seconds
The output clearly shows the presence of a NAT device in the
client's local network. Note how the captured packet (CAPT)
differs from the SENT packet: the source address for the original
packets is in the reserved 10.0.0.0/8 range, while the address
seen by the server is 80.38.10.21, the Internet side address of
the NAT device. The source port was also modified by the device.
The line starting with RCVD corresponds to the responses
generated by the TCP/IP stack of the machine where the Echo
server is run.
Example 3. Discovering a transparent proxy
# nping --echo-client "public" echo.nmap.org --tcp -p80
Starting Nping ( https://nmap.org/nping )
SENT (1.2160s) TCP 10.0.1.77:41659 > 178.79.165.17:80 S ttl=64 id=3317 iplen=40 seq=567704200 win=1480
RCVD (1.2180s) TCP 178.79.165.17:80 > 10.0.1.77:41659 SA ttl=128 id=13177 iplen=44 seq=3647106954 win=16384 <mss 1460>
SENT (2.2150s) TCP 10.0.1.77:41659 > 178.79.165.17:80 S ttl=64 id=3317 iplen=40 seq=567704200 win=1480
SENT (3.2180s) TCP 10.0.1.77:41659 > 178.79.165.17:80 S ttl=64 id=3317 iplen=40 seq=567704200 win=1480
SENT (4.2190s) TCP 10.0.1.77:41659 > 178.79.165.17:80 S ttl=64 id=3317 iplen=40 seq=567704200 win=1480
SENT (5.2200s) TCP 10.0.1.77:41659 > 178.79.165.17:80 S ttl=64 id=3317 iplen=40 seq=567704200 win=1480
Max rtt: 2.062ms | Min rtt: 2.062ms | Avg rtt: 2.062ms
Raw packets sent: 5 (200B) | Rcvd: 1 (46B) | Lost: 4 (80.00%)| Echoed: 0 (0B)
Tx time: 4.00504s | Tx bytes/s: 49.94 | Tx pkts/s: 1.25
Rx time: 5.00618s | Rx bytes/s: 9.19 | Rx pkts/s: 0.20
Nping done: 1 IP address pinged in 6.39 seconds
In this example, the output is a bit more tricky. The absence of
error messages shows that the Echo client has successfully
established an Echo session with the server. However, no CAPT
packets can be seen in the output. This means that none of the
transmitted packets reached the server. Interestingly, a TCP
SYN-ACK packet was received in response to the first TCP-SYN
packet (and also, it is known that the target host does not have
port 80 open). This behavior reveals the presence of a
transparent web proxy cache server (which in this case is an old
MS ISA server).