hping3 – Network Scanning Tool – Packet Generator

hping – a Network Scanning Tool is a free packet generator and analyzer for the TCP/IP protocol distributed by Salvatore Sanfilippo (also known as Antirez).

It is one type of a tester for network security It is one of the de facto tools for security auditing and testing of firewalls and networks and was used to exploit the idle scan scanning technique (also invented by the hping author), and is now implemented in the Nmap Security Scanner.

Network Scanning Tool hping is a command-line oriented TCP/IP packet assembler/analyzer. The interface is inspired by the ping(8) Unix command, but hping isn’t only able to send ICMP echo requests.

- Advertisement -

It supports TCP, UDP, ICMP, and RAW-IP protocols, has a traceroute mode, the ability to send files between a covered channel, and many other features.

While hping was mainly used as a Network Scanning Tool in the past, it can be used in many ways by people that don’t care about security to test networks and hosts.

Also Read Windows Defender Antivirus Bypass Allows Any Malware to Execute on a Windows Machine

You can do this using hping Network Scanning Tool:

• Firewall testing
• Advanced port scanning
• Network testing, using different protocols, TOS, fragmentation
• Manual path MTU discovery
• Advanced traceroute, under all the supported protocols
• Remote OS fingerprinting
• Remote uptime guessing
• TCP/IP stacks auditing
• hping can also be useful to students that are learning TCP/IP.
• Traceroute/ping/probe hosts behind a firewall that blocks attempts using the standard utilities Network Scanning Tool .
• Perform the idle scan (now implemented in nmap with an easy user interface).
• Test firewalling rules.
• Test IDSes.
• Exploit known vulnerabilities of TCP/IP stacks.
• Networking research.
• Learn TCP/IP (hping was used in networking courses AFAIK).
• Write real applications related to TCP/IP testing and security.
• Automated firewalling tests.
• Proof of concept exploits.
• Networking and security research when there is the need to emulate complex TCP/IP behavior.
• Prototype IDS systems.
• Simple to use networking utilities with Tk interface.
• Network Scanning Tool

How to use hping…..

Command syntax:

1. hping3 = Name of the application binary.
2. -c 100000 = Number of packets to send.
3. -d 120 = Size of each packet that was sent to the target machine.
4. -S = I am sending SYN packets only.
5. -w 64 = TCP window size.
6. -p 21 = Destination port (21 being FTP port). You can use any port here.
7. --flood = Sending packets as fast as possible, without taking care to show incoming replies. Flood mode.
8. --rand-source = Using Random Source IP Addresses. You can also use -a or –spoof to hide host names. See the MAN page below.
9. www.gbhackers.com = Destination IP address or target machine’s IP address. You can also use a website name here. In my case resolves to 127.0.0.1 (as entered in /etc/hosts file)

Simple SYN flood – DoS using HPING3

Testing Firewall Rules – Part 1:

Hping3 by default (using no options) sends a null packet with a TCP header to port 0. You can select to use a different protocol by using the numeric option available for each:

-0 (Raw IP mode)

-1 (ICMP mode)

-2 (UDP mode)

-8 (Scan mode)

-9 (Listen mode)

Since hping3 uses TCP by default, the absence of the options below will send a TCP segment. When using TCP, we can decide to either omit flags (default), or set a flag using one of the following options:

-S (SYN)

-A (ACK)

-R (RST)

-F (FIN)

-P (PUSH)

-U (URG)

-X (XMAS)

-Y (YMAS)

In the following examples, we will be using TCP, UDP, and ICMP. In this first half, we are going to craft packets to test how a system would respond by default. This will give an idea of the numerous amount of data we simply do not need to allow through.

PING

First off, we are going to send a simple PING (ICMP Echo Request) packet to our target.

hping3 -1 -c 1 10.0.0.4

The –1 in this command tells hping3 to use ICMP, which by default sends an Echo Reply.
The -c 1 states that we only want to send 1 packet, and the 10.0.0.4 is our target. From the command output, we see that 1 packet was sent and received. Now, let’s check the response in the tcpdump output.

tcpdump -i wlan0 -n host 10.0.0.4

We can see from this tcpdump output confirms that the command did send an ICMP Echo Request, and our target replied with the appropriate ICMP Echo Reply. From the first packet sent, we can already tell that our target is alive.

SYN, Port 0

Now let’s send another packet and watch how the target responds. This time we will send a TCP header marked with the SYN flag to port 0. ()

hping3 -S -c 1 -s 5151 10.0.0.4

As stated before, the -S marks the SYN flag in our TCP header. We also see a new option here, -s 5151, which chooses a source port to use.

Without this option, hping3 would simply choose a random source port.

Since port 0 isn’t open, we see an RST-ACK response (marked in the output.) Later we will see how the target will respond to an SYN packet destined for an open port.

Just as expected, the output shows the packet was sent using source port 5151 to our target at port 0 with the SYN flag set. Below that, we can see the Flags [R.] set, and we also have an ‘ack‘ in the output.

