Learning Nmap Host Discovery with Iptables

and Wireshark Analysis

Finally the wait is no longer , we are going to learn host discovery using nmap in a very detailed way. Well you might say that there are many videos and blogs out there what is special about this one ? , In this blog I will be sharing my knowledge after going through several videos , nmap book and many other blogs in the most detailed way possible , well you will see the difference after going through the blog . When I say I really mean it . Heads up !! you must know basis of iptables before going through the blog and you might ask why ? coz we not just learning just by saying that nmap blocks the packets so this host discovery isn't going to work.

we are going to block the packets and run the discovery again and bypass the our rules ourselves that how this blog is designed very thing is practical practical and practical . How cool is that ?!. well I wrote blog on iptables just for you !! click here and don't forget to come back !! . Enough talk an let's dive in shall we

So why there are many different scan techniques ? Why can’t we just ping the destination computer and conclude if the host is live or not ? Well it used to be the case long ago . Hackers used this to gather the information on company's network and also perform many ddos attacks such as ping to death against the company's network by damaging it , So administrators blocked the ping requests.

Well no need to worry nmap provides us with different types of host discovery methods other than just identifying the live hosts by just sending icmp echo requests and that’s what we will be going through this blog .

Caution : Fasten your seat belts and enjoy the damn ride !

Why should anyone master Host Discovery ?

Many people confuse between host discovery and nmap port scan . So firstly we need to know that by default any nmap scan type does the host discovery and moves forward to scan the system if the host is alive , this way nmap scan saves time by only scanning the live hosts . So we hackers should master the host discovery tecniques to break through the firewall and find out the real status of a particular machine by putting an end to the masquerading . Weahter if the machine is really up and running or not.As we are only interested in the host discovery part for this blog adding -sn (no port scan) will only allow the host discovery and so we can get the information if the host is up .

Requirements :

As I have told this is totally hands on I recommend you have two linux machines doesn’t matter if they are on different hardware or virtual machines , if you don’t have then no worries you can watch me doing and learn but it’s recommended so you can enjoy this blog thoroughly .

Note :

1)You should be a root or should be able to impersonate root using sudo while practicing the commands with me.

2)We are scanning local networks as if they were remote networks using the --disable-arp-ping attribute cause nmap scanning behaviour depends on the type of network whether it is a local or remote even if the commands are the same. So in this blog I am using kali as attacker machine (192.168.0.105) and XUbuntu (192.168.0.117) as target machine.

ICMP Echo Ping :

sudo nmap -sn -PE 192.168.0.117 --disable-arp-ping

we used the -sn option which only let’s the host discovery part and disables the port scan . --disable-arp-ping will make nmap to behave as if we are scanning a remote host even though we are scanning a local host as discussed above .

ICMP Echo request is sent to the target and the attacker waits for the icmp reply , if the attacker machine gets an icmp reply in response from the target machine then nmap concludes that the host is up , else it reverts back displaying 0 hosts up .

Fig : 1.1

In Fig : 1.1 We could see that we've got an icmp echo reply from the target

Fig : 1.2

In Fig:1.2 Hence nmap concludes that the host is up .

Some other cases :

1) If you are an unprivileged user scanning a remote host the following packets are sent:

TCP Packet with SYN On is sent to port 80

If it gets any response like syn/ack or rst/ack nmap concludes that the host is up as we are just interesed in the system's response and not if the port is open or closed. If no response then nmap reverts back saying that 0 hosts is up.

2) If you are a privileged user scanning a local host then arp broadcast request is sent to the target , if it gets the arp response nmap concludes the host is up else it conclues as 0 hosts up

3) If you are an unprivileged user scanning a local host, it behaves same as unprivileged user scanning a remote host

Let’s block icmp echo requests on the target machine

sudo iptables -I INPUT -p icmp --icmp-type echo-request -s 192.168.0.105 -d 192.168.0.117 -i enp0s3 -j DROP

Fig : 1.3

In Fig : 1.3 we have instructed the target machine to drop the icmp echo requests that if they have the ip source 192.168.0.105 (ip of attacker machine) and the ip destination 192.168.0.117 (ip of target machine).

Now lets scan the target after adding the rule.

Fig : 1.4

Fig : 1.5

In Fig : 1.4 We could see that the attacker machine has tried not once but twice reaching out the target but the target machine dropped the icmp echo-request packet

Hence the nmap concludes 0 hosts up in Fig : 1.5

Bypassing ICMP Echo Ping using ICMP Timestamp Ping :

sudo nmap -sn -PP 192.168.0.117 -disable-arp-ping

