Nmap - Intense vs Quick result

Question

I inherited a small network and currently am assessing its security performance.

I started port scanning a host (lets call it Weirdo) in that small network and from my perspective, it seems that that specific host has some kind of port scanning detector and/or scan result obfuscator thing with iptables going on, because the result coming back from the intense scan differs so much from that of the quick one.

So here the quick scan result me@mypc:~# nmap -T4 -F 12.34.56.78:

Starting Nmap 7.01 ( https://nmap.org ) at 2017-04-18 11:48 CEST
Nmap scan report for 12.34.56.78
Host is up (0.57s latency).
Not shown: 93 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
25/tcp   open  smtp
53/tcp   open  domain
80/tcp   open  http
3306/tcp open  mysql
8080/tcp open  http-proxy
8443/tcp open  https-alt

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

This actually shows the same output as running the quick scan from Weirdo localhost root@Weirdo:~# nmap -T4 -F localhost.

But this is the intense scan me@mypc:~# nmap -T4 -A -v 12.34.56.78:

1/tcp     open  tcpmux?
...(every port is shown as open, except a few)
49155/tcp open  unknown
...
9102/tcp  open  jetdirect?
... 
65389/tcp open  tcpwrapped
...
Completed SYN Stealth Scan at 11:49, 18.22s elapsed (1000 total ports) 
... 
Not shown: 120 closed ports

Note: ... means repetition of previous line with different port number

So basically the intense scan finds that many more ports are open, but this is paradox, because the intense scan on the Weirdo localhost root@Weirdo:~# nmap -T4 -A -v localhost gives also the exact same open port list as the quick scan.

When I look at the traceroute then I see the following:

TRACEROUTE (using port 199/tcp)
HOP RTT     ADDRESS
1   1.52 ms 12.99.34.255
2   1.37 ms 12.99.0.3
3   1.09 ms 12.34.56.78

Port Scanning the two ips with me@mypc:~# nmap -sV -T4 -O -F --version-light 12.99.34.255 12.99.0.3 I see that 12.99.34.255 is a Netgear Firewall FVS336Gv2 accessible with the browser (port 80, is open therefore).

A consecutive (1 seconds after), quick scan (after the intense scan) does result in the same output as the intense scan.

After waiting a couple of seconds and then doing the quick scan again it results in the same output as the initial quick scan.

Is this firewall playing tricks on the intense scan probably?

Another little addition:

On the Weirdo host I check the iptables firewall and get this:

root@Weirdo:~# iptables -vL -t filter
Chain INPUT (policy DROP 25288 packets, 1768K bytes)
 pkts bytes target     prot opt in     out     source               destination         
 101K   54M ACCEPT     all  --  lo     any     anywhere             anywhere            
 189K   12M ACCEPT     all  --  eth1   any     anywhere             anywhere            
  285  9686 ACCEPT     icmp --  eth0   any     anywhere             anywhere             icmp echo-request
  297 30354 garbage    all  --  eth0   any     anywhere             anywhere             state INVALID
    0     0 garbage    tcp  --  eth0   any     anywhere             anywhere             tcpflags: FIN,SYN,RST,PSH,ACK,URG/NONE
    0     0 garbage    tcp  --  eth0   any     anywhere             anywhere             tcpflags: FIN,SYN/FIN,SYN
    0     0 garbage    tcp  --  eth0   any     anywhere             anywhere             tcpflags: SYN,RST/SYN,RST
    0     0 garbage    tcp  --  eth0   any     anywhere             anywhere             tcpflags: FIN,RST/FIN,RST
    0     0 garbage    tcp  --  eth0   any     anywhere             anywhere             tcpflags: FIN,ACK/FIN
    0     0 garbage    tcp  --  eth0   any     anywhere             anywhere             tcpflags: PSH,ACK/PSH
    0     0 garbage    tcp  --  eth0   any     anywhere             anywhere             tcpflags: ACK,URG/URG
1968K 2742M ACCEPT     all  --  eth0   any     anywhere             anywhere             state RELATED,ESTABLISHED
 9564  391K ACCEPT     tcp  --  eth0   any     anywhere             anywhere             tcp dpt:http
  463 27508 ACCEPT     tcp  --  eth0   any     anywhere             anywhere             tcp dpt:domain
   45  2392 ACCEPT     tcp  --  eth0   any     anywhere             anywhere             tcp dpt:8443
    0     0 ACCEPT     tcp  --  eth0   any     anywhere             anywhere             tcp dpt:9422
25288 1768K garbage    all  --  eth0   any     anywhere             anywhere            

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 1361K packets, 501M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain garbage (9 references)
 pkts bytes target     prot opt in     out     source               destination 

Are these filters playing the tricks on the intense scan?

What does it mean to have a rule with target garbage ?

Answer 1

First, let's correct some assumptions and terminology which will make understanding the results a lot easier:

• The -F option is a "quick" scan because it scans only 100 ports. It is the equivalent of --top-ports 100. Without this option, Nmap scans 1000 TCP ports.
• The -A option is not "intense" but rather "All features." It is the equivalent of -sV -sC -O --traceroute.

So you have run a port scan of 100 ports and are comparing it to a port scan with version detection and OS fingerprinting of 1000 ports. Its understandable that you would have more results in the second scan. But lets assume you literally meant "every port is open" in the second scan. What could be the cause, and how can we know for sure?

First, it would be interesting to know whether the -F scan produces different results if run after the -A scan. I suspect it would. This would then show that something (likely the firewall) has changed how packets are passed between the scanning system and the target. Here are the clues I see in the second scan:

• more open ports
• Unidentified services (tcpmux?) and tcpwrapped services
• open ports listed that are not in a localhost scan of the target

Iptables is not smart enough on its own to adapt behavior like this, and there's nothing in your rules that shows it either. So interference probably comes from a different system on the network path between scanner and target. If you had saved XML output (-oX or -oA) or had used the --reason option (also activated by -vv or -d), then you would be able to see details about why Nmap considered each port open or closed. The most interesting part of this is the reason_ttl attribute, which records the received IP Time-To-Live field value, which is normally decremented one time for each IP hop on the network path. So for a Linux target, responses start at TTL 64, and with 2 hops in between should be reduced to 62. Whatever you see in the most accurate version of the scan (i.e. the -F scan with mostly closed ports) is your baseline. If you start to see values higher than that, it would most likely mean that something between you and the target is sending responses instead of the target. Example (port 27 is "fake-open"):

PORT   STATE    SERVICE REASON
25/tcp open     smtp    syn-ack ttl 60
27/tcp open     nsw-fe  syn-ack ttl 61
80/tcp open     http    syn-ack ttl 60

Avoiding this will probably involve slowing your scan down to avoid tripping the "port scan" alert threshold. Evasion of adaptive measures like this is complicated. But once you have tripped the threshold, you can do some interesting things to map out the firewall rules.

If you are currently being "blocked" in this way with lots of open ports, but you can still access the real services behind the original set of ports (ssh, smtp, http, etc.), then you can try setting a very low TTL value in your outbound packets. When a router decrements the TTL to 0, it will send an ICMP Time Expired message, causing the port to be labeled filtered. If we can pick a TTL that expires after the firewall, but before the target, we can get a list of "open" ports that are caused by the firewall, and a set of "filtered" ports that are probably allowed through. In your example, based on the traceroute output, I would use the --ttl 2 option, since --ttl 3 would actually reach the target. So the scan would look like: nmap -sS --ttl 2 -Pn example.com. Using -Pn is usually not recommended, but in this case is necessary, since the probes will never actually reach the target. Reminder: this scan will only produce useful output if you are currently being blocked by the firewall and if the block is not on every port, but is letting some traffic through:

PORT   STATE    SERVICE REASON
25/tcp filtered smtp    time-exceeded from 12.99.34.255 ttl 252
27/tcp open     nsw-fe  syn-ack ttl 61
80/tcp filtered http    time-exceeded from 12.99.34.255 ttl 252

In this output, the port 27 received a syn-ack spoofed to look like it came from the target, even though we know from our --ttl 2 that our probe would never have reached the target. The other two ports are allowed through, since we get the time-exceeded messages from when they expired. If the firewall doesn't allow outgoing time-exceeded messages, then they would show as filtered with a no-response reason.