nmap brings CheckPoint Firewall-1 down

["Marc Ruef" <maru () scip ch>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear list,

> Would you please resend this to nmap-dev () insecure org rather than
> nmap-hackers?

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 
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

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 (
Technoparkstr. 1
8005 Zürich
T +41 1 445 18 18 
F +41 1 445 18 19

maru () scip ch
www.scip.ch

- - Aktuellste IT-Sicherheitsluecken -

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0
Comment: http://www.scip.ch

iQA/AwUBQq6DdBe5hzJzqVMhEQKWvwCeKYzwHwPs8KTwktys0gx/TvhqVLcAoKRV
wS0BysuwSiGQp6Nk+PHXhkd8
=QIie
-----END PGP SIGNATURE-----



_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev