PCI Compliance and SYN Flood DoS Attacks
We recently received the following question from a customer about the security checks included in the PCI compliance analysis performed by Athena FirePAC:
I just ran Athena FirePAC on an ASA firewall that is failing PCI requirement 1.3.6 due to SYN flood protection not enabled. I understand what SYN flood protection does, but I believe ASA firewalls still processes in a stateful manner, even without SYN flood protection turned on. This failure would indicate that the firewall will process a non stateful packet, and I don’t believe that’s the case. Can someone advise on why FirePAC failed us on this requirement?
The PCI DSS control item 1.3.6 says, “Implement stateful inspection, also known as dynamic packet filtering. (That is, only ‘established’ connections are allowed into the network.)” It is true that Cisco ASA firewalls implement stateful inspection, as do most modern firewalls including Check Point, and Juniper Netscreen. So checking for it is a moot point.
Rather than simply making this a “checkbox” item in the PCI DSS compliance analysis provided by Athena FirePAC, we decided to take this as an opportunity to check for additional protection against some common attacks that exploit the stateful nature of TCP connections. The SYN flood attack is one example.
In Cisco ASA firewalls, the NAT and Static commands have a parameter that specifies the maximum number of embryonic connections allowed per host. An embryonic connection is a connection request that has not finished the three-way handshake between source and destination. The default is 0, which means unlimited embryonic connections are allowed. Setting the embryonic connection limit to a non-zero value lets you prevent SYN flood attacks by dropping connections after the limit is reached. FirePAC checks if this limit is not set, i.e. 0, which means unlimited embyronic connections are allowed. If it is 0, the host is susceptible to the SYN flood attack and the security check is flagged. FirePAC performs similar checks for Juniper Netscreen and Check Point firewalls as well.
As I’ve noted elsewhere, simply passing a PCI compliance audit is not a substitute for security. You really have to know what’s going on in your firewall to ensure that it’s configured securely. Given some of the changes announced earlier this year by the PCI council, these kinds of robust and detailed analyses will be required to show that that the PCI in-scope network is truly secure and controlled. FirePAC includes these kinds of additional checks to help you get it right.