VPN-1 NGX Architecture SmartConsole and SmartDashBoard SmartCenter Server Security Gateway How VPN-1 NGX Works The

INSPECT Engine Distributed Deployments SVN Foundation Secure Internal Communications (SIC) SmartConsole Components SmartDashboard SmartView Tracker SmartView Monitor Evantia Reporter Lab 3: NGX Distributed Installation Lab 4: SecurePlatform Gateway Installation

Packet filter
IP check TCP/UDP check Data

Characteristic of packet filters
y Advantages y Much Cheaper than firewalls y Faster than Stateful Inspection and apllication proxies y Good for perimeter access control y Disadvantages y Difficult to manage Access Control Lists (ACLs) y Limited to IP and TCP/UDP/ICMP header information checking and that may be basic y Logging usually only to a syslog daemon y Very easy to abuse to open ports with tunneled protocols

Application Proxy
IP check TCP/UDP check Data check

Characteristic of application proxy
y Advantages y Considered to be the most secure method of controlling network connections y Works at the application level and fully understands the protocol being used y Good logging of network and protocol information y Disadvantages y Can be the bottleneck with high bandwidth connections y Can be slow and in not for high speed data streams, like VOIP y Proxies may only be available for TCP services y The number of proxies supplied is limited y Each connection requires it s own process, can be CPU and memory intensive y May be exposed to low level OS and TCP/IP stack compromises

Stateful Inspection
y Check Point VPN-1/Firewall-1 Stateful Inspection has the ability to extract

information from any part of the IP packet to control the network session.



can do

The Inspection Engine uses a programming language called INSPECT to create scripts to handle different protocols. Protocols may not all receive the same degree of inspection. Every release and service pack has extended the protocol inspection abilities of the Inspection Engine.

Characteristics of statefull inspection
y Advantages y Faster than application proxies y Can inspect the whole packet y Can understand protocol details y Easy to administer with GUI from end y Provides good logging y Adds virtual session information to UDP and ICMP y Disadvantages y Less secure than application proxies y Slower than packet filtering routers y Administrators can be flooded into thinking firewall administration is easy with simple GUI y Too easy to add services that need time for further review y Provides little or no better protection than a packet filter for some protocols

Distributed solution

SmartCenter Server Security Gateway Check Point Three-Tier Architecture

Inspect Modul Location

Inspect Engine Dynamic State Tables

Security Gateway

Inspect Modul Characteristic
y Check Point Firewall-1 s Stateful Inspection architecture uses a

unique, patented INSPECT Engine, which enforces Security Policies on the Security Gateway on which they reside. The INSPECT Engine looks at all communication layers and extracts only the relevant data, enabling highly efficient operation, support for a large number of protocols and applications, and easy extensibility to new applications and services.

y When installed on a gateway, the INSPECT Engine controls traffic

passing between networks. The INSPECT Engine is dynamically loaded into the OS kernel, between the Data and Network Layers (layers 2 and 3). Since the Data Layer is the actual NIC and the Network Layer is the first layer of the protocol stack, the INSPECT Engine is positioned at the lowest software layer. By inspecting at this layer, VPN-1 NGX ensures that the INSPECT Engine intercepts and inspects all inbound and outbound packets on all interfaces.

Distributed solution
SmartConsole Router SmartCenter Server

Security Gateway (Solaris)


Router Intranet

NFS Server

Security Gateway (Windows)

Security Gateway (Appliance)

Databaze Server


SVN CPShared
SVN Foundation Check Point SVN Foundation (CPShared) is the Check Point operating system that is integrated with every Check Point product. SVN Foundation includes:
y SIC (Secure Internal Communications) y Check Point Registry y CPShared daemon y Watch Dog for critical services y Cpconfig y License utilities y SNMP daemon

SIC Secure Internal Communications
Check Point s Secure Internal Communications (SIC) enhances network security, by securing administrative communication among NGX components. COMMUNICATION COMPONENTS Communication is secured among Check Point SVN components, such as:
y y y y

SmartCenter Servers SmartConsole Security Gateways OPSEC applications

SIC also substantially eases the administration of large installations, by reducing the number of configuration actions. A simple SIC initialization procedure for each component is all that is needed.

SIC certificates
SECURITY BENEFITS SIC allows Security Administrators to confirm that a SmartConsole connecting to a SmartCenter Server is authorized to connect to that SmartCenter Server. SIC also allows Administrators to confirm that the security Policies installed on a Security Gateway come from an authorized SmartCenter Server. SIC ensures data privacy and integrity are maintained. SIC CERTIFICATES SIC for Check Point SVN components uses Certificates for authentication, and standards-based SSL for encryption. SIC Certificates uniquely identify Check Point enabled machines, or OPSEC, applications, across the Check Pont NGX system. Certificates are created by the Internal Certificate Authority (ICA) on the SmartCenter Server. The ICA creates Certificates for communicating components managed by the SmartCenter Server. One Certificate is created for each physical machine. VPN Certificates, such as those used for IKE, are used for VPNs, and should not be confused with SIC Certificates, used for securing internal network communication.

Communication of SmartCenter with modules

delivers certificates to the Check Point Modules

SmartCenter Server

CERTIFICATE Intranet Security Gateway

The ICA on the SmartCenter Server



SmartCenter and SmartConsole Communication
SIC BETWEEN SMARTCENTER SERVERS AND CLIENTS\ For SIC communication between a SmartCenter Server and SmartConsole, the SmartConsole must be defined as being authorized to use the SmartCeneter Server. When invoking the SmartDashboard on the SmartConsole.
y The Security Administrator is asked to identify himself y The Administrator specifies the IP address of the SmartCenter Server y The SmartCenter Server verifies that the client s IP address belongs to an authorized

SmartConsole y The SmartCenter Server sends its Certificate

Upon authenticating the SmartCenter Server s Certificate, the security Administrator is asked to verify that the right SmartCenter Server is connected. This verification is done using the SmartCenter Server fingerprint, a text string that represents a hash value computed from the SmartCenter Server Certificate. Once the Administrator approves the identity of the SmartCenter Server, the Administrator s name and password are sent securely to the SmartCenter Server. The Administrator s username and password are used to identify and authenticate the user.

Security Policy Editor tab S art efece ab VPN Manager Policy Editor ab esktop Security Policy Editor ab

Net ork dress ranslation Policy Editor ab

etails of the objects selected in the Objects ree are displeyed in the objects list

Central Licensing
Check Point uses two deployment schemes for license management: central licensing and local licensing. The table below the identifies the features unique to each scheme:
Licensing Scheme Central licensing Considerations ‡ Central licensing is Check Point s recommended license-management strategy. Central licensing stores all licenses in a license repository on the SmartCenter Server ‡Licenses are installed on the machine they are assigned to, via SmartUpdate ‡Licenses are not tied to the IP address of the system they are installed on, and can be reassigned to resources as necessary ‡Central licensing is an ideal solution for distributed installations

Local Licensing
Check Point uses two deployment schemes for license management: central licensing and local licensing. The table below the identifies the features unique to each scheme:
Licensing Scheme Local licensing Considerations ‡ Check Point s local licensing installs specific licenses on specific machines ‡Local licenses can be installed using SmartUpdate or installed locally, via cpconfig or the Command Line Interface (CLI) ‡Local licenses are tied to the IP address of the machines on which they are installed. If these addresses change, new licenses must be generated ‡Local licensing is a suitable solution for standalone installations

y Check Point Software s Inspection Module tracks and

acts on both state and context information, to create a powerful security system y SIC enhances network security, by securing administrative communication among NGX components

Security Policy
The security Policy is an essential part of NGX administration. Without a welldefined Security Policy, VPN-1 NGX is limited in its ability to be an effective security solution. Whenever the traffic is inbound or outbound, directed to the DMZ, to and from remote locations, or between corporate partners, the Security Policy is a set of rules that defines your network security. The following aspects of VPN-1 NGX are essential to creating and maintaining network security: y Security Policy properties y Rule Base y Fields specific in the Global Properties setup screens This chapter also provides basic command-line options for administering the Security Policy. These options include the NGX cpstop and cpstart commands. And you will learn how to use object cloning, Database Revision Control, and Policy Package Management, to decrease the burden of management when working with rules and objects.

