Nmap Live Host Discovery

0 views
Skip to first unread message

Violette Ransone

unread,
Jul 18, 2024, 3:50:55 AM7/18/24
to adgansandca

I am trying to find the live hosts on my network using nmap. I am scanning the network in Ubuntu using the command sudo nmap -sP 192.168.2.1/24. However, I am unable to find the live hosts. I just get the network address of my own PC as live. When I see the DHCP client list through my browser (my router can be accessed via browser using my network IP), I get around 10 live hosts on the network. Can anyone tell me the reason why this could be happening and how do I find the live hosts on my network?

When this command runs nmap tries to ping the given IP address range to check if the hosts are alive. If ping fails it tries to send syn packets to port 80 (SYN scan). This is not hundred percent reliable because modern host based firewalls block ping and port 80. Windows firewall blocks ping by default. The hosts you have on the network are blocking ping and the port 80 is not accepting connections. Hence nmap assumes that the host is not up.

nmap live host discovery


تنزيل ★★★ https://ssurll.com/2zlCwF



Yes. One of the options that you have is using the -P0 flag which skips the host discovery process and tries to perform a port scan on all the IP addresses (In this case even vacant IP addresses will be scanned). Obviously this will take a large amount of time to complete the scan even if you are in a small (20-50 hosts) network. but it will give you the results.

The better option would be to specify custom ports for scanning. Nmap allows you to probe specific ports with SYN/UDP packets. It is generally recommended to probe commonly used ports e.g. TCP-22 (ssh) or TCP-3389 (windows remote desktop) or UDP-161 (SNMP).

N.B. even after specifying custom ports for scanning you may not get an active host. A lot depends on how the host is configured and which services it is using. So you just have keep probing with different combinations.Remember, do not performs scans on a network without proper authorization.

update: When scanning a network you can never be sure that a particular command will give you all the desired results. The approach should be to start with basic ping sweep and if it doesn't work try guessing the applications that may be running on the hosts and probe the corresponding ports. The idea of using Wireshark is also interesting. You may want to try sending ACK packets.

You might want to check out Wireshark. It logs all of the traffic on the local network. It will tell you which nodes are broadcasting. You can also see what is being transmitted. It's available in the Ubuntu Software Center.

In regard to the traffic that shows in your DHCP routing tables remember that a lot of Virtual Machines will show up as separate machines in the list. Anything that's connected to your network usually within the default 24 hour lease time (for most WiFi Routers) will still show in the list. You might want to check for the duration of the leases in the router. It might tell you if someone's on your network overnight. On some devices that have dual NICs or a NIC and a Wireless Card they'll show up twice if both interfaces are enabled.

About 6 years ago at the office I was working in our little 3mb connection was down to 128k because of all of the excess traffic. The owners wanted to know if it was possible to see what was going on. The old part time IT guy shrugged his shoulders because not all of the traffic was going through their Windows 2000 server. He checked the routing tables and traffic logs in the server and saw nothing. They weren't using a router strangely enough, so anything on the network could get an address from the modem. The routing tables he looked at in the server were only for static mappings that existed a couple of years prior. I noticed they weren't on the same subnet. Then I showed them DHCP wasn't on in the server.

I found all of the traffic coming in after hours on an overnight sweep with Wireshark. One of my coworkers was unknowingly hosting a Japanese sex site on his machine. The attackers had rooted his machine after he installed a backdoor which came along with a cracked version of a high-end video editing software. We also found out they were running Tor, demonoid, and bitTorrent on various machines in different departments at different times. Wireshark found everything. Next day internet was up to full speed... we also installed a router.

Sometimes arp -a -n wont fetch the ip address.Performing nmap -sP 192.168.1.1/24 will retrieve live hosts and after that if you try arp again, it will show the live hosts. Thats how it worked for me in linux mint. But you can rely on nmap anyday.

Disclaimer: I have no affiliation with the tool or the company making it, and I have no clue what other things (evil or not) the tool might be doing under the hood. I've used their mobile apps for finding IP's on my LAN and found it useful.