As the administrator had blocked the icmp echo-requests we will be using icmp timestamp requests to bypass the firewall rules which sucessfully let’s us know the live hosts Fig : 1.6

Fig : 1.6

Fig : 1.7

In Fig : 1.6 We can see the reply for the timestamp-request made by the attacker machine

Hence nmap concludes that the host is up and running in Fig : 1.7.

Some other cases :

1) If you are an unprivileged user scanning a remote host the following packets are sent:

TCP Packet with SYN On is sent to port 80

If it gets any response like syn/ack or rst/ack nmap concludes that the host is up , else it reverts back saying that 0 hosts is up.

2) If you are a privileged user scanning a local host then arp broadcast request is sent to the target , if it gets the response nmap conclude the host is up else 0 hosts up

3) If you are an unprivileged user scanning a local host, it behaves same as unprivileged user scanning a remote host

It’s time to block it !!

To block icmp timestamp-requests on the target :

sudo iptables -I INPUT -p icmp --icmp-type timestamp-request -s 192.168.0.105 –d 192.168.0.117 -i enp0s3 -j DROP

Fig : 1.8

In Fig : 1.8 you can see that we have blocked both the icmp echo-request and icmp timestamp-request .

Now let’s scan the target machine considering the above rules were added

Fig : 1.9

Fig : 2.0

In Fig : 1.9 We could see that the attacker machine has tried not once but twice reaching out the target but the target machine dropped the icmp timestamp-request packet

Hence the nmap concludes 0 hosts up in Fig : 2.0

Bypassing with TCP SYN Ping :

sudo nmap -sn -PS 192.168.0.117 --disable-arp-ping

Now by default TCP SYN Packet is sent to port 80 , if the attacker machine receives any replay from the target machine like syn/ack or rst/ack then nmap will conclude that the host is up else reverts back saying 0 hosts up.

Fig : 2.1

Fig : 2.2

In Fig : 2.1 We can see the reply TCP SYN/ACK from the webserver (well it means it’s running a webservice on port 80) for the TCP SYN Packet sent by the attacker machine

Hence nmap concludes that the host is up and running in Fig : 2.2.

Note :

The attacker machine running nmap brought down the connection by responding with an rst packet rather than sending an ack packet for the TCP SYN/ACK recieved which would complete the three way handshake and establish a full tcp connection . This is called stealth mode . This might helps us from escaping the logs.

It doesn’t matter if the port is open or closed , in other words either the response is syn/ack or rst/ack , any of the response tells us that the host is up and running .

The RST packet at the end to reset the connection is sent by the kernel of the machine running Nmap in response to the unexpected SYN/ACK, not by Nmap itself !!

You could explicitly specify the port number to which the TCP SYN packet should be sent to by adding the port number right after the option manually eg : -PS443

Some other cases :

1) If you are an unprivileged user scanning a remote host the following packets are sent:

TCP Packet with SYN On is sent to port 80

Well , yes in this case there is no difference between root and ordinary user . So this scan can be performed by a non-root user as well !

If it gets any response like syn/ack or rst/ack nmap concludes that the host is up else it reverts back saying that 0 hosts is up

2) If you are a privileged user scanning a local host then arp broadcast request is sent to the target , if it gets the response nmap conclude the host is up else 0 hosts up

3) If you are an unprivileged user scanning a local host, it behaves same as unprivileged user scanning a remote host

Let’s block syn packet to port 80 shall we !!

sudo iptables -I INPUT -p tcp --syn -s 192.168.0.105 -d 192.168.0.117 --dport 80 -i enp0s3 -j DROP

Fig : 2.3

In Fig : 2.3 We have blocked all the TCP SYN connection initiation packets from ip 192.168.0.105 (attacker machine) to 192.168.0.117 (target machine) that have destionatin port 80 . And we could also see pretty much all the existing previously added rules.

Now let's scan again after adding the rule .

Fig : 2.4

Fig : 2.5

In Fig : 2.4 We could see that the attacker machine has tried not once but twice reaching out the target

but the target machine dropped the TCP SYN packets destined to port 80.

Hence the nmap concludes 0 hosts up in Fig : 2.5

Bypassing with TCP ACK Ping :

sudo nmap -sn -PA 192.168.0.117 --disable-arp-ping

This is similar to TCP SYN Ping Scan but the only difference that you might have already guessed is that ACK flags is set instead of SYN flag for the packet to be sent.

Fig : 2.6

Fig : 2.7

