0

Update 2: pf already defaults to drop. What causes nmap to notice the server? What does 'received reset' mean?

Update 1: Maybe I misinterpreted my findings. When run with -v2, nmap tells me that "Host is up, received reset ttl 52". Does this mean that even though ICMP is blocked, nmap is able to notice that the server is running? Is this due to BLOCK/DROP differences? The server I'm probing runs OpenBSD with pf. pf is set to 'block all', followed by very specific exceptions. IMHO this defaults to BLOCK, not DROP in pf.

When I run

nmap -sn

to probe a specific host, nmap returns "Host is up" even though ICMP is completely blocked for the server I probed, except time. I assume the "Host is up" message is based on an ICMP response (as this is the only "open" channel I'm aware of), based on the nmap docs:

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.

Now I'm wondering if it is somehow possible to make nmap tell me WHY the host is up, e.g. getting verbose output for the single steps involved in the probing. I tried running it with -v, but this only gives version and general chitchat. ´

I know I could do the single requests myself (for example: hping3) but I'm specifically interested if this is possible with nmap as I'm bound to a Windows machine here (and WSL still doesn't support raw sockets stuff necessary for this).

Thanks.

loopend
  • 11
  • 3
  • 1
    Using verbosity level 2 or higher (`-v2`, `-v3`, or `-v4`) gives a bit more than just "Host is up". It adds "received echo-reply ttl 127" in my sample. I'll see if I can set up a test case that'll not respond to the ping, but will respond to one of the other methods that `-sn` uses and see if the output is descriptive. – Doug Deden Aug 12 '19 at 18:21
  • @DougDeden Thanks for the hint! Indeed -vX tells me "Host is up, received reset ttl 52" for the ICMP ping. I wondered about the 'received reset' here and updated my question. Does nmap notice the running server despite the blocking? Right now I'm thinking this might be due to BLOCKs by the firewall, will try DROP config now. **Edit: I was wrong, pf already defaults to DROP** – loopend Aug 12 '19 at 19:14
  • Try the `--reason` option next. It might give more detail as to why the host is viewed as "up". – Doug Deden Aug 12 '19 at 19:26
  • @DougDeden Same thing, just breaks down to 'Host is up, received reset' – loopend Aug 12 '19 at 19:31
  • Next, try the debugging options, starting with `-d1`. You might see in there if nmap is falling back on the SYN or ACK approaches. – Doug Deden Aug 12 '19 at 19:32
  • @DougDeden Ah, thanks a lot. This is interesting: RCVD (1.2620s) TCP [XXX:443 > XXX:50974 RA seq=0 ack=3258517834 etc. - While the request itself gets blocked, nmap receives an TCP:RA anyways, AFAIK this means there is an connection reset including an ACK. Is this right? I'm still stumped because IMHO pf should not do this? – loopend Aug 12 '19 at 19:48

1 Answers1

0

It's all about the options. Here's a site that has a working web server on ports 80 and 443, but does not respond to pings. 

C:\Users\doug>ping www.rlmueller.net

Pinging www.rlmueller.net [65.254.227.240] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Let's try nmap with just the -sn option:

nmap -sn www.rlmueller.net

The results are:

…
Host is up (0.031s latency).
…

So the server is up, but we don't know why nmap thinks that. But we know it isn't because the server is responding to pings.

Let's use the --reason option next:

nmap -sn --reason www.rlmueller.net

The results are:

...
Host is up, received syn-ack ttl 53 (0.031s latency).
…

Aha! So nmap decides that the server is up because it responded to the SYN (sent to port 443, according to the nmap documentation of the -sn option) with a SYN-ACK.

How about the verbosity switches?

nmap -sn -v1 www.rlmueller.net

Nope. It gives more info, but the result is still:

Host is up (0.031s latency).

nmap -sn -v2 www.rlmueller.net

Yep. Similar to using the `--reason`` option, we get:

Host is up, received syn-ack ttl 52 (0.032s latency).

Using the debug options, we can get a bit more detail.

nmap -sn -d1 www.rlmueller.net

...
We got a TCP ping packet back from 65.254.227.240 port 443
…
Host is up, received syn-ack ttl 52 (0.031s latency).
…

Nice! That matches up with the documentation that mentions a SYN packet to port 443.

Higher debug levels, such as -d2 or -d3 give even more detail. You can take it all the way up to -d6 if you want to.

Doug Deden
  • 1,844
  • 7
  • 10