COMMAND
FW-1
SYSTEMS AFFECTED
Those using Firewall-1, VPN-1, FloodGate-1
PROBLEM
Lance Spitzner posted following. He stumbled across a simple
Denial of Service attack for FW-1, many of you may already be
aware of this. You can effectively shutdown FW-1 by filling its
connections table. This is easily done in about 15 minutes with
most port scanners. When FW-1's state connections table is full,
it can no longer accept any more connections (usually between
25,000-35,000 connections, depending on your system). You can
increase this number by increasing kernel memory for the FW-1
module and hacking ../lib/table.def). However, a port scanner
can build that many connections in a manner of minutes.
FW-1 tears down a connection whenever it sees a FIN or RST packet.
However, if you scan a system that does not exist, the FW
builds a connection in its table for every new packet, but will
never see a FIN or RST because there is no system to respond.
The default TCP timeout time on FW-1 is 3600 seconds. So all
these new connections that are genereated will sit in FW-1's
connections table for an hour. You should now understand how easy
it is to fill the connections table.
Any malicious black-hat or disgruntled employee can fill your
connections table. Many organiztion allow all outbound traffic.
Someone can simply scan a non-existant target outbound and fill
the connections table. They even can be sneaky about it and use
nmap with the'-D' option, so someone else gets blamed for the
scanning activity.
Lance Spitzner added following. Everything that follows about it
it is documented in detail at
http://www.enteract.com/~lspitz/fwtable.html
When you start a TCP connection, you send a SYN packet. When FW-1
filters this packet, it checks it against the rule base, if the
session is allowed, it is added to the connections table with a
timeout of 60 seconds. When the remote host responds, the
session is bumped up to a 3600 second timeout. Now, if you start
a connection with an ACK packet, the FW compares it against the
rule base, if allowed it is added to the connections table.
However, the timeout is set to 3600 seconds and does not care if
a remote system responds. You now have a session with a 1 hour
timeout, even though no system responded. Now, do this with alot
of ACK packets, and you have full connections table. Most
companies allow http outbound. Run this command as root from an
internal system, I give your FW about 10 to 15 minutes. If your
internal network is a 10.x.x.x, try 172.16.*.*
nmap -sP 10.*.*.*
nmap is a very powerful port scanner. With this command it does
only a PING and TCP sweep (default port 80), but uses an ACK
instead of a SYN. To verify that your connections table is
quickly growing, try "fw tab -t connections -s" at 10 second
intervals (tested on ver 4.0 SP3 on Solaris x86 2.6).
David Taylor seen this also in a Floodgate-1 machine that was
positioned outside the firewall. Flodgate-1 is Checkpoint's
bandwidth management solution which presumably uses the same
state engine.
SOLUTION
Check Point has developed INSPECT code changes that provides a
solution for this type of attack. This code change enables Check
Point gateways to drop non-first TCP packets instead of matching
the rule base. It should be noted that this INSPECT fix will
cause a change of behavior from the existing Check Point gateway
behavior in the following way: 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 ability for FireWall-1/VPN-1 to
maintain connections after policy reload will not be affected by
this change. For those with UNMODIFIED $FWDIR/lib/code.def
files, you can go to the Check Point web site and download Check
Point updated files:
http://www.checkpoint.com/techsupport/alerts/ackdos.html
Another option is to edit the code.def files as described below.
The following INSPECT code (between the two lines starting with
"-----") should be added to the $FWDIR/lib/code.def file (at the
end of the file, just before the #endif statement). NOTE: if you
are managing V3.0 modules, using the 4.0 backwards compatibility
feature, please make the changes to the V3.0 code.def file
(located in $FWDIR/lib30), as described in the "Check Point
3.0-based Installations". After completing the edit, re-install
the security policy. For 4.0-based installations, this code will
also log these events.
----- 4.0 edit follows -----
#ifndef ALLOW_NONFIRST_RULEBASE_MATCH
tcp, first or <conn> in old_connections or
#ifndef NO_NONFIRST_RULEBASE_MATCH_LOG
<ip_p,src,dst,sport,dport,0> in logged
) or
record <ip_p,src,dst,sport,dport,0> in logged,
set sr10 12, set sr11 0, set sr12 0, set sr1 0,
log bad_conn
) or 1,
#endif
vanish
);
#endif
----- End of 4.0 insert -----
Check Point 3.0-based Installations. The following INSPECT code
(between the two lines starting with "-----") should be added to
the $FWDIR/lib/code.def file (at the end of the file, just before
the #endif statement). After completing the edit, re-install the
security policy.
----- 3.0 edit follows -----
#ifndef ALLOW_NONFIRST_RULEBASE_MATCH
tcp, first or <conn> in old_connections or vanish;
#endif
----- End of 3.0 insert -----