Describes how to configure protection for some of the predefined TCP services that perform content inspection.
Section 5: Web Security
This section describes the VPN-1 Web Intelligence feature, which provides high performance attack protection for Web servers and applications, and VPN-1 Web Content capabilities.
Section 6: Appendices
This section describes how a VPN-1 gateway protects itself and its networks during activation and provides a summary of VPN-1 command line interface commands.
Chapter Description
Chapter 15, “Web Content Protection”
Describes the integrated web security capabilities that are configured through the Security Rule Base and how to secure XML Web Services (SOAP) on Web servers.
Appendix Description
Appendix A, “Security Before VPN-1 Activation”
Describes the Boot Security and Initial Policy features, which are used when a computer does not yet have a VPN-1 security policy installed.
Appendix B, “Command Line Interface”
Describes command line interface commands that relate to VPN-1 firewall components.
Related Documentation
This release of VPN-1 includes the following related documentation:
TABLE P-1 VPN-1 Power documentation suite documentation
Title Description
Internet Security Product Suite Getting Started Guide
Contains an overview of NGX R65 and step by step product installation and upgrade procedures. This document also provides information about What’s New, Licenses, Minimum hardware and software requirements, etc.
Upgrade Guide Explains all available upgrade paths for Check Point products from VPN-1/FireWall-1 NG forward. This guide is specifically geared towards upgrading to NGX R65.
SmartCenter
Administration Guide
Explains SmartCenter Management solutions. This guide provides solutions for control over
configuring, managing, and monitoring security deployments at the perimeter, inside the network, at all user endpoints.
Firewall and SmartDefense Administration Guide
Describes how to control and secure network access; establish network connectivity; use SmartDefense to protect against network and application level attacks; use Web Intelligence to protect web servers and applications; the integrated web security capabilities; use Content Vectoring Protocol (CVP) applications for anti-virus protection, and URL Filtering (UFP) applications for limiting access to web sites; secure VoIP traffic.
Virtual Private Networks Administration Guide
This guide describes the basic components of a VPN and provides the background for the
technology that comprises the VPN infrastructure.
Eventia Reporter Administration Guide
Explains how to monitor and audit traffic, and generate detailed or summarized reports in the format of your choice (list, vertical bar, pie chart etc.) for all events logged by Check Point VPN-1 Power, SecureClient and SmartDefense.
SecurePlatform™/
SecurePlatform Pro Administration Guide
Explains how to install and configure
SecurePlatform. This guide will also teach you how to manage your SecurePlatform machine and explains Dynamic Routing (Unicast and Multicast) protocols.
Provider-1/SiteManager-1 Administration Guide
Explains the Provider-1/SiteManager-1 security management solution. This guide provides details about a three-tier, multi-policy management
architecture and a host of Network Operating Center oriented features that automate time-consuming repetitive tasks common in Network Operating Center environments.
TABLE P-2 Integrity Server documentation
Title Description
Integrity Advanced Server Installation Guide
Explains how to install, configure, and maintain the Integrity Advanced Server.
Integrity Advanced Server Administrator Console Reference
Provides screen-by-screen descriptions of user interface elements, with cross-references to relevant chapters of the Administrator Guide. This document contains an overview of Administrator Console navigation, including use of the help system.
Integrity Advanced Server Administrator Guide
Explains how to managing administrators and endpoint security with Integrity Advanced Server.
Integrity Advanced Server Gateway Integration Guide
Provides information about how to integrating your Virtual Private Network gateway device with Integrity Advanced Server. This guide also contains information regarding deploying the unified SecureClient/Integrity client package.
TABLE P-1 VPN-1 Power documentation suite documentation (continued)
Title Description
Integrity Advanced Server System Requirements
Provides information about client and server requirements.
Integrity Agent for Linux Installation and
Configuration Guide
Explains how to install and configure Integrity Agent for Linux.
Integrity XML Policy Reference Guide
Provides the contents of Integrity client XML policy files.
Integrity Client Management Guide
Explains how to use of command line parameters to control Integrity client installer behavior and
post-installation behavior.
TABLE P-2 Integrity Server documentation (continued)
Title Description
More Information
• For additional technical information regarding Check Point products, refer to Check Point’s SecureKnowledge at https://secureknowledge.checkpoint.com/.
• To view the latest version of this document in the Check Point User Center, go to: http://www.checkpoint.com/support/technical/documents.
Feedback
Check Point is engaged in a continuous effort to improve its documentation. Please help us by sending your comments to:
Network Access
This section describes how to secure the networks behind the VPN-1 gateway by allowing only permitted users and resources to access protected networks.
Chapter 1
Access Control
In This Chapter
The Need for Access Control page 30
Solution for Secure Access Control page 31
Special Considerations for Access Control page 44
Configuring Access Control page 47
The Need for Access Control
Network administrators need the means to securely control access to resources such as networks, hosts, network services and protocols. Determining what resources can be accessed, and how, is the responsibility of authorization, or Access Control. Determining who can access these resources is the responsibility of User Authentication (for additional information, refer to Chapter 2,
“Authentication”).
Solution for Secure Access Control
In This Section
Access Control at the Network Boundary
A VPN-1 gateway at the network boundary inspects and provides access control for all gateway traffic. Traffic that does not pass though the gateway is not controlled.
Figure 1-1 VPN-1 Gateway Traffic Inspection at the Network Boundary
A security administrator is responsible for implementing company security policy.
VPN-1 allows administrators to enforce security policies consistently across multiple gateways. To do this, the administrator defines a company-wide security policy Rule Base using SmartDashboard and installs it to the SmartCenter server.
Access Control at the Network Boundary page 31
The Rule Base page 32
Example Access Control Rule page 33
Rule Base Elements page 33
Implied Rules page 34
Preventing IP Spoofing page 35
Multicast Access Control page 37
Cooperative Enforcement page 40
End Point Quarantine (EPQ) - Intel(r) AMT page 42
SmartDashboard is a SmartConsole client application that administrators use to define and apply security policies to gateways. Granular security policy control is possible by applying specific rules to specific gateways.
VPN-1 provides secure access control because of its granular understanding of all underlying services and applications traveling on the network. Stateful Inspection technology provides full application level awareness and comprehensive access control for more than 150 predefined applications, services and protocols as well as the ability to specify and define custom services.
Stateful Inspection extracts state-related information required for security decisions from all application levels and maintains this information in dynamic state tables that are used to evaluate subsequent connection attempts. For additional technical information on Stateful Inspection, refer to the Check Point Technical Note at:
http://www.checkpoint.com/products/downloads/firewall-1_statefulinspection.pdf
The Rule Base
A security policy is implemented by means of ordered set of rules in the security Rule Base. A well defined security policy is essential to an effective security solution.
The fundamental principle of the Rule Base is that all actions that are not explicitly permitted are prohibited. The Rule Base is a collection of rules that determine which communication traffic is permitted and which is blocked. Rule parameters include the source and destination of the communication, the services and protocols that can be used and at what times, and tracking options. Reviewing SmartView Tracker traffic logs and alerts is an crucial aspect of security management.
VPN-1 inspects packets in a sequential manner. Once VPN-1 receives a packet from a connection, it inspects it according to the first rule in the Rule Base, and then the second and so on. Once VPN-1 finds an applicable rule, it stops
inspecting and applies that rule to the packet. If no applicable rule is found in the Rule Base, the packet is blocked. It is important to understand that the first matching rule applies to the packet, not necessarily the rule that best applies.
Example Access Control Rule
Figure 1-2 displays a typical access control rule. It states that HTTP connections that originate from any of the Alaska_LAN group hosts, and directed to any destination will be accepted and logged.
Figure 1-2 Example Access Control Rule
Rule Base Elements
A rule is made up of the following Rule Base elements (not all fields are relevant in a given rule):
Table 1-1 Rule Base Elements Source and
Destination
Refers to the originator and recipient of the connection. For applications that work in the client server model, the source is the client and the destination is the server. Once a connection is allowed, packets in the connection pass freely in both directions.
You can negate source and destination parameters, which means that a given rule applies to all connection sources/destinations except the specified location. You may, for example, find it more convenient to specify that the a rule applies to any source that is not in a given network To negate a
connection source or destination, right click on the appropriate rule cell and select Negate Cell from the options menu.
VPN Allows you to configure whether the rule applies to any connection (encrypted or clear) or only to VPN connections. To limit a rule to VPN connections, double-click on the rule and select one of the two VPN options.
Service Allows you to apply a rule to specific predefined protocols or services or applications. You can define new, custom services.
Action Determines whether a packet is accepted, rejected, or dropped. If a
connection is rejected, VPN-1 sends an RST packet to the originator of the connection and the connection is closed. If a packet is dropped, no response is sent and the connection eventually times out. (For information on actions that relate to authentication, refer to Chapter 2, “Authentication”.
Implied Rules
Apart from those rules defined by an administrator, VPN-1 also creates implied rules, which are derived from the Policy > Global Properties definitions. Implied rules enable certain connections to occur to and from the gateway using a variety of different services. Examples of implied rules include rules that enable
VPN-1 control connections and outgoing packets originating from the VPN-1 gateway.
VPN-1 implied rules are placed first, last, or before last in the Rule Base and can be logged. Implied rules are processed in the following order:
1. First: This rule cannot be modified or overwritten in the Rule Base because the first rule that matches is always applied to the packet and no rules can be placed before it.
2. Explicit: These are the administrator-defined rules, which may be located between the first and the before last rules.
3. Before Last: These are more specific rules that are enforced before the last rule is applied.
4. Rule n: The last defined rule.
5. Last: A rule that is enforced after the last rule in the Rule Base, which normally rejects all packets and has no effect.
6. Implicit Drop Rule: No logging occurs.
Track Provides various logging options (for additional information, refer to the SmartCenter Administration Guide).
Install-On Specifies the VPN-1 gateways on which the rule is installed. There may be no need to enforce certain rules on every VPN-1 gateway. For example, a rule may allow certain network services to cross only one particular gateway. In this case, the specific rule need not be installed on other gateways. (For additional information, refer to the SmartCenter Administration Guide.) Time Specifies the days and the time of day to enforce this rule.
Table 1-1 Rule Base Elements
Preventing IP Spoofing
IP spoofing occurs when an intruder attempts to gain unauthorized access by changing a packet's IP address to appear as though it originated from network node with higher access privileges.
Note - It is important to ensure that all communication originates from its apparent source.
Anti-spoofing protection verifies that packets originate from and are destined to the correct interfaces on the gateway. It confirms which packets actually come from the specified internal network interface. It also verifies that once a packet is routed, it goes through the proper interface.
A packet coming from an external interface, even if it has a spoofed internal IP address, is blocked because the VPN-1 anti-spoofing feature detects that the packet arrived from the wrong interface. Figure 1-3 illustrates the anti-spoofing process.
Figure 1-3 Anti-Spoofing Process
On Alaska_GW, VPN-1 ensures that:
• All incoming packets to interface IF1 come from the Internet.
• All incoming packets to interface IF2 come from Alaska_LAN or, Alaska_RND_LAN or Florida_LAN.
On Alaska_RND_GW, VPN-1 ensures that:
• All incoming packets to interface IF3 come from Alaska_LAN, Florida_LAN or the Internet.
• All incoming packets to interface IF4 come from Alaka_RND_LAN.
When configuring anti-spoofing, you need to specify in the interface topology definitions whether the interfaces lead to the Internet (defined as External) or an internal network (defined as Internal). Figure 1-3 illustrates whether the gateway interfaces are internal or external in the interface topology definitions.
Excluding Specific Internal Addresses from Anti-Spoofing Protection
In some cases, it may be necessary to allow packets with source addresses that belong to an internal network to enter the gateway through an external interface.
This may be useful if an external application assigns internal IP addresses to external clients. In this case, you can specify that anti-spoofing checks are not made on packets from specified internal networks. For example, in Figure 1-3, it is possible to specify that packets with source addresses in Alaska_RND_LAN are allowed to enter interface IF1.
What Are Legal Addresses?
Legal addresses are those addresses that are permitted to enter a VPN-1 gateway interface. Legal addresses are determined by the network topology. When
configuring VPN-1 anti-spoofing protection, the administrator specifies the legal IP addresses behind the interface. The Get Interfaces with Topology option
automatically defines the interface and its topology and creates network objects.
VPN-1 obtains this information by reading routing table entries.
Additional Information
For additional information on anti-spoofing protection planning, refer to “Spoofing Protection” on page 44.
For additional information on anti-spoofing configuration, refer to “Configuring Anti-Spoofing” on page 49.
Multicast Access Control
In This Section
Introduction to Multicast IP
Multicast IP transmits a single message to a predefined group of recipients. an example of this is distributing real-time audio and video to a set of hosts that have joined a distributed conference.
Multicast is similar to radio and TV where only those people who have tuned their tuners to a selected frequency receive the information. With multicast you hear the channel you are interested in, but not the others.
IP multicasting applications send one copy of each datagram (IP packet) and address it to a group of computers that want to receive it. This technique sends datagrams to a group of recipients (at the multicast address) rather than to a single recipient (at a unicast address). The routers in the network forward the datagrams to only those routers and hosts that want to receive them.
The Internet Engineering Task Force (IETF) has developed multicast communication standards that define:
• Multicast routing protocols
• Dynamic registration
• IP multicast group addressing
Multicast Routing Protocols
Multicast routing protocols communicate information between multicast groups.
Examples of multicast routing protocols include Protocol-Independent Multicast (PIM), Distance Vector Multicast Routing Protocol (DVMRP), and Multicast Extensions to OSPF (MOSPF).
Introduction to Multicast IP page 37
Multicast Routing Protocols page 37
Dynamic Registration Using IGMP page 38
IP Multicast Group Addressing page 38
Per-Interface Multicast Restrictions page 39
Dynamic Registration Using IGMP
Hosts use the Internet Group Management Protocol (IGMP) to let the nearest multicast router know if they want to belong to a particular multicast group. Hosts can leave or join the group at any time. IGMP is defined in RFC 1112.
IP Multicast Group Addressing
The IP address area has four sections: Class A, Class B, Class C, and Class D. Class A, B, and C addresses are used for unicast traffic. Class D addresses are reserved for multicast traffic and are allocated dynamically.
The multicast address range 224.0.0.0 through 239.255.255.255 is used only for the group address or destination address of IP multicast traffic. Every IP datagram whose destination address starts with 1110 is an IP multicast datagram
(Figure 1-4).
Figure 1-4 Multicast Address Range
Just as a radio is tuned to receive a program that is transmitted at a certain frequency, a host interface can be tuned to receive datagrams sent to a specific multicast group. This process is called joining a multicast group.
The remaining 28 bits of the multi-case address range identify the multicast group to which the datagram is sent. Membership in a multicast group is dynamic (hosts can join and leave multicast groups). The source address for multicast datagrams is always the unicast source address.
Reserved Local Addresses
Multicast group addresses in the 224.0.0.0 through 224.0.0.255 range are assigned by the Internet Assigned Numbers Authority (IANA) for applications that are never forwarded by a router (they remain local on a particular LAN segment).
These addresses are called permanent host groups. Table 1-2 provides examples of reserved Local Network Multicast Groups.
For additional information on reserved multicast addresses, refer to:
http://www.iana.org/assignments/multicast-addresses.
Per-Interface Multicast Restrictions
A multicast enabled router forwards multicast datagrams from one interface to another. When you enable multicast on a VPN-1 gateway running on
SecurePlatform, you can define multicast access restrictions on each interface (refer to Figure 1-5). These restrictions specify which multicast groups (addresses or address ranges) to allow or to block. Enforcement is performed on outbound multicast datagrams.
When access is denied to a multicast group on an interface for outbound IGMP packets, inbound packets are also denied.
Table 1-2 Local Network Multicast Groups Examples Multicast Address Purpose
224.0.0.1 All hosts. An ICMP Request (ping) sent to this group should be answered by all multicast capable hosts on the network. Every multicast capable host must join this group at start up on all of its multicast capable interfaces.
224.0.0.2 All routers. All multicast routers must join this group on all of its multicast capable interfaces.
224.0.0.4 All DVMRP routers.
224.0.0.5 All OSPF routers.
224.0.0.13 All PIM routers.
Figure 1-5 Gateway with Per Interface Multicast Restrictions
When access restrictions for multicast datagrams are not defined, inbound multicast datagrams entering a gateway from one interface are allowed out of all other interfaces.
In addition to defining per interface access restrictions, you must define a rule in the Rule Base that allows multicast traffic and services, and the destination defined in this rule must allow the required multicast groups.
For additional information, refer to “Configuring Multicast Access Control” on page 50.
VPN Connections
Multicast traffic can be encrypted and sent across VPN links defined using multiple VPN tunnel interfaces (virtual interfaces associated with the same physical
interface).
Cooperative Enforcement
Cooperative Enforcement works with Check Point Integrity servers. This feature utilizes the Integrity server compliance capability to verify connections arriving from
Integrity server is a centrally managed, multi-layered endpoint security solution that
Integrity server is a centrally managed, multi-layered endpoint security solution that