Re: Checkpoint SYN DoS Vulnerability
Hi Chris,
This is almost similar to what I notice with the scans. The URL you provided
is similar except for a few differences. The scans are being done from the
inside interface to the outside from the firewall. The scan is a complete
TCP Connect scan.
However, what you have pointed out is really appreciated. There definitely
is a problem with this erratic behavior of Checkpoint which is being called
as a feature. The same scans work perfectly fine on our PIX firewalls.
Regards,
Sanjay Naik, CISSP
Sr. Security Consultant
----Original Message Follows----
From: "Christian Swartzbaugh" <feofil@xxxxxxxxx>
To: sanjaynaik@xxxxxxxx
CC: bugtraq@xxxxxxxxxxxxxxxxx
Subject: Re: Checkpoint SYN DoS Vulnerability
Date: Tue, 16 May 2006 16:14:35 -0700
i've seen this behavior recently too. the reason it does this is the
checkpoint device is replying to a session startup before receiving a
legitimate response from the actual endpoint.
you probably should read this thread
http://mail.nessus.org/pipermail/nessus/2005-June/msg00096.html
feofil
On 5/16/06, sanjay naik <sanjaynaik@xxxxxxxxxxx> wrote:
Hello,
I have recently come across a strange behavior observed on the Nokia
Checkpoint Firewall. Nokia as well as Checkpoint have no clue as to why
this
is occuring and have not provided any resolution to this.
We have been having multiple Vulnerability Scanner failures on the
Intranet
of the company XYZ. A careful study using NMAP and Netcat revealed that
the
scans failed only when the scanned IPs had to be reached through the
firewall. This confirmed our doubt that the Checkpoint Firewall was the
the
issue for the scanner failures.
When a scan is intiated from the Inside interface of Checkpoint firewall,
the firewall responds with bogus information intermittently. I would like
to
submit the following bug for Checkpoint:
Checkpoint SYN DoS Vulnerability
A TCP/IP session is established using three-way handshake in compliance to
the TCP protocol. A three-way handshake starts with a Source host sending
a
SYN and the destination host acknowledging the SYN with a SYN/ACK if the
port is in the listening or open state. A port that is closed would result
in a RST being sent back by the destination host. A SYN/ACK reported back
to
NMAP would be an open port and a RST will be assumed to be a closed port.
This is apparently not followed by Checkpoint as it checks the rulebase,
creates a statetable entry and responds with a SYN/ACK on behalf of the
destination host for all ports irrelevant of their actual state.
Checkpoint
creates a connection table entry for all SYN connects from the scanner and
responds with a SYN/ACK even though a RST should have been actually sent.
The results of the NMAP scan were inconsistent and inaccurately reported
by
Checkpoint.
The test was done on hosts that were beyond the firewall and also on the
Interface of the firewall. In both cases, the scans results were
inconsistent. Both SYN and ACK scans had similar issues.
The reason for this is not known to Checkpoint but this is apparently due
to
a bug in Checkpoint where the statetable is created for destination ports
that do not exist. This leads to a DoS condition as the firewall starts
showing performance degradation until the statetable timeouts.
An example of the checkpoint bug ?
[user]$ nmap -sT -P0 -v -p 1-1023 10.x.x.x
Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-04-06 19:55
GMT
Initiating Connect() Scan against 10.x.x.x [1023 ports] at 19:55
Interesting ports on 10.x.x.x:
(The 1017 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
80/tcp open http
111/tcp open rpcbind
199/tcp open smux
443/tcp open https
On scanning again, this is the response received:
[user]$ nmap -sT -P0 -v -p 1-1023 10.x.x.x
Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-04-06 19:55
GMT
Initiating Connect() Scan against 10.x.x.x [1023 ports] at 19:55
Interesting ports on 10.x.x.x:
PORT STATE SERVICE
1/tcp open tcpmux
2/tcp open compressnet
3/tcp open compressnet
4/tcp open unknown
5/tcp open rje
6/tcp open unknown
7/tcp open echo
.
.
.
.
1017/tcp open unknown
1018/tcp open unknown
1019/tcp open unknown
1020/tcp open unknown
1021/tcp open unknown
1022/tcp open unknown
Regards,
Sanjay Naik, CISSP, CHSS
Information Security Advisor
IBM Security & Privacy Practices
IBM Global Services
Business Phone # 978-878-3246
Internet: sanjnaik@xxxxxxxxxx
_________________________________________________________________
Don't just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/