Dropping syn+fin replies, but not really?

Ian Smith smithi at nimnet.asn.au
Tue Nov 25 04:52:40 PST 2008


On Mon, 24 Nov 2008, Eirik Øverby wrote:
 > On Nov 24, 2008, at 23:12, Pieter de Boer wrote:
[..]
 > > > 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.
[..]
 > > 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..

Perhaps off to the side, but I wonder if net.inet.tcp.blackhole may be 
relevant?  Here tcpdump was showing RSTs back to attempted connections 
to unused ports, despite these being dropped on ingress by the firewall, 
which I thought was unnecessarily informative :)

# net.inet.tcp.blackhole: Do not send RST when dropping refused connections
net.inet.tcp.blackhole=1

fixed that here.  Caveats: that's on a 5.5-STABLE box using ipfw to drop 
such connections.  I'd been surprised to see those RSTs too ..

cheers, Ian


More information about the freebsd-security mailing list