Encryption

:ike_use_largest_possible_subnets (false) (New for NG FP3 Hotfix-2)

In the default state of true, this property tells FireWall-1 to attempt to "supernet" any network definitions for your encryption domain when negotating an SA. While this will, in theory, reduce the number of SAs that will be generated, it does not work real well when attempting to interoperate with other vendors VPN products. By disabling this property, the SAs will be defined based on how the network objects were created.

Note that this property does exist in a base NG FP3 configuration, but it does not work.
 

:ike_local_host_auto_refresh (true) (New for 4.1 SP4)
:ike_me_auto_refresh (true) (New for 4.1 SP4)
:ike_peer_gw_auto_refresh (true) (New for 4.1 SP4)
:ike_remote_host_auto_refresh (true) (New for 4.1 SP4)

These properties will establish a persistent IPSec tunnel between objects residing behind two VPN endpoints. The objects can be individual hosts or they can be the entire encryption domain. The feature is supported for

• a single, local host behind a gateway (local_host)
   
• a single,remote host behind a gateway (remote_host)
   
• all traffic sent to and from a single gateway (me), and
   
• all traffic passing between two gateways (peer_gw)
   

These properties are NOT added to the props() section of the objects.C file. It is added to each object for which persistent IPSec tunnels are required. In the case of establishing permanent SAs between gateways A and B, one could add ike_peer_gw_auto_refresh (true) to the Gateway B object installed onto Gateway A or to the Gateway A object installed onto Gateway B, or both.
 

:desktop_site_default_tcp_ike (true)(New for 4.1 SP4)
:supports_tcp_ike (true)(New for 4.1 SP4)

The user may find it impossible to use SecuRemote from a location where the IP attributed by the ISP is a Hide NATed address. This is because IKE negotiations involve sending UDP packets which under certain conditions generate multiple IP fragments. NAT devices used by ISPs are unable to properly translate IP fragments, which leads to the loss of these packets.

You can overcome this problem by configuring VPN-1/FireWall-1 to conduct Phase 1 IKE negotiations over TCP instead of UDP, as follows:
 

1. In the Default Key Scheme window (on the SecuRemote Client), click Advanced Settings.
    
2. Check Support IKE over TCP.
    
3. Define a rule that allows the ike_tcp service (TCP port 500) to the VPN/FireWall Module.
    
4. Edit the objects.C file and either:
    
   • add the ":desktop_site_default_tcp_ike (true)" property (which enables IKE over TCP on all gateways managed by the Management Server), or
      
   • enable the property ":supports_tcp_ike (true)" for a specific gateway object.

:ike_negotiation_timeout (36 < seconds < 600)

It is now possible to increase the IKE negotiation timeout, which is 36 seconds by default. To modify the timeout, add this line to the props() section:
 

:IPSec_cluster_nat (true) (New for 4.1 SP3)

This line will force VPN-1 to respond to IPSec/IKE key negotiations with packets originating from the Gateway Cluster IP address. This is useful when VRRP is used to support the Gateway Cluster IP address.

This eliminates the problem where a remote end of the VPN establishes a connection with the Cluster IP Address and gets a packet that originates from the real IP Address of the Nokia Applications Platform. This solves interoperability problems with Gateway Clusters and third-party VPN products as well as makes UDP Encapsulation (for SecuRemote) work properly in a Gateway Cluster configuration.


Note that in FireWall-1 4.1 SP5 and above, the property is added to each individual gateway definition, not the :props section. See Resolution 9512 for more information.

Note that it is not recommended to enable both IPSec_main_if_nat and IPSec_cluster_nat, despite what the release notes say about this.
 

:IPSec_main_if_nat (true) (New for 4.1 SP4)

This property forces IPSec packets to originate with the IP address of the interface the packet leaves instead of the gateway's main IP address. This is useful for establishing VPNs with different endpoints that are reachable from different interfaces. Note that it is not recommended to enable both IPSec_main_if_nat and IPSec_cluster_nat, despite what the release notes say about this.


Requirements which apply to the IPSec_cluster_nat are presumed to apply to IPSec_main_if_nat: management server and enforcement point must run same service pack of VPN-1/FireWall-1 and in VPN-1/FireWall-1 4.1 SP5 the property should be added to each gateway object definition rather then to the ":props" section.

The property should occur prior to the IPSec_cluster_nat property even though IPSec_cluster_nat has been defined (false).
 

