Bojan actually makes a good point here. Is it possible you are filling up the connection table during the scan? -- Jim Clausing GCFA, GCIA, GCFW, GSIP, GSOC, GREM, CISSP, CCSA GPG fingerprint = EBD0 F967 3B1C 9EA6 79AD 8939 978A 079C 8BAB F921 On or about Wed, 17 May 2006, Bojan Zdrnja pontificated thusly: > Sanjay, > > On 5/17/06, sanjay naik <sanjaynaik@xxxxxxxxxxx> 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 >
