++++++++++++++++++++++++++++++++
Sorry for the long post, but this really need some explaning::
-------------------------------------------------
Looks like Linux TCP/IP packets (rsh, connection to port 514) are unable
to pass through the statefulness of checkpoint
Firewall. Can anybody else confirm this or am I too lame to understand this?
Firewall in question is : FW-1 Ver 4.0, SP4 on Nokia box.
----------
NOTE: I HAVE ALREADY TURNED ON "Enable RSH/Exec reverse stderr connection"
for the experiment below.
-----------
:Legend:
client_linux : Linux box (initiate connection by the user on this box)
server: Any unix/linux box
client_solaris: Solaris box
-------------------------------------------------------------------------------------
Problem: When you rsh (not rlogin) from One linux box to another linux/unix
through Firewall and trying to run remote commands on remote server
(linux/unix) like example below.
client_linux:> rsh server date
(This fails, and I could see drop connection in FW logs, from server -> client_linux.
connection table shows only one connection logged in i.e from client_liunux to server.
NOTE: "Enable RSH/Exec reverse stderr connection" (THIS IS TURNED ON)
-------------------------------------------------------------------------------------
So what is happening:
{A}When client_linux initiate rsh connection to server. A rule base allowing
this
connection allows this traffic and I can see this in Firewall logs and connection
table
"fw tab -table connections". (or using Lance's perl script :,
http://www.enteract.com/~lspitz/fwtable.txt ).
Src_IP Src_Prt Dst_IP Dst_Prt IP_prot Kbuf Type Flags Timeout
client_linux(IP) 1022 server(IP) 514 6 0 28673 ffffff10 39/50
(EXPECTING OTHER LOG HERE FOR STDERR channel, but firewall actually rejects that).
{B}In rsh connections, "server" will try to open(initiate) a fresh connection
(STDERR)
back from "server" to "client_linux" to complete rsh connection. Now this connection is
not explicitly allowed in rule base, but "Enable RSH/Exec reverse stderr connection"
property in checkpoint should take care of this connection and should dynamically
allow
these reverse stderr connection between "server" and "client_linux". BUT THIS IS NOT
HAPPENING IF THE CLIENT IS "LINUX" box.
{C}In case the client machine is "solaris".
client_solaris>rsh server date (server is linux box)
THIS WORKS FINE AND IN FIREWALL LOGS I SEE SINGLE LOG ONLY for connection from
"client_solaris" to "server". and if you see firewall connection table (fwtable.pl ,
using
Lance's script) in this case it can clearly show two entries. (two different
established
connection)
Note: (Even if second was initiated from server, but FW in its connection table shows
otherwise, for example sake I replaced actual IP addresses with client_linux(IP) and
server(IP) ) .
So the first connection in table below is regular rsh initiate connection from port
1022
to 514(shell),
and
Second line shows that server @ 1023 established a connection back to client_solaris
(STDERR) @ 1021. Although
I guess due to the fact that checkpoint supports "reverse dynamic stderr" connection
for
rsh commands, it tend to store this established connection as from client_solaris(IP)
->to
-> server. (although connection initiated in other direction)
Src_IP Src_Prt Dst_IP Dst_Prt IP_prot Kbuf Type Flags Timeout
client_solaris(IP) 1022 server(IP) 514 6 0 28673 ffffff10
39/50
client_solaris(IP) 1021 server(IP) 1023 6 0 28673 02008602 39/50
{D} So my observation is if you are on LINUX box you can't run "rsh server
<command>"
on the server through Firewall. unless you allow connection from server -> client_linux
box. Which is not a very good thing since the STDERR reverse connection can pick up any
random source port and we don't know which port it is going to use it for particular
connection. (That's why checkpoint has this option in properties "Enable RSH/EXEC
reverse
connection".
{E}Because of above you can't run program those are using rsh in some way. Like rdist
etc
from client_linux -> server.
(NOTE: command "rsh server" (with no command argument) actually uses "rlogin server",
login port(513) instead of shell(514) port , and this runs okay from "client_linux" to
"server".)
{F}Since same connection is initiated from solaris box can go through
(client_solaris:>
rsh server date) without any issues. But not from linux, I would suspect the Linux
TCP/IP
stack. It uses some special TCP/IP options like "sackOK" (Selective ACK etc) which I
can
see using tcpdump. and may be checkpoint stateful engine is unable to handle these
kinds
of packets(Generated by Linux) properly and refuses the return STDERR connection
assuming
this is fresh attempt from server -> client_linux and because there is no rule to allow
this will simply drop the packets.
Any thoughts on this or any workaround for this?
Rajeev
================================================================================
To unsubscribe from this mailing list, please see the instructions at
http://www.checkpoint.com/services/mailing.html
================================================================================
