[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [FW1] My experience with CPFW-1 and Legato / Solstice Backup
Hi, you are correct. I have done the same investigation as you. However my solution (2c.) is to set the OS (backup server) tcp timeout to something less than 60s. I never would setup version 2b. Personally I hope Legato will change their software moreover add security (port control, acl, remove buffer overflows). Regards, Josef > -----Original Message----- > From: jonny robertson [SMTP:[email protected]] > Sent: Friday, June 22, 2001 3:52 AM > To: [email protected] > Subject: [FW1] My experience with CPFW-1 and Legato / Solstice Backup > > > Not sure if this got through the first time - apologies if this is a > repeat! > > For those who are interested, have tried this combination before, > or are looking at doing so - this may be helpful.... > > Infact, what I will share here is probably applicable to other > applications that behave in the same way that Solstice Backup does. > And talks about one of the reasons that the 'unknown established TCP > packet error' is generated. > > (This email is a bit of a story, that hopefully someone will find helpful! > - apologies to those who aren't interested). > > > We are running Checkpoint Firewall-1, 4.1 SP3 on a Solaris 2.6 box. > Solstice Network Backup 6.0 would not work successfully through the > firewall (and I can confirm that Legato 5.x has the same problem with > this version and patchlevel of Checkpoint). > > Thanks to a couple of references on Phoneboy, and also Lance Spitzners > whitepaper on how the Checkpoint state table works - I am now convinced of > where the problem lies. > > 'Sniffing' either side of the network backups was a problem as huge > quantities of data was involved. > (Thank god Ethereal can filter on both the capture and the read in! ;)) > > The backups would not fail if they were very small - pointing at a timeout > issue. > For the bigger backups, I would get the famous 'unknown established TCP > packet' error in my logs - and the backups would hang, and complain that > they didn't finish successfully. > Looking at the packets that were being 'dropped' - the data segment > contained a simple message saying "backup completed at: <time>". It was > the notification from the client to the backup server saying that the > particular save-set was finished. > The flags on this packet were: FIN, PSH, ACK. > > If you have read Spitzners FAQ, you will know that the change made in SP3 > causes Checkpoint Firewall to only check SYN packets against the rulebase > (if no current state entry exists), to see if one should be added. > > Unfortunately, even though our TCP Timeout was set at 2 hours, Checkpoint > firewall does not raise the state table entry timeout to this level > _until_ some data has been pushed through the connection. > > This means that any application that connects with a standard 3 way > handshake (SYN --> SYN-ACK --> ACK), only generates a state table entry > with a timeout equivalent to the 'tcpstarttimeout' option (defined in > $FWDIR/conf/objects.C). By default this is 60 seconds. > > If the said application fails to push any data through the connection > before this timer expires, the state is dropped. Then when it decides it > is ready to send data (i.e. the backup completion notification), the state > table is checked, the flags on the packet are examined (non-SYN!) and the > packet is happily discarded. > > The good thing about this behaviour is it makes it fairly difficult to try > and DoS the firewall by filling its state table. (Assuming SYN-defender > is running i guess). > > Solstice Network / Legato Backup uses a heap of control connections as it > backs up a remote machine. One of these connections is simply the > completion notification - and the 3 way handshake occurs at the begining > of the backup process. Once the connection is established, no data is > passed until the backup completes. > (It would not surprise me to find other applications that behave > similarly). > > 2 fixes for this problem were: > a) raise the tcpstarttimeout to some ridiculous size and leave the state > table vulnerable to flooding. > b) make the change suggested on Phoneboy ($FWDIR/lib/fwui_head.def) to > allow non-SYN packets to me matched against the rulebase. > > We have since made the second change as a temporary solution, however this > is fairly unacceptable. It basically renders a heap of CPFW-1's > functionality to 'packet-filtering' status, and increases the chance for > Denial-of-Service (remember SYN-Defender only matches _SYN_ packets! :)) > > The final outcome has been that: > A change request has gone back to Sun / Legato to implement a keep-alive > into their backup software, to keep Checkpoint happy. > And also a message has (hopefully) gone through the Checkpoint describing > the situation and asking for their comment. > > I can prove that the change we have made allows me to DoS Checkpoints > state table if I have control of 1 box inside and 1 box outside the > network. > > > Hope some of this helps someone!! It was certainly a learning experience > for me. Don't hesitate to drop me a message if you have any more > questions about this particular problem - I'll help if I can. > > Cheers, > -jonny > > > > > ========================================================================== > ====== > To unsubscribe from this mailing list, please see the instructions at > http://www.checkpoint.com/services/mailing.html > ========================================================================== > ====== ================================================================================ To unsubscribe from this mailing list, please see the instructions at http://www.checkpoint.com/services/mailing.html ================================================================================
|