DNS Security

:dns_verification (true) (New for 4.1 SP2)

This will add a pre-defined rule to any INSPECT code generated by a security policy, represented by the macro, dns_verification_code. This rule will only allow DNS queries or responses to be transmitted across port 53.
 

Certificate Validation

:use_cms_validation (false) (New for 4.1 SP1)

Forces VPN-1/FireWall-1 to validate Entrust certificates using the same Check Point validation code it uses to validate OPSEC CA certificates. Normally, VPN-1/FW-1 would use the Entrust CMS toolkit.
 

LDAP

:fwldap_TemplateCacheSize (n)
This defines the size of the LDAP template cache, thereby enabling the caching of LDAP templates.
 

HTTP Security Server

:http_transparent_server_connection (false) (New fow NG FP2)

This tells the security server to revert to the 4.1 behaviour in regards to proxying connections that go through the HTTP Security Server. See Resolution 14620.

Note that if you manually enter this property into objects_5_0.C, it should go under the firewall object definition under :firewall_properties instead of the global properties.
 

:http_enable_uri_queries (false) (New for NG FP2)
This prevents Firewall-1 from stripping ASCII encoding of special characters.

:fwurl_code_red (true) (New for 4.1 SP5)

The Code Red worm attacks IIS Web servers by sending them a bad HTTP payload designed to take advantage of a known IIS vulnerability. This service pack and future releases of VPN-1/FireWall-1 can deter this attack by enabling the fwurl_code_red general property and adding special rules to the Security Policy.

Note that in NG FP2 with Smart Defense and later, you should use the appropriate options in Smart Defense to block Code Red, NIMDA, and other similar worms.

This security enhancement will prevent infection from the Code Red and its clones but should not be seen as a substitute for applying the relevant fixes to Web servers.
This fix works by blocking access to the Microsoft Indexing Server with URLs bigger than 200 characters (that should be very rare in normal operation). This server is enabled by default on Microsoft IIS servers, but is often not used. If the service is needed, the Web server should be patched without using this fix, otherwise legitimate access will be blocked.

This security enhancement utilizes Check Point's high-performance TCP Streaming technology. This provides the optimal combination of security and performance, by protecting Web servers from infection while minimizing performance impact on the gateway.

Instructions
Note: This procedure should be only performed on the Management Server or on a standalone gateway.

Enabling fwurl_code_red
 

1. Stop the FireWall services by running fwstop. Alternatively, use fwstop -proc on Unix platforms.
    
2. Backup your existing objects.C file to objects.bak in the $FWDIR/conf directory.
    
3. Delete all objects.C.* files.
    
4. Open objects.C in a text editor.
    
5. In the :props section, add the fwurl_code_red property as displayed above. (Traditionally, Check Point has used (true), but in the 4.1 SP5 release notes, they recommend (1) for the first time. Logically, both should work.)
    

:fwurl_code_red_URL_depth (XX)

By default, the entire URL is scanned for the Code Red pattern ".ida?". You can limit the depth of this search by adding this property to the :props section of objects.C:
As a result only the first XX bytes of the URL will be scanned.

For more information on Code Red, see:

• http://www.microsoft.com/technet/security/bulletin/MS01-033.asp
   
• http://www.cert.org/advisories/CA-2001-13.html
   
• http://www.securityfocus.com/bid/2880

:http_allow_content_disposition (true) (4.1 SP5)
 

NOTE: The release notes for 4.1 SP5 incorrectly list this property as http_content_disposition_allowed.

For information on when you would want to use this property, see Resolution 9744

URI resources can be used to filter specific file extensions (e.g. *.VBS.*.EXE,*.ZIP). The filename and file extension in an HTTP request may not reflect the actual filename and extension of the file downloaded if the web server is using the "Content-Disposition" HTTP header. This can be used by malicious servers to let users download forbidden files.

In this service pack and in future releases, VPN-1/FireWall-1 by default will always filter any Web pages that are sent using the "Content-Disposition" header. As some legitimate Web servers may use this header, it is possible to turn off this behavior by enabling the following general property: http_allow_content_disposition (true).
 

:http_log_every_connection (true)

This will log all sites that an HTTP authenticated user visits.
 

:http_buffers_size (32768) (New for 4.1 Base)
Increases the HTTP security server's buffer size
 

