Re: nmap brings CheckPoint Firewall-1 down

Marc,

I've seen this sort of behavior on CP FW1, on several OS's and on the=20
Nokia's appliance.  You are likely running into an issue of filling up th=
e=20
connection table.  A port scan through the firewall is going to quickly=20
populate the connection table which depending on the OS or appliance can =
be=20
set around 40,000 to 80,000 concurrent connections.  This is normally OK =
but=20
if the firewall is in use and you are scanning through it, this can quick=
ly=20
fill up and cause the firewall to deny future connections until current=20
connections FIN or time out.

If you are using VRRP it could cause the keep alive connection, if not=20
active in the table, to be flushed from the table and then not allowed on=
=20
the next update due to the tables being flooded.  Potentially you can rai=
se=20
the time between keep alives but this obviously increases the time to rou=
te=20
failover, potentially undesirable.

Scanning through firewalls is really only effective for getting a quick v=
iew=20
of what you can see through the firewall policy.  It's not even a thoroug=
h=20
method of doing this but it is a good first glance.  If you are scanning=20
through a firewall to figure out your security posture from outside,=20
throttle down the connections and use the full connect method of scanning=
,=20
not the SYN sweep which leaves connections open in the table due to the=20
firewall never seeing a FIN packet.  If you turn on SYN protection on the=
=20
firewall, this would seem to correct the problem but the default timeout =
the=20
firewall waits for the rest of the communications is 30 seconds, until th=
en=20
it buffers the SYN->  <-SYN/ACK communications, this takes more memory, s=
its=20
in the connection table, etc, until the timeout but even with a full conn=
ect=20
scan, this is resource intensive.  It can also fool your scanner into=20
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 o=
n=20
the firewall maker, the load of the firewall at the time of scanning, the=
=20
scanner and the scan settings/policy.

Recommendations:

1) If you need an external scan, slow down the scan considerably and lear=
n=20
to use the firewalls commands to actively watch the connection table and=20
cpu/memory utilization.  Get a feel for what is acceptable to scan with=20
(speed of port scan, number of concurrent hosts to scan) while leaving th=
e=20
firewall functional.  Nokia has a support articles about checking CP tabl=
e=20
and memory utilization on their customer site, you can look them up.

2) If you have the memory available, consider raising the connection tabl=
e=20
value.  Be very careful with this and follow CheckPoint / Nokia guideline=
s.=20
Just because you have the memory doesn't mean your value will scale.  I'v=
e=20
seen a firewall become very slow as they constantly search an overly larg=
e=20
table.  You may want to decrease the time outs on the firewall for the=20
connection table, especially for UDP.  This can accidentally cause denial=
s=20
of valid traffic though, so test a bit before doing it.

3) Place a scanner on the inside of the firewall for true host vulnerabil=
ity=20
details and not beating your firewall up with a type of traffic it is not=
=20
good at handling, only denying.

Regards,

-- Dan

Regards,

Daniel Bowman - Director
Product QA & Customer Support
Tenable Network Security
http://www.tenablesecurity.com/


----- Original Message -----=20
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 confront=
ed=20
with some problems concerning Nessus/nmap and a bunch of CheckPoint=20
Firewall-1 AI R55 HFA 11 with VPN on Nokia boxes. During our testing the =
FW1=20
devices tend to break down.  No matter if the scanning is done on one of =
the=20
FW1 interfaces, on an existing or non-existing target host. No further=20
traffic to the host or one of the cascaded target networks were possible=20
afterwards. All connection requests wrapped in the VPN tunnel end in an=20
usual connection timeout. Also the VRRP communication got some trouble.=20
Other connections outside the VPN tunnel - as like default ssh connection=
s=20
or FW1 admin connections - are not affected and still working during the=20
unwanted denial of service. Also new connections are possible without any=
=20
problems. The affected devices are not able to re-generate their working=20
state for the still hanging VPN connections within a few minutes. A reboo=
t=20
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. A=
nd=20
never before I have seen such a problem. The only difference I am able to=
=20
determine at the moment is the use of VPN/IPsec. My suggestion is that th=
e=20
VPN module is affected by the problem. Perhaps if heavy network load, a=20
large amount of half open tcp connections or a highly usage of CPU is=20
detected, the VPN module is not able to handle the traffic anymore. The D=
oS=20
starts during the nmap scanning phase of Nessus. So we were able to=20
reproduce the problem with a standalone nmap run. I did a testing with=20
different versions of Linux (Debian and Red Hat), Nessus (some of the 2.x=
=20
tree; e.g. 2.2.3) and nmap (3.x up to 3.81). During a very small time-fra=
me=20
for analysis I was not able to do more testing (e.g. a more polite scanni=
ng=20
behavior in nmap).

Has somebody else seen such a behavior and know how to re-configure FW1,=20
Nessus and/or nmap to get a stable environment for the usual Nessus testi=
ng?=20
A possible workaround would be to de-activate nmap/postscanning within th=
e=20
Nessus testing. But this does not eliminate the danger of such a weak=20
installation as it tends to be in place. One of our workaround approach w=
as=20
to optimize the FW1 configuration. First of all we implemented a connecti=
on=20
limit to 100 connections per host. This made some really nasty false=20
negatives during the mapping, nmap and Nessus scanning. Furthermore we=20
implemented SYN flood detection to 100 half-open connections. This was ab=
le=20
to prevent the full DoS. But partially a timeout could be detected. A ful=
l=20
break-down of the firewalls was not possible anymore. False negatives are=
=20
still given.

Regards,

Marc Ruef

- --=20
) scip AG (
Technoparkstr. 1
8005 Z=FCrich
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
=3DyqrR
-----END PGP SIGNATURE-----

_______________________________________________
Nessus mailing list
[email protected]
http://mail.nessus.org/mailman/listinfo/nessus=20

_______________________________________________
Nessus mailing list
[email protected]
http://mail.nessus.org/mailman/listinfo/nessus