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