Nmap says host down when host is up

  • I am using Nmap 7.12 on Mac OS X. The host that is being scanned is a Linux RHEL server in VirtualBox. I can ping the server and receive ICMP replies and vice versa. I am scanning an IP inside the subnet as per the below information with the Nmap command:

    root# Nmap -sS 192.168.0.171
    Starting Nmap 7.12 ( https://nmap.org ) at 2016-05-28 00:41 SGT
    Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
    Nmap done: 1 IP address (0 hosts up) scanned in 0.49 seconds
    

    When I run tcpdump to see the traffic and where it's going, it shows all these ports being scanned when the Nmap command is run, and the Nmap scan completes successfully.

    root# nmap -sS 192.168.0.171
    Starting Nmap 7.12 ( https://nmap.org ) at 2016-05-28 00:52 SGT
    Nmap scan report for 192.168.0.171
    Host is up (0.00092s latency).
    Not shown: 998 filtered ports
    PORT   STATE SERVICE
    22/tcp open  ssh
    53/tcp open  domain
    MAC Address: 08:00:27:58:0E:98 (Oracle VirtualBox virtual NIC)
    Nmap done: 1 IP address (1 host up) scanned in 5.71 seconds
    

    However, as soon as I stop tcpdump and re-run the Nmap scan, it then states that the host is down.

    What am I missing here?

    The key here- to those trying to answer, is that the scan only works when the OP is in promiscuous mode. It doesn't look like an issue with the command but rather something in the conriguration of the network or network interfaces. Do you have multiple NICs or IP addresses? Can you post tcpdump output?

    Yes, this definitely sounds like a promiscuous mode issue. Please show us the output of running `ip addr show` on the server that you are directing the scan at, initially at least while tcpdump is not running. Also, is that server running anything like fail2ban or friends?

    What's you tcpdump command and params?

    have you figured it out? I have the same issue.

  • Try nmap -Pn 192.168.0.171, also confirm try nc -z -v -w 1 192.168.0.171 80 if that does not work.

    Isn't -Pn only used for passive scans?

    -Pn option didn't do the trick. nc didn't work as port 80 is not open on that host.

    Have you tried using the --packet-trace option to find what is happening? Add -vv to get as much info as possible.

    -Pn is actually used to skip the Ping. That can be used when the host is filtering ICMP packets

  • You can use the -PA and/or -PS commands to check if a host is up or down.

    For example:

    nmap 192.168.0.171 -PA(port#) -PS(port#) -vv -T5
    

    The -PA and -PS will check if a host is running a stateful or stateless firewall. The -vv is extra verbosity for more output to the terminal. The -T5 is how aggressive the scan will be. Try these out and see what your result is.

    (EDIT)

    Don't add a space between -PA -PS and the port number. It should look like this:

    -PA80 or -PS80
    

    You might also look into this video where the creator of nmap explains some advanced functions of the tool.

    https://www.youtube.com/watch?v=Hk-21p2m8YY

    I've tried the commands you mentioned as still advises host is down. I've also tried to do a ping scan nmap -sn 192.168.0.171 and says host is down. As previously mentioned, once I run tcpdump, nmap scans successfully.

    In that case give this command a try: nmap -sP -vv -T5 --packet-trace

    It says host being down still. Any reason why nmap scan would work when tcpdump is initiated?

    Ignore last message. This is my reply. It says host being down still. Any reason why nmap scan is successful when tcpdump is initiated?

    I can only imagine it has something to do with how the vnic is configured in the VM. I had this issue once myself and changing from VMware to virt-manager solved the issue for me. It could be a bug but since I no longer have the issue I haven't pursued looking into it more.

    I have a few more ideas to try out here. strace -t -e trace=network nmap -sn My first observation would be that tcpdump is dumping the packets that arrive on the interface, however nmap is running as a userspace process, hence a number of things could block nmap from seeing the response. Such as an netfilter rule (user iptables -t filter -n -L). Check the iptables nat tables to be sure (iptables -t nat -n -L).

    I don't have strace running. I used dtruss, but I'm not sure how to read it. I have turned off firewalld and stop iptables services. I flushed the iptables, so there are no rules in and out.

    Also, the way network is configured in virtual machine (in virtualbox) is set up as a bridged adapter via wifi interface, with Promiscuous mode set to Allow ALL

    Hmm I wish I could help more on this as I use virt-manager and have my two VMs bridged to my wireless interface as well and have no issues. I wonder if it could be a conflict between virtualbox and nmap regarding the wifi adapter...

  • As per Server Fault issue. Adding --disable-arp-ping to the command will continue to scan even when it would other wise report the host as down.

  • Use command

    nmap -sT -A -n -T4 --top-ports=20 (host address)
    

    -A will do aggressive scan

    This answer is very light on details. Why would an aggressive scan help? How does `-A` address the `tcpdump` oddity?

    The one switch that would avoid the issue mentioned in the original question (`-Pn`) is also absent from your command line

License under CC-BY-SA with attribution


Content dated before 7/24/2021 11:53 AM

Tags used