-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jason Dixon wrote: > On Wed, Mar 11, 2009 at 10:42:38AM -0400, Stuart VanZee wrote: >> I understand that this might annoy a few of you, If it does >> please accept my apologies. >> >> The place I work is required to have an external security scan >> from time to time and the latest scan says that we have failed >> because the firewall responded to a TCP packet that has the SYN >> and FIN flags set. I know that OpenBSD isn't vulnerable to the >> exploits that use this: >> >> http://www.kb.cert.org/vuls/id/IAFY-5F8RWP >> >> However, I don't see any reason to respond to a packet with SYN >> and FIN set, AND, a firewall rule that drops said TCP packets >> would fix the fact that we are now "non compliant" as far as >> the security scan goes. I think a pf rule such as: >> >> block drop in quick proto tcp all flags SF/SF >> >> would do it. >> >> Does anyone see a way that this would come back to bite me on >> the ass later? > > 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. 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. - -- David Goldsmith Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJt+8i417vU8/9QfkRAqwwAJ43XDgeEn/1E4npP/YjexqBEMF5DgCfahVN 8LcIW4mqp4WryCmZ5EN1phQ= =pYPL -----END PGP SIGNATURE-----