Security Policy
y What is Security Policy?

The Security Policy is a set of rules that defines your network security. In VPN-1 NGX, a Security Policy is defined using a Rule Base, a collection of individual rules that make up your Security Policy. Without a well-defined Security, NGX is limited in its ability to be en effective security solution. Rules are comprised of network objects, users, groups, services, resources and actions. Once a Rule Base is defined, NGX provides the ability to distribute it to network.
y Security Policy Considerations

Before creating a Security Policy for your system, answer the following questions: 1. Which services, including customized services and sessions, are allowed across the network? 2. Which user permissions and authentication schemes are needed? 3. Which objects are in the network? Examples include gateways, hosts, networks, routers and domains.

Machine boots up

IP Forwarding disabled, Default Filter loads

Interfaces configured

P -1 Pro egins loading

SmartConsole Clients connected Trust Established

I ITILAL POLICY Fetched from Local Module

Security Policy Installed by Administrator

The initial Policy is enforced until a policy is installed, and is never loaded again. In subsequent boots, the regular policy is loaded immediately after the Default Filter. There are different Initial Policies for stand-alone and distributed setups. In a stand alone configuration, where the SmartCenter Server and VPN-1 Pro module are on the same computer, the Initial Policy allows CPMI communication only. This permits SmartConsole clients to connect to the SmartCenter Server.

Spoofing is a technique where an intruder attempts to gain unauthorized access by altering a packet s IP address. This alteration makes it appear as thought the packet originated in the part of a network with higher access privileges. NGX has a sophisticated anti-spoofing feature that detects such packets, by requiring that the interface on which a packet enters a gateway corresponds to its IP address. Anti-spoofing verifies that packets are coming from, and going to, the correct interfaces on a gateway. It confirms that packets claiming to be from the internal network are actually coming from the internal network interface. It also verifies that, once a packet is routed, it is going through the proper interface.

Antispoofing Configuration
Not fi If y c se t is efi e f r t is i terface ti , t ere ill e a ti-s fi Net or efi ed t e i terf ce IP d Net s VPN-1 NGX ill calc late t e t l y, ase t e sta ar IP a ress c ve ti s. ecific Specify t e ject ( s ally a et et r jects) e i t is i terface. r ject r r p f

Order of Execution Rules
Before you can define Security Policy properties, you must consider Rule Base order. VPN-1 NGX inspects packets by comparing them to the Security Policy, one rule at a time. For this reason, it is important to define each rule in the Security Policy in thr appropriate order. VPN-1 NGX enforces the Rule Base in the following order: 1. IP spoofing/IP options 2. Network address translation (NAT) 3. Security Policy First Rule 4. Administrator-defined Rule Base 5. Security Policy Before Last Rule 6. Cleanup Rule or Security Policy Last Rule

Basic Rules Cleanup Rule
VPN-1 NGX follows the principle, That which is not expressly permitted is prohibited. VPN-1 NGX drops all communication attempts that do not match a rule. The only way to monitor the dropped packets is to create a Cleanup Rule that logs all dropped traffic. The Cleanup Rule, als0 known as the None of the above rule, drops all communication not described by any other rules, and allows you to specify logging for everything being dropped by this rule:

Cleanup Rule

For the cleanup rule to be effective, be sure to add all other rules above the Cleanup Rule. The last rule in the Rule Base should always be the Cleanup Rule.

Basic Rules Stealth Rule
To preve t a y sers from connecting irectly to t e Gate ay, you s oul a a Stealt to your ule ase. Protecting t e Gate ay in t is manner ma es t e Gate ay transparent to t e net or . The Gate ay ecomes invisi le to users on the net or .

Stealth Rule

In most cases, the Stealth Rule should be placed above all other rules. Placing the Stealth Rule at the top of the Rule Base protects your Gateway from port scanning, spoofing, and other types of direct attacks. Connections that need to be made directly to the Gateway, such as Client Authentication, encryption and Content Vectoring Protocol (CVP) rules, always go above the Stealth Rule.

Implicit rules
Implicit rules are defined by VPN-1 NGX to allow certain connections to and from the Gateway with a variety of different services. The gateway enforces two types of implicit rules that enable the following: y NGX control connections y Outgoing packets

Command Line
This section provides basic command-line options for administering the Security Policy.
Command cpstart cpstop cprestart cplic print Function
Launches all Check Point applications running on a system, except cprid, which is invoked on boot and runs independently Kills all Check Point applications running on a system, except cprid, which is invoked on boot and runs independently Issues a cpstop, immediately followed by a cpstart Prints the details of NGX licenses; the syntax for this command is, as follows: cplic print [local management] [remote host]

Cpstart loads VPN-1 NGX, and starts the following processes: y NGX daemon (fwd) y SmartCenter Server (fwm) y NGX SNMP daemon (snmpd) y Authentication daemons

cpstop kills the following (fwd) y NGX daemon (fwd) y SmartCenter Server (fwm) y NGX SNMP daemon (snmpd) y Authentication

f ,f
fw ver [-h] fm ver [-h]



Display version Installs policy on targets Uninstalls Policy on specific targets Download database Fetches last Policy Display protected hosts Display logs Create new log file when old log is moved Exports log to ASCII file Displays current Policy name and date of installation Uninstalls current Policy of local Gateway

fwm load [opts] [filter-file/rule base] targets fwm unload [opts] targets fw dbload [opts] targets fw fetch targets fw lichosts fw log [-h] fw logswitch [-h] Fw logexport [-h] fw stat fw unloadlocal

Rule Base Optimization
Best practices to apply when designing your NGX Rule Base include the following: ‡ Keep it simple. If more than 50 rules are used, the Security Policy becomes hard to manage. Security Administrators may have difficulty determining how rules interact ‡ Comment each rule. Documentation eases troubleshooting , and explains why rules exist. This assists when reviewing the Security Policy for errors and modifications. ‡ Add a Stealth Rule and Cleanup Rule first to each new Policy Package. A Stealth Rule blocks access to the NGX Gateway. Using an Explicit Drop Rule is recommended for logging purposes. ‡ Limit the use of the Reject action in rules. If a rule is configured to Reject, a message is returned to the source address, informing that the connection is not permitted. ‡ Place the most restrictive rules at the top of the Policy, then proceed with the generalized rules further down the Rule Base. If more permissive rules are located at the top, the restrictive rule may not be used properly. This allows misuse or unintended use of access, or an intrusion, due to improper rule configuration. ‡ Restrict access to VPN-1 NGX to Security Administrators only. Remove, or severely restrict, remote access to Security Gateways.

The Rule Base and objects database of a Security Gateway are always changing. Even in a static network, system will be reassigned to the other segments, types of traffic allowed or disallowed to resources and networks will change, and users will be moved from one group to another. Making these changes can be simple or complicated. A Security Administrator needs a method for backing out of a rule or object change, and also needs a way to incrementally adjust the configuration of her Security Gateway. VPN-1 NGX provides two utilities for making these backups and incremental changes:
y Database Revision Control y Policy Package Management

When use DB Revision Control
The following table discusses the unique advantages of these two tools:
Policy and Database Management Utility Database Revision Control Considerations ‡ Database version consists of all Policies, objects and users configured, including settings in SmartDefence and Global Properties ‡ Ideal management utility for stand-alone deployment, or distributed with a single Gateway deployment ‡ Configurable to automatically create new database version on Policy installation Policy Package Management ‡ Policy Package including only Security, NAT, and Desktop and QoS Policy installation ‡Ideal management utility for a distributed installation with multiple Security Gateways: specific Policies created for specific Security Gateways

y A Security Policy is a set of rules that defines your internal network s security y In VPN-1 NGX, the Security Policy is defined by creating a Rule Base in y y y y y y

SmartDashboard When defining a Policy s global properties, you must consider Rule Base order Defining and installing a Policy is vital to protecting your network cpstop and cpstart are NGX commands you can use to administer Policies Object cloning creates and clones objects and their property configurations Database Revision Control allows you to test new Rule Base and object configuration, or revert to earlier configurations for troubleshooting Policy Package Management allows you to administer distributed installations with multiple Security Gateways

