Dropping syn+fin replies, but not really?

[Eirik Øverby]

On Nov 24, 2008, at 23:12, Pieter de Boer wrote:

> Hi Eirik,
>
>>> Perform the nmap scan and look at the tcpdump output to see how your
>>> firewall and/or server react.
>> nmap command:
>> nmap -PN -sT --scanflags SYNFIN -p<port> anduin.net
>> where <port> was either 80 (open) or 8585 (closed).
>> tcpdump command on firewall (which NATs to internal IPs):
>> tcpdump -i <interface> -p -vvv host alge.anart.no and \(port 80 or  
>> port 8585\)
>> where <interface> was the publicly facing interface on the firewall.
>> Results for port 80:
>> IP (tos 0x0, ttl  59, id 12785, offset 0, flags [DF], proto: TCP  
>> (6), length: 64) alge.anart.no.40283 > 213.225.74.230.http: S,  
>> cksum 0xa720 (correct), 3300467486:3300467486(0) win 16384 <mss  
>> 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 2747936488 0>
>> IP (tos 0x0, ttl  63, id 10914, offset 0, flags [DF], proto: TCP  
>> (6), length: 60) 213.225.74.230.http > alge.anart.no.40283: S,  
>> cksum 0x8ef5 (correct), 347647336:347647336(0) ack 3300467487 win  
>> 65535 <mss 1460,nop,wscale 3,sackOK,timestamp 2946365534 2747936488>
>> Results for port 8585:
>> IP (tos 0x0, ttl  59, id 44156, offset 0, flags [DF], proto: TCP  
>> (6), length: 64) alge.anart.no.1839 > 213.225.74.230.8585: S, cksum  
>> 0xf765 (correct), 1324215952:1324215952(0) win 16384 <mss  
>> 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 4070158112 0>
>> IP (tos 0x0, ttl  63, id 34488, offset 0, flags [DF], proto: TCP  
>> (6), length: 40) 213.225.74.230.8585 > alge.anart.no.1839: R, cksum  
>> 0x52ef (correct), 0:0(0) ack 1324215953 win 0
>> I can't tell what's going on here, except I wouldn't have expected  
>> a reply at all to the second one at least, and maybe not even the  
>> first. However, I don't have enough experience to tell if nmap is  
>> doing the "right thing" here at all.
>
> First of all, this is not a scan with both the SYN and FIN flags  
> set. This can be seen from the tcpdump output only showing the 'S'  
> flag. You're using -sT, which makes nmap use connect(), and thus the  
> regular SYN, SYN/ACK, ACK 3-way-handshake. For a SYN/FIN scan,  
> you'll need root access. I tested this locally without supplying  
> further TCP scan options to nmap. Could you retest and make sure you  
> see 'SF' as flags in tcpdump?

I don't. With
nmap --scanflags SYNFIN -p<port> <host>
as root, I got, from what I can tell, exactly the same. May be this is  
filtered on the way out, so I need to find an unhampered box to try  
from? I could simply try crossing vlans through the firewall, I guess.


> Secondly, it would be useful if you'd explain the following: is your  
> firewall NATting port 8585 also, or is traffic sent to that port  
> handled by the TCP/IP stack of the firewall itself? Furthermore, it  
> appears the firewall is not actually filtering traffic to port 8585..

This particular machine is behind 1:1 NATing. I usually do NAT+fwrules  
for needed ports only, but even in those cases I get the (false?) syn 
+fin alerts from (in this case) securityspace.com.


> The strictest firewall configuration would be to have everything  
> filtered except the ports you actually use. Those ports are either  
> NATted to the back-end system or handled by the firewall itself (in  
> case you want that functionality). From a security perspective,  
> simply dropping incoming traffic is better than sending back RST's.  
> In pf this is the default.

That is correct, however in this case I do 1:1 and no pf on the target  
host (it is in a DMZ). I ran the scan on this system out of curiosity  
only, however as stated above this problem is far from unique to this  
particular system.

Thanks for your input, i'll keep trying to reproduce this..

/Eirik