Re: Scan of a Fortigate FW - false positives

["Luke, Jason" <lukej () anx com>]

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/