Explain Nmap intense scan 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 CESTNmap scan report for 12.34.56.78Host is up (0.57s latency).Not shown: 93 closed portsPORT STATE SERVICE22/tcp open ssh25/tcp open smtp53/tcp open domain80/tcp open http3306/tcp open mysql8080/tcp open http-proxy8443/tcp open https-altNmap done: 1 IP address (1 host up) scanned in 4.15 secondsThis 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 portsNote: ... means repetition of previous line with different port numberSo 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 ADDRESS1 1.52 ms 12.99.34.2552 1.37 ms 12.99.0.33 1.09 ms 12.34.56.78Port 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 filterChain 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/URG1968K 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:942225288 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…

Andrew Jenkins · Accepted Answer

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 th…

Explain Nmap intense scan vs quick result?

About this question

Your answer

1 Answer

More Cyber Security discussions

Learn & Explore

Cyber Security Tutorials

Cyber Security Interview Q&A

Latest Cyber Security Blogs

Want answers to more Cyber Security questions?

Stay in the loop — it’s free

You’re on the list!