Hi,
What about Postel's 'be liberal in what you accept' ? What about
peers/intermediate system that have for example bugs which
accidentally set FIN flags (ISP's broken traffic shaping/limiting
device anyone ?). If pf can safely cleanse such legitimate traffic,
then why block it ?
Blindly implementing 'orders' from PCI etc is just wrong - to do so is
only encouraging such bad practices. Instead reject their demands,
using whatever appeals process is available. Only when enough
technical staff do so will it be fixed.
All such regulations should be of the style where both of these are
permitted:
- "I am a stupid admin, so I'll just blindly follow them"
and
- "I am a competent admin, so I'll use my judgement to best protect my
net"
How about this, for a fun response: "We don't want to drop such
'special' traffic, since if we do so, then an attacker can deduce that
we have implemented PCI guidelines, which in turn implies we have CC
details online, and thus are a more attractive target' ...
/Pete
On 12 Mar 2009, at 10:22, J.C. Roberts wrote:
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
