Message-ID: <E07AD36B17A4D411896D00805FCC9B0D12B7C58A@nt05.wstf.nasa.gov>
Date: Wed, 17 May 2006 07:44:43 -0600
From: "Sterling, Chuck" <csterlin@...p3.wstf.nasa.gov>
To: cbrenton@...isbrenton.org
Cc: bugtraq@...urityfocus.com
Subject: RE: Checkpoint SYN DoS Vulnerability


 Would the firewall behavior in attempting the three-packet handshake be
dependent on a large number of connection attempts in a relatively short
period of time, or should a slow scan, say nmap with -T set at 2, also
trigger its returning the SYN/ACK on behalf of the target?

Reason for question:
In one case with which I am particularly familiar, a system was set up on a
spare interface on a Nokia IP530 running IPSO 3.8-BUILD051 and CP FW-1 R55.
The system ran a default nmap port scan of addresses on other Nokia
interfaces except the one facing VictimLAN (the Internet), using its own
address and two "decoy" addresses assigned to external networks on the
Internet. I ran some slow scans (-T = 2) and some faster ones. The firewall
rules were configured to block almost all the traffic from the decoy
addresses. The actual system address was in the local LAN address space and
much of the traffic using that address as source was accepted, but for my
purposes ignored; I was interested in validating the firewall rules with
respect to inbound connections from VictimLAN. Without going into excessive
detail, the general result was that the firewall did log most traffic from
the decoy addresses as blocked when expected, however the firewall attempted
to complete the three-packet handshake with the source (decoy) address in
spite of the traffic ultimately being blocked (according to the log; I did
not snoop the scan destination interfaces). The net effect at first glance
by an external observer (during a faster scan) was that many addresses
within my network (the scan destination addresses) were attempting to
contact two particular external addresses (the decoys), and I was alerted
that a whole lot of my systems were compromised and trying to "phone home"
using a small number of destination ports (actually the source ports nmap
used for the decoys). Got that sorted out. Later I found out that the same
behavior occurred unnoticed by the external observer during the slow scans.

I never did get a satisfactory explanation as to why the firewall would
behave in this manner, especially during the slow scans. Any insight?


Chuck Sterling
505.524.5661

Prediction is difficult, especially the future.
...Niels Bohr

-----Original Message-----
From: Chris Brenton [mailto:cbrenton@...isbrenton.org] 
Sent: Tuesday, May 16, 2006 2:14 PM
To: sanjaynaik@...e.org
Cc: bugtraq@...urityfocus.com
Subject: Re: Checkpoint SYN DoS Vulnerability

On Tue, 2006-05-16 at 11:09 -0400, sanjay naik wrote:
>
> When a scan is intiated from the Inside interface of Checkpoint firewall, 
> the firewall responds with bogus information intermittently.

Sounds like you are triggering the SYN flood protection. Typically the
firewall will respond with a SYN/ACK to ensure the source is not just
generating a SYN flood. If you close the handshake, the connection is
passed through to the target host if it is permitted in the rules. If
not, the connection is simply deleted from the state table and ignored.

Not sure why you are calling this a DoS as it does not sound like
regular connectivity is being effected. The exception would be if you
generated enough bogus SYN packets to fill up the state table so legit
connections could not get through. I seem to remember Lance posting info
about that to this list 4-5 years ago.

> In both cases, the scans results were inconsistent. Both SYN and ACK 
> scans had similar issues.

IMHO this is a feature. I would certainly rather see a port scanner
receiving bogus results rather than accurate info that would assist in a
compromise. Make them work a bit harder and earn it. ;-)

HTH,
Chris

Powered by blists - more mailing lists