1: N.B.: this HOWTO is not completed and in some points very silly. I leave this
2: here only because maybe it's better that nothing.
3:
4: HPING2 HOWTO
5:
6: Changes Log
7: -----------
8: Aug 7 1999 vi HPING2-HOWTO.txt
9: Aug 8 1999 __0000, __0001, __0002, __0003
10: Aug 10 1999 __0004
11:
12: Index
13: -----
14: [search __XXXX in order to jump to point you want]
15:
16: __0000: Copyright notice
17: __0001: What is hping?
18: __0002: What i need to know about TCP/IP in order to use hping?
19: __0003: First step with hping
20: __0004: IP id and how to scan TCP ports using spoofing.
21: __0005: How to test firewall rules. (TODO)
22: __0006: How to trasfer files accross firewall. (TODO)
23:
24: __000A: hping usage example (TODO)
25:
26: __0000: Copyright notice, License, and all that stuff
27:
28: Copyright (C) Salvatore Sanfilippo, 1999.
29:
30: Permission is granted to make and distribute copies of this manual
31: provided the copyright notice and this permission notice are preserved
32: on all copies.
33:
34: Permission is granted to copy and distribute modified versions of this
35: manual under the conditions for verbatim copying, provided that the
36: derived work is distributed under the terms of a permission notice
37: identical to this one. Translations fall under the catagory of
38: ``modified versions.''
39:
40: Warranty: None.
41:
42: Recommendations: Commercial redistribution is allowed and encouraged;
43: however, it is strongly recommended that the redistributor contact the
44: author before the redistribution, in the interest of keeping things
45: up-to-date (you could send me a copy of the thing you're making while
46: you're at it). Translators are also advised to contact the author
47: before translating. The printed version looks nicer. Recycle.
48:
49: __0001: What is hping?
50:
51: Hping is a software to do TCP/IP stack auditing, to uncover firewall
52: policy, to scan TCP port in a lot of different modes, to transfer
53: files accross a firewall and many other stuff. Using hping you are
54: able to do even a lot of not security-regarding stuff. For example you
55: can test networks performance, check if a host is up, check if TOS
56: is handled et cetera.
57:
58: __0002: What i need to know about TCP/IP in order to use hping?
59:
60: If you know TCP/IP you will find hping very usefull, otherwise
61: you can use hping only to do well known tests. See __000A for
62: some example.
63:
64: __0003: First step with hping
65:
66: The simplest usage of hping is the following:
67:
68: #hping host
69:
70: This command sends a TCP null-flags packet to port 0 of target
71: host every second and show the host replies. For example:
72:
73: # hping www.debian.org
74: ppp0 default routing interface selected (according to /proc)
75: HPING www.debian.org (ppp0 209.81.8.242): NO FLAGS are set, 40 headers + 0 data bytes
76: 40 bytes from 209.81.8.242: flags=RA seq=0 ttl=243 id=63667 win=0 time=369.4 ms
77: 40 bytes from 209.81.8.242: flags=RA seq=1 ttl=243 id=63719 win=0 time=420.0 ms
78: 40 bytes from 209.81.8.242: flags=RA seq=2 ttl=243 id=63763 win=0 time=350.0 ms
79: [Ctrl+C]
80: --- www.debian.org hping statistic ---
81: 3 packets tramitted, 3 packets received, 0% packet loss
82:
83: As you can see host replies with a TCP packet with RST and ACK flags
84: set. So you are able to perform a 'TCP ping', usefull when ICMPs are
85: filtered. By default port 0 are used because it's very strange that
86: is in LISTEN state. If we send a TCP null-flags to a port in
87: LISTEN state a lot of TCP/IP stack will not send any reply. So we are
88: able to know if a port is in LISTEN state. For example:
89:
90: # hping www.debian.org -p 80
91: ppp0 default routing interface selected (according to /proc)
92: HPING www.debian.org (ppp0 209.81.8.242): NO FLAGS are set, 40 headers + 0 data bytes
93: [Ctrl+C]
94: --- www.debian.org hping statistic ---
95: 5 packets trasmitted, 0 packets received, 100% packet loss
96:
97: Since port 80 of www.debian.org is in LISTEN mode we got
98: no response.
99:
100: But What's happen if we try to hping a firewalled port? This depends
101: on firewall policy/implementation. Usually we get an ICMP or
102: nothing. For example:
103:
104: # hping www.yahoo.com -p 79
105: ppp0 default routing interface selected (according to /proc)
106: HPING www.yahoo.com (ppp0 204.71.200.67): NO FLAGS are set, 40 headers + 0 data bytes
107: ICMP Packet filtered from 206.132.254.41 (pos1-0-2488M.hr8.SNV.globalcenter.net)
108:
109: --- www.yahoo.com hping statistic ---
110: 14 packets tramitted, 0 packets received, 100% packet loss
111:
112: yahoo firewall doesn't allow connection to port 79, so reply with
113: an ICMP Packet filtered (ICMP unreachable code 13). However
114: there are a lot of firewall that simply drop the packet. For example:
115:
116: # hping www.microsoft.com -p 79
117: ppp0 default routing interface selected (according to /proc)
118: HPING www.microsoft.com (ppp0 207.46.130.150): NO FLAGS are set, 40 headers + 0 data bytes
119:
120: --- www.microsoft.com hping statistic ---
121: 4 packets tramitted, 0 packets received, 100% packet loss
122:
123: No reply from microsoft. Is the port firewalled or in LISTEN mode?
124: To uncover this is very simply. Just we try to set ACK flag instead
125: to send a TCP null-flag packet. If the host respond maybe this port
126: is in LISTEN mode (but it's possible that there is a rules that
127: deny null-flag TCP packet but allow ACK).
128:
129: # hping www.microsoft.com -A -p 79
130: ppp0 default routing interface selected (according to /proc)
131: HPING www.microsoft.com (ppp0 207.46.130.149): A set, 40 headers + 0 data bytes
132:
133: --- www.microsoft.com hping statistic ---
134: 3 packets tramitted, 0 packets received, 100% packet loss
135:
136: No response again, So this port seems to be filtered. Anyway
137: it's possible that microsoft is using an 'intelligent' firewall
138: that know that in order to connect first I must send a SYN.
139:
140: # hping www.microsoft.com -S -p 79
141: ppp0 default routing interface selected (according to /proc)
142: HPING www.microsoft.com (ppp0 207.46.130.149): S set, 40 headers + 0 data bytes
143:
144: --- www.microsoft.com hping statistic ---
145: 3 packets tramitted, 0 packets received, 100% packet loss
146:
147: Ok.. seems that port 79 of microsoft is really filtered.
148: Just for clearness we send some ACK to port 80 of www.debian.org:
149:
150: # hping www.debian.org -p 80 -A
151: ppp0 default routing interface selected (according to /proc)
152: HPING www.debian.org (ppp0 209.81.8.242): A set, 40 headers + 0 data bytes
153: 40 bytes from 209.81.8.242: flags=R seq=0 ttl=243 id=5590 win=0 time=379.5 ms
154: 40 bytes from 209.81.8.242: flags=R seq=1 ttl=243 id=5638 win=0 time=370.0 ms
155: 40 bytes from 209.81.8.242: flags=R seq=2 ttl=243 id=5667 win=0 time=360.0 ms
156:
157: --- www.debian.org hping statistic ---
158: 3 packets tramitted, 3 packets received, 0% packet loss
159:
160: We can see replies even if port 80 is in LISTEN mode because
161: a port in LISTEN mode may not replay only to NULL, FIN, Xmas, Ymas
162: flags TCP packet. ACK and RST are two important TCP flags that
163: allow to do ACL tests and to guess ip->id without to produce any log
164: (usually).
165:
166: __0004: IP id and how to scan TCP ports using spoofing.
167:
168: Every IP packet is identified by a 16 bit id. Thanks to this id
169: IP stacks are able to handle fragmentation. A lot of OSs handle
170: ip->id travially: just increment by 1 this id for each packet sent.
171: Using this id you are able at least to estimate hosts traffic and to
172: scan with spoofed packets. OpenBSD >= 2.5 and many others implement
173: a random not repetitive id so you aren't able to joke with ip->id.
174: Win* ip->id has different byte ordering, so you must specify
175: --winid or -W option if you are using hping2 against Win*.
176:
177: N.B.: You are able to scan spoofed hosts with safe/random ip->id
178: because in order to spoof your packets you need a third
179: part host with incremental id rule but you don't need that
180: target of your scanning has an incremental id.
181:
182: How to estimate host traffic using ip->id? It's really simple:
183:
184: # hping www.yahoo.com -p 80 -A
185: ppp0 default routing interface selected (according to /proc)
186: HPING www.yahoo.com (ppp0 204.71.200.74): A set, 40 headers + 0 data bytes
187: 40 bytes from 204.71.200.74: flags=R seq=0 ttl=53 id=29607 win=0 rtt=329.4 ms
188: 40 bytes from 204.71.200.74: flags=R seq=1 ttl=53 id=31549 win=0 rtt=390.0 ms
189: 40 bytes from 204.71.200.74: flags=R seq=2 ttl=53 id=33432 win=0 rtt=390.0 ms
190: 40 bytes from 204.71.200.74: flags=R seq=3 ttl=53 id=35368 win=0 rtt=380.0 ms
191: 40 bytes from 204.71.200.74: flags=R seq=4 ttl=53 id=37335 win=0 rtt=390.0 ms
192: 40 bytes from 204.71.200.74: flags=R seq=5 ttl=53 id=39157 win=0 rtt=380.0 ms
193: 40 bytes from 204.71.200.74: flags=R seq=6 ttl=53 id=41118 win=0 rtt=370.0 ms
194: 40 bytes from 204.71.200.74: flags=R seq=7 ttl=53 id=43330 win=0 rtt=390.0 ms
195:
196: --- www.yahoo.com hping statistic ---
197: 8 packets tramitted, 8 packets received, 0% packet loss
198: round-trip min/avg/max = 329.4/377.4/390.0 ms
199:
200: As you can se id field increase. Packet with sequence 0 has id=29607,
201: sequence 1 has id=31549, so www.yahoo.com host sent 31549-29607 = 1942
202: packets in circa one second. Using -r|--relid option hping output
203: id field as difference between last and current received packet id.
204:
205: # hping www.yahoo.com -P 80 -A -r
206: ppp0 default routing interface selected (according to /proc)
207: HPING www.yahoo.com (ppp0 204.71.200.68): A set, 40 headers + 0 data bytes
208: 40 bytes from 204.71.200.68: flags=R seq=0 ttl=53 id=65179 win=0 rtt=327.1 ms
209: 40 bytes from 204.71.200.68: flags=R seq=1 ttl=53 id=+1936 win=0 rtt=360.0 ms
210: 40 bytes from 204.71.200.68: flags=R seq=2 ttl=53 id=+1880 win=0 rtt=340.0 ms
211: 40 bytes from 204.71.200.68: flags=R seq=3 ttl=53 id=+1993 win=0 rtt=330.0 ms
212: 40 bytes from 204.71.200.68: flags=R seq=4 ttl=53 id=+1871 win=0 rtt=350.0 ms
213: 40 bytes from 204.71.200.68: flags=R seq=5 ttl=53 id=+1932 win=0 rtt=340.0 ms
214: 40 bytes from 204.71.200.68: flags=R seq=6 ttl=53 id=+1776 win=0 rtt=330.0 ms
215: 40 bytes from 204.71.200.68: flags=R seq=7 ttl=53 id=+1749 win=0 rtt=320.0 ms
216: 40 bytes from 204.71.200.68: flags=R seq=8 ttl=53 id=+1888 win=0 rtt=340.0 ms
217: 40 bytes from 204.71.200.68: flags=R seq=9 ttl=53 id=+1907 win=0 rtt=330.0 ms
218:
219: --- www.yahoo.com hping statistic ---
220: 10 packets tramitted, 10 packets received, 0% packet loss
221: round-trip min/avg/max = 320.0/336.7/360.0 ms
222:
223: Obviously checking the id every 1/2 second instead of 1 second, increment
224: will be half.
225:
226: # hping www.yahoo.com -P 80 -A -r -i u 500000
227: ppp0 default routing interface selected (according to /proc)
228: HPING www.yahoo.com (ppp0 204.71.200.68): A set, 40 headers + 0 data bytes
229: 40 bytes from 204.71.200.68: flags=R seq=0 ttl=53 id=35713 win=0 rtt=327.0 ms
230: 40 bytes from 204.71.200.68: flags=R seq=1 ttl=53 id=+806 win=0 rtt=310.0 ms
231: 40 bytes from 204.71.200.68: flags=R seq=2 ttl=53 id=+992 win=0 rtt=320.0 ms
232: 40 bytes from 204.71.200.68: flags=R seq=3 ttl=53 id=+936 win=0 rtt=330.0 ms
233: 40 bytes from 204.71.200.68: flags=R seq=4 ttl=53 id=+987 win=0 rtt=310.0 ms
234: 40 bytes from 204.71.200.68: flags=R seq=5 ttl=53 id=+952 win=0 rtt=320.0 ms
235: 40 bytes from 204.71.200.68: flags=R seq=6 ttl=53 id=+918 win=0 rtt=330.0 ms
236: 40 bytes from 204.71.200.68: flags=R seq=7 ttl=53 id=+809 win=0 rtt=320.0 ms
237: 40 bytes from 204.71.200.68: flags=R seq=8 ttl=53 id=+881 win=0 rtt=320.0 ms
238:
239: --- www.yahoo.com hping statistic ---
240: 9 packets tramitted, 9 packets received, 0% packet loss
241: round-trip min/avg/max = 310.0/320.8/330.0 ms
242:
243: N.B. Warning, using ip->id you are able only to guess *the number
244: of packets sent/time*. You can't always compare different hosts.
245: ip->id refers to all host interfaces and for example if an host
246: use NAT or redirect TCP connections to another host (for example
247: a firewall used to hide a web server) ip->id increment may
248: result fakely increased.
249:
250: hpinging windows box without using --winid option you will see as
251: increments are 256 multiple because different id byteordering. This
252: can be really usefull for OS fingerprinting:
253:
254: #hping win95 -r
255: HPING win95 (eth0 192.168.4.41): NO FLAGS are set, 40 headers + 0 data bytes
256: 46 bytes from 192.168.4.41: flags=RA seq=0 ttl=128 id=47371 win=0 rtt=0.5 ms
257: 46 bytes from 192.168.4.41: flags=RA seq=1 ttl=128 id=+256 win=0 rtt=0.5 ms
258: 46 bytes from 192.168.4.41: flags=RA seq=2 ttl=128 id=+256 win=0 rtt=0.6 ms
259: 46 bytes from 192.168.4.41: flags=RA seq=3 ttl=128 id=+256 win=0 rtt=0.5 ms
260:
261: --- win95 hping statistic ---
262: 4 packets tramitted, 4 packets received, 0% packet loss
263: round-trip min/avg/max = 0.5/0.5/0.6 ms
264:
265: Windows systems are "marked", so in order to discovery if an host is
266: a Windows host you need to send just some packet.
267:
268: How to perform spoofed SYN scan using incremental id? The following
269: is the original message to bugtraq about spoofed/indirect/idle scan method,
270: bottom i'll try to explain details and how this is possible even with UDP
271: with some restriction.
272:
273: ---- bugtraq posting about spoofed scanning ----
274:
275: Hi,
276:
277: I have uncovered a new tcp port scan method.
278: Instead all others it allows you to scan using spoofed
279: packets, so scanned hosts can't see your real address.
280: In order to perform this i use three well known tcp/ip
281: implementation peculiarities of most OS:
282:
283: (1) * hosts reply SYN|ACK to SYN if tcp target port is open,
284: reply RST|ACK if tcp target port is closed.
285:
286: (2) * You can know the number of packets that hosts are sending
287: using id ip header field. See my previous posting 'about the ip
288: header' in this ml.
289:
290: (3) * hosts reply RST to SYN|ACK, reply nothing to RST.
291:
292:
293: The Players:
294:
295: host A - evil host, the attacker.
296: host B - silent host.
297: host C - victim host.
298:
299: A is your host.
300: B is a particular host: It must not send any packets while
301: you are scanning C. There are a lot of 'zero traffic' hosts
302: in internet, especially in the night :)
303: C is the victim, it must be vulnerable to SYN scan.
304:
305: I've called this scan method 'dumb host scan' in honour of host
306: B characteristics.
307:
308:
309: How it works:
310:
311: Host A monitors number of outgoing packets from B using id iphdr.
312: You can do this simply using hping:
313:
314: #hping B -r
315: HPING B (eth0 xxx.yyy.zzz.jjj): no flags are set, 40 data bytes
316: 60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=0 ttl=64 id=41660 win=0 time=1.2 ms
317: 60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=1 ttl=64 id=+1 win=0 time=75 ms
318: 60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=2 ttl=64 id=+1 win=0 time=91 ms
319: 60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=3 ttl=64 id=+1 win=0 time=90 ms
320: 60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=4 ttl=64 id=+1 win=0 time=91 ms
321: 60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=5 ttl=64 id=+1 win=0 time=87 ms
322: -cut-
323: ..
324: .
325:
326: As you can see, id increases are always 1. So this host have the
327: characteristics that host B should to own.
328:
329: Now host A sends SYN to port X of C spoofing from B.
330: (using hping => 0.67 is very easy, http://www.kyuzz.org/antirez)
331: if port X of C is open, host C will send SYN|ACK to B (yes,
332: host C don't know that the real sender is A). In this
333: case host B replies to SYN|ACK with a RST.
334: If we send to host C a few of SYN it will reply to B with a few
335: of SYN|ACK, so B will reply to C a few of RST... so
336: we'll see that host B is sending packets!
337:
338: .
339: ..
340: -cut-
341: 60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=17 ttl=64 id=+1 win=0 time=96 ms
342: 60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=18 ttl=64 id=+1 win=0 time=80 ms
343: 60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=19 ttl=64 id=+2 win=0 time=83 ms
344: 60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=20 ttl=64 id=+3 win=0 time=94 ms
345: 60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=21 ttl=64 id=+1 win=0 time=92 ms
346: 60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=22 ttl=64 id=+2 win=0 time=82 ms
347: -cut-
348: ..
349: .
350:
351: The port is open!
352:
353: Instead, if port X of C is closed sending to C a few
354: of SYN spoofed from B, it will reply with RST to B, and
355: B will not reply (see 3). So we'll see that host B is not sending
356: any packet:
357:
358: .
359: ..
360: -cut-
361: 60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=52 ttl=64 id=+1 win=0 time=85 ms
362: 60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=53 ttl=64 id=+1 win=0 time=83 ms
363: 60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=54 ttl=64 id=+1 win=0 time=93 ms
364: 60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=55 ttl=64 id=+1 win=0 time=74 ms
365: 60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=56 ttl=64 id=+1 win=0 time=95 ms
366: 60 bytes from xxx.yyy.zzz.jjj: flags=RA seq=57 ttl=64 id=+1 win=0 time=81 ms
367: -cut-
368: ..
369: .
370:
371: The port is closed.
372:
373: All this can appear complicated to perform, but using two sessions
374: of hping on Linux virtual consoles or under X makes it more simple.
375: First session listen host B: hping B -r
376: Second session send spoofed SYN: hping C -a B -S
377:
378: Sorry if my english is not so clear.
379: However this posting is not adequate to describe exaustively
380: this scan method, so i'll write a paper on this topic, specially
381: about how to implement this in a port scanner (i.e. nmap), and
382: about players characteristics and OS used.
383:
384: happy new year,
385: antirez
386:
387: ---- EOF ----
388:
389: As you can see spoofed scanning is travial to perform, especially
390: unsing hping2 you are able to specify micro seconds interval (-i uX)
391: so you don't need that B host is a totally idle host. You may read
392: id increment once every second sending 10 SYN every second. If you
393: send an adequate SYNnumber/second expected id increment is so big
394: that you are able to see if port is open or closed even if B host
395: is sending other packets. Example:
396:
397: # hping awake.host.org -p 80 -A -r
398: ppp0 default routing interface selected (according to /proc)
399: HPING server.alicom.com (ppp0 111.222.333.44): A set, 40 headers + 0 data bytes
400: 40 bytes from 111.222.333.44: flags=R seq=0 ttl=249 id=47323 win=0 rtt=239.7 ms
401: 40 bytes from 111.222.333.44: flags=R seq=1 ttl=249 id=+6 win=0 rtt=630.0 ms
402: 40 bytes from 111.222.333.44: flags=R seq=2 ttl=249 id=+6 win=0 rtt=280.0 ms
403: 40 bytes from 111.222.333.44: flags=R seq=3 ttl=249 id=+8 win=0 rtt=340.0 ms
404: 40 bytes from 111.222.333.44: flags=R seq=4 ttl=249 id=+5 win=0 rtt=440.0 ms
405: 40 bytes from 111.222.333.44: flags=R seq=5 ttl=249 id=+5 win=0 rtt=410.0 ms
406: 40 bytes from 111.222.333.44: flags=R seq=6 ttl=249 id=+8 win=0 rtt=1509.9 ms
407: 40 bytes from 111.222.333.44: flags=R seq=7 ttl=249 id=+4 win=0 rtt=1460.0 ms
408: 40 bytes from 111.222.333.44: flags=R seq=8 ttl=249 id=+7 win=0 rtt=770.0 ms
409: 40 bytes from 111.222.333.44: flags=R seq=9 ttl=249 id=+5 win=0 rtt=230.0 ms
410: ...
411:
412: as you can see this host isn't in idle, it sends ~ 6 packets every second.
413: Now scan www.yahoo.com's port 80 to see if it's open:
414:
415: root.1# hping -a server.alicom.com -S -p 80 -i u10000 www.yahoo.com
416: ppp0 default routing interface selected (according to /proc)
417: HPING www.yahoo.com (ppp0 204.71.200.74): S set, 40 headers + 0 data bytes
418:
419: [wait some second and press CTRL+C]
420:
421: --- www.yahoo.com hping statistic ---
422: 130 packets tramitted, 0 packets received, 100% packet loss
423: round-trip min/avg/max = 0.0/0.0/0.0 ms
424:
425: Looking output of 'hping awake.host.org -p 80 -A -r' it's
426: simple to understand that www.yahoo.com's port 80 is open:
427:
428: 40 bytes from 111.222.333.44: flags=R seq=59 ttl=249 id=+16 win=0 rtt=380.0 ms
429: 40 bytes from 111.222.333.44: flags=R seq=60 ttl=249 id=+75 win=0 rtt=850.0 ms
430: 40 bytes from 111.222.333.44: flags=R seq=61 ttl=249 id=+12 win=0 rtt=1050.0 ms
431: 40 bytes from 111.222.333.44: flags=R seq=62 ttl=249 id=+1 win=0 rtt=450.0 ms
432: 40 bytes from 111.222.333.44: flags=R seq=63 ttl=249 id=+27 win=0 rtt=230.0 ms
433: 40 bytes from 111.222.333.44: flags=R seq=64 ttl=249 id=+11 win=0 rtt=850.0 ms
434:
435: note that 16+75+12+27+11+1-6 = 136 and that we sent 130 packets. So it's
436: very realistic that increments are produced by our packtes.
437:
438: Tips: Using an idle host to perform spoofed scanning it's usefull to
439: output only replies that show an increment != 1. Try
440: `hping host -r | grep -v "id=+1"'
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>
![[BACK]](/icons/cvsweb/back.gif){kind=icon}
Return to HPING2-HOWTO.txt CVS log ![[TXT]](/icons/cvsweb/text.gif){kind=icon}
![[DIR]](/icons/cvsweb/dir.gif){kind=icon}
Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / hping2 / docs