How to debug in kernel mode

Here is a list of the FireWall-1 Kernel Debug Options

The FireWall-1 kernel module may be put into debug mode with the following command:

nokia_fw[admin]# fw ctl debug

The following are valid debug-options         0 - turn debugging off (fw ctl debug 0)         all (DO NOT USE)              all debug features              The output is excessive, making the system unresponsive. Often, only a cold reboot will restore             access to the system.      cookie - "cookie" (abstract data type of representing packets) related messages  crypt - encryption related information  domain - domain queries  driver - device driver operations  filter - filter loading and unloading  hold - packets held and released (related, among other things, to encryption)  if - interface binding  install - driver installation  ioctl - ioctl commands from the daemon  kbuf - kernel buffers (buffers allocated by the kernel for encryption purposes)  ld - operations on dynamic tables  log - log messages sent to the daemon  machine - virtual machine operation (the virtual machine which executes the INSPECT code compiled from .pf files)  memory - memory usage  misc - all others  packet - packet handling  profile - performance monitoring  q - streams and queues operations  synatk - operations related to syn attack protection  tcpseq - TCP sequence numbers changed  winnt - windows NT specific operations  xlate - address translation for new connections  xltrc - address translation for telnet and ftp

Redirecting Output to a File

The information is sent by default to the console. It can also be sent to a kernel buffer. This is necessary because the output often is to great to process real-time. Here are some examples of how to redirect the output to a file for examination later:

tla[admin]# fw ctl debug -buf [1024]

The default size is 1024 Kbytes. At this point, you have only enabled the redirection of stdout to a buffer, but the next step is retrieve the contents of this buffer. This is down with the following command

tla[admin]# fw ctl kdebug -f

This will now dump the buffer to stdout, but this is similar to before. The following are the steps to redirect the buffer to a file:

tla[admin]# fw ctl debug -buf

tla[admin]# fw ctl debug

tla[admin]# fw ctl kdebug -f > filespec

tla[admin]# tail -f filespec

When you have gathered enough information, press to stop the output to the file. You will have to issue `fw ctl debug 0` in order to actually restore the kernel to normal operation.

Debugging HTTP Security Server

We used these below when we debugged HTTP Security Server problems. One of the vulnerabilities in the HTTP Security Server is that it will block all network connections it is checking if a URL is not resolvable. This is serious in that a DOS of DNS to your firewall can cripple it. For example, if you create a URI resource object to explicitly block HTTP to www.somedomain.com and this does not resolve to an IP address, then all HTTP that is subject to Content Security will be blocked.

tla[admin]# setenv HTTP_DEBUG 1

tla[admin]# setenv FWAHTTPD_DEBUG 1

tla[admin]# setenv FW_DEBUG_EVENT 1

tla[admin]# setenv FWT_DEBUG all

tla[admin]# fw kill fwd; fwd `cat $FWDIR/conf/masters`

The later versions of FireWall-1 enable SMTP_DEBUG and MDQ_DEBUG in another way. These variables should be defined in the $FWDIR/conf/smtp.conf file and then the fwd process should be killed using the –USR1 switch, when this is done, the debugging information will start immediately without the need to restart the daemons. To remove these environmental variables, execute unsetenv env_variable The output is directed to $FWDIR/log/ahttpd.log. This particular problem produced numerous duplicate entries in the log file that were of this form:
[port 1023:Connection refused Thu Aug 5 23:42:57 1999] [pid=764] Failed to connect to server for side = 1 at [Thu Aug 5 23:42:57 1999] [pid=764] write_from_queue : side = 1, clnt = 0,
buf = (
:data (
:resolved_name (www.unresolveable.com) :type (dns_resolve_byname)
) :chain_name (resolver_list) :call_function (cached_resolver_gethostbyname) :return_function () :serial_number_resolver_list0(2) :current_side(1)
)
The speculation was that FireWall-1 was attempting, over and over, to resolve to an IP address. It was verified that this particular destination was not resolvable. Once the rule using a URI resource object of type Wildcard, which explicitly specified this site, was removed, everything was restored. This bug was verified to be in 4.0 SP4 for Solaris on Aug 6th, 1999. The immediate solution is to not use a URI resource object of type Wildcard to drop or reject HTTP, but to only Accept HTTP.

Debugging SMTP Security Server

We use the following to debug SMTP Security Server. At this point in time, we do not have a good definition of what these variables do with the exception that they all increase the output of debug information. The variables with MDQ put the spool dequeuer process into debug mode. The SMTP_DEBUG environmental variable is shown with three levels. Choose one. FWT_DEBUG is associated with the fwd daemon. OPSEC_DEBUG_LEVEL

tla[admin]# setenv MDQ_DEBUG 1

tla[admin]# setenv FWMDQ_DEBUG 1

tla[admin]# setenv SMTP_DEBUG [1 2 3]

tla[admin]# setenv FWD_DEBUG cvp

tla[admin]# setenv FWT_DEBUG cvp

tla[admin]# setenv OPSEC_DEBUG_LEVEL [1 2 3]

tla[admin]# fw kill fwd;fwd `cat $FWDIR/conf/masters`

To remove these environmental variables, execute unsetenv env_variable.

Debugging SecuRemote/Encapsulation problem.

tla[admin]# fw ctl debug cookie

tla[admin]# fw ctl debug -buf 100

tla[admin]# fw ctl kdebug -f filespec

tla[admin]# tail -f filespec

 