FIN, Port 0

We are going to send an identical packet, except this time with the FIN flag set.

hping3 -F -c 1 -s 5151 10.0.0.4

The only thing we did differently in this command changes the -S to a -F. Again, we have a response. Since this port is closed, we should see the same response as if we sent a SYN packet.

As we should, we see the same RST-ACK response as before, marked by [R.] and ‘ack‘.

SYN, Port 80

In the previous examples, we’ve been sending packets to port 0. Now we’ll test a well-known port, port 80 (HTTP).

Since SYN is the first step in the three-way handshake of a TCP connection (SYN, SYN-ACK, ACK), if the port is open, we would receive the proper SYN-ACK response due to the target attempting to complete the connection.

This is a popular technique used in port scanning known as a “half-open connection“.

hping3 -S -c 1 -s 5151 -p 80 10.0.0.4

All of these options should look familiar, with the exception of -p 80. This simply specifies the destination port to set in our TCP header.

We see that our target has responded, and the output shows “flags=SA” confirming that we have received an SYN-ACK packet.

Since our target responded with an SYN-ACK (marked by [S.] and ‘ack‘), we know that our target’s port 80 is open and accepting connections. Otherwise, we would see [R.] like in our previous packet SYN packet sent to port 0.

ACK, Port 80

We now know that port 80 is open on our target, Network Scanning Tool so let’s see how if and how it responds to different packets.

We saw in the last example that when we send an SYN packet to an open port, we receive an SYN-ACK.

Let’s see what kind of response we get when we send an ACK packet (the final part of the three-way handshake).

hping3 -A -c 1 -s 5151 -p 80 10.0.0.4

Our target responded, but this time with the RST flag set.

Our tcpdump output shows the packet sent marked with [.] The following ack clarifies that this is an ACK flag. The output also shows the target’s response with an RST packet.

UDP, Port 80

We are gonna send one last packet to our target to see if we get a response.

Since port 80 uses TCP as its transport layer protocol, it should be interesting to see what kind of response we get when we send it a UDP packet.

hping3 -2 -c 1 -s 5151 -p 80 10.0.0.4

By using -2 in this command, we specify to use UDP as our transport layer protocol. We can see in the output that we got ICMP Port Unreachable response, due to that port not being open for UDP traffic.

Our tcpdump output would show this same information.

Testing Firewall Rules – Part 2:

In the first section, we saw how a system would respond to different packets by default.

In this section, we will see how just a few firewall rules can make a huge difference in our target’s responses. You should deny anything you’re not certain that you need open, and insert rules for anything you need open later.

We want to allow only the packets that are necessary and deny anything else. Since the only port needed to allow new connections is port 80 using TCP, we will want to drop all other packets to stop the host from responding to them.

If configured properly, the firewall on the target we’ve been using shouldn’t respond to anything aside from an SYN packet to port 80.

Rule 1: Drop any TCP packet that is starting a new connection and IS NOT marked by an SYN flag

Rule 2: Accept any TCP packet destined for port 80 at 10.0.0.4

Rule 3: Accept any TCP packet that is related to or part of an established connection

Rule 4: Drop all packets

Shown below is the iptables configuration.

This is just a simple example of inbound policies that take care of the issues from Part 1. With this configuration, the target will only respond to TCP packets destined for port 80. Now, let’s take a few of the same commands from before and see how our target responds equipped with these rules. Network Scanning Tool.

PING

hping3 -1 -c 1 10.0.0.4

In part 1 we received an ICMP echo reply, but we can see in our output that this packet has now been dropped. Since this is not a TCP header, the firewall will not respond.

SYN, Port 80

Since the only new connection we need to allow is through TCP on port 80, let’s test the firewall to make sure we still get a response.

hping3 -S -c 1 -s 5151 -p 80 10.0.0.4

As it should, the firewall is still allowing the packet through and giving us a response with an SYN-ACK packet.

Due to the first rule in the iptables configuration, if this packet was marked with any other flag it wouldn’t be allowed through since it is the first packet in the new connection.

UDP, Port 80

So far with the iptables configuration, we’ve seen that ICMP packets are dropped and that we can still successfully start a new connection through TCP on port 80.

Now for our last packet, let’s test to make sure that our rules work correctly for not allowing any other packets through on port 80. Network Scanning Tool.

hping3 -2 -c 1 -s 5151 -p 80 10.0.0.4

Here we’ve sent a UDP packet to port 80. Even though port 80 uses TCP as its transport layer protocol, in part 1 we actually got a response with an ICMP Port Unreachable.

If the packet were to make it through the firewall we would see the same response. Since there was no response, we know the packet was dropped.

We have successfully tested a host, set up rules to correct issues we’ve found, and retested for proper functionality.

Also, Read

10 Best Vulnerability Scanner Tools For Penetration Testing – 2023

Xerosploit – Pentesting Toolkit to Perform MITM, Spoofing, Sniffing & DOS Attacks

50+ Network Penetration Testing Tools for Hackers & Security Professionals – 2023