nmap brings CheckPoint Firewall-1 down
"Marc Ruef" <[email protected]> Mon, 13 Jun 2005 15:03:29 +0200
| Newsgroups | gmane.comp.security.nessus.general,gmane.comp.security.nmap.general |
|---|---|
| Message-ID | <[email protected]> |
=20 -----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 - --=20 ) scip AG ( Technoparkstr. 1 8005 Z=FCrich T +41 1 445 18 18=20 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 =3DyqrR -----END PGP SIGNATURE----- _______________________________________________ Nessus mailing list [email protected] http://mail.nessus.org/mailman/listinfo/nessus