bugtraq - Re: Checkpoint SYN DoS Vulnerability

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: Wed, 17 May 2006 18:52:15 +1200
From: "Bojan Zdrnja" <bojan.zdrnja@...il.com>
To: sanjaynaik@...e.org
Cc: pawel.worach@...il.com, bugtraq@...urityfocus.com
Subject: Re: Checkpoint SYN DoS Vulnerability

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