Here is an update from CheckPoint. Eric Sends ---------------------- Forwarded by James E McWilliams/CA/KAIPERM on 08/05/99 02:13 PM --------------------------- [EMAIL PROTECTED] on 08/05/99 01:43:00 PM To: [EMAIL PROTECTED]@Internet cc: (bcc: James E McWilliams/CA/KAIPERM) Subject: [FW1] Check Point Announcement Check Point is aware of a published Denial Of Service attack against the Check Point connection table, used by FireWall-1, FloodGate-1 and VPN-1. For additional information on the attack, see http://www.securityfocus.com/vdb/bottom.html?vid=549. The remainder of this message describes the attack, its practical impact, ways to mitigate, and the steps Check Point is taking to eliminate the attack. When a Check Point gateway receives a packet which is not registered in its connection table and is not otherwise allowed (e.g. expected FTP data connection) or prohibited (e.g. SAM blocked) it will try to match it to the rule base. Specifically, when a "unfamiliar" TCP ACK packet is received it will be matched against the rule base and if an accept rule is found it will be recorded in the connection table, because this is a packet in an "established" connection (in the context of TCP) the timeout will be set to the TCP timeout that is defined in the policy configuration properties (3600 seconds by default). If enough such packets are sent the connections table may fill up and the connectivity through the gateway may suffer. Note that only packets that are allowed by the rule base can be added to the connections table in this manner. This means that for "inbound" packets (i.e., from the Internet) the destination must normally be a well known server behind the gateway. This server will immediately send a TCP RST packet which will decrease the timeout in the connections table to a smaller timeout (50 seconds by default), this will make it much harder to saturate the connections table. For "outbound" packets (i.e., going to the Internet) rules are likely to be less restrictive and the possibility is much higher of addressing a non-existent server (thereby avoiding a RST and transition to a smaller timeout). Thus, this Denial of Service attack depends on the ability to send enough ACK packets within a certain time period. This is far likelier from the inside, with its relatively higher access speeds (being LAN connected) to the target gateway, than from the Internet side. Therefore, Check Point sees the primary risk of this attack to be from malicious insiders, attempting to deny external connectivity to others within the organization. Possible ways to minimize the vulnerability: 1. Craft a rule base that reduces ability to insert ACK packets into connections table. For example: - Minimize ACCEPT rules with destination ANY, one option is to add Client Authentication (with concurrent session limits). - For those services that use ACCEPT to destination ANY, consider the use of Fast Mode (V4.0) on that service (there are limits on the user of Fast Mode in conjunction with NAT, encryption and other features, please consult the FireWall-1 documentation). 2. Increase the size of the connections table, in order to increase the number of ACKs needed to affect connectivity. To do this (assuming V4.0) perform the following: - Edit $FWDIR/lib/table.def. The attribute limit followed by the limit value (for instance, limit 50000 for 50000 connections), should be inserted after hashsize 8192 attribute of the Connection Table. It must be inserted at the two locations, within $FWDIR/lib/table.def file (the two lines which begin with "connections = "). Example: connections = dynamic refresh expires TCP_START_TIMEOUT expcall KFUNC_EXPIRE implies tracked kbuf 1 hashsize 8192 limit 50000; - Note that increasing the hashsize value might be needed to maintain performance. hashsize should be a power of 2, and its value should be as approximate number as possible to the limit value. For example, if the limit value is 50,000, hashsize should be 65536. - Validate that enough memory has been allocated to the Check Point kernel to handle the increased connections table. Using a general rule of: connection table size = ([memory] - X)/60, where X should be a value between 0.5-3 Mbytes (depending on the amount of logging and accounting done by the FireWall), and [memory] is the internal memory allocated for the FireWall-1 (use $FWDIR/bin/fw ctl pstat to get this number). If the connection table size is less then your desired limit, you may need to increase kernel memory. Please see Page 372 in the FireWall-1 4.0 Architecture and Administration User Guide on how to increase the memory allocated to the FireWall-1 kernel (the method is OS dependent). 3. Reduce the default TCP timeout to a low enough value that will be lower than the time it takes to fill the connections table. This has the disadvantage that low activity sessions (e.g., Telnet) may timeout. In case of using NAT hide, this will mean losing the connection. Check Point is in the process of validating an INSPECT code change that will cause unknown TCP ACK packets to be dropped prior to matching them with the rule base. This change, will be available for both V3.0 and V4.0 versions, and will posted to the Check Point web site, as well as to the FireWall-1 Mailing List. The disadvantage of this INSPECT fix will be that following a reboot, policy unload or stopping the firewall, all active TCP connections will be blocked, and that any timed out TCP connections (i.e., connections that have been inactive longer than the TCP timeout) will be disconnected. The behavior with regards to maintaining connections after policy reload will not be affected by the change. In summary: while flooding a Check Point gateway with acceptable ACK packets may fill the connection table and have adverse connectivity effects, vulnerability is most realistically from users on the internal side of the gateway and there are simple measures that can be taken to minimize it. In addition, Check Point is taking steps to supply an INSPECT script that should eliminate this problem for those customers that view this as a significant vulnerability. Check Point will post the INSPECT code changes to the web site, as well as to the FW-1 mailing list no later than Tuesday, August 10th. Thank you, Check Point Support ============================================================================== == To unsubscribe from this mailing list, please see the instructions at http://www.checkpoint.com/services/mailing.html ============================================================================== ==
