NETWORK PRESENCE ABOUT SERVICES PRODUCTS TRAINING CONTACT US SEARCH SUPPORT
 


Search
display results
words begin  exact words  any words part 

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [FW1] Secure Client and NAT



I agree with your statement about paranoia.  I just try to "lock down" everything as much as possible without impeding the users' functionality for day to day work.  That being said, I realize that certain information is necessary for clients to connect, so there is no way around that.  But my issue is that the information is contained in a flat text file as opposed to an encrypted file on the client's machine.  So I imagine the scanario of one of my users or contractors laptops getting stolen, or their son's 16 yr old hacker buddy drops by for a visit and while using the laptop learns that 1) my company is using Checkpoint, 2) the dns name and IP addresses of my firewall, 3) the topology behind the firewall.  Then he runs off and posts this info on the nearest hacker bbs and now the whole world knows everything that my firewall is suppossed to be hiding.  It is true that they would still need a user name and password to get a connection int! o the network via the firewall, but that information may be used to formulate an attack on some other entry point into my network that I may have inadvertently overlooked, or was unwittingly opened by a user.

Also, in regards to ports being open, I have tried unsuccessfully to change the default ports of topology downloads from 264 (if I remember correctly) to something obscure like 10110.  It seems that from the server this is easily changed but on the client there is no way (that I have found) to tell the client to use port 10110 to get the topology in stead of the default. 

I guess the reason these things are an issue for me is because I am already using a product that takes care of these issues, but I am being instructed by my Director to drop our current solution in favor of Checkpoint.  His decision was based on word of mouth opinion by some of his friends, none of whom, as I understand it, actually use the product in the way that we would be using it.  Don't get me wrong, I am not married to any vendor.  I like to test possible solutions before making a decision and in this case I was not given the opportunity to do so.  Now I have to support a product that, from what I can tell, is not necessarily the best solution for our needs.

Thanks again for the suggestions.

R.

  Jeff Hochberg <[email protected]> wrote:



Paranoia is a good thing in the world of security, but only to a certain extent.  How do you expect SecuRemote clients to be able to connect to the firewall otherwise?

 

Authenticated topology requests prevent just "anyone" from getting a hold your topology.  Even if a hacker scans your firewall and sees that the ports for retrieving FW-1 topology info are open, they still need to provide a valid username and password before they'll even be able to download it.

 

The negate rule will negate all objects within that rule.  You're probably OK with the way you have your rule currently set up, so don't worry about my negate suggestion too much.

 

-Jeff Hochberg


-----Original Message-----
From: Rafiyq Mondesir [mailto:[email protected]]
Sent: Wednesday, March 07, 2001 12:10 PM
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.


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




-----Original Message-----
From: [email protected] [mailto:[email protected]]On Behalf Of Rafiyq Mondesir
Sent: Tuesday, March 06, 2001 11:21 AM
To: [email protected]
Subject: [FW1] Secure Client and NAT



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.



Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices!


 
----------------------------------

ABOUT SERVICES PRODUCTS TRAINING CONTACT US SEARCH SUPPORT SITE MAP LEGAL
   All contents © 2004 Network Presence, LLC. All rights reserved.