Re: Checkpoint SYN DoS Vulnerability

[Jim Clausing <clausing@xxxxxxxx>]

Bojan actually makes a good point here.  Is it possible you are filling up 
the connection table during the scan?

--
Jim Clausing
GCFA, GCIA, GCFW, GSIP, GSOC, GREM, CISSP, CCSA
GPG fingerprint = EBD0 F967 3B1C 9EA6 79AD  8939 978A 079C 8BAB F921

On or about Wed, 17 May 2006, Bojan Zdrnja pontificated thusly:

> Sanjay,
> 
> On 5/17/06, sanjay naik <sanjaynaik@xxxxxxxxxxx> wrote:
> > Pawel,
> > 
> > We have done a complete test using TCPdump on the checkpoint side and
> > Tethereal on the scanner side. We have tested this on atleast 3 dfferent
> > firewalls and found the same issue with our scans.
> > 
> > SYNdefender is disabled on the Nokia/Checkpoint firewall. Nokia's
> > response
> > after seeing the results of the scan has been that SYNdefender is still
> > functional even if we disable it and valid authorized scans won't be
> > allowed
> > from the firewall as that is a product limitation!
> > 
> > I don't agree this is a feature as that would be absurd. SYN Attack
> > Protection is not enabled on the firewalls. The scans are being done from
> > the Internal interface of the firewall and not the external interface.
> > The
> 
> >From my experience with Checkpoint NGX, the Smart Defense module (at
> least some of it's parts) basically can't be turned off. I've seen
> numerous problems due to this, even when the only rule was to allow
> all traffic to the destination IP address. The problems I've seen were
> caused by the Smart Defense module incorrectly interpreting traffic as
> invalid and dropping it, while in fact it was legitimate traffic.
> 
> That being said, and as one other poster wrote, it looks to me like
> you are triggering the SYN flood DoS protection on the firewall, after
> which it answers to every SYN packet. Once the connection is
> established, it will pass this through to the destination IP address,
> otherwise it gets deleted from the stateful connection table.
> 
> This indeed can cause some performance problems, but, if I'm not
> wrong, you can increase the table size so it shouldn't drop any new
> connections (if the table is big enough).
> 
> > firewall has a rule to accept ANY services for the scanner. The scans are
> > sometimes successful and sometimes they get garbaged and how does that
> > make
> > it a feature?
> 
> Now, this looks like a potential problem. Can you reproduce this? Does
> it always works ok first time and then in sequential scans you get all
> the ports open?
> If yes, then the firewall looks to be properly working. If not, you
> should check what's going on with the connection table on the
> firewall.
> 
> Cheers,
> 
> Bojan
>