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

[jonny robertson <jonny@FW1-NOSPAMvixen.correspondence.school.nz>]

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