mirror of
https://github.com/nmap/nmap.git
synced 2025-12-15 04:09:01 +00:00
ed2ba4e168
If you have trouble updating after this revision you need to follow these instructions. You have probably just seen an error like this: svn: URL 'svn://svn.insecure.org/nping' of existing directory 'nping' does not match expected URL 'svn://svn.insecure.org/nmap/nping' This is caused by the replacement of SVN externals. Here's what you need to do. First, save any local changes you might have in the nping, nsock, nbase, ncat, and zenmap directories. (For example by running "cd nping; svn diff > ../nping.diff".) If you don't have any local changes you can skip this step. Then run these commands: rm -rf nping/ nsock/ nbase/ ncat/ zenmap/ svn update svn cleanup If all else fails, you can just delete your whole working directory and check out anew: svn co --username guest --password "" svn://svn.insecure.org/nmap There may be further discussion in the mailing list thread at http://seclists.org/nmap-dev/2011/q4/303.
742 lines
33 KiB
Plaintext
742 lines
33 KiB
Plaintext
+-----------------------------------------------------------------------------+
|
|
|
|
|
|
|
|
|
|
|
|
|
|
NPING ECHO PROTOCOL
|
|
|
|
|
|
|
|
|
|
PROTOCOL SPECIFICATION
|
|
|
|
Request for Comments
|
|
|
|
July 2009
|
|
|
|
|
|
|
|
|
|
|
|
Luis MartinGarcia
|
|
(luis.mgarc@gmail.com)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
+-----------------------------------------------------------------------------+
|
|
|
|
|
|
|
|
|
|
PREFACE
|
|
|
|
This document introduces Nping Echo Protocol, the protocol that has been
|
|
designed to support a new feature that allows Nping users to see what the
|
|
packets they send look like when they reach their destination.
|
|
|
|
|
|
|
|
TABLE OF CONTENTS
|
|
|
|
1. INTRODUCTION ..................................................... x
|
|
|
|
|
|
2. NPING ECHO PROTOCOL SPECIFICATION................................. x
|
|
|
|
2.1 General Packet Format.............. ........................... x
|
|
2.2 Field Description ............................................. x
|
|
2.3 Operation Codes ............................................... x
|
|
2.4 Operation HELLO................................................ x
|
|
2.5 Operation HELLO RESPONSE ...................................... x
|
|
2.6 Operation SPECS ............................................... x
|
|
2.7 Operation READY ............................................... x
|
|
2.8 Operation ECHOPKT ............................................. x
|
|
2.9 Operation QUIT ................................................ x
|
|
2.10 Flow Diagram .................................................. x
|
|
2.11 Security .......................................................x
|
|
|
|
3. GLOSSARY .......................................................... x
|
|
|
|
4. REFERENCES ........................................................ x
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1. 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 even
|
|
hping can't track down the problem alone. One generally have to turn to
|
|
Wireshark/tcpdump on one station and hping on the other but sometimes
|
|
it may be quite 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 mode called "Echo mode" (We are
|
|
still looking for a better name, suggestions are welcome), that will
|
|
give it the power of hping + tcpdump.
|
|
|
|
Both machines have to be running Nping, one of them 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 (including the link layer frame)
|
|
into our own protocol packet and sends it back to the nping 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.
|
|
|
|
|
|
|
|
2. NPING ECHO PROTOCOL SPECIFICATION
|
|
|
|
|
|
2.1 General Packet Format
|
|
|
|
0 1 2 3
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Version | OP Code | Total Length |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Sequence Number |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Reserved |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Reserved |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| |
|
|
. .
|
|
. DATA .
|
|
. .
|
|
| |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| |
|
|
. Checksum .
|
|
| |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
|
|
|
|
There are 6 different kinds of packets:
|
|
|
|
HELLO: (C->S)
|
|
Informs the server of the highest version we support.
|
|
|
|
HELLO RESPONSE: (S->C)
|
|
Informs the client of the highest version we support.
|
|
|
|
SPECS: (C->S):
|
|
Tells the server what kind of packets we are planning to send.
|
|
|
|
READY: (S->C):
|
|
Tells the client that the server is ready to start receiving
|
|
packets.
|
|
|
|
ECHOPKT: (S->C):
|
|
Contains the packet that the server receives from the client.
|
|
|
|
QUIT: (C->S or S->C):
|
|
Asks to stop the echo process.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2.2 Field Description
|
|
|
|
Version: 8 bits
|
|
Current version of the protocol. This document covers version 0x01.
|
|
|
|
|
|
Operation Code: 8 bits
|
|
Indicates the type of packet. It must be one of the operation
|
|
codes defined in section 2.2.
|
|
|
|
|
|
Total Length: 16 bits
|
|
Length of the entire packet, measured in 32bit words. Value must
|
|
be in NETWORK byte order.
|
|
|
|
|
|
Sequence Number: 32 bits
|
|
Initially each peer generates a random sequence number and then
|
|
increments it by one in each packet that it sends. It must be
|
|
in NETWORK byte order. This field is intented to provide some,
|
|
very basic, protection against replay attacks.
|
|
|
|
|
|
Reserved: 64 bits
|
|
Reserved for future use. Reserved fields have been added for two
|
|
reason. To allow future extension of the protocol and to make
|
|
the header a multiple of 128 bits needed to satisfy AES encryption
|
|
requirements in block size.
|
|
|
|
|
|
Data: variable length
|
|
Operation specific data.
|
|
|
|
|
|
Checksum: 256 bits
|
|
SHA-256 sum of the entire packet. Checksum computation includes
|
|
the checksum field which must be previously set to zero.
|
|
This field is intended to provide client authentication. Echo
|
|
messages are transmitted encrypted (unless Nping is compiled
|
|
without OpenSSL). When a server receives a packet, it decrypts it
|
|
using a symmetric key known by both ends. Then it verifies the
|
|
checksum. If the checksum is correct it assumes the client is
|
|
an authorized user because only a person who knows the encryption
|
|
key and is capable of generating packets that when decrypted
|
|
produce valid sums.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2.3 Operation Codes
|
|
|
|
Operation HELLO: 0x01
|
|
Operation HELLO RESPONSE: 0x02
|
|
Operation SPECS: 0x03
|
|
Operation READY: 0x04
|
|
Operation ECHOPKT: 0x05
|
|
Operation QUIT: 0x06
|
|
|
|
|
|
|
|
|
|
|
|
2.4 Operation HELLO
|
|
|
|
The HELLO packet is sent by the client and it asks the server
|
|
to establish a new session. The packet also informs the server
|
|
of the latest version of the protocol that the client supports.
|
|
|
|
0 1 2 3
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|
0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Version | OP Code 0x01 | Total Length |
|
|
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Sequence Number |
|
|
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Reserved |
|
|
3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Reserved | Reserved | IP version |
|
|
4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| |
|
|
5 +-- --+
|
|
| |
|
|
6 +-- Partner IP address --+
|
|
| |
|
|
7 +-- --+
|
|
| |
|
|
8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| |
|
|
9 +-- --+
|
|
| |
|
|
10 +-- Reserved --+
|
|
| |
|
|
11 +-- --+
|
|
| |
|
|
12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| |
|
|
. . .
|
|
. . SHA256 Checksum .
|
|
. . .
|
|
| |
|
|
20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
|
|
|
|
IP Version: 8 bits
|
|
IP version of the following IP address.
|
|
|
|
|
|
Partner IP address: 128 bits
|
|
This is the server's IP address as seen by the client. This is
|
|
not very useful but is provided for consistency with the HELLO
|
|
response packet.
|
|
This field has 128 bits to allow use of both IPv4 and IPv6
|
|
addresses. When IPv4 is used, only the first four bytes are used.
|
|
The rest may be set to zero or filled with random data.
|
|
|
|
Reserved: 128 bits
|
|
Reserved for future use.
|
|
|
|
|
|
|
|
|
|
2.5 Operation HELLO RESPONSE
|
|
|
|
The HELLO RESPONSE packet is sent by the server to indicate the client
|
|
that he is actually a Nping Echo server and to inform about the
|
|
latest version it supports.
|
|
|
|
0 1 2 3
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|
0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Version | OP Code 0x02 | Total Length |
|
|
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Sequence Number |
|
|
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Reserved |
|
|
3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Reserved | Reserved | IP version |
|
|
4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| |
|
|
5 +-- --+
|
|
| |
|
|
6 +-- Partner IP address --+
|
|
| |
|
|
7 +-- --+
|
|
| |
|
|
8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| |
|
|
9 +-- --+
|
|
| |
|
|
10 +-- Reserved --+
|
|
| |
|
|
11 +-- --+
|
|
| |
|
|
12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| |
|
|
. . .
|
|
. . SHA256 Checksum .
|
|
. . .
|
|
| |
|
|
20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
|
|
|
|
IP Version: 8 bits
|
|
IP version of the following IP address.
|
|
|
|
|
|
Partner IP address: 128 bits
|
|
This is the client's IP address as seen by the server. This
|
|
lets the client to inmediatly detect the presence of some
|
|
intermediate device that changes his source IP (e.g a NAT box).
|
|
This can also be useful in case the client wants to specify
|
|
its own BPF filter (overriding server's default behaviour)
|
|
(see section 2.5 for more information).
|
|
This field has 128 bits to allow use of both IPv4 and IPv6
|
|
addresses. When IPv4 is used, only the first four bytes are used.
|
|
The rest may be set to zero or filled with random data.
|
|
|
|
Reserved: 128 bits
|
|
Reserved for future use.
|
|
|
|
|
|
2.6 Operation SPECS
|
|
|
|
The SPECS packet is sent by the client to tell the server what kind
|
|
of packets it should expect. Additionally, the client may also include
|
|
a custom BPF filter for the server.
|
|
|
|
0 1 2 3
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|
0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Version | OP Code 0x03 | Total Length |
|
|
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Sequence Number |
|
|
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Reserved |
|
|
3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Protocol | Reserved | Packet Count |
|
|
4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
. | |
|
|
. . .
|
|
. . BPF filter specification .
|
|
n . .
|
|
| |
|
|
n+1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| |
|
|
. . .
|
|
. . SHA256 Checksum .
|
|
. . .
|
|
| |
|
|
n+9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
|
|
Protocol: 8 bits.
|
|
Specifies which kind of packets will be sent to the server. It
|
|
must contain one of the following values:
|
|
|
|
0x01 (Protocol TCP)
|
|
Tells the server to listen to TCP packets coming from
|
|
the client's IP address.
|
|
|
|
0x02 (Protocol UDP)
|
|
Tells the server to listen to UDP packets coming from
|
|
the client's IP address.
|
|
|
|
0x03 (Protocol ICMP)
|
|
Tells the server to listen to ICMP packets coming from
|
|
the client's IP address.
|
|
|
|
0x04 (Protocol ARP)
|
|
Tells the server to listen to ARP packets coming from
|
|
the client's MAC address (or in most cases, server's
|
|
gateway MAC address).
|
|
|
|
0xAA (Custom BPF filter included)
|
|
Tells the server to use a custom BPF filter specified in
|
|
an additional field.
|
|
|
|
0xFF (Any protocol)
|
|
Tells the server to listen to any packets coming from
|
|
the client's IP address.
|
|
|
|
Reserved: 8 bits
|
|
Reserved for future use.
|
|
|
|
|
|
Packet count: 16 bits.
|
|
Specifies how many packets will be sent. It must be in NETWORK
|
|
byte order.
|
|
|
|
|
|
BPF filter specification: variable length
|
|
|
|
When field "Protocol" contains value 0xAA, an additional
|
|
field is included in the packet: the BPF filter specification.
|
|
|
|
This field contains a BPF filter specification in tcpdump
|
|
format. This is useful when the client wants to override the
|
|
server's default BPF filters and capture a different type of
|
|
traffic.
|
|
|
|
0 1 2 3
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| BPF Filter Spec Length | .
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
|
|
. .
|
|
. BFP Filter Spec .
|
|
. +-+-+-+-+-+-+-+-+
|
|
| | Padding |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
The length is measured in bytes and should be in NETWORK byte
|
|
order. If the length is not a multiple of 16, it must be padded
|
|
with NULL bytes.
|
|
|
|
|
|
When client specifies an empty filter, meaning capture all
|
|
packets, the field will look like:
|
|
|
|
0 1 2 3
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Length=0 | Padding |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
|
|
As a security measure, the server may not allow use of
|
|
custom BPF filters. In that case, a QUIT packet must be
|
|
sent to the client.
|
|
|
|
|
|
|
|
|
|
2.7 Operation READY
|
|
|
|
The READY packet is sent by the server to indicate the client that
|
|
his SPECS packet was accepted and that everything is ready to start
|
|
receiving and echoing packets.
|
|
|
|
0 1 2 3
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|
0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Version | OP Code 0x04 | Total Length |
|
|
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Sequence Number |
|
|
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Reserved |
|
|
3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Reserved |
|
|
4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| |
|
|
. . .
|
|
. . SHA256 Checksum .
|
|
. . .
|
|
| |
|
|
12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
|
|
|
|
|
|
|
|
2.8 Operation ECHOPKT
|
|
|
|
The ECHOPKT packet is sent by the server and it contains an echoed
|
|
packet.
|
|
|
|
|
|
0 1 2 3
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|
0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Version | OP Code 0x05 | Total Length |
|
|
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Sequence Number |
|
|
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Reserved | Reserved |
|
|
4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| DLT Type | Packet Length |
|
|
5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
. . .
|
|
. . Packet .
|
|
. . .
|
|
n . +-+-+-+-+-+-+-+-+
|
|
| | Padding |
|
|
n+1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| |
|
|
. . .
|
|
. . SHA256 Checksum .
|
|
. . .
|
|
| |
|
|
n+9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
|
|
|
|
DLT Type: 16 bits.
|
|
Specifies the type of link layer device used in the server side.
|
|
Since the server includes link layer frames in echoed packets,
|
|
the client needs to know the DLT in order to process link layer
|
|
header information.
|
|
Values used in this field must match DLT types defined in libpcap
|
|
and must be transmitted in NETWORK byte order.
|
|
|
|
Packet Length: 16 bits.
|
|
Specifies the length of the echoed packet measured in bytes.
|
|
It must be in NETWORK byte order.
|
|
|
|
Packet: variable length.
|
|
This corresponds to the packet being echoed. Server should
|
|
store the packet exactly as it was received. No byte order
|
|
conversions or any other alteration should be performed.
|
|
If the length is not a multiple of 16, it must be padded with
|
|
NULL bytes.
|
|
|
|
|
|
|
|
2.9 Operation QUIT
|
|
|
|
The QUIT packet is sent by client or server to tell its peer to
|
|
terminate the current session.
|
|
|
|
0 1 2 3
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|
0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Version | OP Code 0x06 | Total Length |
|
|
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Sequence Number |
|
|
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Reserved |
|
|
3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Reserved |
|
|
4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| |
|
|
. . .
|
|
. . SHA256 Checksum .
|
|
. . .
|
|
| |
|
|
12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
|
|
This packet should be sent:
|
|
By the client: to tell the server to stop echoing packets and
|
|
terminate the current session.
|
|
|
|
By the server: to tell the client that no custom BPF filter
|
|
is allowed so the session will be terminated.
|
|
|
|
|
|
2.10 Flow diagram
|
|
|
|
|
|
The following diagram represents a typical session:
|
|
|
|
+------+ +------+
|
|
|CLIENT| |SERVER|
|
|
+------+ +------+
|
|
| |
|
|
| HELLO | :: Hi. I'm an Nping Client.
|
|
|------------------>>| I support version 1.
|
|
| |
|
|
| |
|
|
| HELLO RESPONSE |
|
|
|<<------------------| :: Nice 2 meet u. Im a server..
|
|
| | I also support version 1
|
|
| |
|
|
| SPECS |
|
|
|------------------>>| :: I'll be sending 5 ICMP
|
|
| | Destination Unreachable probes.
|
|
| |
|
|
| |
|
|
| READY |
|
|
|<<-- ---------------| :: OK, I'm ready for those probes.
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| ECHOPKT |
|
|
|<<------------------| :: Here's what I received.
|
|
| |
|
|
| ECHOPKT |
|
|
|<<------------------| :: Here's what I received.
|
|
| |
|
|
| ECHOPKT |
|
|
|<<------------------| :: Here's what I received.
|
|
| . |
|
|
| . |
|
|
| . |
|
|
| ECHOPKT |
|
|
|<<------------------| :: Here's what I received.
|
|
| |
|
|
| |
|
|
| |
|
|
| QUIT |
|
|
|------------------>>| :: It's been a pleasure.
|
|
|
|
|
|
|
|
|
|
The following diagram represents a session where the client requests
|
|
the use of a custom BPF filter but the server is configured not to
|
|
allow it.
|
|
|
|
+------+ +------+
|
|
|CLIENT| |SERVER|
|
|
+------+ +------+
|
|
| |
|
|
| HELLO | :: Hi. I'm an Nping Client.
|
|
|------------------>>| I support version 1.
|
|
| |
|
|
| |
|
|
| HELLO RESPONSE |
|
|
|<<------------------| :: Nice 2 meet u. Im a server..
|
|
| | I also support version 1
|
|
| |
|
|
| SPECS |
|
|
|------------------>>| :: Use this BPF filter (tcp and udp)
|
|
| |
|
|
| |
|
|
| |
|
|
| QUIT |
|
|
|<<-- ---------------| :: Sorry, no custom BPF allowed.
|
|
|
|
|
|
2.11 Security
|
|
|
|
The Nping Echo functionality involves direct access to network traffic
|
|
on the server side and that can easily involve information leakage
|
|
problems if no security measures are taken.
|
|
|
|
Unless Nping is compiled without OpenSSL support, all Nping Echo
|
|
Protocol (NEP) packets are transmitted encrypted. Rijndael/AES standard
|
|
is used. It has a block size of 128 bits, that's why all NEP packets
|
|
must have a lenght that is multiple of 16 bytes.
|
|
|
|
Every NEP packet includes a SHA-256 checksum. SHA-256 has been chosen
|
|
over MD5 or SHA1, just to be safe in the future. MD5 is already broken
|
|
and some studies show important advances in SHA1 attacks.
|
|
|
|
As described above, client authentication is performed using the
|
|
checksum field. The server assumes only a client in possesion of the
|
|
correct encryption key is capable of producing packets that, when
|
|
decrypted, contain valid SHA-256 checksum. However, replay attacks
|
|
may be possible in this scheme. A small 32bit Sequence field is
|
|
included in every packet. In theory, the server could have a list
|
|
of sequence numbers that have already been used and deny connection
|
|
to clients that use replayed packets. However, a 32 bit space may not
|
|
be sufficiently large to provide security, and exhaustion of sequence
|
|
numbers may result in a denial of service for authorized clients.
|
|
|
|
If we set the "Reserved" field (56 bits) in the initial HELLO packet
|
|
to some random value, and we instruct the server to keep a list of
|
|
both, sequence numbers and checksums, then it is possible that the
|
|
tuple (seq, checksum) provides enough security while significantly
|
|
reducing the possibility of client denial of service. We can even use
|
|
(seq, rand, checksum) where "rand" is the random data included in
|
|
the reserved space.
|
|
|
|
The problem with replay attacks is not tremendously important because,
|
|
at the end of the day, an attacker that does not have the encryption
|
|
key and therefore cannot see the contents of the ECHOPKT packets.
|
|
However, if the attacker replays old packets to establish a new
|
|
connection, the server will send him some data whenever he captures
|
|
a packet, and the fact the it has actually captured a packet can give
|
|
the attacker enough information to tell if the server is behind a
|
|
firewall, etc.
|
|
|
|
Security aspects are not yet defined properly. Any comments and
|
|
suggestions are welcome.
|
|
|
|
|
|
|
|
3. GLOSSARY
|
|
|
|
4. REFERENCES
|
|
|
|
[1]
|
|
|
|
[2]
|
|
|
|
[3]
|
|
|
|
[4]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|