In Fig : 2.6 We can see the reply TCP RST packet from the target for the TCP ACK Packet sent by the attacker machine

Hence nmap concludes that the host is up and running in Fig : 2.7.

Note :

we are not allowed to initiate a connection by sending an acknowledge packet , So this always results target machine sending rst packet inrespective of the state of the port (open or closed)

When stateless firewall rules such as this are in place, SYN ping probes (-PS) are likely to be blocked when sent to closed target ports. In such cases, the ACK probe shines as it cuts right through these rules.

Yes the default port is 80 as you might have already guesses it but we can change the default ports as we have done in TCP SYN Ping Scan eg : -PA21 , -PA22,21.

The reason for offering both SYN and ACK ping probes is to maximize the chances of bypassing firewalls

Some other cases :

1) If you are an unprivileged user scanning a remote host the following packets are sent:

TCP Packet with SYN On is sent to port 80

If it gets any response like syn/ack or rst/ack nmap concludes that the host is up else it reverts back saying that 0 hosts is up

2) If you are a privileged user scanning a local host then arp broadcast request is sent to the target , if it gets the response nmap conclude the host is up else 0 hosts up

3) If you are an unprivileged user scanning a local host, it behaves same as unprivileged user scanning a remote host

Time has come !!

Yep let's block the TCP ACK destined to port 80!

sudo iptables -I INPUT -p tcp --tcp-flags ALL ACK -s 192.168.0.105 -d 192.168.0.117 --dport 80 -i enp0s3 -j DROP

Fig : 2.8

In Fig : 2.8 We have blocked all the TCP packets with ACK set and remaining unset from ip 192.168.0.105 (attacker machine) to 192.168.0.117 (target machine) that have destionatin port 80 . And we could also see pretty much all the existing previously added rules.

Now let's scan the target after adding the rule.

Fig : 2.9

Fig : 3.0

In Fig : 2.9 We could see that the attacker machine has tried not once but twice reaching out the target

but the target machine dropped the TCP ACK packets destined to port 80.

Hence the nmap concludes 0 hosts up in Fig : 3.0

Hey you ! yes you I am talking to , you are working so hard damn it ! .

Don't push yourself too hard . Take a break and come back 😊.

Bypassing with Ping sweep or default ping :

sudo nmap -sn 192.168.0.117 --disable-arp-ping

Woking of Ping sweep scan :

The following packets are sent accordingly :

ICMP Echo Request
SYN Packet To Port 443
ACK Packet To Port 80
Timestamp Request

Fig : 3.1

Fig : 3.2

As you can see in Fig :3.1 If nmap gets replay from any of the requests it has sent then it concludes that the host is up and running.

If it did not get any replay for any of the requests it made from the target it reverts back by display 0 hosts are up . And a we can see that following packets are blocked :

ICMP echo request
ICMP timestamp request
ACK packet to port 80

And replied through port 443 because of the previously set firewall rules

Hence nmap concludes that the host is up and running in Fig : 3.2.

Note :

This default scan is same as the command : sudo nmap -sn -PE -PS443 -PA80 -PP 192.168.0.117 --disable-arp-ping

Some other cases :

1) If you are an unprivileged user scanning a remote host the following packets are sent:

syn packet to port 443
syn packet to port 80

If it gets reply for any of its requests they it concludes that the host is up and running else reverts back displaying 0 hosts up.

2) If you are a privileged user scanning a local host then arp broadcast request is sent to the target , if it gets the response nmap conclude the host is up else 0 hosts up

3) If you are an unprivileged user scanning a local host, it behaves same as in unprivileged user scanning a remote host

Now let’s see by blocking the packets on the target machine .

Well we have replaced the rules that drops syn and ack packet to port 80 to drop syn and ack packets to all the ports

sudo iptables -R INPUT 1 -p tcp --tcp-flags ALL ACK -s 192.168.0.105 -d 192.168.0.117 -i enp0s3 -j DROP

sudo iptables -R INPUT 2 -p tcp --tcp-flags ALL SYN -s 192.168.0.105 -d 192.168.0.117 -i enp0s3 -j DROP

Fig : 3.3

Now let's scan the target after adding the rule.

Fig : 3.4

Fig : 3.5

In Fig : 3.4 We could see that the attacker machine has tried not once but twice reaching out the target

but the target machine dropped the packets sent.

Hence the nmap concludes 0 hosts up in Fig : 3.5

Bypassing with UDP Ping :

nmap -PU -sn 192.168.0.117 --disable-arp-ping

By default a udp packet is sent to udp port 40,125.

