nmap reports a remote host as up, while it is down? [closed]

Question

I want to remotely examine if some servers are up.

I don't use the ping command because it gives a lot of wrong results like "destination host unreachable" and "request Timed out" due to bad networking infrastructure.

I try to use nmap command to examine servers by open ports. Nmap gives me the real opened ports, but when I turn off the server, nmap still reports it running.

The client logs into the internet through a usb modem, and the destination host that I examine is connected to the internet through a TP-Link Access point with usb modem and a static IP.

When I turn off the access point completely and I run this command:

nmap -p 80 -vv 105.198.224.47

Starting Nmap 7.01 ( https://nmap.org ) at 2017-01-31 11:54 EET

Initiating Ping Scan at 11:54

Scanning 105.198.224.47 [2 ports]

Completed Ping Scan at 11:54, 0.61s elapsed (1 total hosts)

Initiating Parallel DNS resolution of 1 host. at 11:54

Completed Parallel DNS resolution of 1 host. at 11:54, 0.01s elapsed

Initiating Connect Scan at 11:54

Scanning 105.198.224.47 [1 port]

Discovered open port 80/tcp on 105.198.224.47

Completed Connect Scan at 11:54, 0.09s elapsed (1 total ports)

Nmap scan report for 105.198.224.47

Host is up, received syn-ack (0.55s latency).

Scanned at 2017-01-31 11:54:17 EET for 0s

PORT   STATE SERVICE REASON

80/tcp open  http    syn-ack


Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 0.78 seconds

And when put the ip in a browser it gives:

"This site can’t be reached"

"The connection was reset."

This happens in both situations when it is turned on and turned off.

traceroute when the access point is turned on gives:

traceroute to 105.198.224.47 (105.198.224.47), 30 hops max, 60 byte packets

 1  192.168.9.1 (192.168.9.1)  1.667 ms  1.768 ms  2.508 ms

 2  * * *

 3  10.255.224.106 (10.255.224.106)  759.425 ms  769.911 ms  770.401 ms

 4  10.255.224.114 (10.255.224.114)  770.142 ms  770.508 ms  770.871 ms

 5  10.255.224.124 (10.255.224.124)  771.866 ms  771.859 ms  779.227 ms

 6  105.199.1.3 (105.199.1.3)  780.458 ms  792.637 ms  792.453 ms

 7  163.121.143.88 (163.121.143.88)  803.571 ms  51.573 ms  41.250 ms

 8  163.121.143.75 (163.121.143.75)  49.261 ms  49.264 ms  49.384 ms

 9  * * *

10  * * *

11  * * *

12  * * *

13  * * *

14  * * *

15  * * *

16  * * *

17  * * *

18  * * *

19  * * *

20  * * *

21  * * *

22  * * *

23  * * *

24  * * *

25  * * *

26  * * *

27  * * *

28  * * *

29  * * *

30  * * *

running traceroute when the access point turned off gives the same result but the changes only in values of milli seconds ms.

So, what the explanation of this behaviour?

Answer 1

What do you have, network-wise, between you and your servers ?

Any active element (router, firewall, etc.) can modify your trafic, hence:

1. the fact that ping does not work can be unrelated to your server state. ICMP trafic is often something completely filtered out
2. your nmap case is stranger, but can still be explained the same way, it also depends if you use a name or an IP

In both cases to really monitor things you should use a service you control on the server (like ssh, http or something more specific), connect to it and verify that you get back what you expect (a specific result).

Answer 2

If the information you provided is correct it entirely possible you have been the victim of a so called 'man-in-the-middle' attack:

https://en.wikipedia.org/wiki/Man-in-the-middle_attack

In computer security, a man-in-the-middle attack (often abbreviated mitm, or the same using all capital letters) is an attack where the attacker secretly relays and possibly alters the communication between two parties who believe they are directly communicating with each other. A man-in-the-middle attack can be used against many protocols. One example of man-in-the-middle attacks is active eavesdropping, in which the attacker makes independent connections with the victims and relays messages between them to make them believe they are talking directly to each other over a private connection, when in fact the entire conversation is controlled by the attacker.

Taking the info provided at face value this is a plausible explanation. The best course of action if you believe this to be the case would probably be to try nmapping (or pinging) the computer via a proxy. This may fix the problem, depending on the source and nature of the MitM.