> How does this undermine the use of a stealth rule?
It undermines the Stealth rule because the idea of
the Stealth rule is to hide the net interfaces of the firewall in such a way
as to be responseless to any connection attempts directly to them (the
interfaces). Thus, when an attacker sees no response from their scans
they are lead to believe that the IP address is not in use, and hopefully
they'll be discouraged and move on.
The data contained in the userc.C file gives
details about the FW network interfaces and network that the Stealth Rule
is supposed to be hiding. For example, it gives the IP addresses of both
nics, the dns name of the FW, and the network subnet behind the
firewall. I am under the impression that this info is supposed to be
hidden. I'll grant that this info by itself is not a major security risk
but it provides detail about the network and FW that the FW is supposed to be
hiding. There is also the possibility that this info can be used in
conjunction with other illicitly acquired data to ammase a pointed
attack that may not have anything to do with the
FW.
Perhaps some details about my setup will help to
clarify:
- I am using CPfw1-41; SP2.
- My Mgmt Station and FW are on two separate
machines.
- I am using IKE.
- "Respond to Unauthenticated Topology Requests" is
Disabled.
- Per instruction from
CheckPoint Support, I have the SecureClients connect to the ext interface of
the FW instead of the Mgmt Server. (I am very close to trying it the other
way to see if less info is generated in the userc.C
file.)
>Also, when
constructing your Client Encrypt rule, make sure to put the firewall object(s)
in the >destination field and negate them so that even VPN users can't make
a direct connection to the >firewall through a SecuRemote
session.
I tried this this morning but the Negate option negates
everything in the box; not just the item I selected. (?)
R.
Jeff Hochberg <[email protected]> wrote:
No there is not.
How does this undermine the use of a stealth rule? Disable the
"Respond to Unauthenticated Topology Requests" option in
Policy->Properties in order to enable SSL authenticated topology
downloads to prevent just "anyone" from getting your userc.C
file.
Also, when constructing your Client Encrypt rule, make sure to put
the firewall object(s) in the destination field and negate them so that even
VPN users can't make a direct connection to the firewall through a
SecuRemote session.
-Jeff Hochberg
Helo.
Does anyone know if its possible to use a NAT'ed address of the
firewall's external interface as the point of connect in
the SecureRemote Client. In otherwords, say the external
interface of of my firewall is publicly addressable: 111.111.111.111,
and I plan giving it a NAT'ed address of 222.222.222.222 to be
used by my clients for topology updates and VPN connections. Is this
possible?
The reason I want to do this is because the file: userc.C, which is
located on the client, contains (in clear text) several firewall and
network details that undermine the use of a Stealth Rule, and thus
compromises my security policy.
Any advice would be appreciated.
Regards,
R.
Do You Yahoo!?
Yahoo! Mail
Personal Address - Get email at your own domain with Yahoo!
Mail.
Do You Yahoo!?
Yahoo! Mail Personal
Address - Get email at your own domain with Yahoo!
Mail.
