lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 18 May 2006 00:07:44 -0400 (EDT)
From: Jim Clausing <clausing@...e.org>
To: Bojan Zdrnja <bojan.zdrnja@...il.com>
Cc: sanjaynaik@...e.org, pawel.worach@...il.com,
	bugtraq@...urityfocus.com
Subject: Re: Checkpoint SYN DoS Vulnerability


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@...mail.com> 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
> 


Powered by blists - more mailing lists