:http_sup_continue (true) (New for 4.0 SP5 and 4.1 SP1)

Enables the HTTP Security Server to support the HTTP 1.1 CONTINUE command.
 

:http_force_down_to_10 (true) (New for 4.0 SP5 and 4.1 SP1)

Forces the HTTP Connection down to version 1.0. Needed when working with CVP servers.
 

:http_avoid_keep_alive (true) (New for 4.0 SP5 and 4.1 SP1)

Forces the HTTP Security Server to ignore the "Keep Alive" directive in HTTP 1.1, needed when working with CVP servers.
 

:http_cvp_allow_chunked (true) (New for 4.0 SP3)
:http_weeding_allow_chunked (true)
:http_block_java_allow_chunked (true)
:http_allow_ranges (true)

Allows the HTTP Security Server to handle downloads that occur as byte ranges, used in HTTP 1.1.
 

:http_allow_double_slash (true) (New for 4.0 SP5)
:http_use_default_schemes (true)

Enables the HTTP Security Server to accept double slashes ('//') in a substring of a URL. In order to allow this, the security server will define a set of schemes that it will accept.

The default set includes prospero, gopher, telnet, finger, mailto, http, news, nntp, wais, file and ftp. You may define new schemes, which will be ADDED to this set.

In order to define additional schemes also add:

:scheme ("scheme_name:")

Where scheme_name is the name of the new scheme. For example, to define http, you would add :scheme ("http:")
 

:http_use_host_h_as_dst (true) New for 4.0 SP5
After authentication with Partially Automatic Client Authentication, the user is normally redirected to the site's IP address instead of the name. This causes problems for sites with cookies and the like. With this property set to true, the user will instead be redirected to the host as shown in the HTTP "host" header (which reflects the host that is being accessed).
 

:http_disable_content_enc (true)
:http_disable_content_type (true)
:http_allow_ranges (true) (New for 4.1 SP2)
This is necessary to support compressed encoding types per Resolution 3471.
 

:http_max_url_length (n)
:http_max_header_length (n)
This prevents the firewall from truncating long URLs, which can cause pages not to load and cookies not to be written.
 

:http_max_auth_redirected_num (n)
The number of redirected connections FireWall-1 can support for Partially Automatic Client Authentication.
 

:http_check_request_validity (false)
:http_check_response_validity (false)
This allows Internet Explorer to browse URLs that contain characters not between ASCII 32 and 127 by disabling the set of checks that the firewall performs on the request and response headers.
 

SMTP Security Server

:smtp_composite_encoding (true) (4.1 SP3 and above)

Allows the SMTP Security Server to support composite MIME types, i.e. it eliminates the error message "Forbidden encoding on composite mime type"
 

:smtp_rfc821 (false)

Configure the SMTP Security Server to work with non-compliant RFC821 mail servers.
 

:smtp_max_global_headers_size (xxx) (New for 4.1SP3)

Set the SMTP mail header buffer size in KB (Default 8KB).

:smtp_encoded_content_field (true)
This prevents incorrect parsing of headers by the firewall?s MIME-stripper, which causes attachments to be stripped and replaced by a numbered ATT file containing the text <>. This mainly occurs with MS Office files whose file names contain non-English encoding (German, Swedish, Hebrew, etc.).

 

:mdq_timeout_to_cvp (n)
This allows you to increase the number of seconds used for the mail dequeuer timeout. The default is forty seconds, which is often too short for larger emails to be scanned.
 

Authentication

It is possible to configure FireWall-1, when using partially automatic client authentication, so that the redirection sent to the client will be done according to the `host` header and not according to the destination IP.

:radius_ignore (255) (New for 4.0 SP4)

When handling RADIUS authentication FireWall-1 verifies that the RADIUS attributes are such that appear in the RFC. If your system uses non-standard RADIUS attributes, you can force FireWall-1 to ignore these attributes. In order to do so you must add to objects.C an appropriate line for each such attribute, giving its ID. The example is for an attribute with ID 255.
 

:automatically_open_ca_rules(true) (Only applies to 3.0)

Allows normal User or Session Authentication rules to automatically perform a standard sign on for Client Authentication Rules. In 4.0 and later, this is replaced by "Partially Automatic" and "Fully Automatic" Sign-On for Client Authentication.
 

:prompt_for_destination (true)

If this is true and there are User Authentication rules, a user will be promoted for their final destination when they telnet to the firewall.
 

