| |
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [FW1] Secure Client and NAT
you
could of course use the :encrypt_db (true) option in the :options section to
encrypt the userc.c file
>If you don't need any direct connections to your firewall
this
>would be fine, but since you're using SecuRemote that is not an
option. And
>you will not be able to completly "stealth" your Firewall.
To have an VPN
>configuration running you will have to allow
communication directly to the
>VPN device and have a public address on
your VPN device (as far as my
>knowledge 'bout VPNs
goes).
Ah-ha! Therein lies the crux of the
matter. Indeed, the information provided in the userc.C file is
necessary for VPN connectivity regardless of vendor. However, you have just
confirmed (perhaps) a weakness in Checkpoint's implementaion of VPN in
contrast to a vendor like Axent who's technology (as far as I am able to
determine) encrypts the details on the network so that it is not easily
obtained. Also, the Axent product does not provide as much info (even
encrypted) as Checkpoint does. Specifically I a! m thinking of the
implementation of the VPN server inside the firewalled network with a rule in
the FW rulebase allowing access via a NATed TCP/IP address to the VPN server
from the VPN client. Thus, an encrypted tunnel will be established
from the client on the Internet through my FW to the VPN server.
This might work using Checkpoint's VPN in a way other
than their documentation suggests. Worth a try?
[email protected] wrote:
-----Original
Message-----
From: Rafiyq Mondesir [mailto:[email protected]]
Sent:
7. mars 2001 18:10
To: [email protected];
[email protected]
Subject: RE: [FW1] Secure Client
and NAT
> 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.
And what will the difference be if you NAT the
address of the firewall? Then
the attacker will be able to check the
NAT'ed address of the Firewall andget the same information as he would by checking the original address
of the
firewall. If you don't need any direct connections to your
firewall this
would be fine, but since you're using SecuRemote that is
not an option. And
you will not be able to completly "stealth" your
Firewall. To have an VPN
configuration running you will have to allow
communication directly to the
VPN device and have a public address on
your VPN device (as far as my
knowledge 'bout VPNs goes).
>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.
The first transfer of the userc.C file is unencrypted. The
only way to get
around this (as far as I know) is to establish some other
way of distrbuting
the text-file. You don't have to let the users
download them from the
firewall, but it is less manual work.
>(I am very close to trying it the other way to see if
>less info is generated in the userc.C file.)
I think you will
get the same result. The userc.C-file contains the
Firewall-1 gateway
object. But you could probably manually delete all the
information that
is not needed, but I've never tried this.
>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.
(?)
'
try makin' two rules in the correct order (the negate one
first:)
/erik
================================================================================
To
unsubscribe from this mailing list, please see the instructions
at
http://www.checkpoint.com/services/mailing.html
================================================================================
Do You Yahoo!?
Yahoo! Mail Personal
Address - Get email at your own domain with Yahoo!
Mail.
________________________________________________________________
The information contained in this message is intended only for the recipient, may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, please be aware that any dissemination or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by replying to the message and deleting it from your computer.
Thank you,
Standard & Poor's
|
|