Monitoring Traffic and Connection
SmartView Tracker Blocking Connections Terminating Active Connections Lab8: Blocking Intruder Connection SmartView Monitor Lab9: Setting Up Suspicious Activity Rules Lab10: Checking Status in SmartView Monitor Eventia Reporter Eventia Reporter Database Management

Communication Monitoring
Use monitoring tools to track, monitor, and account for all connections logged by Check Point components: Use SmartView Trackeer to display information about traffic controlled by NGX, given a variety of scenarios. 2. Use SmartView Tracker to block connections, given evidence of a potencial intrusion or attack. 3. Use SmartView Monitor to display information about an NGX deployment, given a variety of scenarios. 4. Learn how Eventia Reporter delivers a user-friendly solution for monitoring and auditing traffic.

SmartView Tracker
SmartView Tracker gives you control over the information displayed in the log file, which records the events that, according to the Rule Base or Global Properties, are to be logged. Every event causing an alert, and certain important system events (such as Security Policies being installed or uninstalled on a Security Gateway), are also logged. The format of log entries requested by a rule is determined by the log type specified in the rule. You can select the log entries and data fields to display. SmartView Tracker also you to navigate the log file. The Check Point OPSEC framework provides the Log Export Application (LEA) API for exporting NGX log data to other applications, such as spreadsheets or databases. Reporting and event-analysis applications are available from multiple OPSEC partners, and from the SmartView Reporter.

SmartView Monitor
SmartView Monitor is a high-performance network and security-analysis system that helps you easily administer your network, by establishing work habits based on learned system-resource patterns. SmartView Monitor provides a single, central interface for monitoring network activity and performance of Check Point applications.

Suspicious Activity
SmartView Monitor enables the integration of a suspicious-activity monitoring program that is used to modify access privileges, upon detection of any suspicious network activity. This detection is based on the creation of Suspicious Activity rules. Suspicious Activity rules are security rules that enable the Administrator to instantly block suspicious connections that are not restricted by the currently enforced Security Policy. These rules can be applied immediately, without the need to install a Policy.

Monitoring Alerts
The information SmartView Monitor gathers includes status information about: y Check Point Gateways y OPSEC Gateways y Network Objects Alerts are sent to highlight problematic Gateways, and are displayed in SmartView. These alerts are sent:
y If a certain rules or attributes that are set to be tracked as alerts are matched by

a passing connection. y If system events, also called System Alerts, are configured to trigger an alert when various predefined thresholds are surprased Alerts provide real-time information about vulnerabilities to computing systems and how they can be eliminated. Check Point alerts users to potential threats to security of their system, and provides information about how to avoid, minimize or recover from damage.

Eventia Reporter
Eventia Reporter GUI

Eventia Reporter implements a Consolidation Policy, which goes over your original raw log file. The Consolidation Policy compresses similar events and writes the compressed list of events into a relational database (the Eventia Reporter Database). The Eventia Reporter Database enables quick and efficient generation of a wide range of reports. With the Eventia Reporter Consolidation Policy, Rule Base are defined through SmartDashboard and use network objects. And just as Check Point rules determine whether to store or ignore the logs that match them.

Eventia Reporter Server
The figure below illustrates the Eventia Reporter consolidation process, defined by the Consolidation Policy:
Security Gateways Eventia Reporter Server

Log Consolidator Engine

SmartCenter Server

Eventia Reporter Database

Eventia Reporter Consolidation Process

Eventia Reporter Server
Security Gateways Eventia Reporter Server
Log Consolidator Engine


SmartCenter Server


Reads Logs
Eventia Reporter Database



Eventia Reporter Client

Report Request

Eventia Reporter Database

Report Status

Eventia Reporter Server Report Creation

Eventia Reporter Server
Log Entry


Does the log match a Specific Rule?
Yes No




oes the log match a onsolidation ule?

Ignore: No record of Log Entry will be saved

Store: Consolidate by interval & logs fields

Store: Values of relevant fields saved As Is

DB Consolidation
When a log matches a Consolidation Rule, it is either ignored or stored:
y If it is ignored, no record of this log is saved in Eventia Reporter, so the

log s data is not available for report generation. y If it is stored, the log is either saved as is (so all log fields can later be represented in reports), or consolidated to the level specified by the rule. Because of dynamic nature of DHCP address distribution, there is no guarantee that consolidation of old log files will produce correct address name resolving. When DHCP is in use, consolidating log files close to the time of their creation will improve address-resolving accuracy.

All reports results are displayed on-screen and saved to the Eventia Reporter Server. By default, the report is saved in HTML output in an index.html file, and in CSV format in a tables.csv file. The HTML file includes descriptions and graphs, but the CSV file contains only report-table units, without a table of contents, descriptions, or graphs. Tables.csv is provided to enable convenient table import to applications, such as Excel. Before generating a report, determine whether you want it to be saved or sent to additional or different targets. For example, when you generate a user-activity report, you may wish to make it available to all managers in your organization, by sending them the output via e-mail or by placing output on your intranet.

DB Modification
It is possible to change the Eventia Reporter Database settings by modifying the my.ini file, located in the $RTDIR\Database\conf\my.cnf directory. This can be done by using the UpdateMySQLConfig utility. Note that before using this utility, you must stop all Eventia Reporter services by running rmdstop. Using UpdateMySQLConfig creates a backup of the database configuration file. UPDATEMYSQLCONFIG There are a number of factors that can improve performance of the Eventia Reporter¶s database. Most of these factors can be tuned by using the UpdateMySQLConfig utility. RAM ± The database needs substantial amounts of RAM to buffer data up to 1200 MB. This can be set running UpdateMySQLConfig ±R. Temporary directories ± The database uses temporary disk space to perform intermediate operations (such as sorting and grouping), and may require a few GB to generate large reports. Generating a substantial report may fail to execute the required SQL query, if there is not enough disk space for the temporary directory. The temporary directory can be defined running UpdateMySQLConfig ±T. Log files ± The database log files ensure that that changes persist, in the event of a system crash. Place these files on a device that is separate from the database¶s data files, running UpdateMySQLConfig ± L. Database data files ± These files should be put on large, fast disk. The database¶s data files can be placed on several disks. Run UpdateMySQLConfig ±A to add a new file to the set of database files, and run UpdateMySQLConfig ±M to move an existing file to a new location. Do not place database files on a network drive, since performance may suffer, and in some instances the database will not work.

DB Maintaining
The Log Consolidator process continuously add new records into the database as they are generated from the NGX Gateway. Eventually, the space allocated for the database will fill up. Typically, users can manually archive or delete older, less pertinent records from the database, to provide space for the newest records. Automatic Maintenance performs this process automatically. With Automatic Maintenance, the user selects a maintenance operation (whether it is deleting records or archiving them to an external file), and specifies high and low watermarks to trigger when Automatic Maintenance should occur. HIGH/LOW WATERMARKS The High Watermark value represents the percent of space that can occupy the database, and/or the age of database records (that is, how many days old the records are). When the database occupies too much space or the records are older than the specified age, conditions are right to trigger an Automatic Maintenance operation. The High Watermark values are checked once a day. If the percent of space or age of database records is higher than the assigned values, the Automatic Maintenance operation is triggered.

Backup DB
The Eventia Reporter Database consists of a set of files that can be copied, compressed, or backed up. Backup files require the same disk space as the original files. It is highly recommended to save backup copies of the Eventia Reporter Database files, which can later be used to recover from unexpected database corruption, Back up, as follows:
1. 2.


Stop the Eventia Reporter services, by running rmdstop. From the Eventia Reporter Database directories, copy the entire data directory tree (as specified by the datadir parameter in the my.ini file) to the backup location. (You may compress the directories to save disk space). Copy any database and log files that may have been moved to a different location, using the UpdateMySQLConfig utility. Restart the Eventia Reporter services, starting with the Check Point Reporting Database Server service: Windows Start the Check Point Reporting Database Server service. Solaris Run rmdstart.

y The SmartView Tracker allows you to view entries in