One of the very first steps in any network reconnaissance mission is to reduce a (sometimes huge) set of IP ranges into a list of active or interesting hosts. Scanning every port of every single IP address is slow and usually unnecessary. Of course what makes a host interesting depends greatly on the scan purposes. Network administrators may only be interested in hosts running a certain service, while security auditors may care about every single device with an IP address. An administrator may be comfortable using just an ICMP ping to locate hosts on his internal network, while an external penetration tester may use a diverse set of dozens of probes in an attempt to evade firewall restrictions.

Because host discovery needs are so diverse, Nmap offers a wide variety of options for customizing the techniques used. Host discovery is sometimes called ping scan, but it goes well beyond the simple ICMP echo request packets associated with the ubiquitous ping tool. Users can skip the discovery step entirely with a list scan (-sL) or by disabling host discovery (-Pn), or engage the network with arbitrary combinations of multi-port TCP SYN/ACK, UDP, SCTP INIT and ICMP probes. The goal of these probes is to solicit responses which demonstrate that an IP address is actually active (is being used by a host or network device). On many networks, only a small percentage of IP addresses are active at any given time. This is particularly common with private address space such as 10.0.0.0/8. That network has 16 million IPs, but I have seen it used by companies with less than a thousand machines. Host discovery can find those machines in a sparsely allocated sea of IP addresses.

If no host discovery options are given, Nmap sends an ICMP echo request, a TCP SYN packet to port 443, a TCP ACK packet to port 80, and an ICMP timestamp request. (For IPv6, the ICMP timestamp request is omitted because it is not part of ICMPv6.) These defaults are equivalent to the -PE -PS443 -PA80 -PP options. The exceptions to this are the ARP (for IPv4) and Neighbor Discovery (for IPv6) scans which are used for any targets on a local ethernet network. For unprivileged Unix shell users, the default probes are a SYN packet to ports 80 and 443 using the connect system call. This host discovery is often sufficient when scanning local networks, but a more comprehensive set of discovery probes is recommended for security auditing.

The -P* options (which select ping types) can be combined. You can increase your odds of penetrating strict firewalls by sending many probe types using different TCP ports/flags and ICMP codes. Also note that ARP/Neighbor Discovery is done by default against targets on a local Ethernet network even if you specify other -P* options, because it is almost always faster and more effective.

By default, Nmap does host discovery and then performs a port scan against each host it determines is online. This is true even if you specify non-default host discovery types such as UDP probes (-PU). Read about the -sn option to learn how to perform only host discovery, or use -Pn to skip host discovery and port scan all target addresses. The following options control host discovery:

The list scan is a degenerate form of host discovery that simply lists each host of the network(s) specified, without sending any packets to the target hosts. By default, Nmap still does reverse-DNS resolution on the hosts to learn their names. It is often surprising how much useful information simple hostnames give out. For example, fw.chi is the name of one company's Chicago firewall. Nmap also reports the total number of IP addresses at the end. The list scan is a good sanity check to ensure that you have proper IP addresses for your targets. If the hosts sport domain names you do not recognize, it is worth investigating further to prevent scanning the wrong company's network.

Since the idea is to simply print a list of target hosts, options for higher level functionality such as port scanning, OS detection, or host discovery cannot be combined with this. If you wish to disable host discovery while still performing such higher level functionality, read up on the -Pn (skip host discovery) option.

Systems administrators often find this option valuable as well. It can easily be used to count available machines on a network or monitor server availability. This is often called a ping sweep, and is more reliable than pinging the broadcast address because many hosts do not reply to broadcast queries.

The default host discovery done with -sn consists of an ICMP echo request, TCP SYN to port 443, TCP ACK to port 80, and an ICMP timestamp request by default. When executed by an unprivileged user, only SYN packets are sent (using a connect call) to ports 80 and 443 on the target. When a privileged user tries to scan targets on a local ethernet network, ARP requests are used unless --send-ip was specified. The -sn option can be combined with any of the discovery probe types (the -P* options) for greater flexibility. If any of those probe type and port number options are used, the default probes are overridden. When strict firewalls are in place between the source host running Nmap and the target network, using those advanced techniques is recommended. Otherwise hosts could be missed when the firewall drops probes or their responses.

bd95a233a5
Reply all
Reply to author
Forward
0 new messages