We should see messages of the form "cookie data could not XXX". There will be messages that specifically complain about fragmentation. (SecuRemote may be placed into debug mode by creating the file, fwenc.log, at the root of your system drive. For example, this might be c:\fwenc.log)

 Debugging the in.pingd daemon

 

tla[admin]# setenv FWPING_DEBUG 1

 

The output of fw tab -t check_alive is also analyzed

What are the switches to fwd

Here are the current list of switches and what they do:

-u : run a SecuRemote server. -n : management only (no module). -s : no module (Supposedly doesn't do fw stat?) -l : no logs. -A : no alerts. -d : debug -D : log debugging fwd by default will use -u. fwstart calls fwd -n on pure management consoles (i.e. one that don't contain a firewall module). The debug flags sends messages to stderr (or fwd.log on FireWall-1 4.x) and run the process in the foreground instead of background.

How to obtain debug information from the daemons

You will need to kill the fwd daemon and restart it with a debug option
UNIX:

1. Go to $FWDIR/bin
2. Kill the relevant daemon with fw kill {fwd | fwm}
3. Restart the daemon with debug messages. Use 'fwd -d' or 'fwm -d'

NT:

1. Issue fwstop.
2. Enter %SystemRoot%\fw\bin and issue 'fw d -d' or 'fw m -d'.
3. Issue fwstart.

How to monitor what hapens on a management system, or on a system having an evaluation license

fw monitor command allows you to monitor network traffic going through the FireWall-1 Kernel Module. This is sort of like tcpdump except that it shows you what things look like from the perspective of various parts of FireWall-1 and can be used to monitor all interfaces simultaneously.


fw monitor [-d] [-D] -e inspect-filter -f filter-file [-l len] [-m mask] [-x offset[,len]] [-o file]

Command Line Options
-d Turn on dodebugptr
-D Turn on dodebugptr
-e Specify an INSPECT program line (multiple -e options can be used)
-f INSPECT filter name ('-' can be used to specify standard input). The -f and -e options are mutually exclusive.
-l Specify how many bytes of the packet should be transferred from the kernel.
-m Specify inspection points mask, any one or more of i, I, o, O as explained above.
-o Specify an output file. They can be viewed with the 'snoop' command on Solaris. This is only valid on 4.0 SP3 and later.
-x Perform a hex dump of the received data, starting at specify offset and printing out 'len' bytes.

Examples
fw monitor -e '[9:1]=6, accept\;' -l 100 -m iO -x 20 will display all TCP packets entering and leaving FireWall-1. Up to 80 bytes of TCP header and data will be displayed (assuming no IP Options are used)

fw monitor -e 'accept\;' -m iI will display all packets entering and exiting FireWall-1 in the inbound direction (i.e. before the OS routes the packet).

fw monitor -e 'accept ifid=0,src=10.0.0.1 or dst=10.0.0.1\;' will show you all packets in interface ID 0 coming from or going to 10.0.0.1. The value used for ifid corresponds to a number given to an interface by FireWall-1. You can determine which interface has which number by using the command fw ctl iflist.

fw monitor -e 'accept ifid=0,src=10.0.0.1 or dst=10.0.0.1,ip_p=47\;' does the same thing as the previous command except it looks for packets of IP Protocol 47 only.

fw monitor -e 'accept tcp,dport=80 or sport=80,src=10.0.0.1 or dst=10.0.0.1\;' shows all tcp packets going to or from 10.0.0.1 with either a source port of 80 or a destination port of 80.

Does Webtrends use ELA

Webtrends uses LEA (Log Export API), not ELA.  LEA is the opposite of ELA; it allows FW-1 to send events to a 3rd party reporting application. Although it is possible to use Webtrends with manually exported log files, I believe they recommend using LEA as the preferred interface between the two.

Per Check Point: "WebTrends Firewall Suite integrates with the Log Export API (LEA) of the OPSEC architecture in VPN-1/FireWall-1. When LEA is used, a secure connection is set up between WebTrends Firewall Suite and VPN-1/FireWall-1. This connection provides the mechanism that safely and securely transfers data between the firewall and the analysis engine. By encrypting data at the firewall, LEA ensures that firewall logs are not tampered with during transport. The LEA connection also facilitates the creation of real-time reports without the need to export complete log files at every update interval, saving time and bandwidth resources."

How to redirect logs to a different partition

For logging on Windows :
Regedit
go to HKEY_LOCAL_MACHINE\SOFTWARE\CheckPoint\FW1\5.0
create FWLOGDIR and put the full path to the log you want to go to

For logging on Unix :
ln -s /path/to/new/logdir $FWDIR/log
If you're talking about Windows NT then there is a registry hack.

enter the HKEY_LOCAL_MACHINE\SOFTWARE\CheckPoint\FW1\4.1 path and add a new
string value form the edit-->new menu. name it FWLOGDIR.
add the directory name that you wsih to log to, and create the directory.
then bounce the firewall (fwstop/fwstart).

How do I Rotate the Audit Logs in FireWall-1 NG

The VPN-1/FireWall-1 NG audit log type files are:

        

           xx.adtlog - stores the audit log records.

           xx.adtlogptr - provides pointers to the beginning of each log records.

           xx.adtloginitial_ptr - provides pointers to the beginning of each log chain (logs that shared the same  

           connection ID - LUUID). 

           xx.adtlogaccount_ptr - provides pointers to the beginning of each accounting record.

 

To purge/delete the current audit log files without saving it to a backup file, run:

# fw logswitch -audit ""

To logswitch and save the logs to a file, run:

# fw logswitch -audit

Example :

 