the log file. y SmartView Monitor is a high-performance network and security analysis system that helps Security Administrator easily administer their networks. y Each entry in the log file is a record of an event that, according to a Security Policy, is to be logged. y Eventia Reporter delivers a user-friendly solution for monitoring and auditing traffic.

SmartDefense Introduction
Check Piont Software s SmartDefense introduces a new category of Internet security products: active-defense solutions. SmartDefense actively protects organizations from known network attacks and entire categories of emerging or unknown attacks, using intelligent security technology. SmartDefense blocks attacks by type and class, using Check Point s Stateful Inspection and Web Intelligence technologies. SmartDefense provides a single centralized console, delivering realtime information on attacks, as well as attacks detections, blocking, logging , auditing, and alerting. SmartDefense, working with Storm Centers, allows Security Administrators to gather reports on real-time threats to network security.

SmartDefense capabilities fall into three categories, with some overlap of defense between categories: y Defenses against attacks y Implicit defenses y Abnormal-behaviour analysis DEFENSES AGAINST ATTACKS Defenses against attacks include the following: y Denial-of-service attacks y TCP/IP attacks y Web and application vulnerability y Network probing y HTTP worms y Microsoft Network specific vulnerability y Protocol vulnerability y Buffer-overflow attacks IMPLICIT DEFENSES Implicit defenses prevent information about network entities reaching the Internet, where this information could be misused. For example, when an internal server establishes a TCP connection, it sends successive Sequence Numbers (SNs) of the first byte within the connection s packet. These SNs can be used to identify the OS being used, to exploit any known vulnerabilities. SmartDefense ISN Defender uses fingerprint spoofing to replace SN fingerprint with another, making it impossible for external clients to find out which OS is actually being used by internal servers.

Abnormal behaviour
SmartDefense provides reporting and analysis of patterns of network behavior, by analyzing logs sent to SmartCenter Server by NGX gateways. If a suspicious pattern is detected, the Administrator can be alerted to the activity, and track it via a log. An example of this is Successive Events detection. An activity might be considered suspicious by an Administrator, if it repeats more frequently than a configured threshold within a given time period.

Active defense
Active defense is the process of providing in-line security to prevent both known and unknown attacks, before they penetrate the infrastructure. SmartDefense is an active defense product, based on Check Point s Stateful Inspection and NGX technologies. Using these technologies, it is possible to allowing legitimate traffic to pass.

DoS attacks
Denial-of-service (DoS) attacks are aimed at disrupting normal of a service, or depriving users or organizations of resources they would normally expect to have. The DoS attacks described in this chapter exploit bugs in operating systems, to remotely crash machines.
DoS Tear rop Description Some implementations of the TCP/IP fragmentation reassembly code do not properly handle overlapping IP fragments. Sending t o IP fragments, the latter entirely contained inside the former, causes a server to allocate too much memory and crash. Teardrop is a idely available attac tool that exploits this vulnerability. ith Smart efense, this attac ill be bloc ed and logged as Virtual defragmentation error: verlapping fragments. eath Ping of eath is a malformed Ping request that crashes the the target computer. An attac er sends a fragmented Ping request that exceeds the maximum IP pac et size (64 B). Some operating systems are unable to handle such requests, and crash. ith Smart efense, this attac s ill be bloc ed as Virtual defragmentation error: Pac et too big. Some implementations of TCP/IP are vulnerable to pac ets that are crafted in a particular ay, such as a SYN pac et in hich the source address and port are the same as the destination (that is spoofed). AND is a idely available attac tool that exploits this vulnerability.

Ping of


L3 attacks
SmartDefence allows you to enable a comprehensive sequence of Layer 3 tests for the IP and ICMP protocols.
Packet Sanity

This option performs several Layer 3 and Layer 4 checks. These include verifying packet size. UDP and TCP header lengths, dropping IP options, and verifying the TCP flags. This test is mandatory, but you can configure whether logs will be issued for offending packets. Ping (ICMP) echo request) is a protocol used to check whether a remote machine is running. A request is sent by a client, and a server responds with a reply echoing the client s data. This option allows you to limit the maximum requested data-echo size. This should not be confused with Ping of Death, in which the request is malformed. An attacker might break the data sections of a single packet into several fragmented packets, in an attempt to conceal known attacks an exploits. Without reassembling the fragments, it is not always possible to detect such an attack. Network quota enforces a limit upon the number of connections that are allowed from the same source IP, to protect against Denial of Service attacks. When a source exceeds the number of allowed connections, Network Quota can either block all new connection attempts from that source or simply track the event.

Max Ping Size

IP Fragments

Network Quota

ISN attacks
Test ISN Spoofing Description The first done when a TCP connection is established is to synchronize numbers (called sequences ) between a client and server. This is performed in a process called the threeway handshake. In this process, a client notifies a server about the sequences for the client side of connection, and the server notifies the client about the sequences for the server side of the connection. The sequence chosen during the three-way handshake is called the Initial Sequence Number (ISN). While the TCP/IP standard clearly defines how the ISN is to be chosen, the algorithm described there suffers from high predictability of the next initial Sequence Number that the server will use. This gives rise to an attack called ISN guessing, in which an attacker can use that information to create blind TCP connections from a spoofed source address. For that reason, many operating systems today use random numbers for their ISNs. However, these numbers are often not random enough, and can be guessed in a rather small number of attempts. In addition to the attack described above, the mere fact of the difference between different algorithms for different operating systems creates a unique fingerprint for each OS. By sending successive SYN requests and checking the difference between the ISNs, a potential attacker can figure out which OS a server is running. An ISN scrambler counters this attack by creating a difference between the Sequence Numbers pereceived by a client, making it effectively impossible to guess a server s ISN.

TTL attacks
Test TTL Description Each IP packet has a field called Time To Live (TTL), which indicates how many more hops the packet should be allowed to make before being discarded or returned. Each router along a data path decrements this value by one. When a router decrements this value to zero, it drops the packet and sends an ICMP alert notification. Typically, when a host sends a packet, it sets the TTL to a value high enough that the packet can reach its destination under normal circumstances. Different operating systems use different default initial values for the TTL. Because of this an attacker can guess the number of routers between itself and a sending machine, and make assumptions on what the initial TTL was, thereby guessing which OS a host is running, as prelude to an attack. In order to prevent such detection, SmartDefense can change the TTL field of all packets (or all outgoing packets) to a given number. IP ID IP packets have 16-bit field called ID, used when an IP packet is fragmented. The ID allows the receiving machine to know to which virtual IP packet the fragmented packet belongs. While there is a requirement that any two packets have distinct IP IDs, there is no formal specification as to how to assign the IP ID to each packet. Different operating systems use different algorithms for assigning IP IDs to packets. As a result, an attacker can use this information to understand which OS generated the packets. The original IP ID can be overridden whit one generated by the Gateway, masking the operating system s identity from potential attackers.

Successive Events attacks
Successive Events detection does not provide an active-defense mechanism. Successive Events only sends logs, mail, or alerts.
Success Events Settings Address Spoofing Local-Interface Spoofing Description Successive Events detection can be set to track spoofing. Successive Events detection can be set to track local-interface spoofing. There is a LAND attack that targets Gateways.

Port Scanning

An excessive number of attempts to connect to ports on a specific destination IP address from the same source IP address can be tracked. Successive Events detection can be set to track whether an excessive number of NGX alerts are generated, that may indicate an attack in progress. This setting can detect if an excessive number of connections have been opened to a specific destination IP address and port number, from the same source IP

Successive Alerts

Successive Multiple Connections

TCP attacks
This option allows you to configure a comprehensive set of TCP tests.
Test Description
A SYN attack prevents a TCP/IP server from servicing other users. It is accomplished by not sending final acknowledgment to a server s SYN-ACK response in the handshaking sequence, which causes the server to keep signaling until it eventually times out. The source address from the client is of course, counterfeit. SYN flood attacks can overload and crash a server.

SYN Attack Configuration

Small PMTU

