Would the firewall behavior in attempting the three-packet handshake be dependent on a large number of connection attempts in a relatively short period of time, or should a slow scan, say nmap with -T set at 2, also trigger its returning the SYN/ACK on behalf of the target? Reason for question: In one case with which I am particularly familiar, a system was set up on a spare interface on a Nokia IP530 running IPSO 3.8-BUILD051 and CP FW-1 R55. The system ran a default nmap port scan of addresses on other Nokia interfaces except the one facing VictimLAN (the Internet), using its own address and two "decoy" addresses assigned to external networks on the Internet. I ran some slow scans (-T = 2) and some faster ones. The firewall rules were configured to block almost all the traffic from the decoy addresses. The actual system address was in the local LAN address space and much of the traffic using that address as source was accepted, but for my purposes ignored; I was interested in validating the firewall rules with respect to inbound connections from VictimLAN. Without going into excessive detail, the general result was that the firewall did log most traffic from the decoy addresses as blocked when expected, however the firewall attempted to complete the three-packet handshake with the source (decoy) address in spite of the traffic ultimately being blocked (according to the log; I did not snoop the scan destination interfaces). The net effect at first glance by an external observer (during a faster scan) was that many addresses within my network (the scan destination addresses) were attempting to contact two particular external addresses (the decoys), and I was alerted that a whole lot of my systems were compromised and trying to "phone home" using a small number of destination ports (actually the source ports nmap used for the decoys). Got that sorted out. Later I found out that the same behavior occurred unnoticed by the external observer during the slow scans. I never did get a satisfactory explanation as to why the firewall would behave in this manner, especially during the slow scans. Any insight? Chuck Sterling 505.524.5661 Prediction is difficult, especially the future. ...Niels Bohr -----Original Message----- From: Chris Brenton [mailto:cbrenton@xxxxxxxxxxxxxxxx] Sent: Tuesday, May 16, 2006 2:14 PM To: sanjaynaik@xxxxxxxx Cc: bugtraq@xxxxxxxxxxxxxxxxx Subject: Re: Checkpoint SYN DoS Vulnerability On Tue, 2006-05-16 at 11:09 -0400, sanjay naik wrote: > > When a scan is intiated from the Inside interface of Checkpoint firewall, > the firewall responds with bogus information intermittently. Sounds like you are triggering the SYN flood protection. Typically the firewall will respond with a SYN/ACK to ensure the source is not just generating a SYN flood. If you close the handshake, the connection is passed through to the target host if it is permitted in the rules. If not, the connection is simply deleted from the state table and ignored. Not sure why you are calling this a DoS as it does not sound like regular connectivity is being effected. The exception would be if you generated enough bogus SYN packets to fill up the state table so legit connections could not get through. I seem to remember Lance posting info about that to this list 4-5 years ago. > In both cases, the scans results were inconsistent. Both SYN and ACK > scans had similar issues. IMHO this is a feature. I would certainly rather see a port scanner receiving bogus results rather than accurate info that would assist in a compromise. Make them work a bit harder and earn it. ;-) HTH, Chris
