mailing list archives
nmap brings CheckPoint Firewall-1 down
From: "Marc Ruef" <maru () scip ch>
Date: Tue, 14 Jun 2005 09:12:46 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Would you please resend this to nmap-dev () insecure org rather than
Sorry, Fyodor. Okay, here we go ;) !
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
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
PS.: FYI: I have already got a very useful reply by Dan Bowman in the nessus () list nessus org and nmap-hackers ()
insecure org mailing lists.
) scip AG (
T +41 1 445 18 18
F +41 1 445 18 19
maru () scip ch
- - Aktuellste IT-Sicherheitsluecken -
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0
-----END PGP SIGNATURE-----
Sent through the nmap-dev mailing list
- nmap brings CheckPoint Firewall-1 down Marc Ruef (Jun 14)