Explain Nmap intense scan vs quick result?
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 ?
First, let's correct some assumptions and terminology which will make understanding of the nmap intense scan 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. It's understandable that you would have more results in the second scan. But let's 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 behaviour 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 60Avoiding 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 labelled 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 252In 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.