# fw logswitch -audit
 Trying to switch audit logfile to 2002-06-07_150016.adtlog
 Log File was switched to : 2002-06-07_150016.adtlog

procedure for moving the management server on WIndows 2000

1. Install the FireWall-1 software on the 2000 server. When setting this software up, designate the firewall module as a remote module. You will be prompted for a
secret key to authenticate management commands. YOU MUST USE THE SAME KEY OF THE FIRST TIME, OR EVEN DO PUTKEYS AGAIN.

2. Remove current objects.* from the 2000 server

3. Transfer these files from the SOLARIS management module to the new 2000 managment module (FTP is fine):

$FWDIR/conf/objects.C (objects and properties)
$FWDIR/conf/*.W (security policy)
$FWDIR/conf/rulebases.fws (Combined rule bases for GUI clients)
$FWDIR/conf/fwauth.NDB (User database)
$FWDIR/conf/fwmusers Adminstrators
$FWDIR/conf/gui-clients Allow GUI Adminstrative hosts

Note: Any *.NDB files must be transferred in binary mode. All other files should be transferred in ASCII mode.

3. Restart the 2000 management station.

4. Sometimes it is neccessary to regenerate the rulebases.fws file and objects.C files once moved to the new management station. This is done when you no longer see your rulebases or objects once you login to the Gui Client on the new mangement console.

Even with redoing the putkeys nothing changed. What's going on

For some reason, the firewall module is not recognizing the management console as that: the management console. This may be because the management console is described in the GUI with a different IP address than the hosts file on the firewall and management. Correcting the network object and/or the hosts file (possibly re-doing the putkeys)
should solve the problem.

If this does not work, consider the $FWDIR/lib/control.map file (this is more or less the "default"
control.map file):

MASTERS :stat,getkey,gettopo/none opsec/fwn1 */fwa1
CLIENT :load,db_download,fetch,log/fwa1 opsec/fwn1 */none
* :stat,getkey,gettopo/none unload,ioctl,load,db_download/deny opsec/fwn1 */fwa1

What does this file mean?

1.When my master talks to me (as defined in $FWDIR/masters), I will:
Allow stat, getkey, and gettopo functions without authentication
Require fwn1 authentication for opsec-related functions.
Require fwa1 authentication for all other functions.
2.As a client talking to my master (or as a master talking one of the managed firewalls), I
expect to: 

• Authenticate with fwa1 for load, db_download, fetch, and log functions. 
• Authenticate via fwn1 for opsec-related functions. 
• Not authenticate for other functions. 

3.When talking to all other hosts (or other hosts talking to me), I will:

• give (or require) no authentication for stat, getkey, and gettopo functions. 
• deny authentication for unload, ioctl, load, or db_download functions. 
• give (or require) opsec authentication for opsec functions. 
• give (or require) fwa1 or all other functions. 

To resolve this, you will need to modify the control.map file on the remote firewall. Make a copy of the SERVER line, replacing the word "SERVER" with the IP address of the management console (e.g. a.b.c.d). Place the new "SERVER" line between the existing SERVER and the CLIENT line, so the file looks like this:

MASTERS :stat,getkey,gettopo/none opsec/fwn1 */fwa1
a.b.c.d :stat,getkey,gettopo/none opsec/fwn1 */fwa1 
CLIENT :load,db_download,fetch,log/fwa1 opsec/fwn1 */none
* :stat,getkey,gettopo/none unload,ioctl,load,db_download/deny
opsec/fwn1 */fwa1

This new line means makes it so that when communication takes place with a.b.c.d:

Allow (or request) stat, getkey, and gettopo functions without authentication
Require (or give) fwn1 authentication for opsec-related functions.
Require (or give) fwa1 authentication for all other functions.

Because this file is processed in order, the order of the lines in control.map is important. Bounce the remote firewall (fwstop; fwstart) and attempt to load security policy and it should succeed.

If you're still having problems, see Can't Get Putkeys to Work.

Secure Client through a FireWall-1 Firewall

I have an internal local user who is connected to our local network, and he is interesed in using securemote to connect to one of our customers who provide him the necessary information to get into their site. Both our site and the customer site use FireWall-1. The user is able to ping and see the customer's hosts but some of the packet will not go through our firewall.
If the same user uses the modem or dialup from the ISP internet connection he is able to do everything he needs to with securemote, but we are interested in providing connectivity within internal lan to remote customer site.


If your firewall is not performing any address translation on the securemote client, then it will work with the information provided below. If your firewall is doing address translation for the securemote client (because the client has a non-routable or illegal IP address), then read the following FAQ to determine if such a configuration will be possible: Secure Client and NAT
Assuming you are not doing address translation or can workaround it, part of what needs to be done will depend on whether or not the remote FireWall-1 is configured to use encapsulation for securemote connections or not.
General Configuration
In all cases, you will need to permit the following traffic through your local firewall (note only use IKE for FireWall-1 4.0 and above when IKE is used for securemote, in 4.0 the service is named ISAKMP):

Source                   Destination              Service                    Action
                                                  FW1
securemote-Client        Remote-Mgmt-Server       FW1_topo                   Accept
                                                  FW1_pslogon

securemote-Client        Remote-FireWall          RDP                        Accept
                                                  IKE

Remote Site Uses fwz Encapsulation
If the remote site is using encapsulation for securemote clients, the following additional rule needs to be added:

Source                   Destination               Service             Action
securemote-Client        Remote-FireWall           FW1_Encapsulation   Accept
Remote-FireWall          securemote-Client

