|
|
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/