Arch Linux

redcodefinal

Member

Registered: 2013-12-29

Posts: 6

iptables blocks pings, nmap still picks up the host, why?

I've been writing some iptables firewall rules using ferm-http://ferm.foo-projects.org/. My goal is to make as stealthy as a machine as possible, which includes blocking pings. When pinging the system with windows it times out, which is great.

C:\Windows\system32>ping 192.168.2.222

Pinging 192.168.2.222 with 32 bytes of data:
Request timed out.
Request timed out.

Ping statistics for 192.168.2.222:
    Packets: Sent = 2, Received = 0, Lost = 2 (100% loss),
Control-C
^C
C:\Windows\system32>ping 192.168.2.222

However when doing a simple ping scan with nmap, it detects the host is up.

nmap -sn 192.168.2.222

Starting Nmap 6.40 ( http://nmap.org ) at 2013-12-31 14:32 Pacific Standard Time
Nmap scan report for 192.168.2.222
Host is up (0.00s latency).
MAC Address: 00:0C:29:AA:5B:4C (VMware)
Nmap done: 1 IP address (1 host up) scanned in 12.90 seconds

What is weirder is that when listening in with wireshark, it receives no network traffic. For the record, pinging with my windows machine shows up, and the nmap is done from the same machine I pinged from.
To more clear on Wireshark:
I'm running wireshark from my windows computer, my arch install is on VMWare workstation. Wireshark is listening to my network card with the filter ip.addr==192.168.2.222 so it only displays info headed for my virtual machine. Still, it shows nothing when I run a ping scan with nmap on my Windows machine.
Here are my firewall rules

iptables-save

# Generated by iptables-save v1.4.20 on Tue Dec 31 14:45:29 2013
*filter
:INPUT DROP [116:14283]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [116:14060]
:ICMP - [0:0]
:TCP - [0:0]
:UDP - [0:0]
-A INPUT -m state --state INVALID -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -s 127.0.0.1/32 ! -i lo -j DROP
-A INPUT -m connlimit --connlimit-above 5 --connlimit-mask 24 --connlimit-saddr -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -j TCP
-A INPUT -p icmp -j ICMP
-A ICMP -p icmp -m icmp --icmp-type 8 -j DROP
-A TCP -p tcp -m tcp --dport 1110 -j ACCEPT
COMMIT
# Completed on Tue Dec 31 14:45:29 2013

ferm rules

table filter {
	chain INPUT {
		policy DROP;                                                 #Auto drop packets that slip through the rules. We don't know 'em, we don't want 'em!
		
		#Track connections
		mod state state INVALID DROP;                                #Drop invalid packets, keeping some port scans at bay
		mod state state (ESTABLISHED RELATED) ACCEPT;                #Accept packets that are already established, or related to an established connection

		interface lo ACCEPT;                                         #Allow lo to communicate
		
		interface !lo saddr 127.0.0.1 DROP;                          #Says its from 127.0.0.1 but not from lo, drop
		
		#Allow only a certain number of parllel connections
		mod connlimit connlimit-above 5 connlimit-mask 24 REJECT;


		#Send to protocol specific chain
		proto tcp jump TCP;
		proto icmp jump ICMP;
		
 	}	
	
	chain TCP {
   		proto tcp dport 1110 ACCEPT;                                 #Allow port 1110

	}

	chain UDP {
	}

	chain ICMP {
		proto icmp icmp-type echo-request DROP;
	}
}

chain OUTPUT policy ACCEPT;
chain FORWARD policy DROP;

Last edited by redcodefinal (2014-01-01 00:53:14)

Andreaskem

Member

Registered: 2013-10-13

Posts: 67

Re: iptables blocks pings, nmap still picks up the host, why?

nmap -sn is more than a simple ping. Quoting from http://nmap.org/book/man-host-discovery.html

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 a privileged user tries to scan targets on a local ethernet network, ARP requests are used unless --send-ip was specified.

ARP in particular seems to operate on a lower level than ICMP, TCP or UDP which could explain the behavior you're seeing.

Before beginning to use an IPv4 address (whether received from manual configuration, DHCP, or some other means), a host implementing this specification must test to see if the address is already in use, by broadcasting ARP probe packets.

So I guess nmap simply tries to get the address 192.168.2.222 and since that should fail, it knows that there is a host running with that address (or 192.168.2.222 simply responds to a broadcast ARP message). Seems to only work on the same local net, though.

Last edited by Andreaskem (2014-01-01 15:09:05)

amvakar

Member

Registered: 2013-12-04

Posts: 21

Re: iptables blocks pings, nmap still picks up the host, why?

Look into arptables and ebtables -- they'll let you avoid ARP attacks.

redcodefinal

Member

Registered: 2013-12-29

Posts: 6

Re: iptables blocks pings, nmap still picks up the host, why?

nmap -sn is more than a simple ping. Quoting from http://nmap.org/book/man-host-discovery.html

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 a privileged user tries to scan targets on a local ethernet network, ARP requests are used unless --send-ip was specified.

ARP in particular seems to operate on a lower level than ICMP, TCP or UDP which could explain the behavior you're seeing.

Before beginning to use an IPv4 address (whether received from manual configuration, DHCP, or some other means), a host implementing this specification must test to see if the address is already in use, by broadcasting ARP probe packets.

So I guess nmap simply tries to get the address 192.168.2.222 and since that should fail, it knows that there is a host running with that address (or 192.168.2.222 simply responds to a broadcast ARP message). Seems to only work on the same local net, though.

That would explain a lot, specifically why both machines receive no traffic when wireshark filter ip.addr==192.168.2.222 is on. I'll look into it and make sure.