FW1_Encapsulation is pre-defined on most current FireWall-1 boxes. If it is not pre-defined on yours, then create it as service of type Other with \"ip_p=94\" in the Match field.
Remote Site Uses IKE
If the remote site is using IKE for securemote clients, the following additional rule needs to be added:

Source                   Destination              Service             Action
securemote-Client        Remote-FireWall          ESP                 Accept
Remote-FireWall          securemote-Client

ESP is pre-defined on most current FireWall-1 boxes. If it is not pre-defined on yours, then create it as service of type Other with \"ip_p=50\" in the Match field.
Remote Site Uses UDP Encapsulation
If the remote site is using UDP Encapsulation on their clients, the following additional rule needs to be added:

Source                   Destination              Service                  Action
securemote-Client        Remote-FireWall          VPN1_IPSEC_encapsulation Accept
Remote-FireWall          securemote-Client

VPN1_IPSEC_encapsulation is pre-defined on FireWall-1 4.1 SP3 and above. If it is not pre-defined on yours, then create it as service of type UDP, port 2746.
Remote Site uses fwz without Encapsulation
If the remote site does not use encapsulation, then you will need to permit the necessary traffic to and from the remote site by your local firewall's rulebase. You need to make sure that none of the traffic is processed through the security servers or an intermediary proxy or you might get unreliable or unpredictable results. The following rule near the top of your rulebase should suffice:

Source                   Destination               Service             Action
securemote-Client        Remote-Servers            Any                 Accept

The \"any\" above can be replaced with the specific services the securemote client needs to use.
Remote Site uses NG, Policy Server, and Office Mode
If you are using Office Mode on FireWall-1 NG and/or using the Policy Server for NG, you will need the following rules:

Source                   Destination              Service                  Action
securemote-Client        Remote-FireWall          FW1_pslogon_NG           Accept
                                                  IKE
                                                  VPN1_UDP_Encapsulation
                                                  Tunnel-Test

FW1_pslogon_NG is TCP port 18231. Tunnel-Test is UDP Port 18234.

SecureRemote from behind a NAT device

How to encrypt data between an SR Client behind a NAT device and the LAN behind FW-1,

You have to distinguish 2 situations

1) Static NAT, Pool NAT, 1 user behind a Hide NAT

2) Hide NAT with multiple users

In the following configuration you solve it for situation 1) :

SR Client ------ NAT device (FW or other) ----- Internet ------ FW-1--- LAN

For this configuration you need VPN-1 version 4.1.

It it supported with FW-1 4.0 (and SR versions above SR4003) by making the following modifications

Stop FireWall-1 with the command

fwstop

Edit the $FWDIR/conf/objects.C file and add (or modify) the following lines which are under the property

set props : :userc_NAT (true) for FWZ,

and :userc_IKE_NAT (true) for ISAKMP (IKE).

Restart FireWall-1 with the command fwstart Install the policy.

Confirm that these changes appear both in $FWDIR/conf/objects.C and in $FWDIR/database/objects.C For Static NAT and Pool NAT, this configuration works fine with the FWZ and IKE encryption schemes.

This works with Static NAT and Pool NAT fine. For Dynamic NAT, it will only work if there is a single SR client behind each hiding IP address.

2) If you are subject to address translation, it is highly recommended to use IKE instead of FWZ. Both encapsulated and unencapsulated FWZ are known not to work with HIDE NAT at all. Static NAT (1-to-1 address mapping) should work with FWZ in either mode provided you allow IP Protocol 94, UDP Port 259, and other services if you use FWZ in unencapsulated mode. However, most NAT gateways will reject unencapsulated FWZ packets because the checksums are changed to support the FWZ encryption scheme.

If you are subject to any form of NAT, IKE is your best bet. However, most NAT gateways can not be configured to perform HIDE NAT on generic IP Datagrams. Provided you can forward UDP Port 500 packets and IP Protocol 50 (IPSEC) packets with your NAT gateway, you can use IKE with NAT.

Secure Client 4.1 SP2 and later when used with FireWall-1 4.1 SP2 and later support a 'UDP Encapsulation Mode' for IKE. Instead of using IP Protocol 50, UDP port 2746 is used. Most NAT gateways can perform address translation on UDP packets and it is designed to work with HIDE NAT, meaning multiple users can make use of SecuRemote behind a HIDE NAT gateway. Provided your clients are able to use TCP port 264 to fetch the topology, UDP port 500 to perform an IKE key exchange, and UDP port 2746, this should work.

You will need to modify objects.C on the management console to permit FireWall-1 to accept connections from NATted SecuRemote users. Edit $FWDIR/conf/objects.C. After the props: line, add:

:userc_NAT (true)
:userc_IKE_NAT (true)

To configure the UDP Encapsulation Mode for FireWall-1 4.1 SP2, create a service called VPN1_IPSEC_encapsulation if it does not already exists. Create it with port UDP 2746. Then add the following section to the section with your gateway object to objects.C:

:isakmp.udpencapsulation (
:resource (
:type (refobj)
:refname
("#_VPN1_IPSEC_encapsulation")
)
:active (true)
)

You have to add this in between the properties defined for your firewall object. Search the Objects.C file for the name of the firewall object ( through which you would like to the UDP encapsulation enabled ) and add these lines in between the various features configured for your firewall object.

Re-install the policy.

Note that in the default configuration, FireWall-1 will determine whether or not to use this mode based on the source port of the incoming UDP 500 packet. If it comes from source port 500, it will not use the UDP encapsulation mode. If it comes from a different source port, UDP encapsulation mode will be used. More details and instructions for disabling or forcing this mode can be found in the Secure Client 4.1 SP2 Release Notes.

