On Wed, 11 Mar 2009 13:07:22 -0400 Jason Dixon <ja...@dixongroup.net>
wrote:
> On Wed, Mar 11, 2009 at 01:04:34PM -0400, David Goldsmith wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Jason Dixon wrote:
> > >
> > > S/SAFR
> > >
> > > I just had to deal with this on our customer's PCI scan. Don't
> > > argue with the logic, just do it. :)
> >
> > Let me guess -- TrustKeeper? We just had to deal with this as well.
> > Submit an appeal and they should accept it.
>
> Yup.
>
> > The "flags S/SAFR" will work unless you are being a good little pf
> > admin and also scrubbing all the traffic. The problem is pf
> > considers SYN-RST packets to be illegal and drops them (good) but
> > only considers SYN-FIN packets to be ambiguous and so it
> > "normalizes" them and clears the FIN bit (in this case for the PCI
> > scan - bad) Then your server behind the firewall received what it
> > thinks is a nice clean SYN packet and it sends back SYN-ACK.
>
> Yes, we have our own reasons not to scrub there. Well, *someone* has
> their reasons. I have to deal with those reasons. ;)
>
Ahhh my least favorite acronym name space conflict:
PCI == Payment Card Industry
Their "security through ignorance" practices are nearly as illustrious
as their "business through abusive lending" practices. The thing to
remember is the security facade they require is almost entirely for the
sake of public confidence and litigation defense. --hmmm... I should
probably save the rest of this rant for a far more appropriate mailing
list, like /dev/null
Anyhow, back to the original question, "are there any ramifications to
blocking SYN+FIN completely?"
Some (Darren Reed, ipf author) think that pf unconditionally clearing
the FIN flag on scrub is a bug, And no, we don't need a flame war about
whether or not Darren is "right," but none the less, it's still good to
see how the RFC's and ideas about "correct" filtering are both subject
to lots of interpretation.
http://www.derkeiler.com/Mailing-Lists/FreeBSD-Security/2005-07/0011.html
I know SYN+FIN is a valid packet according to RFC 793 and 1644 (T/TCP),
but the more important question is, "what are the valuable *uses* for
SYN+FIN packets?"
Personally, I can't think of any valuable uses. Can you?
Just because SYN+FIN is a technically valid packet according to the
various RFC's doesn't mean we want or need such traffic, and doesn't
mean we consider it valuable and useful. Can you think of any RFC
valid traffic you're dropping when the RFC's tell you that you're
supposed to respond to it? --Ya, I thought so.
Spammers? --Yep, RFC valid traffic.
DDOS? --Yep, RFC valid traffic.
Brute Force? --Yep, RFC valid traffic.
port scans --A lot of it is RFC valid traffic.
Though 'scrub' will drop the FIN flag off the SYN+FIN packets, the
bofhish instinct says without a proven and valuable *use* for SYN+FIN,
then just block it. If anyone complains about breakage, then just point
your (middle) finger at PCI/TrustKeeper compliance requirements, and
tell the user to take it up with them.
Call me overly pragmatic, but if something in a standard is not
providing valuable use (i.e. reward) and poses *any* type of risk or
cost (including the risk and cost of wasting my time filing and
maintaining some appeal), then the answer is painfully simple.
--
J.C. Roberts