The small PMTU is a bandwidth attack discussed in various security mailing lists. In this attack a client fools a server into sending large amounts of data, using small packets. Each packet has a large overheads, which creates a bandwidth bottleneck on the server. The configuration option Minimal MTU size . An exceedingly small value will not prevent an attack. But an unnecessarily large value might result in legitimate requests being dropped, causing black hole effects and degrading performance. So care must be taken to strike a balance.

Sequence Verifier

Sequence Verifier in a mechanism matching a current TCP packet s Sequence Number against a TPC connection state. Packets that match the connection in terms of the TCP session, but have incorrect Sequence Numbers, are stripped of data. Fingerprint is a technique by which a remote host gleans information about a host or network, by looking at the unintentional side effects of benign communications. Techniques involve either active fingerprint by which an attacker sends slightly off protocol packets and tries to glean information from responses (or lack thereof), and passive fingerprint, by which an attacker either generates no traffic , or generates 100-percent standard traffic SmartDefense can scramble some of the fields commonly used for fingerprinting, masking the original identity of hosts behind a Gateway. Totally preventing fingerprinting is next to impossible, but SmartDefense makes it more difficult to fingerprint hosts protected by a Gateway.

Fingerprint Scrambling

y SmartDefense provides a variety of active-defense solutions that

protect information recourses from a board of threats.
y The SmartDefense Subscription service can be purchased to enable

live, real-time updating of SmartDefense s attack signatures.
y SmartDefense provides Security Administrators with the ability to

define worm-signature patterns, to protect HTTP servers
y SmartDefense, working with Storm Centers, allows Administrators to

gather reports on real-time threats to network security

Network Address Translation
y Understanding Network Address Translation y IP Addressing y Dynamic (Hide) NAT y Static NAT y How ARP works y Configuring NAT y Manual NAT and ARP

Introduce to NAT
Network Address Translation (NAT) allows Security Administrators to overcome IP addressing limitations, allowing private IP-address allocation and unregistered internal addressing schemes VPN-1 NGX support Static and Dynamic (Hide) NAT. Static NAT translates private IP addresses to public IP addresses, when packet exit protected networks. Static NAT translates public IP addresses to private IP addresses, when packet enter protected networks. Dynamic NAT conceals one or more private IP addresses behind one public IP address. The main purpose of Dynamic NAT is ot place many hosts withprivate IP addresses behind one public IP address.

Basic NAT translation

Network Address Translation (NAT) was first introduced to the Internet community by RFC 1631. NAT was later refined in RFC 3022, Traditional IP Network Address Translator(Traditional NAT) . The abstact for RFC 3022 states: y Basic Network Address Translation or Basic NAT is a method by which Ipaddresses are mapped from one group to another. Transparent to end users. Network Address Port Translation, or NAPT, is a method by which many network addresses and theirTCP/UDP (Transmission Control Protocol/ User Datagram Protocol) ports are translated into a single network address and its TCP/UDP ports. Together, these two operations,referred to as traditional NAT, provide a mechanism to connect a realm with private addresses to an external realm with globally unique registered addresses. VPN-1 NGX implements both types of traditional NAT, through its Dynamic and Static NAT capabilities. Enterprises employ NAT for a variety of reasons, including: y Private IP addresses used in internal networks y Limiting external network access y Ease and flexibility of network administration



Dynamic translation
y Dynamic (Hide) NAT is used to hide a network, a collection of networks, or a range of IP

addresses behind a single IP address. VPN-1 NGX uses dynamically assigned port numbers to distinguish between internal hosts. The defining characteristic of Dynamic NAT is the one-to-many relationshipbetween the hiding IP address and hidden IP addresses. Dynamic NAT is not appropriate for devices offering services to external clients, for example Web servers that must be accesible from the internet.

Static translation
Static NAT implements a one-to-one relationship between a hidden host and a hiding IP address. Because of this one-to-one relationship, a separate public IP address is required for each hidden host for which a Security Gateway is configured to perform Static NAT. Static NAT appropriate when external hosts must be able to contact an internal host, using its IP address. Static NAT connection are recordered in the Gateway s state tables , to permit Stateful Inspection to occur. No port modifications are required for static NAT.

Where t fi



Example: www server has static public IP IP address of FW interface eth0 is Possibilities: y PC has ARP entry for, PC can form ethernet frame y PC has static host route to, PC broadcast ARP query for IP GW, FW answers with MAC address of eth0 FW, PC can form ethernet frame

NAT Configuration
NGX Administrators configure NAT in three areas: y Global Properties y Object Properties y Address translation rules Settings in these areas determine how a Gateway processes packets when NAT is configured. Only automatic NAT rules are covered in this section. Automatic NAT rules are automatically created from property settings and are appropriate for most installations. In legacy networks where design issues prevent the use of automatic NAT rules. Manual NAT rules may provide solutions.

When automatic NAT rule creation is used, NGX makes all necessary adjustments to the Security Gateway s ARP and routing tables. Using automatic NAT rule creation also eliminates potential anti-spoofing issues. If Manual NAT rule creation is used, special consideration must be paid to ARP and routing-table entries, and anti-spoofing issues. ARP When automatic NAT rule creation is used, Check Point NGX makes all necessary adjustments to the Security Gateway s ARP table. If Manual NAT rule creation is used, the Security Administrator must edit the Security Gateway s ARP table, as follows: Dynamic NAT, Security Gateway in Translated Packet, Source field No additional ARP table entries are required. Dynamic NAT, hiding behind an IP address not assigned to the Security Gateway Add an ARP table entry to the Security Gateway for the hiding address. Static NAT Add ARP table entries to the Security Gateway for all hiding addresses. For information creating persistent ARP table entries, consult your OS

NAT on client side
y 45 str.

Manual NAT
Automatic NAT rule creation is appropriate for most installations. Properly configured object, well-planned networks, and global property settings make Manual NAT rule creation unnecessary for most enterprises. For Security Administrators faced with legacy networks where design issues prevent the use of automatic NAT rules may provide solutions. Some of the situations where Manual NAT rule creation may be warranted include:
‡ Instances where remote networks only allow specific IP addresses. ‡ Situations where translation is desired for some services, and not others. ‡ Environments where more granular control of address translations in VPN tunnels is needed. ‡ Enterprises where Address Translation Rule Base order must be manipulated. ‡ When port address translation is required. ‡ Environments where granular control of address translation between internal networks is required ‡ When a range of IP addresses, rather than a network, will be transalted

y Network Address Translation (NAT) allows Security

Administrator to conceal internal network IP addresses from external networks. y VPN-1 NGX supports Static and Dynamic (Hide) NAT. y Static NAT translates private internal IP addresses to public external IP addresses, when packets exit a firewalled network. Static NAT translates public external IP addresses to private internal IP addresses, when packets enter a firewalled network. y Dynamic (Hide) NAT conceals one or more private IP addresses behind one public address.

Introduction to Authentication
Check Point authentication features enable you to verify the identity of users signing in to VPN-1 NGX. The features also allow you to control security, by allowing some users access and disallowing others. Users authenticate by providing their identities, according t the scheme specified under an NGX authentication scheme. User Authentication allows users to authenticate to a protected network. But NGX Security Administrators may also need to grant access privileges to specific IP addresses or applications. To accomplish this, NGX provides Client and Session Authentication. Client Authentication enables Administrators to machine. Session Authentication provides per-session authentication, which can be integrated with any application.

Types of authentication
‡ VPN-1 NGX supports three types of authentication and several

authentication schemas. Because authentication is specified in a rule s Action field, authentication can be combined with other fields in a rule in a very flexible manner. In addition, NGX supports both transparent and nontransparent authentication.

User Authentication grants access on a per-user basis. This method can only be used for Telnet, FTP, rlogin, HTTP, and HTTPS, and requires separate authentication for each connection. User Authentication is secure, because the authentication is valid only for one connection, but intrusive, because each connection requires another authentication. For example, accessing a single Web page could display several dozen Use Authentication windows, as different components are loaded.