Description of UDP Encapsulation. Seeing UDP encapsulation is a new feature and I was concerned about it affecting the users with older securemote software, here is a quick and dirty explanation of UDP Encapsulation. 

1. SR sends IKE packet to VPN-1, one of the IKE proposals it sends to the gateway is to use UDP encapsulation. Note, only SP2 clients can send this UDP encap proposal, SP1 or earlier clients, cannot. 

2. If IKE negotiation (port UDP-500/500) packet's SRC PORT has NOT been translated, then no UDP encapsulation, it just operates like normal SR IKE session (thus SP2 and SP1 and earlier SR's can run side by side against a single gateway): a standard proposal is selected and a VPN tunnel is established. 

3. If IKE SRC PORT != 500, then the gateway assumes that a NAT HIDE device is between the gateway and SR. Then, and only then, does it accept the UDP encapsulation proposal. This selection is communicated to the client. 

4. The client takes note of the selected IKE Proposal (encap or a "normal" one) and if encap, wraps the IPSEC traffic in a UDP packets. It is actually quite an elegant solution, as it is end user transparent and encapsulation (i.e., the extra overhead) is only used when needed... when the SR client is behind such a NAT device. When the SR client is moved to another non-NATed network, no encap takes place.
 

What do IP Pool features do, in 4.1. This has something to do with NATof inbound traffic, but why one would want to NAT inbound traffic.

The main reason for this new feature is to properly handle internal network routing, when a company's internal network is connected to the Internet in multiple places. 
Prior to version 4.1, if a SecuRemote VPN was established through one of the company's firewalls, the Internet routable source IP address would have to be passed into the internal network.  This works fine, so long as the path back out to the Internet goes through the same firewall original packets came in on. 
However, several large companies now have multiple Internet connections, which poses a unique problem.  If you were to route the Internet routable source address through one firewall, and then try to access internal resources in another office that had it's own Internet connection, there is a high probability that return packets would be routed through the second office's Internet connection, and thus break the VPN.  It is for this reason, that Check Point added new functionality to allow you to "hide" incoming VPN traffic.  This way, one can add specific internal routes to get VPN return traffic back to the specific firewall it came from.

How to configure SecuRemote for a split DNS configuration, to make it get the Secure Domain Login functions working with a 4.1 SP2 firewall and a Windows 98 client

Many pointed out that getting SDL to work correctly can be very challenging.  From Gregor Munro an exact fix that worked for him.  He suggests cutting and pasting the solution (included below), directly into your $FWDIR/conf/dnsinfo.C file, and then editing it to suit your network.  The reason you should not try to start this file from scratch is that spacing and case are extremely important.  For example, using an "LMData" tag will not work - it needs to be "LMdata."

--Begin $FWDIR/conf/dnsinfo.C-- 
( 
:LMdata ( 
: ( 
:ipaddr (10.0.0.1) 
:name (MERLIN) 
:domain (ROUNDTABLE) 
) 
: ( 
:ipaddr (10.0.0.1) 
:name (MERLIN) 
) 
) 
) 
--End $FWDIR/conf/dnsinfo.C-- 

How to have SecuRemote Access to an internal DNS for DNS resolution

the internal DNS server’s IP address

 Modify the $FWDIR/conf/dnsinfo.C file on the Management Station to redirect DNS by providing the following information.
        
         the domain for which it resolves names 
         the maximum number of labels to resolve (for example, 3 for xxx.hello.com). Suppose the SecuRemote Client’s domain is .hello.com and it fails to resolve yyy.goodbye.com. By default, Windows will then try to resolve yyy.goodbye.com.hello.com, and you will probably not want this query to be encrypted.  
         the network addresses for which it resolves (for reverse DNS)

In $FWDIR/conf/dnsinfo.C, 
set :encrypt_dns (true) under :dnsinfo.

Instruct the gateway to encrypt DNS by changing the definition of
USERC_DECRYPT_SRC in crypt.def.

Reinstall the Security Policy on the gateway so that these changes take effect.

On the SecuRemote Client, 
set :dns_encrypt (true) 
under :options in database\userc.C.
Note – :dns_encrypt (true) is the default in VPN-1/FireWall-1 Version 4.1 and higher.

How to connect to NT shares through FW-1

First off, you will need to use encapsulation when setting up your encryption domain. This appears to be the only way to get the NBT stuff to tunnel properly. Yes, it will even work if you are using translation! In my case, I already had a network object defined for my RFC 1918 internal network. All I did was set up the encryption, specifying my existing
local-net object as my encryption domain.

OK, question time now. I could only get this to work using FWZ encryption method. I tried to setup SKIP, but it wouldn't happen. What's the real implication of using FWZ/Maual IPSEC/SKIP here? You can still define DES
data encryption when you set up your users. Which of the above is the better method to choose?
Now that you have the domain set up, start creating your user, and add them to a group. Now you can create a rule to allow that group access to your encryption domain. I my case -SR-Users/Local-Net/ANY/Client Encrypt-.

Now comes the fun part. Installing and configuring the client. The thing to remember here is you NEED some sort of netbios name resolution. There are 2 ways this can be done. 1-create an lmhosts file specifying every device on the internal net you need access to. This is the ugly and painful method. Though I made it work ,never could get a clean logon. Even though I got a good logon to the NT domain, I still got error messages about not being able to find a domain controller?? If you have WINS set up, USE IT!!! If you don't, SET IT UP!! Enter the internal address of
your WINS server in your network properties of the client workstation. Not the properties of the dial-up connected!!!

