I'd like to start by saying that I will be covering many of the basic functions along with examples and explanations why you would want to use the tool in each scenario. In addition, I will hit on several advanced features for those who are familiar with the tool but not to the point where advanced knowledge of the application is grasped. I will be borrowing verbage (in some cases) from the developer because I feel that the developer has worded things in such ways that I cannot improve upon. By no means is this a cut & paste tutorial but I would like to make everyone aware that I will be borrowing info where it makes sense. For those who have been around here for awhile, you know that I preface my tutorials with this advanced warning in the event that someone finds a sentence or two from the original man pages for the app.

SCOPE: Part 1 in a series of 5 – Basic Port and Host Probing
The scope of this tutorial is limited to the more popular options used with packet crafting. I will not be covering *every* switch and combination thereof or I would be writing a 500 page book. If there is a particular switch/switch combo you don’t see covered, PM me and I will be happy to write a companion tutorial. Also, HPING has many other uses (port scanner, stack auditing, fire-walking, etc., etc.). I am also going to assume that readers of this tutorial already have a firm grasp on networking and standard protocols. If you do not, you wont benefit much from this series of tutorials. Like my NMAP series, I will start with very basic techniques and ramp up to the more complex in the last two. Again, all input, good or bad, is welcome.

Tool: HPING:

Using HPING for host detection begins with just sending a packet and waiting for the reply. If no reply is received, the host is down, the packet has been filtered or the packet has been dropped. We will use this rule of thumb throughout the series of tutorials. Also, unless otherwise noted, the target host is going to be a W2K3 server.


TCP SYN Packet Probe:
Packets with the SYN bit flagged typically won't be filtered or dropped if the target port is open. Normally, an open port will receive this packet and return the expected SYN/ACK-flagged packet. Closed ports will normally return a packet flagged with the RST/ACK bits set. Let’s try this command out.

[root@HorseyLand-Labs]#hping -S -c 1 -p 21

Switches defined:
-S = Set the SYN flag.
-c 1 = Packet count. In this example, I only sent one.
- p 21 = The port on the remote host I want to send the packet to.

HPING (eth0 S set, 40 headers + 0 data bytes
len=46 ip= ttl=128 DF id=25618 sport=21 flags=SA seq=0 win=16616 rtt=0.4 ms

NOTE: The return packet info begins with len=46.

The above packet was sent to a host to check if port 21 (File Transfer Protocol) is open, and apparently it was. As we expected, a packet was returned with the SYN/ACK bits flagged. Of course the remote host is now expecting another packet from your host with the ACK bit flagged in order to complete the 3-way handshake required for TCP/IP connections.

Let’s dissect the information returned and see what each item means.

S set – The SYN flag is set.
40 headers + 0 data bytes – Shows you that no data was added to the body of the packet.
len - The size, in bytes, of the data captured from the data link layer excluding the data link header size. This may not match the IP datagram size due to low level transport layer padding.
ip – The target IP address.
ttl – The default time-to-live setting on the packet. It will hop 128 times before dropping off the face of the Earth.
DF - The “don’t fragment” bit is set
id = This is the IP identification
sport = This is the target port
flags = The flags set on the response
seq = The sequence 32bit number in the TCP header.
win = The TCP window size.
rtt = round trip time in milliseconds.

Now that you see what a normal response is to a SYN packet sent to an open port, let’s try to send the same packet to a closed port.

[root@HorseyLand-Labs]#hping -S –c 1 -p 2

HPING (eth0 S set, 40 headers + 0 data bytes
len=46 ip= ttl=128 DF id=25927 sport=2 flags=RA seq=0 win=16616 rtt=0.5 ms

The above packet, flagged with the SYN bit was sent to a closed port, port 2. Notice that the RST/ACK flag is set on the return packet. This is the expected behavior because the port is not accepting TCP/IP connections

TCP ACK packet: Is the host alive?

When a packet with the ACK (acknowledge) bit flagged is sent to a host, if the host is alive, it should respond with another packet with the RST (reset) bit flagged. The beauty of this technique is that it doesn't make a difference whether the port you sent the ACK-flagged packet to is open or closed. If the host is alive, it should respond with a RST-flagged packet.

NOTE: Many vendors are aware of this technique and have built in mechanisms to defeat it.

[root@HorseyLand-Labs]#hping -A –c 1 -p 123

Switches defined:
-A = Set the ACK flag.
-c 1 = Packet count. In this example, I only sent one.
- p 123 = The port on the remote host I want to send the packet to.

HPING (eth0 A set, 40 headers + 0 data bytes
len=46 ip= ttl=128 id=26250 sport=123 flags=R seq=0 win=0 rtt=1.3 ms

Notice the returned packet, flagged with the RST (reset) bit flagged. This indicates that our host is alive and that TCP ACK-flagged packets are allowed through.

TCP SYN/ACK packet: Another way to see if the host is alive.

This technique sends a packet with the SYN and ACK bits flagged. This technique is geared more towards host operating system detection but I wanted to mention it here for two reasons. One, because you can use it to see if a host is alive and two, I want you to become familiar with it for later use. When a host receives a packet flagged with the SYN/ACK bits, it returns a packet flagged with the RST bit flagged. This will be the case whenever a port is open or closed.

[root@HorseyLand-Labs]#hping -SA –c 1 -p 123

HPING (eth0 SA set, 40 headers + 0 data bytes
len=46 ip= ttl=62 DF id=266 sport=123 flags=R seq=0 win=0 rtt=0.3 ms

By now you should be able to identify the switches I’m using. In later tutorials, I will not reference basic switches as I did early in this tutorial.

That’s all for part I. Look for part II within the next week or so.