Types of authentication
Session Authentication is not like User Authentication, because it requres authentication for each session, and can be used with any service. Session Authentication is secure, but requires a Session Authentication Agent running on the authentication client, or another machine in the network. Session Authentication can be used to authenticate any service on a persession basis. After the user initiates a connection directly to the server, the Security Gateway located between the user and the destination intercepts the connection. The Gateway recognizes that user-level authentication is required, and initiates a connection with a Session Authentication Agent. The Session Authentication Agent is a utility provided with VPN-1 NGX, and must be installed on any object using Session Authentication. The Agent performs required authentication, which allows connections to continue to the requested server, if permitted.

Types of authentication
This table presents a feature comparison of the three NGX authentication types:

User Authentication Services

Session Authentication

Client Authentication All services

Telnet, FTP, rlogin, All services HTTP, HTTPs Connection Session

Authentication is performed once per Use when you want a user to

IP address

Authenticates each time a user uses one of the supported services.

Authenticates each time a user uses any service (requires a Session Authentication Agent on the client)

Authenticates once, and uses any service until signing out

Authentication schemas
VPN-1 NGX supports the following authentication schemas:
Authentication schema OS Password Description User is challenged to enter his operating-system (OS) password. This method requires user account to be placed in the OS of the Security Gateway, or make a user account a member of a Windows Authentication Domain User is challenged to enter the NGX password on the Security Gateway. The advantage of an NGX password over an OS password is that an NGX password can be used even if the user does not have an OS account on the Security Gateway User is challenged to enter the number displayed on the RSA SecureID token User is challenged for the response, as defined by the RADIUS server. User is challenged for the response, as defined by the TACACS or TACACS+ server. LDAP user is authenticated via scheme used in authentication rules and in remote access (when the user is not identified using a Certificate or an IKE pre-shared secret). A user can have different passwords on different Security Gateways (for example, if the authentication scheme is OS Password). But users can only have one authentication scheme for all security Gateways.

Check Point Password


Based on industry standards, such as LDAP, RADIUS, PKI and CAPI, OPSEC certified authentication products expand the range of authentication options for VPN-1 NGX. The Secure Authentication API (SAA) allows expansion of client options to third-party products.

User Authentication
Check Point have written authentication daemons for each of the User Authentication protocols that run on the firewall module and interact with the data stream to provide a fairly seamless authentication process.

User Authentication
The fact that user successfully connects does not necessarily mean that the user was first authenticated. The authenticating Security Server first checks if the connection can be allowed by a rule that does not require authentication. If one exists, the user will be connected through the less-restrictive rule, bypassing the User Authentication rule. VPN-1 NGX hides the fact that the user is connecting through VPN-1 NGX. Unknown users do not receive error messages specifying that the Security Gateway does not know their username, or that their password is incorrect. Instead, unknown users receive generic error messages. If correct authentication data is not supplied by the user, the connection is dropped. The default is three authentication attempts before dropping the connection. The user will always be prompted for username and password, even though authentication data may not be recognized by the NGX user database.

Client Authentication
Client Authentication enables Administrators to grant access privileges to a specific IP address after successful authentication. In contrast to User Authentication, which allows access per user, Client Authentication allows access per IP address. Authentication is by username and password, but it is the host machine (client) that is granted access. Client Authentication is less secure than User Authentication, as it allows multiple users and connections from authorized IP address of hosts. The authorization is per machine for services that do not have an initial sign-on procedure. The advantage of Client Authentication is that it can be used for any number of connections, for any service, and authentication is valid for any length of time.

Client Authentication
Client Authentication works with any protocol, however it authenticates the IP address the user initiated the connection from for a specific time period and/or a specific number of sessions. To use client authentication you only require a telnet client or a web browser which are usually available. Client Authentication is less secure than User Authentication, as it allows multiple users users and connections from authorized IP address

Sign-On methods
Standard Sign On If specified in a rule s Client Authentication Action Properties screen, the user on the client machine is allowed to use all services permitted by the rule for the authorization period. The user does not need to perform authentication for each service. Specific Sign On If specified, only connections that match original connection are allowed, without additional authentication. If a rule specifies more than one service or host, the user on the client must reauthenticate for each service or host. Specific Sign On is useful, if you want to limit access to services and target hosts. Although the user is authenticated by the Security Server, access is authorized from the IP address from which the user initiated the connection.

Session Authentication
Session Authentication requires a Session Agent to be installed on the users PC or one can be centrally configured on the network. Session authentication will work with all services and authenticates on a per session basis.

How encryption works
When information is sent over a public network, such as the Internet, a message passes through many computers, routers, switches, and similar equipment, before arriving at a destination. Along the way are many opportunities to intercept the message. The original message can be altered or a false message sent. The false message appears to have come from a trusted sender, but does not. Security Administrators need to ensure: Privacy No one, other than the intended parties, can understand the communication Integrity No one is tampering with the communication Authenticity No one is sending false communication VPN-1 NGX protects communications on the Internet, and enables an enterprise to build its own easy-to-maintain VPN, using private and public network segments. Supported are industry-standard algorithms and protocols, such as DES, Triple DES , and IPSee/IKE. Public Key Infrastructure (PKI) support enables the use of digital certificates.

Asymmetric encryption
Asymmetric encryption, which uses one key to encrypt a message and another to decrypt the message, is an encryption technology used for the following: y Secure key-exchange mechanisms y Authentication y Data-integrity checking Asymmetric encryption is also called public/private-key encryption, because the encryption scheme uses two keys one private and one public. These keys are created using the Diffie-Hellman encryption scheme, where one Security Gateway s public key and another security Security Gateway s private key create a shared secret key. This shared secret key is used to verify and decrypt encrypted packets. Because different keys are used for encryption and decryption, they are called asymmetric keys.

Secret key application
VPN-1 NGX supports the following encryption technologies: y Symmetric and asymmetric encryption y Diffie-Hellman key management y Digital signatures

Creation of a digital signature
Authenticity To verify that a message actually comes from a specific sender and not an imposter, a digital signature is attached to the message. A digital signature acts as proof of a sender s identity and the message s integrity. A digital signature is a code that can be attached to an electronically transmitted message. The digital signature uniquely identifies the sender, and verifies that the message has not been tampered with in transit. Like a written signature, the purpose of a digital signature is to guarantee that the individual sending the message is really who he claims to be. Digital signatures use public-key cryptography. To be effective, digital signatures must be unforgeable. Digital signatures are provided via a Certificate Authority (CA), where a third party verifies the key authority.

Tunnel mod
IP Header TCP Header Packet Data

Encryption Protocol Header
Tunneling-mod Encryption


y Encryption allows communication via a VPN. y Encryption works by passing data via a shared-secret

key. y VPNs provide a way to secure data traveling from internal networks to external networks safely.

9. Configuring VPNs site-to-site
Gateway-to-Gateway Configuration Specifying Encryption

VPN Deployments
Intranet VPNs Remote-Access VNPs

VPN Implementation VPN Setup
Simplified Intranet Setup VPN Community Principles

Integrating VPNs into a Rule Base Lab 6: Two-Gateway IKE Encryption Configuration (Shared Secret) SecureClient Icon

Critical components of VPN
The complete VPN must include three critical VPN components: Security VPN security is essential, and must include access control, authentication, and encryption, to guarantee the security of network connections, authenticity of users, privacy, and integrity of data. QoS VPN traffic control should include bandwidth management, Quality of Service, and hardware-based VPN acceleration, to guarantee VPN reliability and performance. Performance and Management VPN enterprise management should include Policy based management, to guarantee the integration of VPNs within the enterprise Policy, local or remote centralized Policy management, and deployment scalability.

Types of VPN
A VPN is a network that uses the Internet as its network backbone, allowing the establishment of secure communication links among company offices, business partners, and so on. VPNs are replacing more expensive leased lines, Frame Relay circuits, and other forms of dedicated connection. VPN deployment can be grouped into basic categories:
y Intranet VPNs y Remote-access VPNs

Intranet VPNs are built to handle secure communication between a company s internal departments and branch offices. An intranet VPN s design requirements include: y Strong data encryption, to protect confidential information. y Reliability for mission-critical systems, such as database management. y Scalability, to accommodate growth and change.