If you also have this client networked via a NIC, you will also have to implement hardware profiles. Make 2 profiles, on for dial-up, and the other for in the office. Disable the NIC for the dial-up profile. Now you can install the SecuRemote client. Reboot, dial up your isp, and you should be able to create your site within the client.

You should now have a fully functional SecuRemote VPN set up. Dial up your isp, and you will be auto magically prompted to authenticate yourself on the firewall. While your trying to type that id and password in, your NT logon
will popup. Remember to finish the SecuRemote Authentication before you enter your NT logon :>

What is SecureClient

It is SecuRemote configured with the Desktop Security feature.
SecureClient == SecuRemote EXCEPT that SecureClient has the capability to function as a "mini-firewall" to prevent hijacking of SecuRemote sessions (this is the "Enable desktop security support" option you see during install
of SecuRemote 41xx - that's the ONLY difference from an install perspective). To use it without the "mini-firewall" functionality, it is free. To use the SecureClient functionality, however, you must purchase licenses for it, which you would install on the management station. You will also need a policy  server function. This also requires FW1 v4.1/2000. Version 4.0 does not offer SecureClient functionality.

How does SecuRemote work

     IKE: Allows for DES or 3DES to be used to encrypt the packets. Packets are encapsulated in IP Protocol 50 (i.e. IPSEC) or UDP port 2746, depending on whether or not UDP Encapsulation is used.  

    fwz without encapsulation (available in NG FP1 and before): Uses fwz1 or DES to encrypt the packets. Only the data portion of the packet is encrypted. The IP headers are left alone.

    fwz with encapsulation (available in NG FP1 and before): Same as above, except packets are encapsulated in IP Protocol 94 packets.

   

    Visitor Mode (NG AI and above): Tunnels using a standard HTTPS stream. By default, runs over port 443, but can use any port.

When using Transparent Mode in NG, or using 4.1 and earlier, the securemote client will, as it deems necessary, establish an encrypted session with the firewall. Before it can do this, the securemote client needs to know what hosts it can talk to encrypted and what the encryption keys are. This is accomplished by fetching the site from the remote server. This happens on TCP port 264 to the firewall module. securemote 4.0 used TCP port 256 to the management station.

In NG when using Connect Mode, the connection to the encryption domain is controlled by the end user. The connection dialog looks very similar to a dial-up networking. The user can select the site he wishes to connect to, change options, and then connect. Optionally, the start of the VPN connection can be tied into the domain logon in Windows 2000/XP.

Once securemote determines that it needs to encrypt traffic to the firewall, authentication is performed. Authentication can be a simple password, SKey, SecurID, or a certificate, but all data between the firewall and the client is encrypted so the password (even if it is a simple password) is not divulged in the clear. This happens between the firewall and the client on UDP port 259 (source port and destination port) if fwz is used or on UDP port 500 if IKE is used.

What model of DSL routers works best with SecuRemote/SecureClient

Here is the result of different tests performed with DSL routers and SecuRemote.

Checkpoint Safe@Home (s-box) works fine

Linksys They are working with SecuRemote. The only issue with Linksys is that they only support a single IPSEC connection from behind the router. I had a Linksys BEFSR41 router and have multiple computers at home, and for the longest time, was wondering why I was having connection/stability problems. I then found out from Linksys' web site that there routers only support a single IPSEC connection.

SMC routers, as we have not had a single problem with them.

NetGear products work fine

3Com officeconnect DSL gateway works fine

Netopia 3351 works fine

Cisco 678 works fine

D-Link 614+ could not work but 714 worked out of the box.

W-Linx 401,  is working perfectly.


Is it possible to use an answer file for SecureClient installation

Is possible to use an answer file with a SecuRemote installation (Build 4200) to be specific? This allows the ability to blindly answer the questions during the install, without the end user having to do anything.

This is possible. In NG FP2/3 checkpoint also ships a tool for modifying these settings. Use the "Secure Client Packaging tool" that is available from the checkpoint site.

You have to install the packaging tool on a machine that has SecuRemote/SecureClient installed and configured. Then run through the options and when it gets to the part where it asks for the Client installed files point it to the directory where it is installed on the current machine (c:\Program Files\Checkpoint\SecuRemote or something close to that) Then generate your package. Now install it on a TEST machine everything should be there.

 

NG SecuRemote license

The securemote license is separate from other firewall licenses, so if you have a license installed on your management server that contains a string

like (Assuming NG) "CPVP-VSR-XX-NG", you are licensed for securemote. If you don't have a license with this product code in it attached to your

management server, then you aren't licensed. The license is free (as in beer), contact your Checkpoint supplier to obtain one.

How to change the log directory

To direct Log File to directory different then the standard $FWDIR/log. On UNIX system this can be achieved by adding

setenv FWLOGDIR

to the fwstart scripts before running the fwd and them fwm.

To do this in NT, you must upgrade your software to 3.0b, and then use the Registry Editor to add to the key

HKEY_LOCAL_MACHINE\SOFTWARE\CheckPoint\FW1

the value FWLOGDIR with the desired path of the directory (which must exists).

Authentication in more than one NT domain

What ports are used for a trust relationship

PORT 135 TCP or UDP RPC services
PORT 137 UDP Netbios name service
PORT 138 UDP Netbios datagram
PORT 139 TCP Netbios session
All port above 1024 for RPC communication

juniper router configuration command(Network)

           Description                                                                Commands

Show running configuration                                              sh configuration

Show version                                                                  sh ver

displays the status of interfaces configured for IP              show interface terse 

displays the interface configuration, status and statistics.    show interfaces [intfc] detail

displays information about a physical port device              show interfaces intfc extensive

displays the interface configuration, status and statistics     show interfaces description


displays summary information about entries in the
routing table                                                                    show route
displays the status of all Border Gateway Protocol

(BGP) connections                                                          show bgp summary

will show you how that route is being advertised,
look for the first line                                                         show route protocol bgp prefix

will show you how that route is being advertised,
look for the first line                                                         show route range prefix

displays routes matching the autonomous system (AS)
path regular expression                                                    show route aspath-regexp "AS-regexp"

Shows whether a neighbor supports the route refresh
capability   show route receive-protocol bgp neigh           show route source-gateway neigh protocol bgp

                                                                                       
Shows whether a neighbor supports the route refresh
capabilty                                                                         show route advertising-protocol bgp neigh 


displays both ES and IS neighbors                                   show isis adjacency


shows specific information about each interface                show isis interface

displays the current state of the the routing table               show isis routes

displays a list of all connected routers in all areas              show isis spf

 shows neighbor ID, Priority, IP, & State if the
neighbor router, dead time.                                              show ospf neighbor

shows neighbor id, pri, state, dead time, address              
and interface                                                                   show ospf interface

display the current state of the routing table                      show ospf route

display list of information related to the OSPF
database for a specific communication server                   show ospf database

display the system hardware config., software version,
and name and source of configuration files and boot
images                                                                            show version, show system uptime

displays power-on diagnostics status                               show chasis hardware

displays utilization statistics   show system process
displays the current software image, configuration,
controllers, counters, stacks, interfaces, memory
and buffers  -                                                                 request support info


display the state of logging to the syslog                          show log messages

displayall route-maps configured or only the one
specified                                                                        show policy name

display information about a prefix list or prefix                
list entries                                                                       show policy name

display routes that are permitted by BGP                       
community list                                                                configure,show policy-options 

                                                                                     community name

displays temperature and voltage information
on the console                                                               show chassis  environment

to check to see if a destination is alive                            ping dest rapid (for cisco like output)

                                                                                    ping dest (for unix like output)

to check to see if a destination is alive                            ping dest bypass-routing

Change console terminal settings                                    monitor start messages 

Change console terminal settings                                    monitor stop 

sets the length for displaying command output                set cli screen-length 0

How to remove old licenses

Use fw printlic to view the current license situation, and then re-enter your current license string (eval or permanent key) with a -o option. This will overwrite all existing licenses.
fw putlic -o ...

message "to many hosts", what shall we do to unlock the situation

To remove firewall license limitation use the procedure:

fw lichosts
rm $FWDIR/database/fwd.hosts
rm $FWDIR/database/fwd.h
fwstop
fwstart

 

licenses for SecuRemote with NG AI

Chkpnt NG with AI supports 2 licensing schemes - local and central. If you have multiple Enf modules(EM) and a single SmartCenter server(SCS) to manage all of them - go for central licensing. Central licensing is useful in such cases because even if the EM IP address changes you dont need to regenerate ur license, the only time you need to regenerate your license would be in case if you change the SCS IP(which is rarely the case). Go for Local licensing when you have the SCS and EM on the same machine - standalone configuration. In this case, if you change the IP of your EM, you need to regenerate ur License. Tedious ha ?
SCS always requires a LOCAL license in any case.
This may come as a BOOMER to you - if you have already procured the product with local licensing - and already generated it from usercentre.checkpoint.com - nothing can be done about it now.
If you have not yet purchased the product 
- I would suggest you go for centrallicensing as its better in your case.

What is included in the Express license

• VPN-1 Express Gateway
• VPN-1 SecuRemote
• Firewall-1
• SmartDefense
• SmartCenter

there are other things available as add-ons...

How to reconstruct Rulebases

The Motif/Windows GUI uses the rulebases.fws file. to recreate this file for whatever reason. If you have rulebase.W files in your conf directory, quit any open GUIs and recreate this file as follows:

Note: These commands will not work on NG FP2 and above. In fact, in NG FP2, they can cause further corruption of your rulebase file. On Unix:
    # cd $FWDIR/conf
    # fwm -g *.W
On NT:
    c:\> cd %FWDIR%\conf
    c:\WINNT\FW\conf> for %i in (*.W) do fw fwm -g %i
The differences are:

• On Unix, the * is interpreted as a wildcard, including all .W files
• On NT, the * is not interpreted as a wildcard, so you must list the .W files individually.
• On NT, there is no 'fwm' binary, but it is included as part of fw.exe

Other notes:

• When importing rulebase files, if objects referenced in a specific rulebase no longer exist, then the rulebase in question will not be successfully imported. You will see "Not in Scope" messages when you run this command. This is normal.
• These steps will cause CORRUPTION of your rulebase file in NG FP2 as this command is no longer supported. NG FP3 and later do not allow the commands (e.g. executing fwm -g *.W nets a 'this command is no longer supported' message

How to block Kazaa and other network sharing programs

Blocking of Kazaa under NG AI is as follows

Open SmartDefence window

Application Intelligence / Web / HTTP Protocol Inspection / Peer to Peer

You will see the application, chech which you want to blok and check Peer to Peer.

Select the configuration apply to all connection in HTTP Protocol Inspection.



If you want to know more about Kazaa or you run a version previous to NG AI



Initial configuration of Kazaa version 1
Kazaa is only one of a whole culture of peer-to-peer file-sharing networks/programs:  Gnutella, eDonkey, BearShare, etc ad infinitum

Kazaa version 2 uses dynamic ports

How to block it on a firewall
Block them by port number.  This doesn't scale well, and fails completely with the ones that search for unblocked port numbers to
use.  (While to you, a firewall should be a "policy enforcement device", to your users and the authors of these applications, it's just an obstacle to be surmounted.)
If a client uses a HTTP port program like KazaaHTTP, there are very few options that you have as it will tunnel the kazaa traffic over HTTP from the client’s desktop. If you have a novice userbase, simply blocking the port of 1214 should suffice.
If you are using Checkpoint NG, FP3 is supposed to include the additional content filtering needed to block applications like Kazaa.
If you are blocking port 1214, you also have to block all outgoing socks-traffic, because kazaa-client supports Socks-Proxy and
there exists enough free socks-proxy.  The second thing, if you are blocking socks then you also have to block all outgoing http/https-traffic, because you can tunnel socks-traffic over http/https with tools like httport.


How to block it on a Cisco router
access-list 101 deny   tcp any any eq 1214

What measure you should take
Add a content-filtering solution to your border security.  This is about the only way you're going to block stuff that piggy-backs on
well-known service ports (80, 25, etc) in order to circumvent firewalls.



What you should also know about Kazaa

Unfortunately when you install KaZaa you also get at least one virus installed on your computer. I call it a virus because by most descriptions I've seen of the term, TopText qualifies as a virus. You don't ask for it. It takes control of your browser and makes changes to everything you read on the Internet.

TopText operates with a browser to highlight words on every web page, inserting a yellow background behind keywords that have been purchased through their media sales company eZula, Inc. If a web user clicks on one of those yellow highlighted words on a web page, the user is whisked away to the site of the company paying the most that day for each click-through. If a user whose browser is infected with TopText visits your web site, they will be offered links to competitor's web sites for every keyword they find on your site for which they have a buyer.

This is not much, if any, different from the Smart Tags system that Microsoft announced for their Windows XP browser. Media and webmaster pressure and outrage caused Microsoft to cancel, for now, their release of that feature.

How to understand and configure MAD

MAD is Malicious Activity Detection, a process that runs on the Management server and will periodically review the logs to find suspicious behaviour. (Multiple auth failures, port scan, syn and land attacks.)

MAD detects/defends:

    - Syn-Attacks
    - Spoofing attempts (for local interfaces, too)
    - portscan detection
    - blocked ports scan detection
    - login failures
    - fast repeated connects
    - land attacks

MAD land attack
It is CPMAD that tell you it sees a land attack. Check the cpmad_config.conf file (in $FWDIR/conf) and you should find line containing _land_attck_ in it. A land attack sends out just one SYN packet in which the sending device IP address has been replaced with the address of the destination, meaning that it tries to answer to it's own, resulting in loop backed packets ... slowing down the server.



MAD configuration

The configuration of Checkpoint's Malicious Activity Detection System is done through the file $FWDIR/conf/cpmad_config.conf. For Information on how use the variables in the file, take a look in the EntGS.pdf file located on the installation CD-rom (v4.1).

How to allow DHCP on the firewall or through the firewall

In some situations it is necessary to run a DHCP server on the firewall, but it should be avoided when ever possible. As has been mentioned, you probably shouldn't be running a DHCP server on
your firewall.  Your firewall should be your firewall, and little or nothing else.

That said, the only reason FW-1 should interfere with DHCP is if you have   rules preventing the traffic.  You'll need to allow UDP/67 *to* the FW, and UDP/68 *from* the FW, both on the
interfaces that you wish to provide BOOTP/DHCP services to.  Note that your normal stealth rule will prevent any such traffic, and the rules to allow the DHCP traffic will need to be in front of the stealth rule.

On Nokia firewalls you have a DHCP relay capacity that allows you to have access to a DHCP server and that you have to pass through the firewall. Off the main config menu, BOOTP Relay, is what you want.

You will also need to add to your rulebase something to the effect of:

DHCP_Servers Firewalls BOOTP ACCEPT

can I use a published IP address to "hide" multiple DMZ servers, and direct traffic to the correct server based on the service involved

"All you do is create a STATIC NAT rule with the proper settings. (actually two rules in NAT tab, and two in the rulebase)

lets say your outside IP is 1.1.1.1 and you have two servers inside at 192.168.1.1 (ftp) and 192.168.1.2 (http)

    On the NAT tab,
    orig src = any
    orig dest = 1.1.1.1
    orig svc = ftp
    xlat src = any
    xlat dest = 192.168.1.1
    xlat svc = original

    orig src = any
    orig dest = 1.1.1.1
    orig svc = http
    xlat src = any
    xlat dest = 192.168.1.2
    xlat svc = original

and then the obvious rulebase entries to allow packets to enter/leave various interfaces."

Secure DNS accesses

You will need to restrict services as defined below. But pay a special attention to Dynamic updates if you are using or planning  to use them.

    

    allow udp 53 in from outside to dns server    [queries to your server]
    allow udp 53 in from dns server to outside    [queries from your server]
    allow tcp 53 in from secondaries or ISP server  to dns server [zone transfers from your server]
    allow tcp 53 out from dns server to outside [zone transfers from primaries, for which you are a secondary]
    

Note: queries normally use udp, but apparently also use tcp under load, so restrict queries to udp may cause headaches in some situations.

    If you want to enable dynamic updates, despite the additional risk, use TSIG for better authentication of hosts allowed to make updates. Always restrict updates via an ACL.