Policy Verification

:fw_light_verify (true) (New for 4.0 SP3)

With this Service Pack you may add a property which will enable light policy verification, which means verification of each rule separately but no cross rule verification. This option may decrease the policy installation time of policies containing hundreds of rules.
 

FTP

:ftp_transparent_server_connection (true) (New for NG FP2)

This tells the security server to revert to the 4.1 behaviour in regards to proxying connections that go through the FTP Security Server. See Resolution 14620.

Note that if you manually enter this property into objects_5_0.C, it should go under the firewall object definition under :firewall_properties instead of the global properties.
 

:new_ftp_interface (true)

This enables one to establish an FTP connection through two firewalls which require authentication and provides a slightly nicer interface to authenticated FTP. See Resolution 1645 for more details.

 

Telnet/Rlogin

:telnet_transparent_server_connection (false) (New for NG FP2)
:rlogin_transparent_server_connection (false) (New for NG FP2)

This tells the security server to revert to the 4.1 behaviour in regards to proxying connections that go through the Telnet or Rlogin Security Server. See Resolution 14620.

Note that if you manually enter this property into objects_5_0.C, it should go under the firewall object definition under :firewall_properties instead of the global properties.
 

SecuRemote

:force_udp_encapsulation_gw (true) (4.1 SP4 and above)

This property tells FireWall-1 to force UDP encapsulation on the client.

:sr_dont_check_crl (true)

This will turn of the CRL checking on SecuRemote. This property is downloaded to the Client (as part of the manager set), and SecuRemote will not check CRLs during IKE negotiation.

:userc_NAT (true) # for FWZ
:userc_IKE_NAT (true) # for ISAKMP

Enables 4.0 or later SecuRemote clients passing through address translation to establish a VPN with a 4.0 or later packet filter module. This works with Static NAT and Pool NAT fine. For Dynamic NAT, it will only work is there is a single SR client behind each hiding IP address.

:fwz_encap_mtu (1)

When using SecuRemote with FWZ Encapsulation, versions 3.0 and 4.0 (EA) are incompatible. Both combinations - SecuRemote 3.0 with FireWall-1 4.0, and SecuRemote 4.0 with FireWall-1 3.0 have the same problem. It occurs only with packets of a very specific size (total size close to MTU).

SecuRemote 4.0 (EA) and FireWall-1 4.0 (EA) fix the problem in re-assembling, but will not interoperate with version 3.0. FireWall-1 4.0 SP-1 and SecuRemote 4.0 build 4003 now fragment in a backward compatible way (with all versions)

This problem has been fixed with SecuRemote 4.0 Build 4003.

:desktop_build_number (build_number)
:desktop_sw_url_path ("URL")

These properties allow you to specify the minimum Secure Client build number that is allowed to connect to your encryption domain. The URL is the location which the user can access the updated Secure Client software.

 

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

(New for 4.1 SP2)

Instead of the props section, look for the section in your $FWDIR/conf/objects.C that has your firewall or gateway cluster
object and add this to the object definition.

This is required if you wish to take advantage of the UDP Encapsulation mode for Secure Client 4.1 SP2 and later. Instead of adding this to the props section, you add this to the seciton containing your gateway object. This is covered in the Secure Client 4.1 SP2 release notes. Note that if you are using UDP Encapsulation with Gateway Clusters, it is recommended you upgrade to FireWall-1 4.1 SP3 or later and implement the changes in the Encryption section above.

The reference name assumes you have a service called VPN1_IPSEC_encapsulation defined. If not, you must either create it or change this section to match the name you have given it.

 

:resolve_multiple_interfaces (true)

This property, added to the firewall object definition in $FWDIR/conf/objects.C, will enable a SecuRemote or Secure Client platform to be able to try to establish a VPN with more than one network interface of the firewall.

To configure SecuRemote to try multiple interface resolution on gateways, the following conditions must be met:

1. The SecuRemote and the gateway must be running Version 4.1 SP2.
    
2. This feature applies only to IKE key exchange.
    
3. There is no High Availability between interfaces. Therefore, a SecuRemote client which remains at the same IP address will not be able to switch to another interface if the interface it works with is down.
    
4. Topology must be downloaded from the canonical IP.
    
5. Policy Server's logon must be "implicit" AND communication with the Policy Server must be encrypted.

Miscellaneous