2

I have an iptables rule setup that marks addresses as suspicious if they connect on certain ports or any unopen ports. If more than three consecutive connections are made without authentication, then the address is black listed. After blacklisting has occurred, the remote host is blocked from accessing all ports. However, despite dropping packets when an address is black listed, nmap is still able to detect the host is up. What is nmap using to determine this? How can I make the host disappear completely, as in Tesla coil style?

root@yellowtail:~# nmap -Pn 10.42.0.48

Starting Nmap 6.00 ( http://nmap.org ) at 2014-02-12 21:56 GMT
Nmap scan report for 10.42.0.48
Host is up (0.00022s latency).
All 1000 scanned ports on 10.42.0.48 are filtered
MAC Address: EC:43:F6:C0:B1:E8 (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 22.11 seconds

Update: The rule path to DROP

First, handle established and related external connection traffic, before handling incoming new external traffic (what I am testing)...

-N ERIN
-A ERIN -m state --state INVALID -j DROPINVALID
-A ERIN -m state ! --state RELATED,ESTABLISHED -j RETURN
#-A ERIN -j LOG --log-prefix "RELATED,ESTABLISHED ACCEPT" --log-tcp-options --log-ip-options --log-level 7
-A ERIN -j ACCEPT

-N BLACKLIST
-A BLACKLIST -m recent --name whitelist --rcheck -m limit --limit 1/minute -j LOG --log-prefix "!BLACKLIST: WHITELISTED" --log-level 7
-A BLACKLIST -m recent --name whitelist --rcheck -j RETURN
-A BLACKLIST -s 4.79.142.206 -j LOG --log-prefix "!BLACKLIST: SHIELDS-UP" --log-level 7
-A BLACKLIST -s 4.79.142.206 -j RETURN
-A BLACKLIST -m recent --name blacklist ! --rcheck -j LOG --log-prefix "BLACKLIST" --log-tcp-options --log-ip-options --log-level 7
-A BLACKLIST -m recent --name blacklist --set
-A BLACKLIST -j DROP 

-N BLACKLIST_IN
-A BLACKLIST_IN -m recent --name blacklist --rcheck --reap --seconds 172800
-A BLACKLIST_IN -m recent --name blacklist --rcheck -j LOG --log-prefix "BLACKLIST_IN RCHECK" --log-level 7
-A BLACKLIST_IN -m recent --name blacklist --rcheck -j BLACKLIST

-N WAN_IN
-A WAN_IN -j BLACKLIST_IN
...

-A INPUT -j ERIN
-A INPUT -i {EXT_IFACE} -j WAN_IN
...

This is just the relevant paths in iptables. I have confirmed the path through the LOG messages I have littered throughout the ruleset.

Update: After TRACE enabled

This is the path through the ruleset for the first nmap packet namp -F 10.42.0.48:

[ 7021.149480] TRACE: raw:PREROUTING:policy:2 IN=eth0 OUT= MAC=xx SRC=...
[ 7021.173615] TRACE: mangle:PREROUTING:rule:2 IN=eth0 OUT= MAC=xx SRC...
[ 7021.197771] TRACE: mangle:HANDHELDS:rule:1 IN=eth0 OUT= MAC=xx SRC=...
[ 7021.221820] TRACE: mangle:PREROUTING:policy:3 IN=eth0 OUT= MAC=xx S...
[ 7021.246159] TRACE: nat:PREROUTING:rule:1 IN=eth0 OUT= MAC=xx SRC=10...
[ 7021.270094] TRACE: nat:UPNPD_PREROUTING:return:1 IN=eth0 OUT= MAC=x...
[ 7021.294688] TRACE: nat:PREROUTING:policy:6 IN=eth0 OUT= MAC=xx SRC=...
[ 7021.318757] TRACE: mangle:INPUT:policy:1 IN=eth0 OUT= MAC=xx SRC=10...
[ 7021.342657] TRACE: filter:INPUT:rule:2 IN=eth0 OUT= MAC=xx SRC=10.4...
[ 7021.366373] TRACE: filter:ERIN:rule:2 IN=eth0 OUT= MAC=xx SRC=10.42...
[ 7021.390054] TRACE: filter:INPUT:rule:3 IN=eth0 OUT= MAC=xx SRC=10.4...
[ 7021.413772] TRACE: filter:WAN_IN:rule:1 IN=eth0 OUT= MAC=xx SRC=10....
[ 7021.437591] TRACE: filter:BLACKLIST_IN:rule:1 IN=eth0 OUT= MAC=xx S...
[ 7021.461906] TRACE: filter:BLACKLIST_IN:rule:2 IN=eth0 OUT= MAC=xx S...
[ 7021.486269] BLACKLIST_IN RCHECKIN=eth0 OUT= MAC=xx SRC=10.42.0.1 DS...
[ 7021.506133] TRACE: filter:BLACKLIST_IN:rule:3 IN=eth0 OUT= MAC=xx S...
[ 7021.530447] TRACE: filter:BLACKLIST:rule:4 IN=eth0 OUT= MAC=xx SRC=...
[ 7021.554554] TRACE: filter:BLACKLIST:return:5 IN=eth0 OUT= MAC=xx SR...

Update 3

If I only port scan a single port, it still is able to identify that the host is up.

root@yellowtail:~# nmap -Pn -p80 10.42.0.48

Starting Nmap 6.00 ( http://nmap.org ) at 2014-02-12 23:25 GMT
Nmap scan report for 10.42.0.48
Host is up (0.00022s latency).
PORT   STATE    SERVICE
80/tcp filtered http
MAC Address: EC:43:F6:C0:B1:E8 (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 0.34 seconds

Here is the entire TRACE output from that scan:

[ 8565.051960] TRACE: raw:PREROUTING:policy:2 IN=eth0 OUT= M
[ 8565.075775] TRACE: mangle:PREROUTING:rule:2 IN=eth0 OUT= 
[ 8565.099686] TRACE: mangle:HANDHELDS:rule:1 IN=eth0 OUT= M
[ 8565.123557] TRACE: mangle:PREROUTING:policy:3 IN=eth0 OUT
[ 8565.147626] TRACE: nat:PREROUTING:rule:1 IN=eth0 OUT= MAC
[ 8565.171236] TRACE: nat:UPNPD_PREROUTING:return:1 IN=eth0 
[ 8565.195551] TRACE: nat:PREROUTING:policy:6 IN=eth0 OUT= M
[ 8565.219400] TRACE: mangle:INPUT:policy:1 IN=eth0 OUT= MAC
[ 8565.243045] TRACE: filter:INPUT:rule:2 IN=eth0 OUT= MAC= 
[ 8565.266520] TRACE: filter:ERIN:rule:2 IN=eth0 OUT= MAC= S
[ 8565.289870] TRACE: filter:INPUT:rule:3 IN=eth0 OUT= MAC= 
[ 8565.313348] TRACE: filter:WAN_IN:rule:1 IN=eth0 OUT= MAC=
[ 8565.336940] TRACE: filter:BLACKLIST_IN:rule:1 IN=eth0 OUT
[ 8565.361017] TRACE: filter:BLACKLIST_IN:rule:2 IN=eth0 OUT
[ 8565.385057] BLACKLIST_IN RCHECKIN=eth0 OUT= MAC= SRC=10.4
[ 8565.404774] TRACE: filter:BLACKLIST_IN:rule:3 IN=eth0 OUT
[ 8565.428915] TRACE: filter:BLACKLIST:rule:4 IN=eth0 OUT= M
[ 8565.452702] TRACE: filter:BLACKLIST:return:5 IN=eth0 OUT=
[ 8565.476707] TRACE: raw:PREROUTING:policy:2 IN=eth0 OUT= M
[ 8565.500509] TRACE: mangle:PREROUTING:rule:2 IN=eth0 OUT= 
[ 8565.524408] TRACE: mangle:HANDHELDS:rule:1 IN=eth0 OUT= M
[ 8565.548252] TRACE: mangle:PREROUTING:policy:3 IN=eth0 OUT
[ 8565.572322] TRACE: nat:PREROUTING:rule:1 IN=eth0 OUT= MAC
[ 8565.595933] TRACE: nat:UPNPD_PREROUTING:return:1 IN=eth0 
[ 8565.620263] TRACE: nat:PREROUTING:policy:6 IN=eth0 OUT= M
[ 8565.644118] TRACE: mangle:INPUT:policy:1 IN=eth0 OUT= MAC
[ 8565.667760] TRACE: filter:INPUT:rule:2 IN=eth0 OUT= MAC= 
[ 8565.691207] TRACE: filter:ERIN:rule:2 IN=eth0 OUT= MAC= S
[ 8565.714579] TRACE: filter:INPUT:rule:3 IN=eth0 OUT= MAC= 
[ 8565.738085] TRACE: filter:WAN_IN:rule:1 IN=eth0 OUT= MAC=
[ 8565.761640] TRACE: filter:BLACKLIST_IN:rule:1 IN=eth0 OUT
[ 8565.785705] TRACE: filter:BLACKLIST_IN:rule:2 IN=eth0 OUT
[ 8565.809747] BLACKLIST_IN RCHECKIN=eth0 OUT= MAC= SRC=10.4
[ 8565.829463] TRACE: filter:BLACKLIST_IN:rule:3 IN=eth0 OUT
[ 8565.853577] TRACE: filter:BLACKLIST:rule:4 IN=eth0 OUT= M
[ 8565.877387] TRACE: filter:BLACKLIST:return:5 IN=eth0 OUT=
  • We'd need to see you iptables rules to properly answer this. – user9517 Feb 12 '14 at 22:23
  • LOL, are you really sure you want to see ALL of my rules? I will just show you the path to the DROP instead. – Craig Feb 12 '14 at 22:38
  • I have updated with the relevant rules. These are the first rules to be executed and the last once my attacking machine is blacklisted, since the blacklist rules are second only to E,R connections. – Craig Feb 12 '14 at 22:48
  • Try building a trace rule, and looking at your logs? serverfault.com/a/126079/984 – Zoredache Feb 12 '14 at 22:51
  • 1
    Try to check for the reason why. What reason is given by : nmap -Pn -p80 10.42.0.48 --reason – krisFR Feb 13 '14 at 1:35
2

It is showing as "up" because you told Nmap to skip the host discovery phase and assume that it is up. That is the meaning of the -Pn option. Even without this option, though, you may find that Nmap can detect your system.

Nmap's host discovery uses many different probes to determine if a host is up. When scanning from an address on the same link layer (layer 2) as the target, it sends an ARP request to determine the layer-2 address (MAC address) of the target. The target responds with an ARP response containing its IP address and its MAC address. That is how the MAC address ends up in your output above.

You can't block this response with iptables, since it is not a layer-3 protocol. For that, you could use ebtables. Realize, however, that this is not really a threat: if you can't trust the hosts on your own LAN to know that you are up, then you have bigger problems.

To diagnose questions of "Why does Nmap say X?" you can use the --reason option, which will show why Nmap has chosen a particular status for a host or a port:

$ sudo ./nmap -p 443 192.168.1.1 --reason

Starting Nmap 6.41SVN ( http://nmap.org ) at 2014-02-13 06:53 CST
Nmap scan report for 192.168.1.1
Host is up, received arp-response (0.0049s latency).
PORT    STATE SERVICE REASON
443/tcp open  https   syn-ack
MAC Address: 00:21:29:xx:xx:xx (Cisco-Linksys)

Nmap done: 1 IP address (1 host up) scanned in 0.17 seconds
$ sudo ./nmap -p 12345 -Pn google.com --reason

Starting Nmap 6.41SVN ( http://nmap.org ) at 2014-02-13 06:54 CST
Nmap scan report for google.com (74.125.227.231)
Host is up, received user-set.
Other addresses for google.com (not scanned): 74.125.227.232 74.125.227.233 74.125.227.238 74.125.227.224 74.125.227.225 74.125.227.226 74.125.227.227 74.125.227.228 74.125.227.229 74.125.227.230
rDNS record for 74.125.227.231: dfw06s38-in-f7.1e100.net
PORT      STATE    SERVICE REASON
12345/tcp filtered netbus  no-response

Nmap done: 1 IP address (1 host up) scanned in 2.12 seconds

One final note: You should always try to use the latest version of Nmap. Version 6.40 superseded 6.00 in July of 2013.

| improve this answer | |
  • I am testing an external interface on a local network before it is placed on a PPPoE connection. The idea is that I wan't the machine to "disappear" as much as possible when it detects a probe. This is working at Layer 3 as you point out, but I merely didn't understand what tactics nmap was using to "discover" the host. – Craig Feb 13 '14 at 15:18
  • @Craig As I mentioned in the first sentence, you are telling Nmap not to even try to discover the host, but to assume it is up. Therefore it says "Host is up" because it believes you. Remove the -Pn and add --reason, then continue your testing. – bonsaiviking Feb 13 '14 at 15:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.