Nmap Development mailing list archives
Re: Scan of a Fortigate FW - false positives
From: "Luke, Jason" <lukej () anx com>
Date: Wed, 10 Oct 2012 14:11:24 +0000
Help me understand the TTL testing I might do to identify the offending hop. Here is a short snippet with two closed ports and one open port. TCP 541 is the only open port. 46,47 should not respond. #Note: I set my source port to be 50000 for the scan simply for testing and readability. It makes no difference in the results either way. ####Packets for open port TCP 541 09:53:56.040140 IP (tos 0x0, ttl 55, id 39433, offset 0, flags [none], proto TCP (6), length 44) X.X.X.X.50000 > Y.Y.Y.Y.541: Flags [S], cksum 0xb369 (correct), seq 3996432966, win 4096, options [mss 1460], length 0 09:53:56.113346 IP (tos 0x0, ttl 45, id 42671, offset 0, flags [DF], proto TCP (6), length 44) Y.Y.Y.Y.541 > X.X.X.X.50000: Flags [S.], cksum 0xbede (correct), seq 3673297591, ack 3996432967, win 5840, options [mss 1460], length 0 09:53:56.113379 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) ####Packets for non-open ports 09:54:14.381648 IP (tos 0x0, ttl 236, id 565, offset 0, flags [none], proto TCP (6), length 40) Y.Y.Y.Y.8 > X.X.X.X.50000: Flags [R], cksum 0x85b4 (correct), seq 0, win 0, length 0 09:54:14.381853 IP (tos 0x0, ttl 236, id 569, offset 0, flags [none], proto TCP (6), length 40) Y.Y.Y.Y.10 > X.X.X.X.50000: Flags [R], cksum 0x85b2 (correct), seq 0, win 0, length 0 09:54:14.381862 IP (tos 0x0, ttl 236, id 567, offset 0, flags [none], proto TCP (6), length 40) Y.Y.Y.Y.9 > X.X.X.X.50000: Flags [R], cksum 0x85b3 (correct), seq 0, win 0, length 0 09:54:14.382047 IP (tos 0x0, ttl 236, id 571, offset 0, flags [none], proto TCP (6), length 40) Y.Y.Y.Y.11 > X.X.X.X.50000: Flags [R], cksum 0x85b1 (correct), seq 0, win 0, length 0 09:54:14.382607 IP (tos 0x0, ttl 236, id 577, offset 0, flags [none], proto TCP (6), length 40) Y.Y.Y.Y.6 > X.X.X.X.50000: Flags [R], cksum 0x85b6 (correct), seq 0, win 0, length 0 The TTL from the open TCP 541 port looks to be 64, but the TTL's of the non-open ports looks to all be 236. I've been boning up on TTL's but not sure how this helps me yet. On 10/9/12 7:42 PM, "David Fifield" <david () bamsoftware com> wrote:
On Tue, Oct 09, 2012 at 07:33:49PM +0000, Luke, Jason wrote:Originally found this issue from running a Rapid7 Nexpose scan, which uses NMAP for host discovery. Repeatable on my own local version, 5.5 and 6.0. sudo nmap --privileged -n -PS21-23,25,53,80,110-111,135,139,143,443,445,541,993,995,1723,3306,3389, 3475,5900,8080,8200,9300,27249 -sS -O --osscan-guess --max-os-tries 1 -p1-2850--max-retries 4 --max-rtt-timeout 1000ms --initial-rtt-timeout 100ms --defeat-rst-ratelimit --min-rate 200 --max-rate 3000 -r X.X.X.X IF I set the # of ports to scan anything higher than about 2850, I get many false "open" ports shown. I had started with all ports and have narrowed it down to around that 2850 number. It seems obvious that their is some IDS/IPS functionality somewhere causing the interference but I have seen the firewall config and see nothing untoward. I have gone round and round with the ISP and they vehemently claim no such interference.We have seen some problems related to false SYN/ACKs recently: http://seclists.org/nmap-dev/2012/q3/864 http://seclists.org/nmap-dev/2012/q3/872 http://seclists.org/nmap-dev/2012/q3/949 The assertion failures have been fixed in Subversion, but it is still a problem when scanning something that sends SYN/ACK for ports that are no open. I suspect the same as you: that there is some middlebox that starts speculatively sending SYN/ACKs when the load gets high enough. You can try -sT scan instead of the default -sS. That will do a full TCP handshake and weed out the ports that aren't really open. You can also try checking the TTLs of the spoofed SYN/ACKs. They will likely be different from the genuine SYN/ACKs, and can give you a clue as to where in the network path the spoofing is happening. David Fifield
_______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Current thread:
- Scan of a Fortigate FW - false positives Luke, Jason (Oct 09)
- Re: Scan of a Fortigate FW - false positives David Fifield (Oct 09)
- Re: Scan of a Fortigate FW - false positives Luke, Jason (Oct 10)
- <Possible follow-ups>
- Re: Scan of a Fortigate FW - false positives David Fifield (Oct 10)
- Re: Scan of a Fortigate FW - false positives David Fifield (Oct 09)