RE: [FW1] My experience with CPFW-1 and Legato / Solstice Backup

["Hartmann, Josef" <hartmann@FW1-NOSPAMsecunet.de>]

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:jonny@vixen.correspondence.school.nz]
> Sent:	Friday, June 22, 2001 3:52 AM
> To:	fw-1-mailinglist@beethoven.us.checkpoint.com
> 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
================================================================================