Generally in udp protocol a response for the message sent is not expected . So as you might have guessed there is no response for the udp packet if the port is open or filtered so we can’t count on results of udp scan . If destination port is open or filtered as the result 0 hosts up is displayed even if the host is up,only because there is no response so keep this in mind. So the nmap udp scan can only discover the host is up or down if the packet is sent to a closed port cause the target replies with a message in response as host is unreachable which is icmp packet have type 3 (destination unreachable) code 3 (port unreachable).

Fig : 3.6

Fig : 3.7

In Fig : 3.6 We can see the reply icmp port unreachable packet from the target for the udp packet sent by the attacker machine

Hence nmap concludes that the host is up and running in Fig : 3.7.

Note :

We can change the default port eg: -PU53 which is the same case with previous scans like -PS and -PA .

The default port is set to 40125 as it is highily unlikely to be in use , so that it increases the chances of getting a response in return from that target .

Most of the packets sent to udp ports by nmap are empty except for few port eg:53,67 . Why ? let me explain . If a packet is sent to an open port there will not be any response . To overcome this, a protocol specific payload is sent within the packet by nmap udp ping to the target and it is also important to remember that nmap has payloads only to few popular ports Eg : dns, dhcp and these payloads makes the open ports respond so that nmap could determine if the host is up or not . To view to what ports nmap sends packets that include payloads you can view the them in a file nmap-payloads , to be specific /usr/share/nmap/nmap-payloads .

You can also specify or add the data in the packets to be sent to unpopular ports using the attributes like --data , --data-length ,--data-string .

The advantage of UDP scan is that it can detect the systems which have firewalls with strict TCP rules and leaving UDP rules at ease .

Some other cases :

1) If you are an unprivileged user scanning a remote host :

Opps ! can’t do that cause you must have root privilege or must be a sudo impersonating root to perform udp ping scan

2) If you are a privileged user scanning a local host then arp broadcast request is sent to the target , if it gets the response nmap conclude the host is up else 0 hosts up

3) If you are an unprivileged user scanning a local host

Ooo shit here we go again , Gotta be a root or sudo to impersonate root powers

Let's block udp packets

sudo iptables -I -p udp INPUT -s 192.168.0.105 -d 192.168.0.117 -i enp0s3 -j DROP

Fig : 3.8

In Fig : 3.8 We have blocked the UDP packets to all ports on the target machine if the packet is from ip 192.168.0.105 (attacker machine) to 192.168.0.117 (target machine) . And we could also see pretty much all the existing previously added rules.

Now let's scan the host after adding the rule.

Fig : 3.9

Fig : 4.0

In Fig : 3.9 We could see that the attacker machine has tried not once but twice reaching out the target

but the target machine dropped the udp packets sent.

Hence the nmap concludes 0 hosts up in Fig : 4.0

Bypassing with ARP Ping :

sudo nmap -sn -PR 192.168.0.117

This scan sends arp request to the target and concludes the host is up if arp response packet is received in response.

wait what ?

Well isn’t this is the same as default nmap scan in local area network which also means :

sudo nmap 192.168.0.117 -sn

Yep ! You absolutely right my friend that’s the same thing .

Fig : 4.1

Fig : 4.2

In Fig : 4.1 We can see the reply arp response packet from the target for the arp request packet sent by the attacker machine

Hence nmap concludes that the host is up and running in Fig : 4.2.

Note :

you might have already guessed as we are dealing with arp packet , your pc and the target pc must be in the same lan .

arp ping is the most efficient way for discovering the hosts.

It is always recommended to do arp ping instead of icmp ping for host discovery when you and your targets are on the same lan for two reasons . One is that arp scans are faster and the other reason is that when we use icmp ping for host discovery the source host generally adds an imcomplete entry for the destination ip in its arp table and the thing is arp table has finite space . some operating systems might even crash when the arp table fills up . It makes sense when discovering live hosts over a whole subnet .

Fig : 4.3

Fig : 4.4

In Fig : 4.3 and 4.4 we can see the arp cache fulled with empty entries and it does not end here , it went on. And this is not recommended to try as in my case it is small subnet .

in some cases nmap sometimes has to wait several minutes for ARP cache entries to expire before it can continue with host discovery. So using arp ping is highily recommended.

And also remember that arp request are not blocked in any local area network as end devices need to communicate through arp requests and responses to send data !!

We learned a lot today didn't we ?! but the roller coaster doesn't end here . This is just a break until the next blog comes , so don't miss the ride next time !

-----------------------------------------------------------------------FAREWELL---------------------------------------------------------------------