To all:
I have just recently upgraded
our two Nokia IP650 FW's running in a VRRP monitored circuit environment to IPSO
3.3 with FW-1 4.1SP2 and I am seeing a LOT of Unknown established TCP
connections being dropped by rule 0 in the logs.
I have determined that this is
indeed due to the nature as to how 4.1SP2 and beyond now handle TCP session
timeouts. In 4.1SP1? and prior versions of CheckPoint if a TCP session exceeded
the TCP session timeout set in the FW properties the FW would first attempt to
re-establish the connection and if it could not it would then drop the
connection and a message would be received on the client that the "connection
was reset by a foreign host." Now from 4.1SP2 and on the FW does NOT attempt to
re-establish the connection but does indeed drop the connection and it also does
NOT send the signal/message back to the client indicating that the connection
was reset by a foreign host (because it is being dropped).
The problem with this is that to
the simple user this is very confusing as their window (whether they are using a
simple telnet client or ssh client or whatever) just freezes (sometimes for a
very long time) before they can regain control of their client window. Most
users just get fed up with this and cancel/close the window and open up another
window.
Now for the
question:
I have done
some testing and was wondering.... Now that CheckPoint has a new "monitoring"
tool much like snoop on variants of Unix platforms is there a way to "watch"
this traffic given a specific src and dest IP address (and perhaps a service
port to listen on) along with the Src_Port (because I want to be able to watch
the connection from beginning to end)?? And can you set it up to monitor say
every 5 minutes?
I am hoping
to be able to prove something. In our testing I have had one of our problem
users telnet into one of their machines in the DMZ and just let it sit. At about
the 45 minute mark I have had them hit the <CR> return key a couple of
times to verify that the telnet session is still active; which it is. In about
another 20 minutes (because I know that the TCP session timeout threshhold has
now been exceeded I have them hit the <CR> return a couple more times.
This time the window is frozen. I would basically like to track the TCP session
timeout counters for "a" particular session and verify that the TCP session
timeouts are not getting re-set.
I have also
had users complain that they are in the middle of typing when the window freezes
but have not been able to verify the particulars on this.
Does the
FireWall ignore <CR> returns as a form of communication? It sure seems
like it because the window freezes at exactly one hour from the time that the
telnetted in and got the login prompt (Unix machine).
I know that I
can modify one of the files (can't remember which one, I'd have to go back to
one of the FAQs that I gleaned) under FW-1 to ignore this TCP session timeout
but I am a little weary of this since the reason that I hear that
CheckPoint did it this way was to close a hole for a DoS attack against TCP
session timeouts under CheckPoint.
Note: I also have in the FW-1 properties page set
the traffic INSPECT direction to Inbound (not Outbound nor
Etherbound).
Sorry for the length but I was hoping that with the
detail it would help someone with the answer. As always TIA for any help that
might be given.
|