Simplified VPN
There are two basic types of intranet VPN topologies: a mesh topology and star topology. The topology of a VPN Community is determined by the collection of VPN links between community members:
Mesh Every VPN connection between any Community pair (NGX Gateways) is enabled in Community. Star Any VPN connection between satellite and central Gateway in a Community is enabled. Star topologies can have one of the following configurations:

Meshed center with multiple Gateways Non-meshed center, with either single or multiple Gateways

Example simplified VPN
The gateway s Rule Base defines access control: whether a connection is allowed. Whether a connection is encrypted is determined by the VPN Community. If both source and destination belong to the Community, the connection is encrypted. If the connection is not between Community members, the connection is not encrypted.

y IKE provides a consistent framework for transferring

key and authentication data, independent of encryption and authentication mechanisms. y IKE encryption can be done with shared secrets or Certificates. y A VPN can be directly defined on a group of Security Gateways, creating a VPN Community.

VPN Remote Access introduction
VPN-1 SecuRemote/SecureClient allows client-to-site VPN services, providing secure, encrypted communication among remote clients and enterprise networks, LAN segments, and servers. SecureClient extends security to the desktop by enabling Security Policy enforcement desktops, both inside and outside LANs. This Chapter also discusses remote-access VPNs. In a remote-access VPN, a remote-access Community allows Security Administrators to define Security Gateways and user groups involved in SecuRemote/SecureClient communications. In this chapter, you will also learn about the SecureClient Diagnostic Tool, a stand-alone application included with SecureClient. This tool provides user the ability to monitor statistical and performance information about installed SecureClient features, to minimize the Security Administrator s involvement when a problem occurs. In VPN-1 NGX, Connect Mode is an alternative way to initialize a connection between SecuRemote/SecureClient and site. This mode makes it easier for the user, by defining connect and disconnect events. And with VPN-1 NGX, office Mode uses RADIUS to assign IP address, and new DHCP attributes can be added to DHCP request packets. Using Office Mode, connecting to different NGX Security Gateways on the same site is possible.

VPN SecureRemoteSecureClient
VPN-1 SecuRemote is built on the framework of the Check Point VPN. All data is necrypted by SecuRemote before it leaves remote user s computers, making connection completely secure. SecuRemote enables you to create a VPN tunnel between a remote user and organization s internal network. The VPN tunnel guarantees: y Authenticity, by using standard authentication methods. y Privacy, by encrypting data y Integrity, by using standard integrity-assurance methods. SecuRemote extends the VPN to remote users, enabling them to securely communicate sensitive information to networks through a VPN tunnel, using either dial-up or LAN connections. After SecuRemote user is treated us as any other user in the VPN, The Security Administrator can enforce NGX security features, including content security, logging and alerts. VPN-1 SecureClient enhances SecuRemote with a complete client side security, including Desktop Security Policy, automatic software distribution, and other features.

Secure Remote features
SecuRemote: y Encrypts data before it leaves a remote computer y Transparently encrypts TCP/IP communicatons y Interfaces with any Network Driver Interface Specification (NDIS) interface and TCP/IP stack y Enables access for SecuRemote users, through the Rule Base y Enforces security features, including authentication servers, logging, and alerts on SecuRemote connections y Include support for dynamic IP addressing, necessary for dial-up communication y Includes stronger authentication, using Diffie-Hellman and RSA algorithms y Supports User Authentication, by means of Certificates, RADIUS, S/Key, password, and so on y Supports IKE encryption, using DES, Triple DES, AES-128, or AES-256

Configuration of Remote VPN community
1. 2. 3. 4. 5.


Verify that each participant Gateway in the configuration has the same version of the software installed Verify that each participant Gateway s VPN Domain has been properly configured in the Topology screen of Global Properties Edit the default remote-access VPN object in the VPN manager Configure the Participating Gateways screen to include all Gateways to which remote Clients can connect Configure the Participating User Groups screen to include all user groups representing the remote users connecting with SecuRemote or Secureclient. Configure the Rule Base to allow SecuRemote or SecureClient traffic access to the VPN Domain

Sec re emote client - characteristics
SecuRemote Client is made up of a kernel module and a daemon. The kernel module is an NDIS driver that is installed between the TCP/IP stack and the adapter in use, and filters all TCP/IP communication passing through a networked device. During the initial setup of networked device, the TCP/IP stack is bound to a real adapter. The SecuRemote kernel is installed by first unbinding the TCP/IP stack from the real adapter, then binding the transport side of the SecuRemote kernel module, while binding the transport side of the SecuRemote kernel module to the real adapter. The SecuRemote kernel can determine if an outgoing or incoming packet is going to, or coming from a VPN Domain, and should be encrypted or decrypted. The SecuRemote kernel also knows with which Gateway the encryption will take place, in order to exchange keys with the Gateway. The SecuRemote daemon is a Win32 service that runs when Windows starts. The daemon is also a Win32 application that starts when a user logs in and stops when a user logs out. When a user connects to one of the sites in the database or to a host in one of the VPN domains, the kernel module wakes up the daemon, and the daemon: y Holds the first packet, without transmitting it y Examines the packet, and determines the relevant site and Security Gateway in the site y Challenges the user to authenticate herself y Initiates a key-exchange protocol with the Security Gateway y Encrypts the first packet and transmits it After this happens, everything the SecuRemote Client sends to the Security Gateway s VPN Domain is encrypted

Secure Remote Client- configuration
From the Connections tab, the user can: y Create new sites and profiles, as well as clone and export existing profile information y Delete sites and profiles y View the properties of existing sites and profiles

y VPN-1 SecureClient is an extension of VPN-1 SecuRemote, and enables users to download y y y y y

Desktop Policies from Policy Servers SecureClient is ideal for providing desktop-security protection within a LAN A Remote Access Community allows Security Administrators to define Security Gateways and user groups involved in SecuRemote/SecureClient communications The SecureClient Diagnostics Tool monitors Statistical and performance information about installed SecureClient features Connect Mode is an alternative way to initialize a connection between SecuRemote/SecureClient and a site Office Mode uses RADIUS to assign IP addresses, and new DHPC attributes can be added to DHCP request packets. Using Office Mode, connecting to different NGX Security Gateways on the same site is possible

Introduction to LDAP
To implement NGX LDAP, you must install and configure the following components: y VPN-1 NGX y An LDAP server, containing users and/or groups This chapter covers implementing LDAP, and integrating it with NGX SnartCenter Server. The account Management Client is integrated into SmartDashboard in VPN-1 NGX. This additional component of SmartDashboard is used to interface with an LDAP server, for creating modifying accounts. The Account Management interface operates with OPSEC-partner LDAP directories.

LDAP protocol
Account management for a large network can be a daunting task. Organizations with account management in a protected network can appreciate a process where all databases are maintained from one location. When Check Point software is purchased, an effective usermanagement infrastructure, such as Lightweight Directory Access Protocol (LDAP), may already be in place. LDAP is used to communicate with a server that maintains information about users and items within an organization. LDAP is smaller version of X.500 ISO standard. VPN-1 NGX uses existing LDAP servers to obtain user information for authentication and authorization purposes.

Account management
VPN-1 NGX allows LDAP authentication and authorization through the use of the SmartDashboard GUI. Security Administrators can define and maintain LDAP directories located on an LDAP server. If the customer does not have a user management infrastructure in place, a choice will need to be made between managing customers on the internal user database, or choosing to implement an LDAP server. If the customer has a large user account, it is recommended to opt for an external usermanagement database, such as LDAP. By maintaining a large user database externally, NGX performance is greatly enhanced. For example, if the user database is external, the database will not have to be reinstalled every time the user information changes. Additionally, the LDAP user database can be used as the user database by other applications. This minimizes the number of areas where user information needs to be modified. When deployed with an LDAP server, NGX components such as the SmartCenter Server and Security Gateways, function as LDAP clients.
y y

The SmartCenter Server manages user information on the LDAP server. Gateways act as LDAP clients, to:
y y y

Query user information Retrieve Certificate Revocation Lists (CRL) In some cases perform bind operations for authentication purposes.

