Date: Thu, 5 Aug 1999 14:16:02 -0700
From: James E McWilliams <James.E.Mcwilliams@KP.ORG.>
To: [email protected]Subject: [FW1] Check Point Announcement
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
==
