Bugtraq mailing list archives
Re: Checkpoint SYN DoS Vulnerability
From: "sanjay naik" <sanjaynaik () hotmail com>
Date: Wed, 17 May 2006 01:41:15 -0400
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 () gmail com> To: sanjaynaik () ieee org CC: bugtraq () securityfocus com 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 () hotmail com> 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 () us ibm com _________________________________________________________________ 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/
Current thread:
- Re: Checkpoint SYN DoS Vulnerability, (continued)
- Re: Checkpoint SYN DoS Vulnerability Bojan Zdrnja (May 17)
- Re: Checkpoint SYN DoS Vulnerability Jim Clausing (May 22)
- Re: Checkpoint SYN DoS Vulnerability Erick Mechler (May 18)
- Re: Checkpoint SYN DoS Vulnerability Bojan Zdrnja (May 22)
- Re: Checkpoint SYN DoS Vulnerability sanjay naik (May 18)
- Re: Checkpoint SYN DoS Vulnerability Niranjan S Patil (May 24)