Marc,
I've seen this sort of behavior on CP FW1, on several OS's and on the
Nokia's appliance. You are likely running into an issue of filling up the
connection table. A port scan through the firewall is going to quickly
populate the connection table which depending on the OS or appliance can be
set around 40,000 to 80,000 concurrent connections. This is normally OK but
if the firewall is in use and you are scanning through it, this can quickly
fill up and cause the firewall to deny future connections until current
connections FIN or time out.
If you are using VRRP it could cause the keep alive connection, if not
active in the table, to be flushed from the table and then not allowed on
the next update due to the tables being flooded. Potentially you can raise
the time between keep alives but this obviously increases the time to route
failover, potentially undesirable.
Scanning through firewalls is really only effective for getting a quick view
of what you can see through the firewall policy. It's not even a thorough
method of doing this but it is a good first glance. If you are scanning
through a firewall to figure out your security posture from outside,
throttle down the connections and use the full connect method of scanning,
not the SYN sweep which leaves connections open in the table due to the
firewall never seeing a FIN packet. If you turn on SYN protection on the
firewall, this would seem to correct the problem but the default timeout the
firewall waits for the rest of the communications is 30 seconds, until then
it buffers the SYN-> <-SYN/ACK communications, this takes more memory, sits
in the connection table, etc, until the timeout but even with a full connect
scan, this is resource intensive. It can also fool your scanner into
thinking a host(s) is/are alive and/or having ports open that are not.
Scanning through firewalls is very suspect, results will vary depending on
the firewall maker, the load of the firewall at the time of scanning, the
scanner and the scan settings/policy.
Recommendations:
1) If you need an external scan, slow down the scan considerably and learn
to use the firewalls commands to actively watch the connection table and
cpu/memory utilization. Get a feel for what is acceptable to scan with
(speed of port scan, number of concurrent hosts to scan) while leaving the
firewall functional. Nokia has a support articles about checking CP table
and memory utilization on their customer site, you can look them up.
2) If you have the memory available, consider raising the connection table
value. Be very careful with this and follow CheckPoint / Nokia guidelines.
Just because you have the memory doesn't mean your value will scale. I've
seen a firewall become very slow as they constantly search an overly large
table. You may want to decrease the time outs on the firewall for the
connection table, especially for UDP. This can accidentally cause denials
of valid traffic though, so test a bit before doing it.
3) Place a scanner on the inside of the firewall for true host vulnerability
details and not beating your firewall up with a type of traffic it is not
good at handling, only denying.
Regards,
-- Dan
Regards,
Daniel Bowman - Director
Product QA & Customer Support
Tenable Network Security
http://www.tenablesecurity.com/
----- Original Message -----
From: "Marc Ruef" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[email protected]>
Sent: Monday, 13 June, 2005 09:03
Subject: nmap brings CheckPoint Firewall-1 down
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dear list,
I am currently in a testing of CheckPoint Firewall-1. There I am confronted
with some problems concerning Nessus/nmap and a bunch of CheckPoint
Firewall-1 AI R55 HFA 11 with VPN on Nokia boxes. During our testing the FW1
devices tend to break down. No matter if the scanning is done on one of the
FW1 interfaces, on an existing or non-existing target host. No further
traffic to the host or one of the cascaded target networks were possible
afterwards. All connection requests wrapped in the VPN tunnel end in an
usual connection timeout. Also the VRRP communication got some trouble.
Other connections outside the VPN tunnel - as like default ssh connections
or FW1 admin connections - are not affected and still working during the
unwanted denial of service. Also new connections are possible without any
problems. The affected devices are not able to re-generate their working
state for the still hanging VPN connections within a few minutes. A reboot
was required to get the full working state back again.
This is not the first time I am checking an environment with FW1 in it. And
never before I have seen such a problem. The only difference I am able to
determine at the moment is the use of VPN/IPsec. My suggestion is that the
VPN module is affected by the problem. Perhaps if heavy network load, a
large amount of half open tcp connections or a highly usage of CPU is
detected, the VPN module is not able to handle the traffic anymore. The DoS
starts during the nmap scanning phase of Nessus. So we were able to
reproduce the problem with a standalone nmap run. I did a testing with
different versions of Linux (Debian and Red Hat), Nessus (some of the 2.x
tree; e.g. 2.2.3) and nmap (3.x up to 3.81). During a very small time-frame
for analysis I was not able to do more testing (e.g. a more polite scanning
behavior in nmap).
Has somebody else seen such a behavior and know how to re-configure FW1,
Nessus and/or nmap to get a stable environment for the usual Nessus testing?
A possible workaround would be to de-activate nmap/postscanning within the
Nessus testing. But this does not eliminate the danger of such a weak
installation as it tends to be in place. One of our workaround approach was
to optimize the FW1 configuration. First of all we implemented a connection
limit to 100 connections per host. This made some really nasty false
negatives during the mapping, nmap and Nessus scanning. Furthermore we
implemented SYN flood detection to 100 half-open connections. This was able
to prevent the full DoS. But partially a timeout could be detected. A full
break-down of the firewalls was not possible anymore. False negatives are
still given.
Regards,
Marc Ruef
- --
) scip AG (
Technoparkstr. 1
8005 Z�rich
T +41 1 445 18 18
F +41 1 445 18 19
[EMAIL PROTECTED]
www.scip.ch
- - Aktuellste IT-Sicherheitsluecken -
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0
Comment: http://www.scip.ch
iQA/AwUBQq2EJxe5hzJzqVMhEQJIvQCfdF3+INozxDiJyDSA22GBOx6QuCMAn0VW
0ub85W3m+5QjVkPUqtxxqI21
=yqrR
-----END PGP SIGNATURE-----
_______________________________________________
Nessus mailing list
[email protected]
http://mail.nessus.org/mailman/listinfo/nessus
_______________________________________________
Nessus mailing list
[email protected]
http://mail.nessus.org/mailman/listinfo/nessus
