1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
|
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 |<------------------------>|
| |
|