LDAP features
There are several LDAP features that can be applied to further enhance NGX LDAP functionality. These include:
y High Availability, where user information can be duplicated across several servers (LDAP

replications) y Support of multiple LDAP servers on which many user databases are distributed y The use of encrypted or non-encrypted LDAP connections; the Administrator must decide, for each LDAP server specified in the Account Unit, whether LDAP connections are encrypted between the LDAP server and VPN-1 NGX using SSL, or whether they are clear , i.e. not encrypted. y Support of multiple LDAP vendors by using profiles; integrated profiles are available for different supported vendors. These profiles can be selected and applied to an Account Unit. This solution enables the system to adapt to the specified LDAP server and to recognize from which vendor it originated. All LDAP servers specified in an Account Unit must be from the same vendor. When a given LDAP server is queried, NGX queries will be customized according to the selected profile.

LDAP features
Features of LDAP are as follows:
y LDAP is based on a client/server model, in which an

LDAP client makes a TCP connection to an LDAP server. y Each entry has a unique Distinguished Name. y Default port numbers are 389 for standard connections, and 636 for Secure Socket Layer (SSL) connections. y Each LDAP server is called an Account Unit

LDAP structure
cn = John Brown, o=XYZ Company, c=US The two CNs John Brown belongs to two different DNs. This can be outlined as an inverted tree, as in the figure:
o= ABC

o= XYZ
Ou= Sales Cn= John Brown

Ou= Marketing

Cn= John Brown

Cn= John Brown

LDAP server locations
If VPN-1 NGX includes the appropriate license, account management is allowed for an unlimited number of LDAP server. Therefore , as many LDAP servers as needed may be managed through SmartDashboard, as shown below:

Integration of LDAP and NGX
y There are two methods to consider when integrating LDAP servers with VPN-1 NGX: y If a large number of users have been placed into the NGX user database, exporting them

for integration into the LDAP server is a possibility. However, this requires the integration of the Check Point LDAP schema with the LDAP server. y If an LDAP server already exists for authentication, the Check Point schema does not need to be imported. VPN-1 NGX can use existing users in the LDAP server for authentication purposes. Examples of each method are presented in this section. Note that any OPSEC certified LDAP directory server may be used. The decision whether to use the Check Point schema depends on where user management will take place. If the directory server s interface will be used to update LDAP, you do not need to add the schema to the LDAP structure. If user management is performed in SmartDashboard, the schema must be imported into the LDAP server.

Existing LDAP
If there is an existing LDAP user database, integration with VPN-1 NGX is relatively simple. The LDAP server maintains all user information, including login name and password. Addition and deletion of users is performed on the LDAP server through the LDAP user interface, instead of through SmartDashboard.

Export User Database
y Users may be exported from the NGX user database directly into Lightweight Directory

Interchange Format (LDIF). This process allows users to be imported into an LDAP server, without needing to reenter all of user data. The syntax for the command is as follows:
-g group -u user -d delim -a (attrib1, attrib2, )

Specifies a group to be exported; users in the group are not exported Specifies that only one user is to be exported Specifies a delimeter, different from the default value Specifies the attributes to export, in the form of a comma-separated list, between {} characters for example, -a {name, days}: if there is only one attribute, the {} may be omitted Specifies the name of the output file: the default output file is $FWDIR/conf/user_def_file. Creates an LDIF file for import by an LDAP server Allows you to export the database based on one of the four LDAP profiles (OPSEC, Microsoft_AD, etc. ) The branch under which users are to be added The Account Unit s IKE shared secret (IKE key in the encryption tab, of the Account Unit Properties screen)

-f file -l -p -s -k

LDAP user managing
To examine or change information in an LDAP server, Administrators need a way to interface with it. This interaction is possible through the command line or graphic client on most LDAP servers. However, LDAP servers may also be manipulated through SmartDashboard. SmartDashboard allows the creation of the LDAP node, the LDAP server object.LDAP Account Units (AU), and LDAP users. All major LDAP servers come with their own graphic client. Check Point provides account-management capabilities as a GUI to manage NGX user attributes in the LDAP server. Most LDAP clients include only the standard LDAP attributes. VPN-1 NGX has specific requirements for the user databases it manages.

Definition of users
Before creating a user, group or organization unit, be certain schema checking is enabled, and the Check Point schema has been imported into the LDAP server. Enabling schema checking varies between different vendor implementations of the LDAP service. Schema checking ensures error-checking capabilities in the LDAP data structure, when values are entered into the database. The NGX schema may be imported from schema.ldif file located on the SmartCenter Server. To import the schema, disable schema checking on the LDAP server, then import schema.ldif. This file is located in the $FWDIR/lib/ldap directory. After the new schema is imported, reenable schema checking. Both VPN-1 NGX and LDAP user databases cache users, so any change in user definition will take effect after Policy installation or cache time-out. If a user is removed from a group in the SmartDashboard or LDAP server, and only installed using the Install User Database option in SmartDashboard, that user will still be allowed access under Client Authentication rules. If changes are made using SmartDashboard, changes will take effect in VPN-1 NGX only after the cache times out, the Security Policy is installed, or the user database is downloaded.

y SmartDashboard can be used to modify and update

the LDAP directory server with account information y Account management for a network can be a large and resource-intensive task. y An LDAP server can be used to store user information, centralizing account management.

Backup and Recovery
Regular backups are necessary for servers running VPN-1 NGX. These are generally mission-critical servers for a company, and need to be able to recover quickly from a disaster, or even accidental file deletion.

A full backup should be performed on the NGX SmartCenter Server regularly, along with frequent backups of the $FWDIR/conf directory. This directory contains Rule Bases, objects , and the user database.

$FWDIR/lib The $FWDIR/lib directory should also be backed up frequently. There are several instances where files in this directory, such as base.def, are modified. If an NGX Feature Pack is installed over these modified files, $FDIR/lib will revert to the default installation. This will remove any modifications. Changes should be kept to a minimum, when possible. This prevents unwanted downtime. A change log should be maintained whenever modifications are performed, to assist in quick recovery of deleted or removed files. Do not upgrade VPN-1 NGX without first making a complete backup of the system. A computer backup will allow a quick restore, in case of problem. Log Files The connection-log files the logs displayed in SmartView Tracker should be log-switched regularly. The time between a log switch will depend on how many rules are logging, the type of logging, and the amount of traffic passing through the Security Gateway. The log switch can be configured to perform on a set schedule, using time objects. This is completed through the SmartCenter Server and log server s General Properties.

Backup and Recovery
SFWDIR/LOG Other log files located in the $FWDIR/log directory should be removed periodically, ahttp.log. aftp.log and smtp.log should be removed to another system, or backed up and removed. These files contain information about each Security Server. To properly remove these files, stop the Security Gateway first. $FWDIR/log can get large quickly, depending upon the amount of network traffic passing through the Security Gateway. Objects.C and objects_5_0.C The objects_5_0.C file includes a section of properties whose values affect NGX behavior : In addition, network objects, server objects, service objects, time objects and other miscellaneous data also exist in this file. objects_5_0.C is modified when global and local properties are changed, or when the DbEdit utility is used. Objects_5_0.C is used only by the SmartCenter Server. Objects_5_0.C is used to create the objects.C file, which is passed to the Security Gateway and contains information required for the Gateway s operation. These files are located in the $FWDIR/conf/ directory. Objects_5_0.C is created when a Security Policy is installed on the Security Gateway. Objects_5_0.C is then sent to the Gateway, along with the new Policy.

Backup and Recovery
Rulebases_5_0.fws The rulebases_5_0.fws file is located in $FWDIR/conf. The rulebases_5_0.fws file contains rules and auditing information about modifications made to the Rule Base. Unlike objects.C, rulebases_5_0.fws does not appear on the Security Gateway in a distributed environment. All created Rule Bases may be extracted from rulebases_5_0.fws: Select a Rule Base, then install the Security Policy on the Security Gateways. Rulebases_5_0.C in not modified manually, but is manipulated through SmartDashboard. Fwauth.NDB The fwauth.NDB database file contains all NGX users and groups. It is located in both the $FWDIR/conf, and $FWDIR/databse directories. File modification is performed through SmartDashboard user administration. Fwauth.NDB should be backed up on a regular basis, especially for large user populations.