mirror of
https://github.com/nmap/nmap.git
synced 2025-12-24 08:29:04 +00:00
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 length 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]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|