Firewall and SmartDefense - Check Point Software Technologies

Firewall and SmartDefense
Version NGX R62
702048 September 25, 2006
© 2003-2006 Check Point Software Technologies Ltd.
All rights reserved. This product and related documentation are protected by copyright and distributed under licensing restricting their use, copying,
distribution, and decompilation. No part of this product or related documentation may be reproduced in any form or by any means without prior written
authorization of Check Point. While every precaution has been taken in the preparation of this book, Check Point assumes no responsibility for errors or
omissions. This publication and features described herein are subject to change without notice.
RESTRICTED RIGHTS LEGEND:
Use, duplication, or disclosure by the government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer
Software clause at DFARS 252.227-7013 and FAR 52.227-19.
TRADEMARKS:
©2003-2006 Check Point Software Technologies Ltd. All rights reserved.
Check Point, Application Intelligence, Check Point Express, the Check Point logo, AlertAdvisor, ClusterXL, ConnectControl, Connectra, Cooperative
Enforcement, Cooperative Security Alliance, CoSa, DefenseNet, Eventia, Eventia Analyzer, Eventia Reporter, FireWall-1, FireWall-1 GX, FireWall-1 SecureServer,
FloodGate-1, Hacker ID, IMsecure, INSPECT, INSPECT XL, Integrity, InterSpect, IQ Engine, NGX, Open Security Extension, OPSEC, OSFirewall, Policy Lifecycle
Management, Provider-1, Safe@Office, SecureClient, SecureKnowledge, SecuRemote, SecurePlatform, SecureServer, SecureUpdate, SecureXL, SecureXL
Turbocard, SiteManager-1, SmartCenter, SmartCenter Power, SmartCenter Pro, SmartCenter UTM, SmartDashboard, SmartDefense, SmartDefense Advisor,
Smarter Security, SmartLSM, SmartMap, SmartUpdate, SmartView, SmartView Monitor, SmartView Reporter, SmartView Status, SmartViewTracker, SofaWare,
SSL Network Extender, Stateful Clustering, TrueVector, Turbocard, UAM, UserAuthority, User-to-Address Mapping, VPN-1, VPN-1 Accelerator Card, VPN-1
UTM Edge, VPN-1 Power, VPN-1 Power VSX, VPN-1 Pro, VPN-1 SecureClient, VPN-1 SecuRemote, VPN-1 SecureServer, VPN-1 UTM, VPN-1 UTM Edge,
VPN-1 VSX, Web Intelligence, ZoneAlarm, ZoneAlarm Anti-Spyware, ZoneAlarm Antivirus, ZoneAlarm Internet Security Suite, ZoneAlarm Pro, Zone Labs, and
the Zone Labs logo are trademarks or registered trademarks of Check Point Software Technologies Ltd. or its affiliates. All other product names mentioned
herein are trademarks or registered trademarks of their respective owners. The products described in this document are protected by U.S. Patent No.
5,606,668, 5,835,726, 6,496,935, 6,873,988, and 6,850,943 and may be protected by other U.S. Patents, foreign patents, or pending applications.
For third party notices, see: THIRD PARTY TRADEMARKS AND COPYRIGHTS.
Contents
Preface
Who Should Use This Guide.............................................................................. 16
Summary of Contents ....................................................................................... 17
Section 1: Network Access .......................................................................... 17
Section 2: Connectivity ............................................................................... 18
Section 3: SmartDefense ............................................................................. 18
Section 4: Application Intelligence ............................................................... 19
Section 5: Web Security .............................................................................. 20
Appendices ................................................................................................ 20
Related Documentation .................................................................................... 21
More Information ............................................................................................. 24
Network Access
Chapter 1
Access Control
The Need for Access Control ............................................................................. 28
Solution for Secure Access Control .................................................................... 29
Access Control at the Network Boundary ....................................................... 29
The Security Rule Base ............................................................................... 30
Example Access Control Rule ....................................................................... 31
Rule Base Elements .................................................................................... 31
Implied Rules............................................................................................. 32
Preventing IP Spoofing ................................................................................ 33
Multicast Access Control ............................................................................. 35
Considerations for Access Control ...................................................................... 39
Spoof Protection ......................................................................................... 39
Simplicity .................................................................................................. 39
Basic Rules ................................................................................................ 40
Rule Order ................................................................................................. 40
Topology Considerations: DMZ ..................................................................... 40
The X11 Service ......................................................................................... 41
When to Edit Implied Rules ......................................................................... 41
Configuring Access Control ............................................................................... 42
Defining Access Control Rules...................................................................... 42
Defining a Basic Policy................................................................................ 42
Configuring Anti-Spoofing ............................................................................ 43
Configuring Multicast Access Control ............................................................ 44
Table of Contents
5
Chapter 2
Authentication
The Need for Authentication ............................................................................. 48
VPN-1 Power Solution for Authentication ........................................................... 49
Introduction to VPN-1 Power Authentication.................................................. 49
Choosing an Authentication Method.............................................................. 50
Authentication Schemes.............................................................................. 50
Authentication Methods............................................................................... 53
Configuring Authentication ............................................................................... 63
Creating Users and Groups........................................................................... 63
Configuring User Authentication................................................................... 65
Configuring Session Authentication .............................................................. 66
Configuring Client Authentication ................................................................. 70
Configuring Authentication Tracking ............................................................. 75
Configuring a VPN-1 Power Gateway to use RADIUS ...................................... 76
Granting User Access Based on RADIUS Server Groups .................................. 77
Associating a RADIUS Server with a VPN-1 Power Gateway............................. 79
Configuring a VPN-1 Power Gateway to use SecurID....................................... 79
Configuring a VPN-1 Power Gateway to use TACACS+ .................................... 80
Groups of Windows users ............................................................................. 81
Connectivity
Chapter 3
Network Address Translation (NAT)
The Need to Conceal IP Addresses .................................................................... 86
Check Point Solution for Network Address Translation ......................................... 87
Public and Private IP addresses ................................................................... 87
NAT in VPN-1 Power ................................................................................... 88
Static NAT ................................................................................................. 89
Hide NAT................................................................................................... 90
Automatic and Manual NAT Rules ................................................................ 91
Automatic Hide NAT for Internal Networks .................................................... 92
Address Translation Rule Base ..................................................................... 93
Bidirectional NAT ....................................................................................... 94
Understanding Automatically Generated Rules............................................... 95
Port Translation .......................................................................................... 97
NAT and Anti-Spoofing................................................................................ 97
Routing Issues............................................................................................ 97
Disabling NAT in a VPN Tunnel.................................................................... 99
Planning Considerations for NAT ..................................................................... 100
Hide Versus Static .................................................................................... 100
Automatic Versus Manual Rules ................................................................. 100
Choosing the Hide Address in Hide NAT ..................................................... 101
Configuring NAT ............................................................................................ 102
General Steps for Configuring NAT ............................................................. 102
6
Basic Configuration - Network Node with Hide NAT...................................... 103
Sample Configuration - Static and Hide NAT ............................................... 104
Sample Configuration - Using Manual Rules for Port Translation ................... 106
Configuring Automatic Hide NAT for Internal Networks................................. 107
Advanced NAT Configuration .......................................................................... 108
Allowing Connections Between Translated Objects on Different Gateway Interfaces
108
Enabling Communication for Internal Networks with Overlapping IP addresses 109
SmartCenter Behind NAT .......................................................................... 113
IP Pool NAT ............................................................................................. 117
Chapter 4
ISP Redundancy
Need for ISP Link Redundancy ....................................................................... 124
Solution for ISP Link Redundancy ................................................................... 125
ISP Redundancy Overview ......................................................................... 125
ISP Redundancy Operational Modes ........................................................... 126
Monitoring the ISP Links ........................................................................... 127
How ISP Redundancy Works ...................................................................... 127
The ISP Redundancy Script ....................................................................... 129
Manually Changing the Link Status (fw isp_link) .......................................... 130
ISP Redundancy Deployments.................................................................... 131
ISP Redundancy and VPNs ........................................................................ 133
Considerations for ISP Link Redundancy .......................................................... 136
Choosing the Deployment .......................................................................... 136
Choosing the Redundancy Mode................................................................. 136
Configuring ISP Link Redundancy ................................................................... 137
Introduction to ISP Link Redundancy Configuration ..................................... 137
Registering the Domain and Obtaining IP Addresses..................................... 137
DNS Server Configuration for Incoming Connections .................................... 138
Dialup Link Setup for Incoming Connections ............................................... 139
SmartDashboard Configuration ................................................................... 139
Configuring the Default Route for the ISP Redundancy Gateway .................... 142
Chapter 5
ConnectControl - Server Load Balancing
The Need for Server Load Balancing ................................................................ 144
The ConnectControl Solution for Server Load Balancing..................................... 145
Introduction to ConnectControl................................................................... 145
Load Balancing Methods ........................................................................... 146
ConnectControl Packet Flow....................................................................... 147
Logical Server Types ................................................................................. 147
Persistent Server Mode.............................................................................. 150
Server Availability ..................................................................................... 152
Load Measuring ........................................................................................ 152
Configuring ConnectControl ............................................................................ 153
Table of Contents
7
SmartDefense
Chapter 6
SmartDefense
Need for Active Defense ................................................................................. 158
The SmartDefense Solution for an Active Defense ............................................. 160
Introduction to SmartDefense .................................................................... 160
Application Intelligence-Defending Against the Next Generation of Threats..... 161
Network and Transport Layers: Necessary for Application Intelligence ............ 162
SmartDefense Services.............................................................................. 162
How SmartDefense Works .......................................................................... 164
Categorizing SmartDefense Capabilities ...................................................... 164
The SmartDefense Tree Structure ............................................................... 166
SmartDefense Profiles .................................................................................... 173
Profile Cloning.......................................................................................... 173
Logging.................................................................................................... 174
Configuring SmartDefense .............................................................................. 175
Updating SmartDefense with the Latest Defenses ........................................ 175
Staying Vigilant ........................................................................................ 175
SmartDefense Services................................................................................... 176
Download Updates .................................................................................... 176
Advisories ................................................................................................ 177
Security Best Practices.............................................................................. 178
Configuring SmartDefense Profiles .................................................................. 179
Creating Profiles ....................................................................................... 179
Assign a Profile to the Gateway .................................................................. 179
View Protected Gateways by a Profile .......................................................... 180
SmartDefense StormCenter Module ................................................................. 181
The Need for Cooperation in Intrusion Detection .......................................... 181
Check Point Solution for Storm Center Integration ....................................... 182
Planning Considerations ............................................................................ 186
Configuring Storm Center Integration .......................................................... 187
Application Intelligence
Chapter 7
Anti Virus Protection
Introduction to Integrated Anti Virus Protection ................................................ 194
Architecture .................................................................................................. 195
Configuring Integrated Anti Virus Scanning ...................................................... 196
Signature Update Mechanism ......................................................................... 197
Understanding Scan By Direction and Scan By IP ............................................. 198
Definition of Scan By Direction and Scan By IP ........................................... 198
Comparing Scan by Direction and by IP ...................................................... 199
Scanning by Direction: Choosing the Data to Scan ............................................ 203
8
What is a DMZ? ........................................................................................ 203
Scan By Direction Options ......................................................................... 203
File Type Recognition..................................................................................... 206
Continuous Download..................................................................................... 207
Logging and Monitoring .................................................................................. 208
File Size Limitations and Scanning.................................................................. 209
General Settings ....................................................................................... 209
File Handling ........................................................................................... 209
Archive File Handling ................................................................................ 210
Scan Failure............................................................................................. 210
VPN-1 UTM Edge Anti Virus ........................................................................... 211
Chapter 8
Securing Voice Over IP (VoIP)
The Need to Secure Voice Over IP ................................................................... 214
Introduction to the Check Point Solution for Secure VoIP................................... 215
Control Signalling and Media Protocols ............................................................ 216
VoIP Handover............................................................................................... 217
When to Enforce Handover......................................................................... 218
VoIP Application Intelligence .......................................................................... 219
Introduction to VoIP Application Intelligence ............................................... 219
Restricting Handover Locations using a VoIP Domain ................................... 220
Controlling Signalling and Media Connections ............................................. 221
Preventing Denial of Service Attacks........................................................... 221
Protocol Specific Application Intelligence ................................................... 222
VoIP Logging ................................................................................................. 223
Protocol-Specific Security: SIP, H.323, MGCP and SCCP .................................. 224
Securing SIP Based VoIP................................................................................ 225
SIP Architectural Elements in the Security Rule Base .................................. 225
Supported SIP RFCs and Standards............................................................ 226
Secured SIP Topologies and NAT Support ................................................... 227
Application Intelligence for SIP.................................................................. 228
SmartDefense Application Intelligence Settings for SIP ................................ 229
Synchronizing User Information.................................................................. 230
SIP Services............................................................................................. 231
Using SIP on a Non-Default Port ................................................................ 231
ClusterXL and Multicast Support for SIP ..................................................... 232
Securing SIP-Based Instant Messenger Applications .................................... 232
Configuring SIP-Based VoIP ....................................................................... 232
Troubleshooting SIP....................................................................................... 237
Securing H.323-Based VoIP ........................................................................... 238
H.323 Architectural Elements in the Security Rule Base .............................. 238
Supported H.323 RFCs and standards ........................................................ 239
Secured H.323 Topologies and NAT Support............................................... 239
Application Intelligence for H.323.............................................................. 242
SmartDefense Application Intelligence Settings for H.323 ............................ 243
H.323 Services ........................................................................................ 245
Configuring H.323-Based VoIP................................................................... 246
Securing MGCP-Based VoIP............................................................................ 261
Table of Contents
9
The Need for MGCP .................................................................................. 261
MGCP Protocol and Devices ....................................................................... 262
MGCP, SIP and H.323 .............................................................................. 263
MGCP Network Security and Application Intelligence ................................... 264
Configuring MGCP-Based VoIP ................................................................... 266
Securing SCCP-Based VoIP............................................................................. 271
The SCCP Protocol.................................................................................... 271
SCCP Devices........................................................................................... 272
SCCP Network Security and Application Intelligence .................................... 272
ClusterXL Support for SCCP ....................................................................... 273
Configuring SCCP-Based VoIP .................................................................... 273
Chapter 9
Securing Instant Messaging Applications
The Need to Secure Instant Messenger Applications ......................................... 280
Introduction to Instant Messenger Security....................................................... 281
Understanding Instant Messengers Security ..................................................... 282
NAT Support for MSN Messenger over SIP ....................................................... 283
NAT Support for MSN Messenger over MSNMS ................................................ 284
Logging Instant Messenger Applications........................................................... 285
Configuring SIP-based Instant Messengers ....................................................... 286
Configuring MSN Messenger over MSNMS ....................................................... 288
Configuring Skype, Yahoo and ICQ and Other Instant Messengers....................... 289
Chapter 10
Microsoft Networking Services (CIFS) Security
Securing Microsoft Networking Services (CIFS)................................................. 292
Restricting Access to Servers and Shares (CIFS Resource) ................................. 293
Chapter 11
FTP Security
Introduction to FTP Content Security ............................................................... 296
FTP Enforcement by the VPN-1 Power kernel ................................................... 297
FTP Enforcement by the FTP Security Server.................................................... 298
Control the Allowed Protocol Commands ..................................................... 298
Maintaining Integrity of Other Protected Services ......................................... 298
Avoiding Vulnerabilities in FTP Applications ................................................ 298
Content Security via the FTP Resource........................................................ 298
Configuring Restricted Access to Specific Directories ........................................ 299
Chapter 12
CVP and UFP Content Security
The Need for Content Security ........................................................................ 302
Check Point Solution for Content Security ........................................................ 303
Introduction to Content Security................................................................. 303
Security Servers........................................................................................ 304
Deploying OPSEC Servers .......................................................................... 305
CVP Servers for Anti-Virus and Malicious Content Protection ......................... 306
Using URL Filtering (UFP) to Limit Web Surfers .......................................... 309
The TCP Security Server ............................................................................ 312
Configuring Content Security .......................................................................... 313
10
Resources: What They Are and How to Use Them......................................... 313
Creating a Resource and Using it in the Rule Base ....................................... 314
Configuring Anti-Virus Checking for Incoming Email ..................................... 315
Configuring CVP Checking for Web Traffic with Improved Performance........... 317
Configuring URL Filtering with a UFP Server ............................................... 318
Performing CVP or UFP Inspection on any TCP Service................................. 321
Advanced CVP Configuration: CVP Chaining and Load Sharing ........................... 322
Introduction to CVP Chaining and Load Sharing ........................................... 322
CVP Chaining ........................................................................................... 322
CVP Load Sharing ..................................................................................... 324
Combining CVP Chaining and Load Sharing ................................................. 325
Configuring CVP Chaining and Load Sharing................................................ 325
Chapter 13
Services with Application Intelligence
Introduction to Services with Application Intelligence........................................ 328
DCE-RPC ...................................................................................................... 329
SSLv3 Service ............................................................................................... 330
SSHv2 Service .............................................................................................. 331
FTP_BASIC Protocol Type............................................................................... 332
Domain_UDP Service ..................................................................................... 333
Point-to-Point Tunneling Protocol (PPTP) ......................................................... 334
Configuration for PPTP .............................................................................. 334
Blocking Visitor Mode (TCPT).......................................................................... 336
Introduction to TCPT ................................................................................. 336
Why Block Visitor Mode and Outgoing TCPT?............................................... 336
How VPN-1 Power identifies TCPT.............................................................. 336
When to Block Outgoing TCPT.................................................................... 336
Configuration of Visitor Mode Blocking........................................................ 337
Web Security
Chapter 14
Web Intelligence
The Need for Web Attack Protection ................................................................ 342
The Web Intelligence Solution for Web Attack Protection ................................... 343
Web Intelligence Technologies ........................................................................ 344
Web Intelligence Online Updates..................................................................... 345
Web Intelligence Security and Usability ........................................................... 346
Web Server Focused Security ..................................................................... 346
Enforcement Granularity ............................................................................ 346
Configuration Flexibility............................................................................. 347
Variable Security Levels............................................................................. 348
Monitor-Only Mode ................................................................................... 348
Customizable Error Page............................................................................ 349
Web Intelligence Protections........................................................................... 351
Table of Contents
11
Web Intelligence and ClusterXL Gateway Clusters ........................................ 351
Web Content Protections ................................................................................ 352
Understanding HTTP Sessions, Connections and URLs...................................... 353
HTTP Request Example............................................................................. 353
HTTP Response Example........................................................................... 354
HTTP Connections .................................................................................... 354
Understanding URLs ................................................................................. 355
Connectivity Versus Security Considerations ..................................................... 356
Monitor-Only Mode ................................................................................... 356
Protection for Specific Servers ................................................................... 356
Variable Security Levels............................................................................. 356
Connectivity Implications of Specific Protections ......................................... 356
Web Security Performance Considerations........................................................ 358
Protections Implemented in the Kernel Vs. Security Server ........................... 358
Protections with a Higher Performance Overhead ......................................... 359
Adjusting the Number of Allowed Concurrent HTTP Connections ................... 359
Backward Compatibility Options for HTTP Protocol Inspection ........................... 360
Web Intelligence License Enforcement ............................................................ 361
Chapter 15
Web Content Protection
Introduction to Web Content Protection ........................................................... 364
Web Content Security via the Security Rule Base .............................................. 365
What is a URI Resource? ........................................................................... 365
Filtering URLs, Schemes and Methods by Source and Destination ................. 365
Basic URL Filtering................................................................................... 366
URL Logging ............................................................................................ 366
Java and ActiveX Security .......................................................................... 367
Securing XML Web Services (SOAP) ................................................................ 368
Understanding HTTP Sessions, Connections and URLs...................................... 369
HTTP Request Example............................................................................. 369
HTTP Response Example........................................................................... 370
HTTP Connections .................................................................................... 370
Understanding URLs ................................................................................. 371
Connectivity Versus Security Considerations for Web Surfers .............................. 372
Allowing or Restricting Content .................................................................. 372
Content Compression ................................................................................ 373
Factors that Affect HTTP Security Server Performance ...................................... 374
The Number of Simultaneous Security Server Connections............................ 374
How To Run Multiple Instances of the HTTP Security Server......................... 375
Configuring Web Content Protection ................................................................ 376
Blocking URL-based Attacks using a URI Resource ...................................... 376
Configuring URL Logging........................................................................... 377
Configuring Basic URL Filtering ................................................................. 378
12
Appendices
Appendix A
Security Before
VPN-1 Power Activation
Achieving Security Before VPN-1 Power Activation............................................ 382
Boot Security ................................................................................................ 383
Control of IP Forwarding on Boot ................................................................ 383
The Default Filter...................................................................................... 383
The Initial Policy ........................................................................................... 386
Default Filter and Initial Policy Configuration ................................................... 389
Verifying the Default Filter or Initial Policy is Loaded ................................... 389
Change the Default Filter to a Drop Filter .................................................... 390
User-Defined Default Filter ........................................................................ 390
Using the Default Filter for Maintenance ..................................................... 390
To Unload a Default Filter or an Initial Policy .............................................. 391
If You Cannot Complete Reboot After Installation......................................... 391
Command Line Reference for Default Filter and Initial Policy ........................ 392
Appendix B
VPN-1 Power Command Line Interface
Index........................................................................................................... 403
Table of Contents
13
14
Preface
P
Preface
In This Chapter
Who Should Use This Guide
page 16
Summary of Contents
page 17
Related Documentation
page 21
More Information
page 24
15
Who Should Use This Guide
Who Should Use This Guide
This guide is intended for administrators responsible for maintaining network
security within an enterprise, including policy management and user support.
This guide assumes a basic understanding of
16
•
System administration.
•
The underlying operating system.
•
Internet protocols (IP, TCP, UDP etc.).
Summary of Contents
Summary of Contents
This guide describes the firewall and SmartDefense components of VPN-1 Power. It
contains the following sections and chapters:
Section 1: Network Access
This section describes how to secure the networks behind the VPN-1 Power
enforcement point by allowing only permitted users and resources to access
protected networks.
Chapter
Description
Chapter 1, “Access Control”
How to set up a security policy that fits the
organizational requirements.
Chapter 2, “Authentication”
The available VPN-1 Power authentication
schemes (for username and password
management), and authentication methods (how
users can authenticate themselves).
Preface
17
Section 2: Connectivity
Section 2: Connectivity
This section describes how to give internal users and resources unrestricted yet
secure connectivity across the enforcement point.
Chapter
Description
Chapter 3, “Network Address
Translation (NAT)”
Network Address Translation (NAT) involves
replacing one IP address with another. NAT can
change both the source and destination address
inside the packet. It is used for both security
and administrative reasons.
Chapter 4, “ISP
Redundancy”
ISP Redundancy assures reliable Internet
connectivity by allowing a single or clustered
VPN-1 Power gateway to connect to the Internet
via redundant Internet Service Provider (ISP)
links.
Chapter 5, “ConnectControl Server Load Balancing”
ConnectControl is a server load balancing
solution. Use it to distribute network traffic
among a number of servers, which reduces the
load on a single machine, improves network
response time, and provides high availability.
Section 3: SmartDefense
This chapter gives a conceptual overview of SmartDefense, which enables
customers to configure, enforce and update network and application attack
defenses. The DShield StormCenter is also described in detail. For information
about specific protections, see the SmartDefense HTML pages and the online
help.
18
Chapter
Description
Chapter 6, “SmartDefense”
SmartDefense actively defends your network,
even when the protection is not explicitly
defined in the Security Rule Base. It
unobtrusively analyzes activity across your
network, tracking potentially threatening events
and optionally sending notifications. It protects
organizations from all known, and most
unknown, network attacks using intelligent
security technology.
Section 4: Application Intelligence
Section 4: Application Intelligence
Check Point Application Intelligence is a set of advanced capabilities,
integrated into VPN-1 Power and SmartDefense, which detect and prevent
application-level attacks. This section describes how to protect against
application-level attacks for each application protocol, and how to work with
anti-virus (CVP) and URL filtering (UFP) applications.
Chapter
Description
Chapter 7, “Anti Virus
Protection”
Check Point Express CI (Content Inspection)
gateways include integrated Anti Virus
technology. Anti Virus protection is available for
the HTTP, FTP, SMTP and POP3 protocols.
Options for each protocol can be centrally
configured.
Chapter 8, “Securing Voice
Over IP (VoIP)”
How to secure VoIP traffic in H.323, SIP, MGCP
and SCCP environments.
Chapter 9, “Securing Instant
Messaging Applications”
How to secure SIP-based Instant Messenger, and
MSN Messenger in particular.
Chapter 10, “Microsoft
Networking Services (CIFS)
Security”
How to secure Microsoft Networking (CIFS)
Services by restricting access to servers and
shares.
Chapter 11, “FTP Security”
How to provide FTP content security and
configure restricted access to specific
directories.
Chapter 12, “CVP and UFP
Content Security”
How to integrate with third-party OPSECcertified antivirus applications and URL filtering
applications.
Chapter 13, “Services with
Application Intelligence”
How to configure protection for some of the
predefined TCP services that perform content
inspection.
Preface
19
Section 5: Web Security
Section 5: Web Security
This section describes the VPN-1 Power Web Content capabilities, and the Web
Intelligence add-on for VPN-1 Power that provides high performance attack
protection for web servers and applications.
Chapter
Description
Chapter 14, “Web
Intelligence”
Understanding Web Intelligence, which allows
customers to configure, enforce and update
attack protections for web servers and
applications, against known and unknown
attacks.
Chapter 15, “Web Content
Protection”
Understanding the integrated web security
capabilities that are configured via the Security
Rule Base, and how to secure XML Web Services
(SOAP) on Web Servers.
Appendices
This section describes how the VPN-1 Power machine protects itself and the
networks behind it upon activation, and the command line interface.
20
Appendix
Description
Appendix A, “Security Before
VPN-1 Power Activation”
Sometimes a computer does not yet have a
VPN-1 Power Security Policy installed, and is
vulnerable. Two features provide security during
these situations: Boot Security, and the Initial
Policy.
Appendix B, “VPN-1 Power
Command Line Interface”
A brief summary of the command line
commands relate to the firewall components of
VPN-1 Power.
Related Documentation
Related Documentation
The NGX R62 release includes the following documentation
TABLE P-1
VPN-1 Power documentation suite documentation
Title
Description
Getting Started Guide
Contains an overview of NGX R62 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
R62.
SmartCenter 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 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
Eventia Reporter
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.
Preface
21
Related Documentation
TABLE P-1
Title
Description
SmartView Tracker
Guide.
Provides information about how to collect
comprehensive information on your network activity in
the form of logs. Learn how to use SmartView Tracker
to audit these logs at any given time, analyze traffic
patterns and troubleshoot networking and security
issues.
SecurePlatform Guide
Explains how to install and configure SecurePlatform.
This guide will also teach you how to manage your
SecurePlatform and explains Dynamic Routing
(Unicast and Multicast) protocols.
Provider-1 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
22
VPN-1 Power documentation suite documentation (continued)
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.
Related Documentation
TABLE P-2
Integrity Server 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.
Preface
23
More Information
More Information
24
•
For additional technical information about Check Point products, consult Check
Point’s SecureKnowledge at https://secureknowledge.checkpoint.com/.
•
See the latest version of this document in the User Center at
http://www.checkpoint.com/support/technical/documents/
Network Access
This section describes how to secure the networks behind the VPN-1 Power
enforcement point by allowing only permitted users and resources to access
protected networks.
Chapter
Access Control
1
In This Chapter
The Need for Access Control
page 28
Solution for Secure Access Control
page 29
Considerations for Access Control
page 39
Configuring Access Control
page 42
27
The Need for Access Control
The Need for Access Control
As a network administrator you 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 job of authorization, or Access
Control. Determining “who” can access these resources is the job of user
authentication, described in Chapter 2, “Authentication”.
28
Solution for Secure Access Control
Solution for Secure Access Control
In This Section
Access Control at the Network Boundary
page 29
The Security Rule Base
page 30
Example Access Control Rule
page 31
Rule Base Elements
page 31
Implied Rules
page 32
Preventing IP Spoofing
page 33
Multicast Access Control
page 35
Access Control at the Network Boundary
A VPN-1 Power Gateway (a “firewall”) at a network boundary acts as an
enforcement point that inspects and provides access control for all traffic passing
through the gateway (Figure 1-1). Traffic that does not pass though the
enforcement point is not controlled.
Figure 1-1 A VPN-1 Power enforcement point inspects all traffic that cross it
The VPN-1 Power administrator is responsible for implementing the company
Security Policy. VPN-1 Power allows the company Security Policy to be consistently
enforced across multiple firewalls. To achieve this, an enterprise-wide Security
Policy Rule Base is defined at the SmartCenter Server central SmartCenter console.
The SmartDashboard SmartConsole Client is used to install the Policy, and
distribute it to the VPN-1 Power Gateways. Granular control of the Policy is
possible by having specific rules apply only on specific enforcement points.
Chapter 1
Access Control
29
Solution for Secure Access Control
VPN-1 Power provides secure access control through its granular understanding of
all underlying services and applications traveling on the network. Stateful
Inspection technology provides full application-layer awareness, and comprehensive
access control for more than 150 pre-defined 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 layers and maintains this information in dynamic state tables
for evaluating subsequent connection attempts. For complete technical information
about Stateful Inspection, see the Check Point Tech. Note at
http://www.checkpoint.com/products/downloads/firewall-1_statefulinspection.pdf
The Security Rule Base
The Security Policy is implemented by defining an ordered set of rules in the
Security Rule Base. A well-defined Security Policy is essential in order for VPN-1
Power to be an effective security solution.
The fundamental concepts of the Security Rule Base is “That which is not
explicitly permitted is prohibited”.
The Rule Base specifies what communication will be allowed to pass and what will
be blocked. It specifies the source and destination of the communication, what
services can be used, at what times, whether to log the connection and the logging
level. Reviewing SmartView Tracker traffic logs is a very important aspect of
security management, and should get careful attention.
VPN-1 Power works by inspecting packets in a sequential manner. When VPN-1
Power receives a packet belonging to a connection, it compares it against the first
rule in the Security Rule Base, then the second, then the third, and so on. When it
finds a rule that matches, it stops checking and applies that rule. If the packet
goes through all the rules without finding a match, then that packet is denied. It is
important to understand that the first rule that matches is applied to the packet,
not the rule that best matches.
30
Solution for Secure Access Control
Example Access Control Rule
Figure 1-2 shows a typical Access Control rule. It says that HTTP connections that
originate in one of Alaska_LAN group of hosts, to any destination, will be accepted,
and logged.
Figure 1-2 Example Access Control Rule
Rule Base Elements
A rule is made up of a number of Rule Base elements. Not all fields are always
relevant in a given rule.
Table 1-1
Rule Base elements
Source and
Destination
The source and destination is with respect to the originator of the connection.
For applications that work in the client server model, the source is the client.
Once the connection is accepted, packets in the connection are allowed in
both directions.
Source and destination can also be negated. You may for example find it
convenient to specify that the source is NOT in a given network.
VPN
Configure whether the rule applies to any connection, either encrypted or
clear, or only to VPN connections. To limit this rule to VPN connections,
right-click and select Replace... .
Service
The service column allows predefined applications to be specified. It is also
possible to define new services.
Action
A packet can either be Accepted, Rejected, or Dropped. The other possible
Actions relate to authentication (see Chapter 2, “Authentication” on
page 109). If a connection is Rejected, the firewall sends a RST packet to
the originating end of the connection and the connection is closed. If a
packet is Dropped then no response is sent and the connection will eventually
time out.
Chapter 1
Access Control
31
Solution for Secure Access Control
Table 1-1
Rule Base elements
Track
Various logging options are available. See the SmartCenter guide.
Install-On
Specifies the VPN-1 Power Gateways on which the rule is to be installed.
There may be no need to enforce a particular rule at every VPN-1 Power
Gateway. For example, a rule may allow certain network services to cross one
particular gateway. If these services are not to be allowed to networks behind
other VPN-1 Power Gateways, the rule need not be installed on other
gateways. For further information, see the SmartCenter guide.
Time
Specify the days and time of day at which this rule should be enforced.
Implied Rules
The Security Policy is made up of rules. Apart from the rules defined by the
administrator, VPN-1 Power also creates Implied Rules, which are derived from the
Policy Global Properties. Implied rules are defined by VPN-1 Power to allow certain
connections to and from the firewall with a variety of different services. Examples
of two important implied rules are ones that enable
•
VPN-1 Power Control Connections
•
Outgoing Packets originating from the VPN-1 Power Gateway
There are also implied rules for other possible connection scenarios.
VPN-1 Power creates a group of implied rules from the Policy Global Properties,
that it places first, last, or before last in the Security Rule Base defined by the
administrator. Implied rules can be logged. The rules are therefore processed in the
following order:
1. Implied Rules defined as first. If an implied rule is first, the implied rule cannot
be modified or overwritten in the Security Rule Base, because the first rule that
matches is always applied to packet, and no rules can be placed before it.
2. Explicit, administrator-defined rules 1 through n-1 in the Rule Base (assuming
n rules).
3. Implied Rules listed as Before Last. Setting a property to Before Last makes it
possible to define more detailed rules that will be enforced before this property.
4. Last explicitly defined rule (Rule n).
5. Implied Rules listed as Last. If a property is Last, it is enforced after the last rule
in the Security Rule Base, which usually rejects all packets, and it will typically
have no effect.
6. Implicit Drop Rule (no logging occurs).
32
Solution for Secure Access Control
Preventing IP Spoofing
Spoofing is a technique where an intruder attempts to gain unauthorized access by
altering a packet's IP address to make it appear as though the packet originated in
a part of the network with higher access privileges. It is important to make sure
that the communication does in fact originate from the apparent source.
Anti-spoofing verifies that packets are coming from, and going to, the correct
interfaces on the gateway. It confirms that packets claiming to be from an 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.
A packet coming from an external interface, even if it has a spoofed internal IP
address, will be blocked because the VPN-1 Power anti-spoofing feature detects
that the packet arrived from the wrong interface.
Figure 1-3 illustrates what anti-spoofing does.
On Alaska_GW, VPN-1 Power checks 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 Power checks that:
•
All incoming packets to interface IF3 come from Alaska_LAN or Florida_LAN or
the Internet.
•
All incoming packets to interface IF4 come from Alaska_RND_LAN.
When configuring anti-spoofing, you also need to specify (in the interface topology
definitions) whether the interfaces lead to the Internet, in which case they must be
defined as External, or whether they lead to an internal network, in which case they
are defined as Internal. Figure 1-3 illustrates whether the gateway interfaces are
Internal or External.
Chapter 1
Access Control
33
Solution for Secure Access Control
Figure 1-3
Illustrating Anti-Spoofing
Excluding Specified Internal Addresses from
Anti-Spoofing Checks
In certain scenarios, it may be necessary to allow packets with source addresses
that belong in an internal network to come in to the gateway via an external
interface. This could be useful if an external application assigns internal IP
addresses to external clients.
In this case, it is possible to 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
come into interface IF1.
What are the Legal Addresses
Legal addresses are those that are allowed to enter a VPN-1 Power interface. Legal
addresses are determined by the topology of the network. When configuring
Anti-Spoofing protection, the administrator must tell VPN-1 Power what are the
legal IP addresses behind the interface. This can be done automatically using the
Get Interfaces with Topology option which automatically defines the interface with its
topology, and creates network objects. VPN-1 Power obtains this information by
reading routing table entries.
34
Solution for Secure Access Control
More information about Anti-spoofing Protection
•
For planning considerations, see “Spoof Protection” on page 39.
•
For configuration details, see “Configuring Anti-Spoofing” on page 43.
Multicast Access Control
In This Section
Introduction to Multicast IP
page 35
Multicast Routing Protocols
page 36
Dynamic Registration Using IGMP
page 36
IP Multicast Group Addressing
page 36
Per Interface Multicast Restrictions
page 37
Introduction to Multicast IP
Multicast is used to transmit a single message to a select group of recipients. A
typical use of multicast is to distribute real time audio and video to a set of hosts
which have joined a distributed conference.
Multicast is much like radio or TV where only those who have tuned their receivers
to a selected frequency receive the information. In 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 addresses
datagrams to a group of receivers (at the multicast address) rather than to a single
receiver (at a unicast address). The routers in the network forward the datagrams to
only those routers and hosts that need to receive them.
The Internet Engineering Task Force (IETF) has developed standards to support
multicast communications. These standards define
•
Multicast Routing Protocols
•
Dynamic registration
•
IP Multicast Group Addressing
Chapter 1
Access Control
35
Solution for Secure Access Control
Multicast Routing Protocols
Multicast enabled routers use multicast routing protocols to communicate multicast
group information with each other.
Examples of multicast routing protocols include Protocol-Independent Multicast
(PIM), Distance Vector Multicast Routing Protocol (DVMRP), and Multicast
Extensions to OSPF (MOSPF).
Dynamic Registration Using IGMP
Hosts use the Internet Group Management Protocol (IGMP) to update the nearest
multicast router as to whether or not they wish 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 space is divided into 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 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 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.
36
Solution for Secure Access Control
Reserved Local Addresses
Multicast group addresses in the range 224.0.0.0 through 224.0.0.255 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. Some examples of reserved
Local Network Multicast Groups are shown in Table 1-2.
Table 1-2
Some examples of Local Network Multicast Groups
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 its multicast capable interfaces.
224.0.0.2
All routers. All multicast routers must join this group on all
its multicast capable interfaces.
224.0.0.4
The group of all DVMRP routers
224.0.0.5
All OSPF routers
224.0.0.13
All PIM routers
More information about reserved multicast addresses can be found at
http://www.iana.org/assignments/multicast-addresses.
Per Interface Multicast Restrictions
A multicast enabled router forwards multicast datagrams from one interface to
another. When multicast is enabled on a VPN-1 Power Gateway running on
SecurePlatform, you can define multicast access restrictions on each interface (see
Figure 1-5). These restrictions specify multicast groups (that is, addresses or
address ranges) to allow or block. The enforcement is performed on outgoing
multicast datagrams.
When access is denied to a multicast group on an interface in the outbound
direction, IGMP packets destined to the group will be denied on that interface in
the inbound direction.
Chapter 1
Access Control
37
Solution for Secure Access Control
Figure 1-5
Gateway with per-interface multicast restrictions
When no restrictions for multicast datagrams are defined, multicast datagrams
entering the gateway on one interface are allowed out of all others.
As well as defining a per-interface restrictions, a rule must also be defined in the
Security Rule Base that allows multicast traffic and required services. The
Destination of this rule must allow the required multicast groups.
For configuration details, see “Configuring Multicast Access Control” on page 44.
VPN connections
Multicast traffic can be encrypted and sent across VPN links that are defined using
multiple VPN tunnel interfaces (virtual interfaces associated with the same physical
interface).
38
Considerations for Access Control
Considerations for Access Control
In This Section
Spoof Protection
page 39
Simplicity
page 39
Basic Rules
page 40
Rule Order
page 40
Topology Considerations: DMZ
page 40
The X11 Service
page 41
When to Edit Implied Rules
page 41
Spoof Protection
If you don’t protect your network against address spoofing, all your carefully crafted
access control rules will be ineffective. It is easy enough for a malicious user to
attempt to gain access by changing the source address of the packet. Make sure
you configure anti-spoofing protection on every interface of the VPN-1 Power
Gateway, including internal interfaces. For configuration details, see “Configuring
Anti-Spoofing” on page 43.
Simplicity
The key to a secure firewall is a simple Rule Base. The biggest danger to the
security of your organization can be simple misconfiguration. Why should a
malicious user try to sneak spoofed, fragmented packets past your firewall when
you have accidentally allowed unrestricted messaging protocols? To keep your Rule
Base simple, keep it short. The more rules you have, the more likely you will make
a mistake. The fewer rules your Rule Base has, the easier it is to understand and
maintain.
Chapter 1
Access Control
39
Considerations for Access Control
Basic Rules
Be careful to allow only the traffic that you want. Consider both traffic crossing the
firewall that is initiated on the unprotected side of the firewall, and traffic initiated
on the protected side of the firewall.
The following basic Access Control rules are recommended in every Security Rule
Base:
•
A Stealth Rule to prevent any direct access to the VPN-1 Power Gateway.
•
A Cleanup Rule to drop all traffic that is not permitted by the previous rules.
There is an implied rule that does this, but the Cleanup Rule allows you to log
any access attempts.
Remember the fundamental concept of a Rule Base: “That which is not explicitly
permitted is prohibited”.
Rule Order
Rule order is critical. Having the same rules, but placing them in a different order,
can radically alter how your firewall works. It is therefore best to place the more
specific rules first, the more general rules last. This prevents a general rule being
matched before a more specific rule, and protects your firewall from
misconfigurations.
Topology Considerations: DMZ
If you have servers that are externally accessible from the internet, you should
create a demilitarized zone (DMZ). Servers in the DMZ are accessible from any
network, and all externally accessible servers should be in the DMZ. The purpose of
the DMZ is to isolate all servers that are accessible from untrusted sources, like the
Internet, so that if someone compromises one of those servers, the intruder will
have only limited access to externally accessible servers. Servers in the DMZ should
be as secure as possible. Do not allow the DMZ to initiate connections into the
internal network, other than for specific applications such as UserAuthority.
40
Considerations for Access Control
The X11 Service
The X11 (X Window System Version 11) graphics display system is the de-facto
graphics system in the Unix world. To allow X11, you must create a specific rule
using the X11 service. When selecting Any as the Source or Destination, the X11
service is not included. This is because of the unusual nature of X11, by which the
GUI application actually acts as the server, rather than the client.
When to Edit Implied Rules
Implied rules are controlled from the Global Properties window FireWall Implied
Rules page. In general, there is no need to change them. Some are best left
unselected so that the property can be controlled with greater granularity via the
Rule Base. For example, you may wish to allow ICMP pings across certain gateways
only. The following are the recommended settings:
Table 1-3
FireWall Implied Rules recommended settings
Implied Rule
Recommended Setting
Accept VPN-1 Power/UTM Control Connections
First
Accept Remote Access control connections
First
Accept SmartUpdate connections
First
Accept outgoing packets originating from
gateway
Unselected
Accept RIP
Unselected
Accept Domain Name Over UDP (Queries)
Unselected
Accept Domain Name over TCP (Zone transfer)
Unselected
Accept ICMP requests
Unselected
Accept dynamic address Modules’ DHCP traffic
First
Accept VRRP packets originating from cluster
members (VSX Nokia VRRP)
First
Chapter 1
Access Control
41
Configuring Access Control
Configuring Access Control
In This Section
Defining Access Control Rules
page 42
Defining a Basic Policy
page 42
Configuring Anti-Spoofing
page 43
Configuring Multicast Access Control
page 44
Defining Access Control Rules
An example Access control Rule is shown in Figure 1-2 on page 31. To define a
rule:
1. Define the network objects for each network and host (for details, see
SmartCenter guide).
2. From the menu, select Rules > Add Rule and choose one of Bottom, Top, Below,
Above.
3. In the Source and Destination columns, right click and select Add..., choose a
network object and click OK.
4. In the Service column, right click, select Add..., choose a service or a service
group, and click OK.
5. In the Action column, right click and select Accept, Drop, or Reject.
6. In the Track column, right click, select Add... and choose one of the tracking
options.
Defining a Basic Policy
Figure 1-6 shows a network requiring an Access Control policy.
42
Configuring Access Control
Figure 1-6
Sample network requiring an Access Control Policy
The Access Control Policy is required to
1. Allow internal users access to the World Wide Web.
2. Allow all users access to the servers on the DMZ network.
3. Protect the network from outsiders.
The Policy also requires two basic rules: a Stealth Rule and a Cleanup Rule
To create the Policy, add rules in the SmartDashboard using the Rules > Add Rules...
menu items, as detailed in “Defining a Basic Policy” on page 42. Figure 1-7 shows
the resulting Access Control Security Rule Base.
Figure 1-7 Typical Access Control Security Rule Base
Configuring Anti-Spoofing
Make sure you configure anti-spoofing protection on every interface of every VPN-1
Power Gateway, including internal interfaces. This basic configuration example
shows how to set up anti-spoofing parameters on an external interface and the
internal interface.
Chapter 1
Access Control
43
Configuring Access Control
Define a Valid Address for the External Interface
1. In SmartDashboard, select Manage > Network Objects.
2. Select the Check Point Gateway and right click Edit.
3. In the Properties list, click Topology.
4. Click Get > Interfaces to read the interface information on the gateway machine.
5. Select the interface that faces the Internet and click Edit.
6. In the Interface Properties window, click Topology, and select External (leads out
to the internet).
7. Check Perform Anti-Spoofing based on interface topology.
8. To ensure Anti-Spoofing checks do not take place for addresses from certain
internal networks coming into the external interface, define a network object
that represents those internal networks, select Don't check packets from:, and
from the drop-down list, select that network object.
9. Under Spoof Tracking select Log, and click OK.
Define a Valid Address for Internal Interfaces
10. Under the name column, select the internal interface, click Edit.
11. In the Interface Properties window, click Topology, and click Internal (leads to the
local network).
12. Under IP Addresses behind this interface:
•
If there is only one network behind the interface, choose Network defined by
the interface IP and Net Mask.
•
If there is more than one network behind the interface, define a Group
Network object that comprises all the networks behind the interface, choose
Specific and select the group.
13. Check Perform Anti-Spoofing based on interface topology, under Spoof Tracking
select Log, and click OK.
14. Repeat step 10 to step 13 for all internal interfaces.
15. Install the Security Policy.
Configuring Multicast Access Control
For background information about Multicast access control see “Multicast Access
Control” on page 35. To configure Multicast access control, proceed as follows:
44
Configuring Access Control
1. In the Gateway General Properties page, ensure the Gateway version is correctly
specified. A per-interface multicast policy can be defined for Gateways of
version R60 or higher.
2. In the Topology page, edit an interface.
3. In the Interface Properties window, Multicast Restrictions tab (Figure 1-8), check
Drop Multicast packets by the following conditions.
Figure 1-8 Interface Properties window, Multicast Restrictions tab
4. Define either a restrictive or a permissive multicast policy for the interface. You
can either
•
Drop multicast packets whose destination is in the list, or
•
Drop all multicast packets except those whose destination is in the list
5. Click New to add a multicast address range. In the Multicast Address Range
Properties window, define either an IP address Range or a Single IP Address that
are in the range 224.0.0.0 to 239.255.255.255.
6. In the Security Rule Base, add a rule to allow the required multicast groups. In
the Destination of the rule specify the multicast groups defined in step 5.
7. Save and install the Security Policy.
Chapter 1
Access Control
45
Configuring Access Control
46
Chapter
Authentication
2
In This Chapter
The Need for Authentication
page 48
VPN-1 Power Solution for Authentication
page 49
Configuring Authentication
page 63
47
The Need for Authentication
The Need for Authentication
People in different departments and with different levels of responsibility must be
given different access permissions to different parts of the network. It is therefore
necessary to allow access only to valid users. Determining who is a valid user is the
job of Authentication.
48
VPN-1 Power Solution for Authentication
VPN-1 Power Solution for Authentication
In This Section
Introduction to VPN-1 Power Authentication
page 49
Choosing an Authentication Method
page 50
Authentication Schemes
page 50
Authentication Methods
page 53
Introduction to VPN-1 Power Authentication
VPN-1 Power authenticates individual users via the use of credentials. VPN-1
Power can manage credentials using a number of different Authentication
Schemes. All Authentication Schemes in VPN-1 Power rely on some sort of
username and password. Some of these schemes involve storing the passwords on
the VPN-1 Power enforcement module. In other schemes, passwords are stored on
external servers.
There are three ways in which users that wish to access a network resource can
authenticate themselves to VPN-1 Power. The available Authentication Methods
are: User Authentication, Session Authentication, and Client Authentication. These
Authentication Methods can be used for unencrypted communication.
Authentication is also required for Remote Access communication using
SecuRemote/SecureClient.
Authentication ensures that the individual is who he or she claims to be, but says
nothing about the access rights of the individual.
Chapter 2
Authentication
49
VPN-1 Power Solution for Authentication
Choosing an Authentication Method
With User Authentication, the administrator can allow the user who is away from
his or her desk, to work on the local network without extending access to all users
on the same host. However, User Authentication is available only for the services
Telnet, FTP, HTTP, and RLOGIN.
Client Authentication is less secure than User Authentication because it allows
multiple users and connections from the authorized IP address or host. The
authorization is per machine. For example, if FINGER is authorized for a client
machine, then all users on the client are authorized to use FINGER, and will not be
asked to supply a password during the authorization period. For this reason, Client
Authentication is best enabled for single user machines.
The advantage of Client Authentication is that it can be used for any number of
connections, for any service, and the authentication can be set to be valid for a
specific length of time.
Session Authentication supplies an authentication mechanism for any service, and
requires users to supply their credentials per session. A Session Authentication
agent must be installed on every authenticating client. It is therefore not suitable
for authenticating HTTP, which opens multiple connections per session. Like Client
Authentication, use it only on single-user machines, where only one user can come
from a given IP at any one time.
Authentication Schemes
Authentication Schemes employ usernames and passwords to identify users. Some
of these schemes are maintained locally, storing the usernames and passwords on
the VPN-1 Power enforcement module. Others store the user database externally,
and authentication requests are directed to an external authentication server. Some
schemes, such as SecurID, are based on a one-time password. All the schemes can
be used with users defined on an LDAP server. For information on configuring
VPN-1 Power to integrate LDAP, see SmartDirectory (LDAP) and User Management
in the SmartCenter book.
Check Point Password
VPN-1 Power can store a static password in its local user database for each user
configured in SmartCenter Server. No additional software is needed.
50
VPN-1 Power Solution for Authentication
OS Password
VPN-1 Power can use the user and password information that is stored in the
operating system of the machine on which VPN-1 Power is installed. It is also
possible to use passwords that are stored in a Windows domain. No additional
software is needed.
RADIUS
Originally developed by Livingston Enterprises (now part of Lucent Technologies) in
1992, Remote Authentication Dial-In User Service (RADIUS) is an external
authentication scheme that provides security and scalability by separating the
authentication function from the access server. RADIUS was submitted to the
Internet Engineering Task Force (IETF) as a proposed standard protocol in 1996.
RFC 2865 is the latest update to the proposed standard, and can be found at URL:
www.ietf.org/rfc/rfc2865.txt.
When employing RADIUS as an authentication scheme, VPN-1 Power forwards
authentication requests by remote users to the RADIUS server. The RADIUS server,
which stores user account information, authenticates the users.
The RADIUS protocol uses UDP for communications with the gateway. RADIUS
Servers and RADIUS Server Group objects are defined in SmartDashboard. For
more on configuring RADIUS, see “Configuring a VPN-1 Power Gateway to use
RADIUS” on page 76.
SecurID
Developed by RSA Security, SecurID requires users to both possess a token
authenticator and to supply a PIN or password. Token authenticators generate
one-time passwords that are synchronized to an RSA ACE/Server, and may come in
the form of hardware or software. Hardware tokens are key-ring or credit card-sized
devices, while software tokens reside on the PC or device from which the user
wants to authenticate. All tokens generate a random, one-time-use access code that
changes every minute or so. When a user attempts to authenticate to a protected
resource, that one-time-use code must be validated by the ACE/Server.
When employing SecurID as an authentication scheme, VPN-1 Power forwards
authentication requests by remote users to the ACE/Server. ACE manages the
database of RSA users and their assigned hard or soft tokens. The VPN-1 Power
enforcement module acts as an ACE/Agent 5.0, which means that it directs all
access requests to the RSA ACE/Server for authentication. For agent configuration
see ACE/Server documentation.
Chapter 2
Authentication
51
VPN-1 Power Solution for Authentication
There are no scheme-specific parameters for the SecurID authentication scheme.
For more on configuring SecurID, see “Configuring a VPN-1 Power Gateway to use
SecurID” on page 79.
TACACS
Terminal Access Controller Access Control System (TACACS) provides access
control for routers, network access servers and other networked devices via one or
more centralized servers. TACACS was originally developed by the U.S. Department
of Defense and BBN Planet Corp. and then further developed by Cisco. A newer
version of the protocol called TACACS+ provides enhancements to the original
protocol, including the use of TCP instead of UDP.
TACACS is an external authentication scheme that provides verification services.
When employing TACACS as an authentication scheme, VPN-1 Power forwards
authentication requests by remote users to the TACACS server. The TACACS server,
which stores user account information, authenticates users. The system supports
physical card key devices or token cards, and supports Kerberos secret-key
authentication. TACACS encrypts the username, password, authentication services
and accounting information of all authentication requests for more secure
communications.
For information on configuring TACACS see “Configuring a VPN-1 Power Gateway to
use TACACS+” on page 80.
Undefined
The authentication scheme for a user can be specified as undefined. If a user with
an undefined authentication scheme is matched to a Security Rule with some form
of authentication, he or she is always denied access.
52
VPN-1 Power Solution for Authentication
Authentication Methods
In This Section
Introduction to Authentication Methods
page 53
User Authentication
page 54
Session Authentication
page 56
Client Authentication
page 57
Introduction to Authentication Methods
Instead of creating a security rule that simply allows or denies connections, the
firewall administrator can compel clients to authenticate when they try to access
specific network resources. There are three such Authentication Methods:
•
User Authentication.
•
Session Authentication.
•
Client Authentication.
These three Authentication Methods differ in services provided, logon mechanism,
and user experience. All can be configured to connect and authenticate clients
initially to the VPN-1 Power Gateway before passing the connection to the desired
resource, a process known as non-transparent authentication. Alternatively, they
can be configured to connect clients directly to the target server, a process known
as transparent authentication.
This section describes how the user authenticates using each of these methods,
and how they work. For details on setting up the different authentication methods,
see “Configuring Authentication” on page 63.
Chapter 2
Authentication
53
VPN-1 Power Solution for Authentication
User Authentication
User Authentication provides authentication for the services: Telnet, FTP, HTTP,
and rlogin. By default, User Authentication is transparent. The user does not
explicitly connect to the VPN-1 Power Gateway, but initiates a connection directly
to the target server.
The following example demonstrates a Telnet session to 10.11.12.13, with User
Authentication and the OS Password authentication scheme (Rlogin works in
almost exactly the same way):
# telnet 10.11.12.13
Trying 10.11.12.13...
Connected to 10.11.12.13.
Escape character is ‘^]’.
Check Point FireWall-1 authenticated Telnet server running on
tower
User: fbloggs
FireWall-1 password: *******
User fbloggs authenticated by FireWall-1 authentication
Connected to 10.11.12.13
...
...
login:
User Authentication works as follows:
1. VPN-1 Power intercepts the communication between the client and server.
2. VPN-1 Power prompts for a username and password.
3. If the user successfully authenticates, VPN-1 Power passes the connection on
to the remote host. If the correct authentication information is not supplied by
the user within the allowed number of connection attempts, the connection is
dropped.
4. The remote host prompts for its own username and password.
Note - When configuring user objects, you can set the locations that they are allowed to
access. This can lead to conflicts with security rules that require a form of authentication.
See “Resolving Access Conflicts” on page 71 for more information.
The following example demonstrates an FTP session to 10.11.12.13, with User
Authentication and the OS Password authentication scheme.
# ftp 10.11.12.13
Connected to 10.11.12.13.
220 london Check Point FireWall-1 Secure FTP server running on
tower
Name (10.11.12.13:fbloggs):
54
VPN-1 Power Solution for Authentication
Now the username must be entered in the following format:
FireWall-1 User@Destination Host
This format is demonstrated as follows:
fbloggs@10.11.12.13
331-aftpd: FireWall-1 password: you can use FW-1-password
Now enter the Check Point password:
Password: xyz987
230-aftpd: User fbloggs authenticated by FireWall-1
authentication.
230-aftpd: Connected to 10.11.12.13. Logging in...
230-aftpd: 220 bigben ftp server (UNIX(r) System V Release 4.0)
ready.
ftp>
At this point you will be connected to the remote FTP server. Log in using the user
command:
ftp> user anonymous
331 Anonymous access allowed, send identity (e-mail name) as
password.
Password: fbloggs@checkpoint.com
230 Anonymous user logged in.
ftp>
Timeout Considerations for User Authentication of HTTP
In HTTP, the Web browser automatically supplies the password to the server for
each connection. This creates special security considerations when using User
Authentication for HTTP with one-time passwords.
To avoid forcing users of one-time passwords to generate a new password for each
connection, the HTTP Security Server extends the validity of the password for the
time period defined in User Authentication session timeout in the Authentication page
of the Check Point Gateway window. Users of one-time passwords do not have to
reauthenticate for each request during this time period.
To enhance security, you may want to compel users to reauthenticate for certain
types of requests. For example, you can specify that every request to a specific
HTTP server requires a new password, or that requests that change a server’s
configuration require a new password. To set reauthentication parameters, adjust
the Reauthentication options in the HTTP Server definition of the Global Properties >
FireWall > Security Server page.
Chapter 2
Authentication
55
VPN-1 Power Solution for Authentication
For information on configuring User Authentication, see “Configuring User
Authentication” on page 65.
Session Authentication
Session Authentication can be used for any service, but to retrieve a user’s identity
it requires a Session Authentication agent. The Session Authentication agent is
normally installed on the authenticating client, in which case the person who
initiates the connection to the destination host supplies the authentication
credentials. Like User Authentication, it requires an authentication procedure for
each connection. However, the Session Authentication agent can also be installed
on the destination machine, or on some other machine in the network. In that case,
the person at the machine on which the Agent is installed is asked to supply the
username and password.
Figure 2-1 shows the Session Authentication login prompt. After typing his or her
username, another prompt asks the user to supply a password.
Figure 2-1 Session Authentication login prompt
The Session Authentication agent works as follows:
1. The user initiates a connection directly to the server.
2. VPN-1 Power intercepts the connection.
3. The Session Authentication agent challenges the user for authentication data
and returns this information to VPN-1 Power.
4. If the authentication is successful, VPN-1 Power allows the connection to pass
through the gateway and continue on to the target server.
56
VPN-1 Power Solution for Authentication
For information on configuring Session Authentication and the Session
Authentication agent, see “Configuring Session Authentication” on page 66.
Note - When configuring user objects, you can set the locations that they are allowed to
access. This can lead to conflicts with security rules that require a form of authentication.
See “Resolving Access Conflicts” on page 71 for more information.
Client Authentication
In This Section
Introduction to Client Authentication
page 57
Manual Sign On
page 58
Wait Mode for Client Authentication
page 60
Partially Automatic Sign On
page 61
Fully Automatic Sign On
page 61
Agent Automatic Sign On
page 62
Single Sign On
page 62
Introduction to Client Authentication
Client Authentication can be used to authenticate any service. It allows access from
a specific IP address for an unlimited number of connections. The user working on
a client performs the authentication by successfully meeting an authentication
challenge, but it is the client machine that is granted access. Client Authentication
is less secure than User Authentication, as it allows multiple users and connections
from authorized IP addresses or hosts. The authorization is per machine for services
that do not have an initial login procedure. The advantage of Client Authenticaiton
is that it can be used for any number of connections, for any service, and
authentication is valid for any length of time.
Note - When configuring user objects, you can set the locations that they are allowed to
access. This can lead to conflicts with security rules that require a form of authentication.
See “Resolving Access Conflicts” on page 71 for more information.
Client Authentication can be used with any one of the different sign on methods.
These sign on methods provide a choice of Authentication Methods for
authenticated and other services, as summarized in Table 2-1. For all sign on
Chapter 2
Authentication
57
VPN-1 Power Solution for Authentication
methods other than Manual Client Authentication, the VPN-1 Power Gateway is
transparent to the user. This means that the user authenticates directly to the
destination host.
Table 2-1
Client Authentication Sign On Methods
Client
Authentication
Sign On Method
Authentication Method for
authenticated services:
Telnet, FTP, HTTP, RLOGIN
Authentication Method for
other services
Manual
Telnet to port 259 on Gateway
HTTP to port 900 on Gateway
Telnet to port 259 on Gateway
HTTP to port 900 on Gateway
Partially
automatic
User Authentication
Not available
Fully automatic
User Authentication
Session Authentication
Agent automatic
Session Authentication
Session Authentication
Single Sign On
UserAuthority
UserAuthority
There are two Client Authentication Sign On options:
•
Standard Sign On
•
Specific Sign On
Standard Sign On allows the user to use all the services permitted by the rule,
without having to perform authentication for each service.
Specific Sign On allows the user to access only the services they specify when they
authenticate, even if the rule allows more than one service. If the user wishes to
use another service, he or she needs to reauthenticate for that specific service.
At the end of the session, the user can sign off. When a user signs off, he or she is
signed off from all services, and the connection is closed by the remote host.
An explanation follows of each of the Client Authentication sign on methods
summarized in Table 2-1:
Manual Sign On
Manual Sign On is available for any service, as long as it is specified in the Client
Authentication rule.
In Manual Sign On, the user must first connect to the Gateway in order to
authenticate (in other words, the authentication is not transparent). The user must
authenticate in one of two ways:
1. A Telnet session to the Gateway on port 259
58
VPN-1 Power Solution for Authentication
2. An HTTP connection to the gateway on port 900, through a Web browser. The
requested URL must include the gateway name and the port number, such as
http://Gateway:900.
The following example shows what Client Authentication with Standard, Manual
Sign On looks like to a user. Before opening a connection to the destination host,
user fbloggs first authenticates to london, the VPN-1 Power Gateway:
tower 1% telnet london 259
Trying 191.23.45.67 ...
Connected to london.
Escape character is '^]'.
CheckPoint FireWall-1 Client Authentication Server running on
london
Login: fbloggs
FireWall-1 Password: ********
User authenticated by FireWall-1 auth.
Choose:
(1) Standard Sign On
(2) Sign Off
(3) Specific Sign On
Enter your choice: 1
User authorized for standard services (1 rules)
Connection closed by foreign host.
Chapter 2
Authentication
59
VPN-1 Power Solution for Authentication
The following example shows what Client Authenticating with Specific, Manual Sign
On looks like to a user. In the example, two services are specified: rstat and
finger, each one to a different host.
tower 3% telnet london 259
Trying 191.23.45.67 ...
Connected to london.
Escape character is '^]'.
CheckPoint FireWall-1 Client Authentication Server running on
london
Login: jim
FireWall-1 Password: ********
User authenticated by Internal auth.
Choose:
(1) Standard Sign On
(2) Sign Off
(3) Specific Sign On
Enter your choice: 3
Service: rstat
Host: palace
Client Authorized for service
Another one (Y/N): Y
Service: finger
Host: thames
Client Authorized for service
Another one (Y/N): n
Connection closed by foreign host.
Wait Mode for Client Authentication
Wait Mode is a Client Authentication capability for the VPN-1 Power Gateway that
applies to Manual Sign On when the user initiates a Client Authenticated
connection with a Telnet session to port 259 on the Gateway.
Wait Mode makes it unnecessary to open a new Telnet session in order to Sign Off
and withdraw Client Authentication privileges. In Wait mode, the initial Telnet
session remains open, and Client Authentication privileges remain valid so long as
the connection is open. The privileges are withdrawn when the Telnet session is
closed.
VPN-1 Power keeps the Telnet session open by pinging the authenticating client. If
for some reason the client machine stops running, VPN-1 Power closes the Telnet
session and Client Authentication privileges from this IP address are withdrawn.
Enable Wait Mode works only with Client Authentication rules which specify
Standard Sign On. If you select Enable Wait Mode, Client Authentication rules which
require Specific Sign On are not applied.
60
VPN-1 Power Solution for Authentication
Partially Automatic Sign On
Partially Automatic Sign On is available for the authenticated services Telnet, FTP,
HTTP, and RLOGIN services, as long as they are specified in the Client
Authentication rule. No other services can be authenticated with Partially
Automatic Client authentication.
If the user attempts a connection to a remote host using one of the authenticated
services, he or she is asked to authenticate by means of User Authentication.
For Partially automatic client authentication, make sure that port 80 is accessible
on the gateway machine.
Fully Automatic Sign On
Fully Automatic Sign On is available for any service, as long as the required service
is specified in the Client Authentication rule.
If the user attempts a connection to a remote host using an authenticated service
(Telnet, FTP, HTTP, and RLOGIN), he or she is asked to authenticate by means of
User Authentication.
If the user attempts a connection to a remote host using any other service, he or
she is asked to authenticate by means of the Session Authentication agent, which
must be properly installed.
For Fully automatic client authentication, make sure that port 80 is accessible on
the gateway machine.
Chapter 2
Authentication
61
VPN-1 Power Solution for Authentication
Agent Automatic Sign On
Agent Automatic Sign On is available for any service, as long as the required
service is specified in the Client Authentication rule, and as long as the Session
Authentication agent is properly installed.
If the user attempts a connection to a remote host using any service, he or she is
asked to authenticate by means of the Session Authentication agent.
Single Sign On
Single Sign On is available for any service, as long as the required service is
specified in the Client Authentication rule. UserAuthority must be installed.
Single Sign On is the Check Point address management feature that provides
transparent network access. In this method, VPN-1 Power consults the user IP
address records to determine which user is logged on at a given IP address. When
a connection matches a Single Sign On enabled rule, VPN-1 Power queries
UserAuthority with the packet's source IP. UserAuthority returns the name of the
user who is registered to the IP. If the user's name is authenticated, the packet is
accepted; if not, it is dropped.
62
Configuring Authentication
Configuring Authentication
In This Section
Creating Users and Groups
page 63
Configuring User Authentication
page 65
Configuring Session Authentication
page 66
Configuring Client Authentication
page 70
Configuring Authentication Tracking
page 75
Configuring a VPN-1 Power Gateway to use RADIUS
page 76
Granting User Access Based on RADIUS Server Groups
page 77
Associating a RADIUS Server with a VPN-1 Power Gateway
page 79
Configuring a VPN-1 Power Gateway to use SecurID
page 79
Configuring a VPN-1 Power Gateway to use TACACS+
page 80
Groups of Windows users
page 81
Creating Users and Groups
Authentication Rules are defined in terms of user groups, rather than in terms of
individual users. You must therefore define users and add them to groups. You can
define users using the VPN-1 Power proprietary user database, or using an LDAP
server. For details on incorporating LDAP, see SmartDirectory (LDAP) and User
Management in the SmartCenter book.
This simple example shows how to create a group, create VPN-1 Power users from
a template, add the users to the group, and install the user information in the
database. For more details on creating users and groups, see SmartCenter Overview
in the SmartCenter book.
Chapter 2
Authentication
63
Configuring Authentication
Creating a User Group
1. Select the User Groups from the Users and Administrators tab of the Objects
tree. Right Click, and select New Group.... The Group Properties window opens.
Give the group a Name. You will populate the group later, when creating the
users.
Creating a User Template
2. Select the Users from the Users and Administrators tab of the Objects tree. In
the Templates branch right click and select New Template.... The User Template
Properties window is displayed.
3. Give the template a name. In the Groups tab, add this user template to all the
groups to which users based on this template need to belong. In the
Authentication tab, choose the appropriate authentication scheme for the user.
In the remaining tabs, enter the other properties of the user template.
Once you have created a template, any user you create based on the template
will inherit all of the template’s properties, including membership in groups. If
you modify a template’s properties, the change will affect all users created from
the template in the future. Users already created from the template will not be
affected.
Creating Users
4. In the Users branch of the objects tree, right click and choose the template on
which the new user’s properties will be based. The User Properties window is
displayed.
5. Enter the data for the user. For any user, you can freely change the properties
that user inherited from the template, but they will be changed for the user
only. The template remains unchanged.
Install the User Information in the Database
6. Users and groups can be installed separately from the Rule Base. This means
you can update users and groups without re-installing the Rule Base. To install
the User Database, select Policy > Install Database... from the SmartDashboard
menu.
64
Configuring Authentication
Configuring User Authentication
1. Configure the Users and Groups that are needed for authentication, and install
the User Database (see “Creating Users and Groups” on page 63).
2. Define a User Authentication access rule.
a. In the Source column, right click to select Add User Access..., and choose
the group.
b. If you would like to restrict the location of authenticating users: In the
Location section of the same window, check Restrict To and choose the host,
group of hosts, network or group of networks from which users can access.
c. In the Service field choose the services you would like to authenticate.
d. In the Action column, choose User Auth.
Table 2-2 shows an HTTP User Authentication Rule.
Table 2-2
User Authentication Rule for HTTP and FTP
SOURCE
DESTINATION
VPN
SERVIC
E
ACTION
Alaska_Users@Any
Alaska_LAN
Any
Traffic
HTTP
FTP
User Auth
3. Double click the Action column to edit the User Authentication Action Properties.
4. If you wish, adjust the User Authentication session timeout in the Authentication
page of the VPN-1 Power Gateway object.
5. Install the Security Policy.
The Importance of Rule Order for User Authentication
When defining one or more User Authentication rule for the services Telnet, FTP,
HTTP, and RLOGIN, and there are other non-authentication rules that use these
services, make sure the User Authentication rule is placed last among these rules.
Chapter 2
Authentication
65
Configuring Authentication
Configuring Session Authentication
1. If using the Session Authentication agent, install and configure it for all the
machines desktops that are to allow Session Authentication (see “Installing and
Configuring the Session Authentication Agent” on page 67).
2. Configure the Users and Groups that are needed for authentication, and install
the User Database (see “Creating Users and Groups” on page 63).
3. Edit the Check Point Gateway object representing the VPN-1 Power Gateway, and
in the Authentication page, enable the required authentication schemes. The
gateway must support all the authentication schemes defined for the users. For
example, if some users use Check Point Password, and others use RADIUS
Authentication, check both these schemes.
4. Define a Session Authentication access rule.
a. In the Source column, right click to select Add User Access..., and choose
the group. Don’t close the window yet.
b. If you would like to restrict the location of users: In the Location section of
the same window, check Restrict To and choose the host, group of hosts,
network or group of networks from which users can access.
c. In the Service field choose the services you would like to authenticate.
d. In the Action column, choose Session Auth.
Table 2-3 shows a typical Session Authentication Rule.
Table 2-3
Session User Authentication Rule for HTTP and FTP
SOURCE
DESTINATION VPN
SERVICE
ACTION
Alaska_Users@Any
Alaska_LAN
HTTP
FTP
Session
Auth
Any Traffic
5. Double click the Action column to edit the User Authentication Action Properties.
6. If you wish, adjust the Failed Authentication Attempts settings for Session
Authentication in the Authentication page of the Global Properties.
7. Install the Security Policy.
66
Configuring Authentication
Installing and Configuring the Session Authentication
Agent
1. Install the Session Authentication agent from the CD-ROM. The Session
Authentication agent is normally installed on the authenticating client, in which
case the person who wants to the connection to the destination host supplies
the authentication credentials. However, the Session Authentication agent can
also be installed on the destination machine, or on some other machine in the
network. In that case, the person at the machine on which the Agent is
installed is asked to supply the username and a password.
2. Open the Session Authentication agent. On Windows machines, double-click its
icon in the system tray. The FireWall-1 Session Authentication window
(Figure 2-2) is displayed.
Figure 2-2 FireWall-1 Session Authentication window
3. Click Configure. The Configuration window (Figure 2-3) is displayed. The
Configuration window has three tabs, explained below.
Passwords Tab
Figure 2-3
Configuration window — Passwords tab
Chapter 2
Authentication
67
Configuring Authentication
The Passwords tab of the Configuration window enables you to specify how
frequently the user is asked to supply a password (that is, to authenticate himself
or herself). One-time passwords (such as SecurID) cannot be cached.
Check one of the available choices:
Every request — The user will be prompted for the password each time VPN-1
Power requests authentication. Each time the user initiates a session to which a
Session Authentication rule applies, the user will be prompted for a password. In
this case, no password caching occurs.
Once per session — The user will be prompted for a password once per Session
Authentication agent session. In this case, the user supplies the password once and
the Session Authentication agent caches the password indefinitely. This option
cannot be used with one-time passwords. If the Session Authentication agent is
terminated and then re-started, the user will have to supply the password again.
After ... minutes of inactivity — This option is the same as Once per session, except
that the user will be prompted again for a password if there has been no
authentication request for the specified time interval.
Allowed FireWall-1 Pro Tab
Figure 2-4
Configuration window — Allowed FireWall-1 tab
The Allowed FireWall-1 tab of the Configuration window enables you to specify the
VPN-1 Power Gateways for which this Session Authentication agent may provide
authentication services.
Any IP Address — This Session Authentication agent may provide authentication
services for any VPN-1 Power Gateway.
IP Address — This Session Authentication agent may provide authentication
services only for a VPN-1 Power Gateway running on the specified IP address. You
can specify up to three IP addresses.
68
Configuring Authentication
Options Tab
Figure 2-5
Configuration window — Options tab
The Options tab of the Configuration window (Figure 2-5) enables you to specify
whether to allow clear passwords and resolve addresses.
Starting the Session Authentication Agent
When you start the Session Authentication agent, it is minimized and its icon
appears in the system tray. From this point on, one of two things can happen:
•
The user can open the Session Authentication agent and configure it.
•
The Session Authentication agent can receive an authentication request from a
VPN-1 Power Gateway.
Chapter 2
Authentication
69
Configuring Authentication
Configuring Client Authentication
In This Section
Basic Client Authentication Configuration
page 70
Allowing Client Authentication Wait Mode
page 71
Resolving Access Conflicts
page 71
Authorizing All Standard Sign On Rules
page 72
Changing the Client Authentication Port Number
page 73
Allowing Encrypted Client Authentication (HTTPS connections)
page 74
Basic Client Authentication Configuration
1. Configure the Users and Groups that are needed for authentication, and install
the User Database (see “Creating Users and Groups” on page 63).
2. Edit the Check Point Gateway object representing the VPN-1 Power Gateway, and
in the Authentication page, enable the required authentication schemes. The
gateway must support all the authentication schemes defined for the users. For
example, if some users use Check Point Password, and others use RADIUS
Authentication, check both these schemes.
3. Define a Client Authentication access rule.
a. In the Source column, right click to select Add User Access..., and choose
the group.
b. If you would like to restrict the location of authenticating users: In the
Location section of the same window, check Restrict To and choose the host,
group of hosts, network or group of networks from which users can access.
c. In the Service field choose the services you would like to authenticate.
d. In the Action column, choose Client Auth.
Table 2-4 shows a typical Client Authentication Rule.
70
Table 2-4
Client Authentication Rule for HTTP and FTP
SOURCE
DESTINATION VPN
SERVICE
ACTION
Alaska_Users@Any
Alaska_LAN
HTTP
FTP
Client Auth
Any Traffic
Configuring Authentication
4. For Partially or fully automatic client authentication, make sure that port 80 is
accessible on the gateway machine.
5. Double click the Action column to edit the Client Authentication Action
Properties. The settings for Requires Sign On and for Sign On Method are
described in “Client Authentication” on page 57.
6. Make sure all Client Authentication Rules are placed above the Rule that
prevents direct connections to the VPN-1 Power Gateway (the “Stealth Rule”),
so that they have access to the VPN-1 Power Gateway.
7. If you wish, adjust the Failed Authentication Attempts settings for Client
Authentication in the Authentication page of the Global Properties.
8. Install the Security Policy.
Allowing Client Authentication Wait Mode
When using Manual Sign On, and the user authenticates with a Telnet session to
port 259 on the Gateway, Wait Mode makes it unnecessary to open a new Telnet
session in order to Sign Off and withdraw Client Authentication privileges.
To enable Wait Mode, edit the Check Point Gateway object, and in the
Authentication page, check Enable Wait Mode for Client Authentication.
In Client Authentication Wait Mode, VPN-1 Power monitors the Telnet connection
to port 259 of the Gateway by pinging the user’s host. You should define rules to
allow the ping as follows:
1. Allow the echo-request service from the VPN-1 Power Gateway to the user’s
host.
2. Allow the echo-reply service from the user’s host to the VPN-1 Power Gateway.
Resolving Access Conflicts
When configuring users, you can set locations to which they are allowed to access.
In doing so, however, you are disallowing all locations not specified. This can lead
to a conflict with any security rule requiring authentication. For example, if a rule
grants authenticated access to users from Mktg_net to Finance_net, yet the
Location tab of user Susan allows connections only within Mktg_net, VPN-1 Power
does not know whether to allow the authentication request when Susan tries to
connect to Finance_net.
You can specify how to resolve this conflict by editing the Authentication Action
Property of the rule in question. Right click on the Action field of a rule using some
form of authentication and select Edit Properties.
Chapter 2
Authentication
71
Configuring Authentication
•
If you want to apply the more restrictive access privileges specified in the rule
and in the Location tab of each user’s User Properties window, choose Intersect
with User Database.
•
If you want to allow access according to the location specified in the rule,
choose Ignore User Database.
You can set this property for both the Source and Destination of the rule.
Authorizing All Standard Sign On Rules
By default, the automatic sign on methods (Partially or Fully Automatic) open one
rule after successful authentication — the rule for which the sign on was initiated.
For example, if a user successfully authenticates according an automatic sign on
rule, that user is allowed to work with the services and destinations permitted only
by that rule.
You can configure VPN-1 Power to automatically open all Standard Sign On rules
after successful authentication through Partially or Fully Automatic Sign On. If a
user successfully authenticates according to an automatic sign on rule, then all
Standard Sign On rules which specify that user and source are opened. The user is
then permitted to work with all the services and destinations permitted by the
relevant rules. In other words, VPN-1 Power knows which user is at the client, and
additional authentication is not necessary.
To authorize all relevant Standard Sign On Rules after successful Partially or Fully
Automatic authentication, use the GUIdbedit Database Tool to change a setting in
VPN-1 Power’s database. You can find the GUIdbedit Database Tool in the same
directory on your local drive where SmartConsole is installed.
1. Launch GUIdbedit.
2. Search for the field name automatically_open_ca_rules.
3. Set the value to
Policy.
72
true.
The new value will take effect after you install the Security
Configuring Authentication
Changing the Client Authentication Port Number
To change the port number used for Client Authentication, proceed as follows:
1. Stop VPN-1 Power (cpstop).
2. Modify the port number in the Manage
for the following services:
>
Service
>
Show
>
TCP Services window
•
If you want to modify the port number for Telnet sign on, then modify the
port number of the FW1_clntauth_telnet service.
•
If you want to modify the port number for HTTP sign on, then modify the
port number of the FW1_clntauth_http service.
These services are special VPN-1 Power services provided as part of the Client
Authentication feature.
3. Use a simple text editor to edit the file $FWDIR/conf/fwauthd.conf, an example
of which is depicted in Figure 2-6. Change the port number for the Client
Authentication application to the same port number as in the previous step.
•
For Telnet Sign On, modify the first column in the in.aclientd line.
•
For HTTP Sign On, modify the first column in the in.ahclientd line.
21fwssd in.aftpd wait 0
80 fwssd in.ahttpd wait 0
513 fwssd in.arlogindwait 0
25 fwssd in.asmtpd wait 0
23 fwssd in.atelnetd wait 0
259 fwssd in.aclientd wait 259
10081 fwssd in.lhttpd wait 0
900 fwssd in.ahclientdwait 900
0 fwssd in.pingd respawn 0
0 fwssd in.asessiond respawn 0
0 fwssd in.aufpd respawn 0
0 vpn vpnd respawn 0
0 fwssd mdq respawn 0
0 xrm xrmdrespawn0-pr
Figure 2-6
$FWDIR/conf/fwauthd.conf file
Warning - Do not change anything else in the line.
4. Make sure that there is no rule that blocks the connection to the new port.
5. Restart VPN-1 Power (cpstart).
Chapter 2
Authentication
73
Configuring Authentication
Not all of the parameters shown in the sample file of Figure 2-6 will necessarily be
present in your file.
For information on configuring Client Authentication, see “Configuring Client
Authentication” on page 70.
Allowing Encrypted Client Authentication (HTTPS
connections)
To configure Encrypted Client Authentication, and set up authentication to both the
VPN-1 Power Gateway and to your Internal Web Server. proceed as follows:
1. Run cpstop on the VPN-1 Power Gateway.
2. Edit the file fwauthd.conf in the $FWDIR/conf directory by changing the line
900
fwssd
in.ahclientd
wait
900
900
fwssd
in.ahclientd
wait
900 ssl:defaultCert
to:
Note - defaultCert is a nickname on the Certificate List on the VPN-1 Power Gateway.
To check the nickname of your Gateway, open the VPN page of the Gateway Properties
window and see the Certificates List.
3. Save the file and close it.
4. Run cpstart.
5. Open SmartDashboard.
6. Create the following Rule:
Table 2-5
Source
Destination
Service
Action
User_group@Any
Internal
server
https
Client Auth
(Partially
automatic
or Manual mode)
Note - This Rule also allows HTTPS traffic between the client and the Web server. This
traffic is allowed after a successful authentication.
7. Install the Policy.
8. In the client's browser proceed as follows:
74
Configuring Authentication
a. Enter the URL address:
https://<FireWall-1_name_or_IP_address>:900
b. Press Yes to trust the VPN-1 Power Gateway certificate.
c. Enter the VPN-1 Power user name.
d. Press OK.
e. Press Yes.
f.
Enter the VPN-1 Power password.
g. Press Submit.
h. Enter the following URL address:
https://<Internal_Web_Server_IP_address>
i.
Press Yes.
Now you are authenticated both to the VPN-1 Power Gateway and to your Internal
Web Server.
Configuring Authentication Tracking
Successful and unsuccessful authentication attempts can be monitored in
SmartView Tracker or via other tracking options, such as email, alerts, etc.
Authentication tracking is configured in the following ways:
1. Failed authentication attempts can be tracked for all forms of Authentication.
On the Authentication page of a Gateway Object, the Authentication Failure Track
property sets the tracking option when authentication failures occur. The
selection that you make here sets the tracking policy for all failed
authentication attempts that take place through this gateway.
2. Successful authentication attempts can be tracked for Client Authentication. In
the Client Authentication Action Properties window, the Successful Authentication
Tracking property sets the tracking option for all successful Client
Authentication attempts. Right click in the Action column of the Client
Authentication rule to set this option. The default setting is Log.
3. You can track all Authentication attempts, whether successful or unsuccessful,
by selecting an option in the Track column of any rule using a form of
authentication. The tracking option set by rule can only add to the tracking
policy set in the Gateway Object. For example, if the Gateway Object is set to
Log all failed authentication attempts, setting a rule to None will have no effect
Chapter 2
Authentication
75
Configuring Authentication
- failed authentication attempts will still be logged in SmartView Tracker.
However, setting the rule to Alert will cause an Alert to be sent for each failed
authentication attempt.
Note - Authentication failure tracking for Check Point firewalls prior to version NG is set by
the Authentication Failure Track property on the Authentication page of Global
Properties.
Configuring a VPN-1 Power Gateway to use RADIUS
1. In SmartDashboard, create a RADIUS Host object by choosing Manage >
Network Objects > New > Node > Host... Name it and assign it an IP address.
2. Create a RADIUS Server object by choosing Manage > Server and OPSEC
Applications > New…> RADIUS…
a. Name the RADIUS Server object.
b. Associate the RADIUS Server object with the RADIUS Host object you
created in step 1.
c. Assign the Service - choose between RADIUS on port 1645 service or
NEW-RADIUS on port 1812. (The default setting is RADIUS, however the
RADIUS standards group recommends using NEW-RADIUS, as 1645 can
conflict with the datametrics service running on the same port.)
d. Assign the same Shared Secret that you configured on the actual RADIUS
server.
e. Choose whether you want RADIUS Ver. 1.0 Compatible, which is RFC 2138
compliant, or RADIUS Ver. 2.0 Compatible, which is RFC 2865 compliant.
f.
Assign the RADIUS server’s Priority if you are employing more than one
RADIUS Authentication Server.
g. Click OK.
3. Right click on your gateway object and choose Edit > Authentication page.
Enable RADIUS authentication.
4. Define a user group by choosing Manage > Users & Administrators > New > User
Group (e.g. RADIUS_Users).
5. Enable RADIUS authentication for VPN-1 Power users by choosing Manage >
Users and Administrators > New > User by Template > Default.
76
Configuring Authentication
6. Enable RADIUS authentication for users without VPN-1 Power user accounts by
creating an External User Profile. Choose Manage > Users and Administrators >
New > External User Profile > Match all users... or Match by domain.... To support
more than one external authentication scheme, set up your External User
Profiles with the setting Match By Domain.
7. For all User Profiles and Templates:
a. On the General tab, enter the default login name for the RADIUS Server.
(When configuring Match all users as an External User Profile, the name
“generic*” is automatically assigned).
b. On the Personal tab, adjust the Expiration Date.
c. On the Authentication tab, choose RADIUS from the drop down list.
d. On the Groups tab, add the User Profile to the RADIUS group.
8. Verify that communications between the firewall and the RADIUS Server are not
NATed in the Address Translation Rule Base.
9. Save, verify, and install the policy.
Granting User Access Based on RADIUS Server
Groups
With VPN-1 Power gateway you can control access for authenticated RADIUS users,
based on the RADIUS group of the user. The administrator assigns users to groups.
These groups are used in the Security Rule Base to restrict or grant access for
users to resources. Users are unaware of the groups to which they belong.
To use RADIUS groups, you must define a return attribute on the RADIUS Server,
in the RADIUS user profile. This RADIUS attribute is returned to the VPN-1
gateway that contains the group name (RAD_<group to which the RADIUS users
belong>) to which the users belongs. By default the Class attribute is used (IETF
RADIUS attribute number 25), though other RADIUS attributes can be used.
Chapter 2
Authentication
77
Configuring Authentication
On the VPN-1 Power Gateway
1. Follow step 1 to step 3 in “Configuring a VPN-1 Power Gateway to use
RADIUS” on page 76.
2. Create an External User Profile (Manage > Users and Administrators > New... >
External User Profile > Match all users...). This is the generic* user. Go to the
Authentication tab, and select Authentication Scheme: RADIUS, and then select
the created RADIUS server (not the node) from the drop down list.
3. Define the necessary RADIUS user groups by choosing Manage > Users &
Administrators > New > User Group. The name of the group must be in the
format RAD_<group to which the RADIUS users belong>. Make sure the group
is empty.
4. Create the necessary Security Rule Base rules to allow access to RADIUS users.
5. Save the changes, and exit SmartDashboard.
6. Run cpstop on the SmartCenter Server.
7. On the SmartCenter Server, use the Graphical Database Tool (GUIdbEdit) to
change the value of the attribute add_radius_groups from false to true.
8. Run cpstart on the SmartCenter Server.
9. Install the policy.
On the RADIUS server
10. Modify the RADIUS users to include a “class” RADIUS attribute on the users'
Return list that corresponds to the Firewall user group they will be using for
their access.
To use a different attribute instead of the “Class”
attribute
11. On the VPN-1 Power Gateway, use GUIdbEdit to modify the value of the
firewall_properties attribute radius_groups_attr to the new RADIUS
attribute.
12. On the RADIUS server, make sure you use the same RADIUS attribute (on the
users' Return list that corresponds to the Firewall user group they will be using
for their access).
78
Configuring Authentication
Associating a RADIUS Server with a VPN-1 Power
Gateway
A user can be associated with the Radius authentication server via the User
Properties Authentication tab.
It is also possible to associate an enforcement module with a Radius server, such
that this overrides the User to Radius server association. This is done by directly
editing the VPN-1 Power database using the dbedit command.
To associate one or more Radius servers to an enforcement module, use the dbedit
command:
modify network_objects <gw obj> radius_server servers:<radius obj>
It is possible to switch off the Radius to VPN-1 Power association on a per user
basis, so that the user will always authenticate to the Radius server specified in the
User Properties Authentication tab. Do this by switching off another attribute in the
VPN-1 Power database, using the dbedit command:
modify users <user obj> use_fw_radius_if_exist false
Configuring a VPN-1 Power Gateway to use
SecurID
1. Generate and copy the sdconf.rec file from the ACE/Server to:
•
on UNIX, Linux or IPSO - /var/ace/sdconf.rec;
•
on Windows NT - %SystemRoot%\System32\sdconf.rec.
2. In SmartDashboard, right click on your gateway object and choose Edit >
Authentication page. Enable SecurID authentication.
3. Define a user group by choosing Manage > Users & Administrators > New > User
Group (e.g. SecurID_Users).
4. Enable SecurID authentication for VPN-1 Power users by choosing Manage >
Users and Administrators > New > User by Template > Default.
5. Enable SecurID authentication for users without VPN-1 Power user accounts by
creating an External User Profile. Choose Manage > Users and Administrators >
New > External User Profile > Match all users... or Match by domain.... If you are
supporting more than one external authentication scheme, make sure to set up
your External User Profiles with the setting Match By Domain.
6. For all User Profiles and Templates:
Chapter 2
Authentication
79
Configuring Authentication
a. On the General tab, enter the default login name for the ACE/Server. (When
configuring Match all users as an External User Profile, the name “generic*”
is automatically assigned).
b. On the Personal tab, adjust the Expiration Date.
c. On the Authentication tab, choose SecurID from the drop down list.
d. On the Groups tab, add the User Profile to the SecurID group.
7. Verify that communications between the firewall and the ACE/Server are not
NATed in the Address Translation Rule Base.
8. Save, verify, and install the policy.
When the VPN-1 Power Gateway has multiple interfaces, the SecurID agent in
VPN-1 Power will in some cases use the wrong interface IP to decrypt the reply
from ACE/Server, and authentication will fail. To overcome this problem, place a
new text file named sdopts.rec is the same directory as sdconf.rec. The file
should contain the following line
CLIENT_IP=<ip>
where <ip> is the primary IP of VPN-1 Power, as defined on the ACE/Server. This is
the IP of the interface to which the server is routed.
Configuring a VPN-1 Power Gateway to use
TACACS+
1. In SmartDashboard, create a TACACS Host object by choosing Manage >
Network Objects > New > Node > Host... Name it and assign it an IP address.
2. Create a TACACS server by choosing Manage > Server and OPSEC Applications >
New…> TACACS…
a. Name the TACACS Server object.
b. Associate the TACACS Server object with the TACACS Host object you
created in step 1.
c. Choose the Type of TACACS you want to run. (The default is TACACS, but
TACACS+ is recommended).
d. Assign the Service - match the TACACS service (UDP or TCP) to the Type
you chose in step c.
3. Right click on your gateway object and choose Edit > Authentication page.
Enable TACACS authentication.
80
Configuring Authentication
4. Define a user group by choosing Manage > Users & Administrators > New > User
Group (e.g. TACACS_Users).
5. Enable TACACS authentication for VPN-1 Power users by choosing Manage >
Users and Administrators > New > User by Template > Default.
6. Enable TACACS authentication for users without VPN-1 Power user accounts by
creating an External User Profile. Choose Manage > Users and Administrators >
New > External User Profile > Match all users... or Match by domain.... If you are
supporting more than one external authentication scheme, make sure to set up
your External User Profiles with the setting Match By Domain.
7. For all User Profiles and Templates:
a. On the General tab, enter the default login name for the TACACS Server.
(When configuring Match all users as an External User Profile, the name
“generic*” is automatically assigned).
b. On the Personal tab, adjust the Expiration Date.
c. On the Authentication tab, choose TACACS from the drop down list.
d. On the Groups tab, add the User Profile to the TACACS group.
8. Verify that communications between the firewall and the TACACS Server are not
NATed in the Address Translation Rule Base.
9. Save, verify, and install the policy.
Groups of Windows users
To create policy rules for groups of users which are not defined on the SmartCenter
Server but are defined either on the enforcement module’s host which is a Windows
machine or in the Windows machine’s trusted domain, proceed as follows:
1. Enable the feature by using the Graphical Database Tool (GUIdbEdit) to change
the value of the attribute add_nt_groups to true. This attribute is located
under the firewall_properties object in the properties table.
2. Make sure that the user belongs to a Windows user group.
3. In the SmartDashboard, create a user group with the name Windows_<Windows
user group which the user belongs to>. The group may be empty.
4. Define a Generic User Profile for a user that uses OS password as the
authentication scheme.
Chapter 2
Authentication
81
Configuring Authentication
82
Connectivity
This section describes how to give internal users and resources unrestricted yet
secure connectivity across the enforcement point.
3
Chapter
Network Address Translation
(NAT)
In This Chapter
The Need to Conceal IP Addresses
page 86
Check Point Solution for Network Address Translation
page 87
Planning Considerations for NAT
page 100
Configuring NAT
page 102
Advanced NAT Configuration
page 108
85
The Need to Conceal IP Addresses
The Need to Conceal IP Addresses
In an IP network, each computer is assigned a unique IP address that defines both
the host and the network. Many computers in an organization have private,
non-routable IP addresses, but nevertheless require access to the Internet. In most
cases it is impossible to simply give them Internet-routable IP addresses, due to
the lack of available public IP addresses, and administrative constraints.
IPv4 (the current version of IP) provides only 32 bits of address space, so available
IP addresses are becoming scarce, most having already been assigned. Internet
Service Providers will usually allocate only one or a few addresses at a time. Larger
companies may purchase several addresses for use, but purchasing addresses for
every computer on the network is usually impossible.
Even if public IP addresses become available, changing the addresses of every
machine in a large network can be an administrative nightmare, being both labor
intensive and time consuming.
Whether computers have a routable or a non-routable addresses, the administrator
may wish to conceal their real addresses for security reasons. The administrator
may wish to ensure that addresses cannot be seen from outside the organization, or
even from other parts of the same organization. Making a network’s internal
addresses public knowledge can reveal the topology of the network. Hiding this
information can only enhance security.
86
Check Point Solution for Network Address Translation
Check Point Solution for Network Address
Translation
In This Section
Public and Private IP addresses
page 87
NAT in VPN-1 Power
page 88
Static NAT
page 89
Hide NAT
page 90
Automatic and Manual NAT Rules
page 91
Automatic Hide NAT for Internal Networks
page 92
Address Translation Rule Base
page 93
Bidirectional NAT
page 94
Understanding Automatically Generated Rules
page 95
Port Translation
page 97
NAT and Anti-Spoofing
page 97
Routing Issues
page 97
Disabling NAT in a VPN Tunnel
page 99
Public and Private IP addresses
Public IP addresses are those that are routable on the Internet. RFC 1918
documents private address spaces can be used on internal networks that will not
have hosts directly connected to the Internet. The Internet assigned Numbers
authority (IANA) has set aside the following three blocks of IP addresses for
internal (private) network use:
•
Class A network numbers: 10.0.0.0–10.255.255.255
•
Class B network numbers: 172.16.0.0–172.31.255.255
•
Class C network numbers: 192.168.0.0–192.168.255.255
In an intranet that uses private addresses, a VPN-1 Power NAT gateway is put in
place to connect the intranet to the Internet. The Global Properties > Non Unique IP
Address Ranges page specifies the address ranges that VPN-1 Power considers
private (non-unique).
Chapter 3
Network Address Translation (NAT)
87
Check Point Solution for Network Address Translation
NAT in VPN-1 Power
Network Address Translation (NAT) involves replacing one IP address with another.
NAT can change both the source and destination address inside the packet. This
means that a packet that is sent from the internal (protected) side to the external
(unprotected) side of the firewall appears to the destination as if it came from a
different address, and packet that is sent from the external to the internal side of
the firewall will arrive at the correct address.
VPN-1 Power supports two kinds of NAT:
•
Static NAT, where each private address is translated to a corresponding public
address. In a typical Static NAT scenario with a number of machines in an
internal network, the address of each machine is translated to a different public
IP address. It is a many-to-many translation. Static NAT allows machines on
both sides of the VPN-1 Power Gateway to initiate connections, so that, for
example, internal servers can be made available externally.
•
Hide NAT, where a single public address is used to represent multiple
computers on the internal network with private addresses. Hide NAT is a
many-to-one translation. Hide NAT allows connections to be initiated only from
the protected side of the VPN-1 Power Gateway.
NAT can be performed on Check Point network objects, Nodes, Networks, Address
Ranges, and Dynamic objects.
NAT can be defined either automatically, via the network object, which
automatically adds rules to the Address Translation Rule Base, or manually, by
defining rules in the Address Translation Rule Base.
Manually creating NAT Rules adds extra flexibility. For example, as well as
translating IP addresses, it is possible to translate the Service, in other words the
destination port numbers. Port number translation is a type of Static NAT, in which
one port number is translated to another port number.
88
Check Point Solution for Network Address Translation
Static NAT
Static NAT translates each private address to a corresponding public address.
•
Static NAT on a node translates the private address of the node to a public
address.
•
Static NAT on a network or address range translates each IP address in the
network or range to a corresponding public IP address, starting from the
defined Static IP address.
In Figure 3-1, an address range (10.1.1.2 to 10.1.1.10) is hidden behind a NAT
range (192.168.0.2-192.168.0.11). A connection is shown originating at
10.1.1.3, and the source and destination translation for the original and reply
packet.
Figure 3-1 Static NAT on an Address Range
Chapter 3
Network Address Translation (NAT)
89
Check Point Solution for Network Address Translation
Hide NAT
With a NAT gateway, it is possible to share a single public address with multiple
computers on your intranet that have private addresses. The Internet is unaware of
the division you have created between the Internet and your intranet, and sees your
multiple computer connection as simply a single connection.
Hide NAT allows only connections that originate on the internal network. This lets
an internal host initiate a connection to both inside and outside the intranet, but a
host outside the network cannot initiate a connection to an internal host.
The Hide Address is the address behind which the internal network, address range
or node is hidden. You can choose to hide the internal address(es)
•
behind a virtual IP address, which is a public (routable) IP address that does
not belong to any real machine, or
•
behind the IP address of the VPN-1 Power interface through which the packet
is routed out (what used to be known as “Hiding behind IP address 0.0.0.0”).
In Figure 3-2, an address range (10.1.1.2 to 10.1.1.10) is hidden behind the
address of the external VPN-1 Power interface (192.168.0.1). A connection is
shown originating at 10.1.1.3, and the source and destination translation for the
original and reply packet.
Figure 3-2 Hide NAT on An Address Range
90
Check Point Solution for Network Address Translation
How Hide NAT Works
In Hide Mode, the source port numbers of the packets are modified. When return
packets enter a firewall, VPN-1 Power determines by port number to which internal
machines the packets are destined. Port numbers are dynamically assigned from
two pools of numbers:
•
from 600 to 1023
•
from 10,000 to 60,000
Port numbers are almost always assigned from the second pool. The first pool is
used for only three services: rlogin (destination port 512), rshell (destination port
513) and rexec (destination port 514). If the service of the connection is one of
these three, and the original source port is less than 1024, then a port number is
assigned from the first pool. This behavior is configurable.
VPN-1 Power keeps track of the port numbers assigned, so that the original port
number is correctly restored for return packets. A port number currently in use is
not assigned again to a new connection.
Hide NAT has a capacity of 50,000 connections per server. This means that the
Hide NAT capacity limit is only reached if more than 50,000 connections from
Hide NATed internal clients are simultaneously directed at a single server on the
unprotected side of the VPN-1 Power Gateway—a webcast of a wildly popular
basketball game, perhaps?
Automatic and Manual NAT Rules
NAT can be defined automatically via the network object (Node, Network or Address
Range). When you define NAT via the network object, rules are automatically added
to the Address Translation Rule Base
You can manually specify NAT rules, by adding or editing NAT rules to the Address
Translation Rule Base. VPN-1 Power validates manual NAT rules, helping to avoid
mistakes in the setup process. Creating manual NAT Rules gives maximum control
over the way NAT will function. You can specify the source, destination and service
separately for the original and the translated packet.
When creating Manual NAT Rules, you must explicitly define the translated network
objects in addition to the original objects. With Automatic rules this is not
necessary.
Automatic NAT rules cannot be edited in the Address Translation Rule Base.
Chapter 3
Network Address Translation (NAT)
91
Check Point Solution for Network Address Translation
Automatic Hide NAT for Internal Networks
It is possible to use Hide NAT to allow Internet access for very large, complex
internal networks containing many subnets, not all of which may be known.
Regular Hide NAT requires that all internal network addresses that need to be
NATed must be specified. However, this may be impractical.
If this is the case, it is possible to specify automatic Hide NAT for all internal
networks. This means that every connection coming from internal interfaces and
going out through an external gateway interface (as defined in the Topology page of
the gateway object) will be NATed behind the external gateway interface address.
Figure 3-3 shows connections from clients in internal networks initiating
connections to servers in the Internet. The source addresses of internal clients are
NATed to the address of the external interface, either 192.168.0.1 or 172.16.1.1,
depending on the interface from which the connection emerges.
Figure 3-3 Hide NAT behind gateway interface
Note that regular NAT rules take precedence over NAT-for-internal-networks rules.
In other words, if a connection can match both a regular NAT rule and a
NAT-for-internal-networks rule, the connection will be matched to the regular NAT
rule.
Access Rules must still be defined in the Security Rule Base.
Note - For configuration details, see “Configuring Automatic Hide NAT for Internal
Networks” on page 107.
92
Check Point Solution for Network Address Translation
Address Translation Rule Base
The Address Translation Rule Base is shown in Figure 3-4.
Figure 3-4 Address Translation Rule Base
Each rule specifies what happens to the first packet of a connection. Reply packets
travel in the opposite direction to the original packet, but are matched to the same
rule.
The Address Translation Rule Base is divided into two sections, the Original Packet
section, and the Translated Packet section. The Original Packet section specifies
the conditions when the rule is applied. The Translated Packet section specifies the
action taken when the rule is applied.
Each section in the Address Translation Rule Base Editor is divided into Source,
Destination, and Service. The action is always the same:
•
Translate Source under Original Packet, to Source under Translated Packet
•
Translate Destination under Original Packet, to Destination under Translated
Packet
•
Translate Service under Original Packet, to Service under Translated Packet
Rule Match Order
Rule matching in the Address Translation Rule Base follows the same principle as
in the Security Rule Base (see “The Security Rule Base” on page 30). When VPN-1
Power receives a packet belonging to a connection, it compares it against the first
rule in the Rule Base, then the second, then the third, and so on. When it finds a
rule that matches, it stops checking and applies that rule.
The exception to this is when two automatic rules can match a connection, and
Bidirectional NAT is turned on.
Chapter 3
Network Address Translation (NAT)
93
Check Point Solution for Network Address Translation
Bidirectional NAT
Bidirectional NAT applies to automatic NAT rules in the Address Translation Rule
Base, and allows two automatic NAT rules to match a connection. Without
Bidirectional NAT, only one automatic NAT rule can match a connection.
When NAT is defined for a network object, an automatic NAT rule is generated
which performs the required translation. If there are two such objects and one is
the source of a connection and the other the destination, then without Bidirectional
NAT, only one of these objects will be translated, because only one of the
automatically generated NAT rules will be applied, and so a connection between
the two objects will only be allowed in one direction. With Bidirectional NAT, both
automatic NAT rules are applied, and both objects will be translated, so
connections between the two objects will be allowed in both directions.
The detailed logic of Bidirectional NAT is as follows:
•
If the first match on a connection is on a Manual NAT rule, no further checking
of NAT Rule Base is done.
•
If the first match on a connection is on an Automatic NAT rule, then the rest of
the NAT Rule Base is checked, one rule at a time, to see if another Automatic
NAT Rule matches the connection. If it does, both rules are matched, and no
further checking is performed.
The operation of Bidirectional NAT can be tracked using the SmartView Tracker,
using the fields NAT Rule Number and NAT Additional Rule Number. The
“additional rule” is the rule that matches the automatic translation performed on
the second object in Bidirectional NAT.
94
Check Point Solution for Network Address Translation
Understanding Automatically Generated Rules
NAT can be defined automatically via the network object (Node, Network or Address
range). When you define NAT via the network object, rules are automatically added
to the Address Translation Rule Base.
Hide NAT on a Node adds one rule to the Address Translation Rule Base. It
specifies that the source address of the packet is translated for connections that
originate in the Node in the internal network. This is called a Source Hide Rule.
Static NAT on a Node adds two rules to the Address Translation Rule Base. In
addition to the Source Hide rule, another rule specifies that for connections that
originate in the external network, the Destination address of the packet is
translated. This is called a Destination Static Rule.
If NAT (Hide or Static) is performed on a Network or an address range, an extra rule
is added. The extra rule specifies that communication within the network or
address range is not translated, that is, a packet sent from one machine to another
in the same network is not changed.
Example of Automatically Generated Rule — Hide NAT
For the scenario in Figure 3-2 on page 90, automatically defined Hide NAT on the
address range Node adds two rules to the NAT Rule Base, as shown in Figure 3-6.
Figure 3-5 Automatically Generated NAT Rules for Hide NAT on an Address Range
Rule 1 says that for connections within the internal (unprotected) side of the
firewall, no NAT takes place.
Rule 2 says that for connections initiated on the internal (protected) side of the
firewall, the source address of the packets is translated to the public Hide NAT
address.
In automatic Hide NAT rules, the translated address is known as the Hiding
Address, and this is the address that is known and used on the unprotected side of
the VPN-1 Power Gateway. The “real” addresses are the private addresses that are
used on the protected side of the VPN-1 Power Gateway.
Chapter 3
Network Address Translation (NAT)
95
Check Point Solution for Network Address Translation
Example of Automatically Generated Rules — Static
NAT
For the scenario in Figure 3-1 on page 89, automatically defined Static NAT on the
Node adds two rules to the NAT Rule Base, as shown in Figure 3-6.
Figure 3-6 Automatically Generated NAT Rules for Static NAT on an Address Range
Rule 1 says that for connections within the internal (unprotected) side of the
firewall, no NAT takes place. A packet sent from one machine to another in the
same network is not changed.
Rule 2 says that for packets originating on the internal (protected) side of the
firewall, source addresses are translated to valid (public) static NAT addresses.
Rule 3 says that for packets originating on the external (unprotected) side of the
firewall, valid (public) destination addresses are translated to static NAT addresses.
In automatic Static NAT rules, statically translated public addresses are called Valid
Addresses, and these are the addresses that are known and used on the
unprotected side of the VPN-1 Power Gateway. The “real” addresses are the private
addresses that are used on the protected side of the VPN-1 Power Gateway.
Precedence In Automatic Rules
Automatic Rules are placed in the Address Translation Rule Base as follows:
1. Static NAT rules before Hide NAT rules.
2. NAT on a node before NAT on a network or an address range.
96
Check Point Solution for Network Address Translation
Port Translation
Port Translation allows multiple application servers in a hidden network to be
accessed using the a single IP address, based on the requested service (destination
port). This has the benefit of saving on scarce public IP addresses. A typical
implementation could allow an FTP server (accessible via port 21), an SMTP server
(port 25) and an HTTP server (port 80) to be accessed using a single IP public
address.
To use Port Translation you need to craft manual NAT rules. Port Translation rules
are supported on VPN-1 Power enforcement points of version NG FP3 and higher.
NAT and Anti-Spoofing
NAT is always performed after the anti-spoofing checks, and anti-spoofing checks
are performed only on the source IP address of the packet. This means that
irrespective of NAT, spoofing protection is configured on the interfaces of the
VPN-1 Power Gateway in the same way. Unlike in previous versions of VPN-1
Power, there are no special issues regarding anti-spoofing configuration and NAT.
Routing Issues
Static Routes on the VPN-1 Power Gateway
This section is intended only for administrators who have upgraded the
SmartCenter Server, where in the pre-upgrade:
•
pre-NG version, automatic NAT for the server was performed on the server side,
or in the
•
pre-NG FP3 version, manual NAT for the server was performed on the server
side.
In a client-server connection across the VPN-1 Power Gateway, connections
originate at the client, and the server sends reply packets back to the client.
In NG or higher versions of VPN-1 Power, for both manual and automatic rules,
NAT for the server is performed by default on the client side of the VPN-1 Power
Gateway (Figure 3-7). This ensures that the Operating System routes the packets
correctly.
In Figure 3-7, for the original packet, the VPN-1 Power Gateway translates the
destination address to the valid address of the server, and then the packet is routed
to destination.
Chapter 3
Network Address Translation (NAT)
97
Check Point Solution for Network Address Translation
For reply packets, no NAT is performed on the destination, and the OS correctly
routes the packet back to the client.
Figure 3-7 Illustrating NAT on Client side, which ensures that static routes are not
needed
The NG and higher default setting ensures reliable anti-spoofing and routing. It is
recommended to stick to the default setting unless you have upgraded your
SmartCenter Server from a pre-NG version, and you have VPN-1 Power enforcement
modules whose configuration requires other settings.
If NAT for the server destination is configured to be performed on the server side,
the operating system receives the packet for routing before NAT is performed. The
operating system therefore sees a valid address as the destination, and will
therefore route the packet back out to the Internet router rather than to the server.
To resolve this, configure Static Host Routes on the VPN-1 Power Gateway, so that
it forwards packets to the correct interface. For example:
route add 192.168.0.3 10.1.1.2
98
Check Point Solution for Network Address Translation
Automatic and Proxy arp
Giving a machine in the internal network an external IP address using NAT makes
that machine appear to the Internet to be on the external network, on the Internet
side of the firewall.
When NAT is configured automatically, the VPN-1 Power Gateway machine will
reply on behalf of translated network objects to arp requests from the internet
router for the address of the internal machine (Figure 3-8).
Figure 3-8 Illustrating Automatic Arp configuration
If using manual rules, you must configure proxy-arps. In other words, you must
associate the translated IP address with the MAC address of the VPN-1 Power
Gateway interface that is on the same network as the translated addresses.
Disabling NAT in a VPN Tunnel
When communicating within a VPN, it is usually not necessary to perform NAT. It is
possible to disable NAT in a VPN tunnel with a single click in the VPN community
object. Disabling NAT in a VPN tunnel by defining a NAT rule will slow down the
performance of the VPN.
Chapter 3
Network Address Translation (NAT)
99
Planning Considerations for NAT
Planning Considerations for NAT
In This Section
Hide Versus Static
page 100
Automatic Versus Manual Rules
page 100
Choosing the Hide Address in Hide NAT
page 101
Hide Versus Static
For protocols where the port number cannot be changed, Hide NAT cannot be used.
When the external server must distinguish between clients based on their IP
addresses, Hide NAT cannot be used, because all clients share the same IP address
under Hide NAT.
To allow connections from the external network to the internal network, only Static
NAT can be used.
Automatic Versus Manual Rules
Automatic NAT rules are easy to configure and so are less prone to configuration
errors. Automatic ARP configuration is only effective for automatic rules.
Manually defining NAT Rules is complicated, but gives complete control over NAT.
The following can only be done using Manual NAT Rules:
100
•
Restricting rules to specified destination IP addresses, as well as to specified
source IP addresses.
•
Translating both source and destination IP addresses in the same packet.
•
Performing Static NAT only in one direction
•
Translating services (destination ports).
•
Restricting rules to specified services (ports).
•
Performing NAT on Dynamic objects.
Planning Considerations for NAT
Choosing the Hide Address in Hide NAT
The Hide Address is the address behind which the network, address range or node
is hidden.
It is possible to either hide behind the interface of the Install on Gateway, or to
hide behind a specified IP address.
Choosing a fixed public IP address is a good option if you wish to hide the address
of the VPN-1 Power Gateway. However, it means using an extra publicly routable IP
address.
Choosing to hide behind the address of the Install On Gateway is a good option for
administrative purposes. If the external IP address of the firewall changes, there is
no need to change the NAT settings.
Chapter 3
Network Address Translation (NAT) 101
Configuring NAT
Configuring NAT
In This Section
General Steps for Configuring NAT
page 102
Basic Configuration - Network Node with Hide NAT
page 103
Sample Configuration - Static and Hide NAT
page 104
Sample Configuration - Using Manual Rules for Port Translation
page 106
Configuring Automatic Hide NAT for Internal Networks
page 107
General Steps for Configuring NAT
The steps for configuring NAT are always the same:
1. Determine the IP addresses to be used for translation.
2. Define Network Objects.
3. Define the Access Rules in the Security Rule Base. When defining Manual NAT
rules, you must define network objects with translated addresses, whereas if
using Automatic NAT Rules, you need define only one network object per real
object. For example, if Static NAT is defined on an object called Alaska_Web,
then the Security Rule Base need only refer to Alaska_Web (as in Figure 3-9),
and there is no need to define a rule for Alaska_Web (Valid Address).
Figure 3-9 Example Security Rule Base Rule for an object with Automatic NAT
Source
Destination
Action
Any
Alaska_Web
Accept
4. Define NAT Rules (Automatic and/or Manual).
5. Install the Security Policy.
102
Configuring NAT
Basic Configuration - Network Node with Hide NAT
The following example shows how to set up basic Hide NAT for the configuration in
Figure 3-10. The aim is to hide the IP address of the Alaska_Web web server
(10.1.1.10) from connections that originate on the Internet. Alaska_GW has three
interfaces, one of which faces the network on which Alaska_Web resides.
Figure 3-10 Example Network Showing Network Node with Hide NAT
1. Edit the Node object for Alaska_Web, and in the NAT page, select Add
Automatic Address Translation rules (Figure 3-11).
Figure 3-11 Hide NAT configuration for a Node- NAT page
Chapter 3
Network Address Translation (NAT) 103
Configuring NAT
2. Select Translation Method Hide, and the option Hide behind the interface of the
Install on Gateway.
3. Select the Install on Gateway. The NAT Gateway in this example is Alaska_GW,
so you can select either Alaska_GW or All.
Packets originating in Alaska_Web with the Internet as their destination will have
their source address translated from 10.1.1.10 to 192.168.0.1. For example,
packets originating on the web server will have their source address changed from
172.16.10.3 to 192.168.0.1.
Sample Configuration - Static and Hide NAT
The goal is make the SMTP server and the HTTP server on the internal network
available to the Internet using public addresses, and provide Internet access for all
users on the internal network.
Figure 3-12 Sample Configuration - illustrating Static and Hide NAT
The web and mail servers require static translation because incoming connections
will be made to them from the Internet. Two routable addresses are available.
192.168.0.5 will be used for the Alaska.Web HTTP server, and 192.168.0.6 for
the Alaska.Mail SMTP server.
The internal clients require hide translation because they will initiate connections.
No incoming connections are allowed to them from the Internet. They will hide
behind the external interface of the VPN-1 Power Gateway.
1. Define network objects for Alsaka.Web (10.1.1.5), Alaska.Mail (10.1.1.6),
Alaska_LAN (10.1.1.0 with Net Mask 255.255.255.0), and the VPN-1 Power
Gateway (Alaska.GW).
2. Edit the Alaska.Web object, and in the NAT page check Add Automatic Address
Translation Rules, select Translation Method Static, and define the Translate to IP
Address as 192.168.0.5.
104
Configuring NAT
3. Similarly for Alaska.Mail, select Translation Method Static, and define Translate
to IP Address as 192.168.0.6.
4. Edit the Alaska_LAN object, and in the NAT page select Translation Method
Hide, and select Hide behind the interface of the Install On Gateway. The effective
Hide address for the internal clients on Alaska_LAN is therefore 192.168.0.1.
The resulting Address Translation Rule Base is shown in Figure 3-13.
Figure 3-13 Automatic Address Translation Rule Base for Static and Hide NAT
Chapter 3
Network Address Translation (NAT) 105
Configuring NAT
Sample Configuration - Using Manual Rules for
Port Translation
The goal is to make an both a web server and a mail server in a DMZ network
available from the Internet using a single IP address. Hide NAT is to be performed
on all addresses in the DMZ.
Figure 3-14 Sample Configuration - illustrating Port Translation using Manual NAT
1. Define network objects for the network Alaska.DMZ.LAN (172.16.0.0 with Net
Mask 255.255.0.0), the web server Alaska_DMZ_Web (172.16.1.7), and the
Mail server Alaska_DMZ_Mail (172.16.1.5), and the VPN-1 Power Gateway
(Alaska.GW).
2. On the Alaska.DMZ.LAN network object, in the NAT tab, select Add Automatic
Address Translation Rules, and Translation Method Hide, and select Hide behind
the interface of the Install on Gateway. This adds two automatic rules to the
Address Translation Rule Base (Rules 1 and 2 in Figure 3-15).
3. In the Address Translation Rule Base, define a Manual NAT Rule that translates
requests for the HTTP service to the Web server (Rule 3 in Figure 3-15), and a
Manual NAT Rule to translate SMTP requests to the SMTP server (Rule 4 in
Figure 3-15).
106
Configuring NAT
Figure 3-15 Address Translation Rule Base for Port Mapping
Configuring Automatic Hide NAT for Internal
Networks
Note - For background information, see “Automatic Hide NAT for Internal Networks” on
page 92.
Configure automatic Hide NAT for internal networks from the NAT page of the
Check Point Gateway object. In the section Automatic Hide for Internal Networks,
either check or uncheck the option Hide all connections from internal interfaces to
external interfaces behind the gateway.
Chapter 3
Network Address Translation (NAT) 107
Advanced NAT Configuration
Advanced NAT Configuration
In This Section
Allowing Connections Between Translated Objects on Different Gateway
Interfaces
page 108
Enabling Communication for Internal Networks with Overlapping IP
addresses
page 109
SmartCenter Behind NAT
page 113
IP Pool NAT
page 117
Allowing Connections Between Translated Objects
on Different Gateway Interfaces
The goal is to allow connections in both directions between statically translated
objects (nodes, networks or address ranges) on different VPN-1 Power Gateway
interfaces.
If NAT is defined via the network object (as opposed to using Manual NAT Rules),
then you will need to ensure that Bidirectional NAT is enabled.
108
Advanced NAT Configuration
Enabling Communication for Internal Networks with
Overlapping IP addresses
Overview
Where two internal networks have overlapping (or partially overlapping) IP
addresses, VPN-1 Power, makes it possible to:
•
Enable communications between the overlapping internal networks.
•
Enable communications between the overlapping internal networks and the
outside world.
•
Enforce a different Security Policy for each of the overlapping internal
networks, if desired.
Network Configuration
The network shown in Figure 3-16 will be used as an example.
Figure 3-16 Example — Class C network
Both network A and network B share the same address space (192.168.1.0/24), so
standard NAT cannot be used to enable communications between network A and
network B. Instead, overlapping NAT must be performed on a per-interface basis.
Users in network A who wish to communicate with users in network B will use the
192.168.30.0/24 network as a destination. Users in network B who wish to
communicate with users in network A will use the 192.168.20.0/24 network as a
destination.
The VPN-1 Power enforcement module will translate the IP addresses differently on
each interface, as follows:
Chapter 3
Network Address Translation (NAT) 109
Advanced NAT Configuration
interface A
•
inbound source IP addresses will be translated to virtual network
192.168.20.0/24
•
outbound destination IP addresses will be translated to network
192.168.1.0/24
interface B
•
inbound source IP addresses will be translated to network 192.168.30.0/24
•
outbound destination IP addresses will be translated to network
192.168.1.0/24
interface C
Overlapping NAT will not be configured for this interface. Instead, use NAT Hide in
the usual way (not on a per-interface basis) to hide source addresses behind the
interface’s IP address (192.168.4.1).
Communication Example
Suppose you wish to allow communication between internal networks and between
an internal network and the Internet, as follows:
Between Internal Networks
Suppose user A at IP address 192.168.1.10 in network A wishes to connects to
user B at IP address 192.168.1.10 (the same IP address) in network B. User A
opens a connection to IP address 192.168.30.10.
Table 3-1
step
source IP address
destination IP address
interface A — before NAT
192.168.1.10
192.168.30.10
interface A — after NAT
192.168.20.10
192.168.30.10
VPN-1 Power enforcement module enforces Security Policy for packets from network
192.168.20.0/24 to network 192.168.30.0/24.
interface B — before NAT
192.168.20.10
192.168.30.10
interface B — after NAT
192.168.20.10
192.168.1.10
110
Advanced NAT Configuration
Between an Internal Network and the Internet
Suppose user A at IP address 192.168.1.10 in network A connects to IP address
10.10.10.10 on the Internet.
Table 3-2
step
source IP address
destination IP address
interface A — before NAT
192.168.1.10
10.10.10.10
interface A — after NAT
192.168.20.10
10.10.10.10
VPN-1 Power enforcement module enforces Security Policy for packets from network
192.168.20.0/24 to the Internet.
interface C — before NAT
192.168.20.10
10.10.10.10
interface C — after NAT Hide
192.168.4.1
10.10.10.10
Routing Consideration
In order to allow routing from network A to network B, routing needs to be
configured on the firewall machine. The following examples are for Windows and
Linux. For other Operating Systems, use the equivalent commands:
On Windows
route add 192.168.30.0 mask 255.255.255.0 192.168.3.2
route add 192.168.20.0 mask 255.255.255.0 192.168.2.2
On Linux
route add -net 192.168.30.0/24 gw 192.168.3.2
route add -net 192.168.20.0/24 gw 192.168.2.2
Chapter 3
Network Address Translation (NAT) 111
Advanced NAT Configuration
VPN-1 Power Object Database Configuration
To implement the overlapping NAT feature, use the dbedit database editor GUI (or
command line utility).
In the example configuration, you would set the per interface values for interface A
and interface B as follows:
Table 3-3
112
parameter
value
enable_overlapping_nat
true
overlap_nat_dst_ipaddr
The overlapping IP addresses (before NAT). In
the example configuration, this would be
192.168.1.0 for both interfaces.
overlap_nat_src_ipaddr
The IP addresses after NAT. In the example
configuration, this would be 192.168.20.0 for
interface A, and 192.168.30.0 for interface B.
overlap_nat_netmask
The net mask of the overlapping IP addresses.
In the example, 255.255.255.0.
Advanced NAT Configuration
SmartCenter Behind NAT
The SmartCenter server sometimes uses a private IP address (as listed in RFC
1918), or some other non routable IP address. Using private addresses for the
internal networks has become common, mainly because the lack of IP addresses.
Network Address Translation for the SmartCenter Server IP address is easy to
configure. Static or Hide NAT on the SmartCenter Server address can be configured
in one click, while still allowing connectivity with managed enforcement modules.
All enforcement modules can be controlled from the SmartCenter Server, and logs
can be sent to the SmartCenter Server.
Network Address Translation can also be configured for a Management High
Availability server and a Log Server, as well as for a SmartCenter Server.
Note - SmartCenter Behind NAT is not supported for deployments in which SmartCenter
also acts as an enforcement module and must be addressed from outside the NATed domain
(for example, when it receives SAM commands).
Figure 3-17 shows a typical scenario. The SmartCenter Server is in a network on
which Network Address Translation is performed (the “NATed network”). The
SmartCenter Server is able to control Check Point enforcement modules inside the
NATed network, on the border between the NATed network and the outside world,
and outside the NATed network.
Figure 3-17 Typical configuration with NAT for the SmartCenter
In ordinary Hide NAT configurations, no connections can be established from the
external side the VPN-1 Power NAT gateway. In contrast, when using Hide NAT on
the SmartCenter Server, enforcement modules are able to send logs to the
SmartCenter Server.
When using the SmartCenter behind NAT feature, the enforcement module (that is,
the remote module) automatically selects the SmartCenter address to be addressed,
and simultaneously applies NAT considerations when making this selection.
Chapter 3
Network Address Translation (NAT) 113
Advanced NAT Configuration
NAT for the SmartCenter Server is enabled in the NAT page of the SmartCenter
Server object by defining NAT and selecting Apply for VPN-1 Power/UTM control
connections.
There are situations in which the module will decide to contact the SmartCenter
with an address that does not correspond to the remote module’s deployment. For
example:
•
When there are enforcement modules from a version prior to NG with
Application Intelligence. In such a case, refer to SecureKnowledge solution
SK15558 at https://secureknowledge.checkpoint.com/ for further instructions.
•
When the enforcement module’s automatic selection does not conform with the
routing of the module’s deployment.
In the second case, you can define the masters and loggers manually. This allows
the remote module to contact SmartCenter using the desired address. When an
inbound connection from a managed module comes in to the VPN-1 Power
Gateway, port mapping is used to translate from the hiding address to the real IP
address of the SmartCenter Server.
To do this select Use local definitions for Log Servers and Use local definitions for
Masters and specify the correct IPs on the enforcement module.
Such a solution encompasses two cases:
•
The remote module addresses the NATed IP when you would like it to address
the real IP.
•
The remote module addresses the real IP when you would like it to address the
NATed IP. In this case, specify the SIC name of the SmartCenter in the masters
file.
Note that:
114
•
Only one object can be defined with these settings, unless the second object is
defined as a Secondary SmartCenter Server or a Log Server.
•
It is important to properly define the Topology settings on all enforcement
modules. In Figure 3-17 for example, on California_GW, you must define the
Primary_SmartCenter on its internal interface.
•
All managed modules, and the SmartCenter Server must be of version NG with
Application Intelligence and above.
•
In previous versions, various workarounds were required. All previous
workarounds will continue to work, with no changes in behavior.
Advanced NAT Configuration
Configuring the SmartCenter Server Object
1. On the Primary_SmartCenter object, In the NAT page, choose either Static NAT
or Hide NAT.
If using Hide NAT, select Hide behind IP Address (for example, 192.168.55.1).
Do not Hide behind Gateway (address 0.0.0.0).
2. Install on the Gateway that protects the NATed objects or network. Do not select
All. In Figure 3-17, Install on Gateway: California_GW.
3. Check Apply for VPN-1 Power/UTM control connections.
Configuring the Enforcement Module Object
California_GW must know that Primary_SmartCenter is behind it. In the
California_GW Topology page, define:
•
Interface Eth3
In the General tab of the Interface Properties window of this interface:
•
IP Address 10.0.0.0
•
Netmask 255.255.0.0
In the Topology tab of the Interface Properties window of this interface:
•
Network defined by the interface IP and Net Mask.
Configuring Pre-NG with Application Intelligence
Enforcement Module Objects
For managed modules that are not of version NG with Application Intelligence or
higher, you must define a dummy object. Referring to Figure 3-17, if Florida_GW
and California_GW have a version lower than NG with Application Intelligence, the
dummy objects ensure that
•
Florida_GW knows that its SmartCenter Server has the address 192.168.255.1.
•
California_GW knows that its SmartCenter Server has the address 10.0.0.1.
Proceed as follows:
Define a dummy object with the translated address of the Primary_SmartCenter:
1. Give it a Name (Dummy-SmartCenter).
2. In the General Properties page, in the Check Point Products section, select
Secondary Management Station and Log Server.
Chapter 3
Network Address Translation (NAT) 115
Advanced NAT Configuration
Define a dummy object for the California_GW object:
1. Give it a Name.
2. Give it the IP Address 192.168.255.1.
3. Give it the address of the Primary SmartCenter NAT definition.
4. In the General Properties page, in the Check Point Products section, select
Secondary Management Station and Log Server.
5. In the Logs and Masters page:
116
•
Define Dummy-SmartCenter as a Master.
•
Define Dummy-SmartCenter as a Log Server (if the log server is on a
separate machine, define two virtual objects).
Advanced NAT Configuration
IP Pool NAT
An IP Pool is a range of IP addresses (an Address Range, a network or a group of
one of these objects) routable to the gateway.
IP Pool NAT ensures proper routing for encrypted connections, in two connection
scenarios:
•
SecuRemote/SecureClient to MEP (Multiple Entry Point) Gateways
•
Gateway to MEP Gateways
When a connection is opened from a SecuRemote/SecureClient or a client behind a
Gateway, to a server behind the MEP Gateways, the packets are routed through one
of the MEP Gateways. Return packets in the connection must be routed back
through the same Gateway in order to maintain the connection. To ensure that this
happens, each of the MEP Gateways maintains a pool of IP addresses that are
routable to the Gateway itself. When a connection is opened to a server, the
gateway substitutes an IP address from the IP Pool for the source IP address. Reply
packets from the server return to the gateway, which restores the original source IP
address and forwards the packets to the source.
The pool of IP addresses is configured in the NAT > IP Pool page of the Gateway
object. For a discussion of how IP Pool NAT is used in MEP scenarios, see
Chapter 11, “Multiple Entry Point VPNs” in the Virtual Private Networks user guide.
IP Pool Per Interface
It is possible to define a separate IP address pool on one or more Gateway
interfaces, instead of defining a single pool of IPs for the Gateway.
Defining an IP Pool per interface provides a solution to routing issues that can
occur when the Gateway has more than two interfaces. It is sometimes important
that reply packets return to the Gateway via the same Gateway interface.
Figure 3-18 shows one of the MEP Gateways in a SecuRemote/SecureClient to MEP
(Multiple Entry Point) Gateways deployment.
Chapter 3
Network Address Translation (NAT) 117
Advanced NAT Configuration
Figure 3-18 IP Pool Per Interface
If a remote client makes a connection to the internal network, reply packets from
hosts inside the internal networks are routed to the correct Gateway interface
through the use of static IP pool NAT addresses.
The remote VPN client’s IP address is NATed to an address in the IP pool on one of
the Gateway interfaces. The addresses in that IP pool are routable only through that
Gateway interface, so all reply packets from the target host are returned to that
interface, and not to any other. For this reason, it is important that the IP NAT
pools of the interfaces do not overlap.
When the packet returns to the Gateway interface, the Gateway restores the remote
peer’s source IP address.
The routing tables on the routers that lie behind the Gateway must be edited so
that addresses from a Gateway IP pool are returned to the correct Gateway
interface.
Switching between IP Pool NAT per gateway and IP Pool NAT per interface and
then installing the Security Policy deletes all IP Pool allocation and all NATed
connections.
118
Advanced NAT Configuration
NAT Priorities
IP Pool NAT can be used both for encrypted (VPN) connections and for clear
connections that are not encrypted and decrypted by the Gateway.
Note - To allow IP Pool NAT for clear connections through the Gateway, you must configure
INSPECT changes in the user.def file. Contact Technical Support for details.
For non-encrypted connections, IP Pool NAT has the following advantages over Hide
NAT:
1. New back connections (X11, for example) can be opened to the NATed host.
2. User-to-IP mapping servers of protocols that allow one connection per IP, can
work with a number of hosts instead of one host.
3. Protocols such as IPSec, GRE and IGMP can be NATed using IP Pool NAT (and
Static NAT). Hide NAT works only with TCP, UDP and ICMP protocols.
Because of these advantages, it is possible to specify that IP Pool NAT has priority
over Hide NAT, if both match the same connection. Hide NAT is only applied if the
IP pool is used up.
The NAT priorities are:
1. Static NAT
2. IP Pool NAT
3. Hide NAT
Static NAT has all the advantages of IP Pool NAT as well as other advantages, and
so has a higher priority than the other NAT methods.
For Gateways of versions lower than NGX (R60), and for upgraded Gateways (by
default), the NAT priorities are:
1. Static NAT
2. Hide NAT
3. IP Pool NAT
Chapter 3
Network Address Translation (NAT) 119
Advanced NAT Configuration
Reusing IP Pool Addresses For Different Destinations
For Gateways of versions lower than NGX (R60) that are using IP Pool NAT, if an IP
pool contains N addresses, up to N different clients can be NATed.
From version NGX (R60), IP Pool addresses can be reused for different
destinations. If a pool contains N addresses then any number of clients can be
assigned an IP from the pool, as long as there are no more then N clients per
server. This makes much more efficient use of the addresses in the pool.
Using IP Pool allocation per destination, two different clients can receive the same
IP from the pool, as long as they are communicating with different servers
(connections 1 and 2 in Figure 3-19). When reusing addresses from the IP Pool,
back connections are supported only from the original server. In other words,
connections back to the client can be opened only from the specific server to which
the connection was opened (connection 3).
Figure 3-19 Reusing IP Pool NAT Addresses For Different Destinations
The default “do not reuse” IP Pool behavior is that each IP address in the IP Pool
is used once (connections 1 and 2 in Figure 3-20). In this mode, if an IP pool
contains 20 addresses, up to 20 different clients can be NATed. Back connections
can be opened from any source to the client (connection 3).
120
Advanced NAT Configuration
Figure 3-20 Do Not Reuse IP Pool NAT Addresses
Switching between “reuse” and “do not reuse” modes and then installing the
Security Policy deletes all IP Pool allocation and all NATed connections.
Configuring IP Pool NAT
1. In Global Properties > NAT page, select Enable IP Pool NAT and choose tracking
options.
2. In the Gateway General Properties page, ensure the Gateway version is correctly
specified. IP Pool NAT can be defined per Gateway or (for Gateways of version
NGX (R60) or higher) per Gateway interface.
3. For each Gateway or Gateway interface, create a network object that represents
the IP pool NAT addresses for that Gateway or Gateway interface. The IP pool
can be a network, group, or address range. For an address range, for example:
•
On the network objects tree, right-click Network Objects branch > New >
Address Range... The Address Range Properties window opens.
•
On the General tab, enter the first IP and last IP of the address range.
•
Click OK. In the network objects tree, Address Ranges branch, the new
address range appears.
4. On the Gateway object where IP pool NAT translation is performed, Gateway
Properties window, NAT > IP Pool NAT page, select either one of:
•
Allocate IP Addresses from, and select the address range you created in order
to configure IP Pool NAT for the whole Gateway, or select
•
Define IP Pool addresses on gateway interfaces in order to configure IP Pool
NAT per interface.
5. If required select one or more of the options:
Chapter 3
Network Address Translation (NAT) 121
Advanced NAT Configuration
•
Use IP Pool NAT for VPN client connections
•
Use IP Pool NAT for gateway to gateway connections
•
Prefer IP Pool NAT over Hide NAT to specify that IP Pool NAT has priority over
Hide NAT, if both match the same connection. Hide NAT is only applied if
the IP pool is used up.
6. Click Advanced.
•
Return unused addresses to IP Pool after has a default of 60 minutes.
Addresses in the Pool are reserved for that period even if the user logs off.
If the user disconnects from his/her ISP and then redials and reconnects,
there will be two Pool NAT addresses tied up for this user until the first
address from the IP Pool times-out. If users regularly lose their ISP
connections, you may want to decrease this time-out to stop the IP Pool
being depleted.
•
Reuse IP addresses from the pool for different destinations is a good option to
choose, unless you need to allow back connections to be opened to clients
from any source, rather than just from the specific server to which the
client originally opened the connection.
•
Click OK.
7. Edit the routing table of each internal router, so that packets with an a IP
address assigned from the NAT pool are routed to the appropriate Gateway or (if
using IP Pools per interface) the appropriate Gateway interface.
IP Pool NAT for Clusters
IP Pools for Gateway clusters are configured in two places in SmartDashboard:
122
•
In the Gateway Cluster object NAT > IP Pool NAT page, choose the connection
scenario.
•
In the Cluster member object IP Pool NAT page, define the IP Pool on the
cluster member. A separate IP pool must be configured for each cluster
member. It is not possible to define a separate IP Pool for each cluster member
interface.
Chapter
ISP Redundancy
4
In This Chapter
Need for ISP Link Redundancy
page 124
Solution for ISP Link Redundancy
page 125
Considerations for ISP Link Redundancy
page 136
Configuring ISP Link Redundancy
page 137
123
Need for ISP Link Redundancy
Need for ISP Link Redundancy
As Internet access becomes increasingly critical to business, the costs associated
with loss of that connectivity become greater. To protect against network downtime
it makes sense to deploy redundant systems for mission critical Internet
applications. Connecting to the Internet via more than one Internet Service Provider
(ISP) provides that additional redundancy.
A number of solutions are available in the market to enable connections to multiple
ISPs, however, these solutions require expensive specialized hardware, and need
detailed knowledge to set up and maintain. A simple solution is needed that makes
use of the existing boundary between the Internet and organization, namely the
firewalled gateway.
124
Solution for ISP Link Redundancy
Solution for ISP Link Redundancy
In This Section
ISP Redundancy Overview
page 125
ISP Redundancy Operational Modes
page 126
Monitoring the ISP Links
page 127
How ISP Redundancy Works
page 127
The ISP Redundancy Script
page 129
Manually Changing the Link Status (fw isp_link)
page 130
ISP Redundancy Deployments
page 131
ISP Redundancy and VPNs
page 133
ISP Redundancy Overview
ISP Redundancy assures reliable Internet connectivity by allowing a single or
clustered VPN-1 Power gateway to connect to the Internet via redundant Internet
Service Provider (ISP) links. The feature is part of the standard VPN-1 Power
installation, and does not require specialized and costly networking hardware, nor
does it require new skills.
ISP Redundancy is supported on VPN-1 Power NG with Application Intelligence
(R55) enforcement modules or higher, on the following platforms:
•
Red Hat Linux 7.2 or higher.
•
SecurePlatform.
•
IPSO
ISP Redundancy monitors the ISP links, and directs connections to the appropriate
link, depending on the operating mode. The available modes are Load Sharing and
Primary/Backup modes.
Figure 4-1 shows a typical deployment with a single ISP link, and redundant
deployment with duplicate ISP links.
Chapter 4
ISP Redundancy 125
Solution for ISP Link Redundancy
Figure 4-1
ISP Link Redundancy
ISP Redundancy Operational Modes
ISP Redundancy can work in one of two modes. These modes control the behavior
of outgoing connections, that is, connections from clients in the internal networks
towards the Internet:
•
Primary/Backup mode connects to an ISP through the primary link, and switches
to a backup ISP when the primary ISP link fails. When the primary link is
restored, new outgoing connections are assigned to it, while existing
connections are maintained over the backup link until they are complete.
•
Load Sharing mode connects to both ISPs, while distributing the load of
outgoing connections between the ISPs. New connections are randomly
assigned to a link. If a link fails, all new outgoing connections are directed to
the active link.
Incoming connections (connections from the Internet to application servers in the
DMZ or internal networks) also benefit from the high availability of the two ISP
links because VPN-1 Power returns packets via the same ISP Link through which
the connection was initiated.
126
Solution for ISP Link Redundancy
In addition, in Load Sharing mode, incoming connections can reach the application
servers via either ISP link. This is because VPN-1 Power can answer DNS requests
for the IP address of internal servers with addresses from both ISPs, alternating
their order.
Monitoring the ISP Links
ISP Redundancy monitors the status of the ISP links, and directs outgoing
connections to the appropriate link.
To monitor the status of the link, VPN-1 Power checks whether the interface is up
or down, and also determines whether the cable is plugged in. The next hop router
is also monitored automatically.
In addition, there is an optional way of monitoring the status of the ISP link. The
administrator can configure a list of hosts that must answer to ICMP echo requests
(pings) in order for the ISP link to be considered active. If one of the hosts fails to
return any ICMP replies, the link is considered to be down. You may choose to
include hosts such as an ISP web server or some other host on the Internet.
The status of the ISP links is reported by SmartView Monitor, in the Firewall
section.
How ISP Redundancy Works
Both outgoing connections from behind the VPN-1 Power gateway towards the
Internet, and incoming connections from the Internet, benefit from the existence of
duplicate links.
Outgoing Connections
In Load Sharing mode, outgoing traffic that leaves the VPN-1 Power gateway
towards the Internet is distributed between the ISP Links. In Primary/Backup
mode, outgoing traffic uses the primary link, if it is up.
Hide NAT is used to change the source address of outgoing packets to the address
of the interface through which the packet leaves the VPN-1 Power gateway. This
allows return packets to be automatically routed through the same ISP link,
because their destination address is the address of the appropriate link. Hide NAT
must be configured by the administrator.
Chapter 4
ISP Redundancy 127
Solution for ISP Link Redundancy
Incoming Connections
For external users to make incoming connections, the administrator must give each
application server two routable IP addresses, one from each ISP. The administrator
must also configure Static NAT to translate the routable addresses to the real server
address.
If the servers handle different services (HTTP, FTP, etc.), it is possible to use NAT
to make do with only two routable IP addresses for all the publicly available
servers.
External clients use one of the two addresses. In order to connect, the clients must
be able to resolve the DNS name of the server to the correct IP address.
Note - In these explanations, the subnets 172.16.0.0/24 and 192.168.0.0/24 represent
public routable addresses.
This is illustrated in Figure 4-2. The web server www.example.com is assigned an
IP address from each ISP: 192.168.1.2 from ISP A, and 172.16.2.2 from ISP B.
If ISP link A is down, 192.168.1.2 becomes unavailable, so the clients must be
able to resolve www.example.com to 172.16.2.2.
Figure 4-2 IP address resolution for incoming connections
The process by which an incoming connection is established, is as follows:
When a user in the Internet contacts www.example.com, the client machine sends
a DNS query for the IP address. The DNS query reaches the VPN-1 Power gateway.
128
Solution for ISP Link Redundancy
VPN-1 Power has a built-in mini-DNS server that can be configured to intercept
DNS queries (of type A) for servers in its domain.
A DNS query arriving at an interface belonging to one of the ISP links is
intercepted by VPN-1 Power.
If VPN-1 Power recognizes the name of the host, it will send a reply, as follows:
•
In Primary/Backup mode, VPN-1 Power replies only with the addresses
associated with the primary link, as long as the primary link is active.
•
In Load Sharing mode, VPN-1 Power replies with two addresses, alternating
their order.
If VPN-1 Power is unable to handle the DNS requests, (it may not recognize the
host name, for example), VPN-1 Power passes the DNS query to its original
destination, that is, the DNS server of the domain example.com.
When the external client receives the reply to its DNS query, it opens a connection.
Once the packets reach the gateway, VPN-1 Power uses Static NAT to translate the
destination address 192.168.1.2 or 172.16.2.2 to the real server address
10.0.0.2.
VPN-1 Power routes reply packets from the server to the client through the same
ISP link that was used to initiate the connection.
The ISP Redundancy Script
Whenever VPN-1 Power starts or an ISP link changes state, a script runs.
Depending on whether the ISP link is up or down, this script automatically changes
the default route of the VPN-1 Power enforcement module.
If one of the ISP links is a dialup interface, it is possible to manually edit the ISP
Redundancy script, to make VPN-1 Power take the dialup interface up or down
when the ISP links change state, or when VPN-1 Power starts.
The script can be configured to perform any other action. For example, to issue a
SAM command to block certain traffic when the primary link goes down, in order to
decrease the traffic load on the link.
The name and location of the ISP Redundancy script is $FWDIR/bin/cpisp_update.
Chapter 4
ISP Redundancy 129
Solution for ISP Link Redundancy
Manually Changing the Link Status (fw isp_link)
Use the fw isp_link command to configure the ISP link on VPN-1 Power to Down
or Up. This command is useful:
•
To test your configuration.
•
If you know the ISP link is down but VPN-1 Power thinks otherwise. In that
case, take care to use the command again to bring the link back up when the
link in reality becomes available.
This command can be executed locally on the enforcement module or remotely
from the SmartCenter Server. In the latter case the target argument must be
supplied.
fw isp_link [target] link-name up|down
Table 4-1
130
fw isp_link arguments
Argument
Meaning
target
The name of the enforcement module.
link-name
The name of the ISP link, as defined in the ISP Redundancy page
of the Gateway or Gateway Cluster object.
Solution for ISP Link Redundancy
ISP Redundancy Deployments
A number of deployments are supported. Considerations for choosing each
deployment are described in “Considerations for ISP Link Redundancy” on
page 136.
Two External Interfaces
The simplest way of connecting to two ISPs is to connect each VPN-1 Power
gateway interface to a different ISP via a LAN, as in Figure 4-3. The next hop
routers are either at the boundary of the organization or at the ISP.
Figure 4-3 Two ISPs connected to different external VPN-1 Power gateway interfaces
One External interface
If only one external interface is available on the VPN-1 Power gateway, you can
configure two subnets on the same external interface. Both ISP links are then
connected to the same VPN-1 Power interface, but to different next hop routers
(usually via a switch). This is illustrated in Figure 4-4.
Chapter 4
ISP Redundancy 131
Solution for ISP Link Redundancy
Figure 4-4
Two ISPs connected to the same VPN-1 Power gateway external interface
One Permanent and One Dialup (Backup) Interface
To connect to one of the ISPs via a dialup network (a modem), and to the other ISP
via a LAN, connect each VPN-1 Power gateway external Interface to a different ISP
link, as in Figure 4-5. This deployment is useful if you have a dialup connection to
your backup ISP.
Figure 4-5 One ISP link is a LAN, and the other is a dialup network
Gateway Cluster Connection
If you have a ClusterXL gateway cluster, connect each cluster member to both ISPs
via a LAN using two interfaces, as in Figure 4-6.
132
Solution for ISP Link Redundancy
Configure ClusterXL in the usual way. Note however that the member interfaces
must be on the same subnet as the cluster external interfaces. For details, see the
ClusterXL guide.
Figure 4-6 Both ISP links are LANs connected to a Gateway cluster
ISP Redundancy and VPNs
When ISP Redundancy is configured on the VPN-1 Power gateway, VPN (that is,
encrypted) connections will survive a failure of one of the ISP links on the gateway.
ISP Redundancy works with both gateway to gateway VPNs and
SecuRemote/SecureClient Remote Access VPNs.
The settings configured in the ISP Redundancy window are by default, applied to
the Link Selection page and will overwrite any pre-existing configuration. If the
Primary/Backup setting is configured, this will be carried over to the Link Selection
configuration.
Chapter 4
ISP Redundancy 133
Solution for ISP Link Redundancy
On the VPN > Topology > ISP Redundancy window, configure the appropriate
settings. When ISP Redundancy is configured, the default setting in the Link
Selection page is Use ongoing probing. However, Link Selection will only probe the
ISPs configured in the ISP Redundancy window. This enables connection failover of
the VPN tunnel if connectivity to one of the Gateway interfaces fails.
There are instances when having a different configuration for Link Selection is
required.
Figure 4-7 Two Gateways with two ISPs
In this scenario:
•
Gateways A, B, and C have two ISPs.
•
ISP Redundancy is configured on Gateway A.
•
Gateway A should use ISP 1 in order to connect to Gateway B and ISP 2 in
order to connect to Gateway C. If one of the ISPs becomes unavailable, the
other ISP should be used.
For more details, see the Link Selection chapter of the VPN guide.
134
Solution for ISP Link Redundancy
ISP Redundancy and 3rd Party VPNs
The ability of a 3rd party VPN device to detect an ISP link failure depends on the
3rd party device implementation. A failure of an ISP link could lead to a VPN
failure for two reasons:
1. The 3rd. party device may not recognize incoming encrypted traffic from the
secondary link as coming from the enforcement module.
2. The 3rd party device may be unable to detect an ISP link failure and may
therefore keep encrypting traffic to the failed link.
Chapter 4
ISP Redundancy 135
Considerations for ISP Link Redundancy
Considerations for ISP Link Redundancy
Choosing the Deployment
The choice of deployment that best suits your own particular needs will usually be
very clear:
•
The simplest configuration is to use a different interface for each ISP link, as in
Figure 4-3.
•
If only one external interface is available on the VPN-1 Power gateway, you can
connect both ISPs to the same interface. This is done by defining two subnets,
one for each ISP, on the same interface. Such a configuration is illustrated in
Figure 4-4.
•
If one of the ISP links is a dialup network (that is, a connection via a modem),
to be used for backup, use the deployment in Figure 4-5, and choose the
Primary/Backup mode of operation.
•
If the ISP links are connected to a VPN-1 Power gateway Cluster, use the
deployment in Figure 4-6.
Choosing the Redundancy Mode
If both ISPs are essentially the same, use Load Sharing mode. That way you will be
making best use of both ISPs.
You may prefer to use one of your two ISPs who may, for example be more
cost-effective in terms of price and reliability. In that case, use Primary/Backup
mode, and use the more cost-effective ISP for the Primary ISP link.
136
Configuring ISP Link Redundancy
Configuring ISP Link Redundancy
In This Section
Introduction to ISP Link Redundancy Configuration
page 137
Registering the Domain and Obtaining IP Addresses
page 137
DNS Server Configuration for Incoming Connections
page 138
Dialup Link Setup for Incoming Connections
page 139
SmartDashboard Configuration
page 139
Configuring the Default Route for the ISP Redundancy Gateway
page 142
Introduction to ISP Link Redundancy Configuration
The following configuration allows outgoing connections from behind the VPN-1
Power gateway, towards the Internet, and for incoming connections from the
Internet to the networks behind the VPN-1 Power gateway.
Note - For advanced configuration options see SecureKnowledge solution sk23630 at
https://secureknowledge.checkpoint.com/ (username and password required).
In the configuration explanations, the subnets 192.168.1.0/24 and 172.16.2.0/24 represent public
routable addresses.
Registering the Domain and Obtaining IP Addresses
The VPN-1 Power gateway or a DNS server behind it must respond to DNS queries
and resolve IP addresses that belong to publicly accessible servers in the DMZ (or
other internal network). It is not necessary to have an actual DNS server, because
the VPN-1 Power gateway will intercept the DNS queries if configured to do so.
1. Obtain one routable IP address from each ISP for the DNS server or for the
VPN-1 Power gateway that will intercept DNS queries. Alternatively, if routable
IP addresses are not available, make the DNS server accessible from the
Internet using manual NAT, as described in step 23, below.
2. Register your domain (e.g. example.com) with both ISPs.
3. Inform both ISPs of the two addresses of the DNS server that will respond to
DNS queries about the domain example.com.
Chapter 4
ISP Redundancy 137
Configuring ISP Link Redundancy
4. To allow incoming connections, obtain one routable IP address from each ISP
for each application server that is to be accessed from the Internet. For
example, in Figure 4-2 on page 128, obtain two IP addresses for the web server
in DMZ-net.
Alternatively, it is possible to avoid using routable IP addresses for the publicly
available servers, as described in step 23, below.
DNS Server Configuration for Incoming Connections
The following procedure configures VPN-1 Power to:
•
Intercept DNS queries to your web server (for example www.example.com in
Figure 4-2 on page 128) that arrive at the VPN-1 Power external interfaces,
and
•
Respond to them with 192.168.1.2 and 172.16.2.2.
Proceed as follows:
5. In the ISP Redundancy window, DNS Proxy tab, check Enable DNS proxy.
6. VPN-1 Power responds to DNS queries with either one or two IP addresses,
depending on the status of the ISP link and on the Redundancy mode. To
configure this behavior, map each server name to an IP address pair. In the DNS
Proxy tab, click Add….
•
Type a Host name (such as www.example.com)
•
Add an IP address in ISP-1 (such as. 192.168.1.2 in Figure 4-2 on
page 128) and address for ISP-2 (such as 172.16.2.2).
7. It is important to ensure that DNS servers in the Internet do not store
out-of-date address information. Each DNS reply has a Time To Live (TTL) field
which indicates to the recipients of the reply how long the information in the
reply may be cached. By default, VPN-1 Power replies with a TTL of 15
seconds. This can be changed in the DNS TTL field.
138
Configuring ISP Link Redundancy
Dialup Link Setup for Incoming Connections
8. If one of the ISP links is a dialup network, edit the ISP Redundancy Script
located in $FWDIR/bin/cpisp_update. In the script, use the Linux or
SecurePlatform operating system command to bring up or to take down the
dialup interface.
9. You can connect SecurePlatform to ISPs that provide xDSL services using
PPPoE or PPTP xDSL modems. If using one of these connections, then in the
PPPoE or PPTP configuration of SecurePlatform, uncheck Use Peer Gateway.
SmartDashboard Configuration
10. Define a Security Rule Base rule that accepts DNS traffic through the VPN-1
Power gateway. Use the domain_udp service.
11. In the Check Point Gateway window, Topology page, define the VPN-1 Power
interfaces leading to the ISPs.
12. In the Topology > ISP Redundancy page, check Support ISP Redundancy.
13. Perform either Automatic ISP Link Configuration or Manual ISP Link
Configuration. Automatic configuration will only work if there are exactly two
external interfaces defined in the Topology page, and is not possible for a
Gateway Cluster object.
Automatic ISP Link Configuration
14. Click Automatic ISP Links configuration. This configures the ISP links based on
information taken from the routing table of the enforcement module, and from
the Topology page of the enforcement module object.
15. To work in Primary/Backup mode:
1. In the Redundancy Mode section, select Primary/Backup.
2. Select and Edit the link you wish to be primary. In the ISP Link Properties
window, General tab, check Primary ISP.
16. Examine the automatically configured ISP Links configuration for correctness.
17. Continue with step 20.
Chapter 4
ISP Redundancy 139
Configuring ISP Link Redundancy
Manual ISP Link Configuration
18. In the Redundancy Mode section, select Load Sharing or Primary/Backup.
19. Define two ISP links. For each ISP link, click Add. In the ISP Link Properties
window, General tab:
1. Give the ISP link a Name, and choose the Interface leading to the ISP.
2. Specify the Next Hop IP Address by clicking Get from routing table. If the ISP
link is a dialup connection, leave the Next Hop IP Address field blank.
In the example of Figure 4-3 on page 131, the next hop router on the way to
ISP A has IP address 192.168.1.1, and the next hop router on the way to ISP
B has IP address 172.16.2.1.
3. In Primary/Backup mode, define whether the ISP link is Primary.
20. If you wish, define a list of hosts to be monitored in order to verify that the link
is operational. To specify those hosts, move to the Advanced tab of the ISP Link
Properties window, and Add the desired hosts to the list of Selected hosts.
21. Define Tracking. Choose an option for both ISP failure and ISP recovery.
Allowing Incoming and Outgoing Connections
22. To allow outgoing connections via both ISP links, define automatic Hide NAT on
network objects that initiate the outgoing connections.
For example, in Figure 4-2 on page 128, edit the internal_net object. In the
Network Properties window General tab, check Add Automatic Address Translation
Rules, select Translation Method Hide, and choose Hide behind Gateway.
23. To allow incoming connections via both ISP links, to the application servers and
the DNS server, define manual Static NAT rules.
If you have only one routable IP address from each ISP, and those addresses
belong to the VPN-1 Power gateway, you can allow specific services to reach
specific servers. Using Figure 4-2 on page 128 as an example, define NAT rules
140
Configuring ISP Link Redundancy
as in Table 4-2. Incoming HTTP connections from both ISPs reach the web
server www.example.com, and DNS traffic from both ISPs reaches the DNS
server.
Table 4-2
Manual Static Rules for a Web Server and a DNS Server
Original
Translated
Comment
Source
Destination
Service
Source
Destination
Serv.
Any
192.168.1.2
http
=
10.0.0.2
(Static)
=
Incoming Web
ISP A
Any
172.16.2.2
http
=
10.0.0.2
(Static)
=
Incoming Web
ISP B
Any
192.168.1.2
domain
_udp
=
10.0.0.3
(Static)
=
Incoming DNS
ISP A
Any
172.16.2.2
domain
_udp
=
10.0.0.3
(Static)
=
Incoming DNS
ISP B
If you have a routable address from each ISP for each publicly reachable server
(in addition to the addresses that belong to the VPN-1 Power gateway), you can
allow any services to reach all the application servers. Give each server a
non-routable address, and in the NAT Rule Base in Table 4-2:
•
Use the routable addresses in the Original Destination.
•
Use the non-routable address in the Translated Destination.
•
For Original Service, use Any.
Note - If using Manual NAT, automatic arp won’t work for the NATed addresses. You may
need to implement SecureKnowledge solution sk8022.
24. Save and install the Security Policy.
Chapter 4
ISP Redundancy 141
Configuring ISP Link Redundancy
Configuring the Default Route for the ISP
Redundancy Gateway
25. Configure the ISP Redundancy gateway machine to have only a single default
route. Do not give it any metric.
•
When working in a Primary/Backup mode, set the IP address of the router
leading to the primary ISP as the default route.
•
When working in Load Sharing mode, use the router of the first ISP link in
the Check Point Gateway > Topology > ISP Redundancy window as the default
route.
When an ISP link fails, the default route of the gateway is automatically
changed by means of the ISP Redundancy script. When the link goes up again,
the original default route will be reinstated.
142
5
Chapter
ConnectControl - Server Load
Balancing
In This Chapter
The Need for Server Load Balancing
page 144
The ConnectControl Solution for Server Load Balancing
page 145
Configuring ConnectControl
page 153
143
The Need for Server Load Balancing
The Need for Server Load Balancing
While Check Point offers optimal performance for single server deployment, there
are several disadvantages to relying on a single server to host an application. While
a server's capabilities can often be expanded with additional processors and RAM,
in many cases a lone machine cannot handle the traffic volume, which results in
poor response times and connection time-outs. Additionally, server maintenance
and other unplanned downtime are problematic in a single server environment.
Sharing network traffic intelligently among multiple servers can shorten response
times and reduce the risk to the application by any one machine failure.
144
The ConnectControl Solution for Server Load Balancing
The ConnectControl Solution for Server
Load Balancing
In This Section
Introduction to ConnectControl
page 145
Load Balancing Methods
page 146
ConnectControl Packet Flow
page 147
Logical Server Types
page 147
Persistent Server Mode
page 150
Server Availability
page 152
Load Measuring
page 152
Introduction to ConnectControl
ConnectControl is Check Point’s solution for server load balancing. It allows you to
distribute network traffic among a number of servers, which reduces the load on a
single machine, improves network response time, and provides high availability.
Beside the performance benefits of this feature, spreading the load over multiple
machines creates redundancy for your application, thus reducing the risk of
downtime.
Load-balanced servers are represented by a single virtual IP address. Clients are
thus unaware that more than one server may be serving their requests. This is
accomplished using a Logical Server, a network object defined in SmartDashboard
that represents a of physical servers. The Logical Server fields service requests for
the load-balanced application and directs them to the appropriate physical server.
ConnectControl runs on the enforcement points and does not impose any additional
memory or processing requirements. It continuously checks the availability of each
server. If a server fails, or is unreachable, ConnectControl stops directing
connections to that server until it becomes available.
Chapter 5
ConnectControl - Server Load Balancing 145
The ConnectControl Solution for Server Load Balancing
Load Balancing Methods
ConnectControl not only spreads out the network traffic to your load-balanced
servers; it also allows you to distribute that traffic according to predefined
balancing methods. There are five available methods from which to choose:
146
•
Server Load measures the load on each server to determine which has the most
available resources to service a request. Each server in the group runs a load
measuring agent that automatically reports the current system load to the
ConnectControl module on the VPN-1 Power Gateway. Server Load may be a
good choice for your environment if your servers are running other demanding
applications in addition to supporting your load-balanced application. See
“Load Measuring” on page 152 for more details.
•
Round Trip ensures that incoming requests are handled by the server with the
fastest response time. ConnectControl ascertains the response times of the
servers in the group at a user-defined interval, whereupon the enforcement
module executes a series of ICMP echo requests (pings) and reports the server
with the shortest average round trip time. ConnectControl then directs the
service request to that server. The round trip method may be a good choice if
there are large variations in the traffic load on your network, or when load
balancing over WAN connections.
•
Round Robin assigns service requests to the next server in the sequence. The
round robin method provides optimal load balancing when the load-balanced
servers all have similar RAM, CPU, and are located on the same segment.
•
Random assigns service requests to servers at random. The random method
provides optimal load balancing when the load-balanced servers all have similar
RAM, CPU, and are located on the same segment.
•
Domain directs service requests based on domain name.
The ConnectControl Solution for Server Load Balancing
ConnectControl Packet Flow
When a client requests access to an application load-balanced by ConnectControl,
the packet flow is as follows (the following steps correspond with Figure 5-1):
1. A client initiates a connection with the logical IP address of the application
server, which is in actuality the address assigned to the Logical Server.
2. The service request arrives at the gateway, and is matched by the Logical Server
rule in the Rule Base. VPN-1 Power directs the packet to the Logical Server.
3. ConnectControl determines which of the servers in the group will fulfill the
request based on the load balancing method.
Figure 5-1 ConnectControl Packet Flow
Logical Server Types
When creating the Logical Server object, you must identify the server type as either
HTTP or Other. This distinction is meaningful, as ConnectControl handles the
connection to the client differently for each server type. To direct network traffic,
server type HTTP uses HTTP redirection, while server type Other uses address
translation.
Chapter 5
ConnectControl - Server Load Balancing 147
The ConnectControl Solution for Server Load Balancing
HTTP
The Logical Server of type HTTP employs HTTP redirection as its method of
distributing network traffic, and as such supports only HTTP services. The
redirection mechanism ensures that all sessions comprising an HTTP connection
are directed to a single server. This is vital for many Web applications, such as
those using HTTP-based forms, which require that a single server process all user
data.
The HTTP redirection mechanism works in conjunction with ConnectControl’s load
balancing methods. The initial HTTP connection is directed to the proper server
based on the chosen load balancing method. ConnectControl then notifies the
client that subsequent connections should be directed to the IP address of the
selected physical server rather than the IP address of the Logical Server. The IP
address can be that of a server behind the firewall, or offsite. The remainder of the
session is conducted without ConnectControl intervention. All operations are
transparent to end-users.
The Logical Server may direct the client to an HTTP server behind the firewall, or
to an offsite HTTP server, depending on the result of ConnectControl’s load
balancing. Figure 5-2 depicts a connection being directed to an offsite server.
Figure 5-2 Packet Flow in a Logical Server of type HTTP Environment
All further communication between the client and the server take place without the
intervention of ConnectControl.
148
The ConnectControl Solution for Server Load Balancing
Other
The Logical Server of type Other can be used for all services supported by VPN-1
Power, including HTTP. It uses address translation to direct network traffic to the
grouped servers. ConnectControl mediates each service request, even when clients
continue a session. When you create a Logical Server of type Other, ConnectControl
allows the connection by automatically placing entries in VPN-1 Power’s kernel
table. ConnectControl determines which server will receive the request, and uses
NAT to modify the destination IP address of the incoming packet. If a return
connection is opened, the connection is automatically established between the
server and the client, and the server’s source address in the packet is translated to
that of the Logical Server. Figure 5-3 depicts a connection being directed to a
NATed FTP server inside the firewall.
Figure 5-3 Packet Flow in a Logical Server of type Other Environment
On the packet’s return journey, the firewall translates the packet’s origin address to
that of the Logical Server.
You can use a Logical Server of type Other to handle HTTP service requests as well.
In contrast to type HTTP, once a connection between client and server has been
established, the Logical Server of type Other does not disconnect from the
conversation. Instead ConnectControl handles each HTTP service request from the
client, and multiple service requests from one client may be directed to different
servers.
Chapter 5
ConnectControl - Server Load Balancing 149
The ConnectControl Solution for Server Load Balancing
Considering Logical Server Types
In considering the proper implementation for your environment, there are three
decisive criteria: use of HTTP forms, server location, and servers configured for
NAT. Type HTTP supports offsite HTTP servers and form-based applications, but
works only with the HTTP protocol. Type Other supports all protocols and may
provide the most accurately balanced load, but requires servers to be NATed by the
gateway.
Persistent Server Mode
Persistent server mode is a ConnectControl feature that maintains a client’s
connection to the server to which it was first directed (see “Persistent Server
Timeout” on page 151 for more on length of persistent sessions). You must choose
whether the persistency is by server or by service.
Persistency By Server
Persistency by server is useful for certain types of HTTP applications, such as
forms support. For example, consider a load-balanced environment of three web
servers, as illustrated in Figure 5-4. With Persistency by server enabled,
ConnectControl directs an HTTP client to a specific server, and each subsequent
request by the client is directed to that same server. This mode allows clients to fill
out forms without the data loss that would occur if separate service requests were
directed to different servers. If you are supporting forms, make sure Persistent
server mode is enabled (the default setting) and Persistency by server is set as well.
150
The ConnectControl Solution for Server Load Balancing
Persistency By Service
Persistency by service is useful if you are load balancing multiple services in your
server group. For example, consider a redundant environment of two machines,
each running HTTP and FTP.
Figure 5-4 Example of Persistency by Service
With persistency by service, the client can be directed to one server for HTTP
services, and another for FTP services. This provides the benefit of not becoming
locked in to a server under a heavy load, as you might be if you were running
persistency by server in this configuration. Thus ConnectControl allows you to
configure Persistency by service, which directs previously load-balanced clients who
request a different service to be load-balanced and directed to the appropriate
server again.
Persistent Server Timeout
One aspect of Persistency is configured on the ConnectControl page of the Global
Properties window. The Persistent server timeout sets the amount of time that a
client, once directed to a particular server, will continue to be directed to that same
server. In the event that a server becomes unavailable, new connections will be
directed to an available server even if persistent server mode is enabled. If you
desire the optimal load balance among your servers, uncheck Persistent server
mode, and all of your application’s traffic will be distributed according to the load
balance method.
Chapter 5
ConnectControl - Server Load Balancing 151
The ConnectControl Solution for Server Load Balancing
Server Availability
ConnectControl allows you to configure aspects of its system to check the
availability of servers in the Logical Server group. You can control how often the
module pings the servers to make sure they are still active. You can also configure
the number of attempts it will make to contact a non-responsive server, after which
ConnectControl stops directing connections to it.
These settings are located on the ConnectControl page of the Global Properties
window. Server availability check interval sets how often the servers are pinged, and
Server check retries sets the number of attempts to contact non-responsive servers.
Load Measuring
The server load balancing method is unique in that it requires a special load
measuring agent to run on each server in the group. The agent is lightweight and
does not add additional latency or system overhead to the server. It uses the UDP
transport protocol to support communication between the load measuring agent and
the ConnectControl module. Check Point provides a sample load measuring agent
application for installation on servers, as well as a load measuring application
programming interface (API) for organizations who wish to write their own agents.
You can download the load agent application for your OS from SecureKnowledge at:
https://support.checkpoint.com/login/login.jsp. Sign in with your User Center email
and password, and enter the SecureKnowledge ID 47.0.1569467.2530820.
You can configure certain aspects of the load measuring agent on the
ConnectControl page of the Global Properties window. The Load agents port property
specifies the port the load agent uses to communicate with VPN-1 Power. All the
load measuring agents in a configuration must use the same port number. The Load
measurement interval property sets the interval at which the agent returns
information about the server’s load to the firewall. The default is every 20 seconds.
For Windows servers, configure and enable the load agent with the syntax:
load_agent_nt <port_number> <load_value>.
The default port used by ConnectControl for version NG or higher is 18212. The
values for load_value are 0, 1, 2, where:
• 0 measures the load over a 1 minute interval
• 1 measures the load over a 5 minute interval
• 2 measures the load over a 15 minute interval
152
Configuring ConnectControl
Configuring ConnectControl
Create Network Objects for the Application Servers
1. In SmartDashboard, right click on Network Objects in the Network Objects tree,
and select New > Node > Host.
2. Define a server object that represents a server that will be load-balanced.
3. Repeat step 2 for each server you place in the group.
Create a Network Group Object to Group the Application
Servers
4. In SmartCenter, right click on Network Objects, and select New > Group > Simple
Group.
5. Name the group (ex. HTTP_Server_Group).
6. Add the server objects to the group in the Group Properties box. It is
recommended to add no more than 29 Logical Servers to a group.
Create a Logical Server Object to Pool the Application
Servers
7. In SmartDashboard, right click on Network Objects in the Network Objects tree,
and select New > Logical Server. Make sure the IP address you assign is a
routable IP address. All traffic to be load-balanced should be directed through
the gateway.
8. Select the Server’s Type.
9. In Servers Group, add the Group Object you created in step 3.
10. If you intend to use persistent server mode, select Persistency by service or
server. The default mode is Persistency by service. Deselect Persistent server
mode if you don’t want to use it.
11. Select a load balance method in Balance Method.
Chapter 5
ConnectControl - Server Load Balancing 153
Configuring ConnectControl
12. Add the following rule to the Rule Base:
Table 5-1
Source
Destination
Service
Action
Any
Logical_Server
[load-balance
d service(s)]
Accept or
User Auth or
Client Auth or
Session Auth
For applications using HTTP redirection (Logical Server of type HTTP), add a
second rule to allow the physical server group to communicate directly with clients
after sessions are started:
Table 5-2
Source
Destination
Service
Action
Any
HTTP_Server_Group
http
Accept
Configure ConnectControl Global Properties
13. In the Policy menu, choose Global Properties > ConnectControl. Review the
default settings and adjust according to your implementation.
•
Servers Availability settings manage how often ConnectControl checks to
make sure the load balanced servers are running and responding to service
requests, and how many times ConnectControl attempts to contact a server
before ceasing to direct traffic to it.
Server availability check interval: default is 20 seconds
Server check retries: default is 3 times.
•
Servers Persistency sets the amount of time that a client, once directed to a
particular server, will continue to be directed to that same server.
Persistent server timeout: default is 1800 seconds
•
Servers Load Balancing settings manage how often the load measuring
agents (if employed) report their load status to ConnectControl, and on what
port they communicate with ConnectControl.
Load agents port: default is 18212
Load measurement interval: default is 20 seconds
154
SmartDefense
This chapter gives a conceptual overview of SmartDefense, which enables
customers to configure, enforce and update network and application attack
defenses. The DShield StormCenter is also described in detail. For information
about specific protections, see the SmartDefense HTML pages and the online
help.
Chapter
SmartDefense
6
In This Chapter
Need for Active Defense
page 158
The SmartDefense Solution for an Active Defense
page 160
SmartDefense Profiles
page 173
Configuring SmartDefense
page 175
SmartDefense Services
page 176
Configuring SmartDefense Profiles
page 179
SmartDefense StormCenter Module
page 181
157
Need for Active Defense
Need for Active Defense
The threats to network security are many, and they are evolving in sophistication as
well as variety.
Figure 6-1 Network Attacks
Since access control devices like Check Point’s VPN-1 Power have prevented
unauthorized traffic from passing through the gateway, hackers are now focusing
their efforts on the misuse of allowed traffic and services. Some of the most serious
threats in today's Internet environment come from attacks that attempt to exploit
the application layer. Of particular interest to hackers are services such as HTTP
(TCP port 80) and HTTPS (TCP port 443), which are commonly open in many
networks. Access control devices cannot easily detect malicious attacks aimed at
these services.
Consider the following two examples of Denial of Service (DoS) attacks. Let’s say
that you have decided to allow ICMP requests (pings) on your network. A DoS
attack may exploit this to flood your network with pings, thereby preventing other
connections. Without a defense that automatically detects and prevents this attack,
your only recourse may be to disallow pinging, certainly not an ideal solution. But
what do you do when a DoS attack exploits the protocol you use to communicate on
the Internet? That’s what happens with a SYN attack, which disrupts TCP/IP traffic
by sending SYN packets and then not acknowledging the TCP/IP server’s response
packet. This causes the server to keep signaling until it eventually times out, a very
effective attack. Certainly disabling TCP/IP is not an option.
Other solutions available, such as content security applications like virus scanners,
are important, but inadequate for this purpose. While they do inspect the content
of individual packets, content security applications are limited to specific services,
and are unable to detect patterns of malicious activity.
158
Need for Active Defense
Securing the network with the most up-to-date methods of detecting and preventing
attacks is critical for safeguarding data and communications. The only solution that
addresses these types of threats is an active, intelligent, and reliably up-to-date
defense. The following section details Check Point’s solution to the mutating nature
of attacks on the perimeter of the network.
Chapter 6
SmartDefense 159
The SmartDefense Solution for an Active Defense
The SmartDefense Solution for an Active
Defense
In This Section
Introduction to SmartDefense
page 160
Application Intelligence-Defending Against the Next Generation of Threats
page 161
Network and Transport Layers: Necessary for Application Intelligence
page 162
How SmartDefense Works
page 164
Categorizing SmartDefense Capabilities
page 164
The SmartDefense Tree Structure
page 166
Introduction to SmartDefense
Check Point SmartDefense provides a unified security framework for various
components that identify and prevent attacks. SmartDefense actively defends your
network, even when the protection is not explicitly defined in the Security Rule
Base. It unobtrusively analyzes activity across your network, tracking potentially
threatening events and optionally sending notifications. It protects organizations
from all known, and most unknown, network attacks using intelligent security
technology.
Keeping up-to-date with the latest defenses does not require up-to-the-minute
technical knowledge. A single click updates SmartDefense with all the latest
defenses from the SmartDefense website.
SmartDefense provides a console that can be used to:
160
•
Choose the attacks that you wish to defend against, and read detailed
information about the attack.
•
Easily configure parameters for each attack, including logging options.
•
Receive real-time information on attacks, and update SmartDefense with new
capabilities.
The SmartDefense Solution for an Active Defense
Application Intelligence-Defending Against the
Next Generation of Threats
A growing number of attacks attempt to exploit vulnerabilities in network
applications rather than target the firewall directly. Check Point Application
Intelligence is a set of advanced capabilities, integrated into Firewall and
SmartDefense, which detects and prevents application-level attacks. Based on
INSPECT intelligent inspection technology, Check Point Application Intelligence
gives SmartDefense the ability to protect against application attacks and hazards.
Figure 6-2 OSI (Open Systems Interconnection) Reference Model
Note - The OSI Reference Model is a framework, or guideline, for describing how data is
transmitted between devices on a network.
The Application Layer is not the actual end-user software application, but a set of services that allows
the software application to communicate via the network. Distinctions between layers 5, 6, and 7 are
not always clear, and some competing models combine these layers, as does this user guide.
Chapter 6
SmartDefense 161
The SmartDefense Solution for an Active Defense
Network and Transport Layers: Necessary for
Application Intelligence
Application Intelligence is primarily associated with application level defenses.
However, in practice many attacks aimed at network applications actually target the
network and transport layers.
Hackers target these lower layers as a means to access the application layer, and
ultimately the application and data itself. Also, by targeting lower layers, attacks
can interrupt or deny service to legitimate users and applications (e.g., DoS
attacks). For these reasons, SmartDefense addresses not only the application layer,
but also network and transport layers.
Preventing malicious manipulation of network-layer protocols (e.g., IP, ICMP) is a
crucial requirement for multi-level security gateways. The most common vehicle for
attacks against the network layer is the Internet Protocol (IP), whose set of services
resides within this layer.
As with the network layer, the transport layer and its common protocols (TCP, UDP)
provide popular access points for attacks on applications and their data.
SmartDefense Services
SmartDefense Services maintain the most current preemptive security for the
Check Point security infrastructure. SmartDefense Services provide ongoing and
real-time updates and configuration advisories for defenses and security policies.
SmartDefense Services also add completely new defense techniques for new and
emerging protocols and applications between your regularly scheduled product
upgrades.
The SmartDefense Research Center also actively monitors and where appropriate
communicates with white-, black- and grayhat communities to identify
vulnerabilities and potential exploits before they are introduced into "the wild" (i.e.,
to the general internet community). Using this information, the SmartDefense
Research Center develops defenses and disseminates the information using relevant
components of the SmartDefense Services.
SmartDefense Services content is delivered in several different ways:
•
162
SmartDefense Updates are automatically imported into the SmartDashboard
GUI when the Update Now button is pressed in SmartDashboard. After the
Updates are imported, defenses can be activated and configured via the
SmartDashboard.
The SmartDefense Solution for an Active Defense
•
SmartDefense Advisories, Updates and Security Best Practices can be viewed
on the Check Point website, and customers can be notified of new Advisories,
Updates and Security Best Practices by signing-up for the SmartDefense
Services newsletter and email notifications.
•
RSS feeds can be used to provide real-time notification of new content.
•
The Program Advisor for Integrity database is updated on an ongoing basis, and
the database is accessed by endpoint computers as needed whenever the
endpoint is connected to the Internet.
•
Anti-virus updates for Check Point Express CI are automatically delivered to the
appropriate network enforcement points.
SmartDefense Services utilize an annually recurring license based on either the
number of gateways or endpoints secured. Check Point InterSpect and Connectra
each include a complimentary one-year SmartDefense Services license with product
purchase.
SmartDefense Services support the Check Point VPN-1 product family (NG FP3 and
higher), InterSpect, Connectra, and Integrity (Version 6 and higher).
Subscription Information
SmartDefense functionality is freely included with VPN-1 Power. However,
subscribing customers can automatically update SmartDefense and Web
Intelligence with a single click. Customers who purchase a SmartDefense
subscription service can obtain the following updates as soon as they are released.
1. HTTP and CIFS worm patterns.
2. INSPECT file updates.
3. Dynamic Attack protection.
4. Peer to Peer HTTP Headers
Customers with a valid subscription license also receive special SmartDefense
Advisories that provide updated SmartDefense and Web Intelligence attack
protections, as well as information, tools and best practice methods to mitigate
different attacks.
Note - SmartDefense is integrated with Check Point gateways of version NG FP2 and
higher. Previous versions do not receive the SmartDefense configurations. It is
recommended to keep your gateway version up-to-date, as the newest defenses are
incorporated into only the latest version of Check Point software.
Chapter 6
SmartDefense 163
The SmartDefense Solution for an Active Defense
Advisories
SmartDefense Advisories are detailed descriptions and step-by-step instructions on
how to activate and configure relevant defenses provided by Check Point products
and SmartDefense Updates. The SmartDefense Advisories are available to
SmartDefense Service subscribers.
Security Best Practice
Security Best Practices contain the latest security recommendations from Check
Point about how to protect your system.
How SmartDefense Works
SmartDefense is integrated with all VPN-1 Power versions of NG FP2 and higher.
As all inbound traffic is routed through the firewall, this is the natural place for
active defense to reside. Some of SmartDefense’s capabilities are enforced on the
network boundary, while others, such as Abnormal Behavior Analysis, are directed
from the SmartCenter Server. The SmartDefense protections that you enable are
distributed as part of the Security Policy to each enforcement point from the
SmartCenter Server. SmartDefense blocks attacks at the network boundary using
Check Point's Stateful Inspection technology.
Categorizing SmartDefense Capabilities
Check Point SmartDefense protects organizations against attacks and other non
legitimate or undesired network activity. Its capabilities can be categorized as
follows:
•
Defense against attacks page 165.
•
Information Disclosure Prevention page 165.
•
Abnormal Behavior Analysis page 166.
Some SmartDefense features provide more than one category of capability. The
Initial Sequence Number Defender (ISN Defender) for example, provides both
defense against a specific attack, and Implicit Defense.
164
The SmartDefense Solution for an Active Defense
Defense against attacks
Check Point SmartDefense protects organizations from known and unknown
network attacks. Attacks are stopped at the gateway, and are prevented from
affecting the target server.
SmartDefense is easy to configure, and defends against attacks while freeing the
administrator from the need to understand the technical details of the attack.
SmartDefense features protection against the following types of attack:
•
Denial of Service Attacks
•
TCP/IP Attacks
•
Web and Application Vulnerabilities
•
Network Probing
•
HTTP Worms
For example, consider a type of TCP/IP attack called ISN Guessing. TCP/IP
connections are initiated by way of a three-way handshake. The client sends a SYN
packet, the server replies with a SYN/ACK, and the client sends an ACK packet to
acknowledge the connection. With each SYN/ACK, the server also generates an
initial sequence number (ISN or SN) that identifies the connection.
The SNs are generated using a key of some sort, and for some operating systems it
is possible to guess the next SN from the previous SN. If an external client can
successfully guess the next valid SN, it can then open a connection to the server by
sending a SYN/ACK packet with a valid SN. This connection could be from a
non-existent IP address, and may carry damaging data.
SmartDefense fends off this sort of attack by replacing the server as the SN
generator, and uses an encrypted key to generate SNs much less susceptible to
attack.
Information Disclosure Prevention
Implicit Defense prevents information about network entities from reaching the
Internet, where this information could be misused.
To return to our SN vulnerability example, when an internal server establishes a
TCP connection, it sends successive SNs. In certain conditions, these SNs can be
used to identify the source’s operating system. SmartDefense uses “fingerprint
spoofing” to replace this fingerprint with another, thereby making it impossible for
external clients to discover the operating system used by the internal servers.
Chapter 6
SmartDefense 165
The SmartDefense Solution for an Active Defense
Abnormal Behavior Analysis
SmartDefense provides reporting and analysis of patterns of network behavior. It
detects these patterns by analyzing logs sent to the SmartCenter by the VPN-1
Power enforcement modules. If a suspicious pattern is detected, the administrator
can track the activity via a log or other kind of alert, depending on the
configuration setting.
The Port Scan detection feature is an example of abnormal behavior analysis. When
enabled, SmartDefense senses when its ports are being scanned, logs the activity
and can be configured to issue an alert.
The SmartDefense Tree Structure
The SmartDefense console is divided into a tree structure that classifies the
defenses provided by SmartDefense. The following summarizes the major categories
in the tree.
Note - When updating SmartDefense, new categories, as well as attack defenses, may be
added to the tree structure.
General
This page allows you to easily update SmartDefense with the latest information on
new and emerging attacks (provided you participate in the subscription program).
Anti-Spoofing Configuration Status
This page indicates how anti-spoofing is configured on the gateways. It identifies
any Check Point gateways on which anti-spoofing is not enabled, i.e., the attribute
IP address behind this interface of the offending gateway is configured as Not
Defined. You can change the settings by reconfiguring the individual gateways
For more information, see the SmartDefense HTML pages and online help.
Network Security
These pages allow you to configure various SmartDefense protections against
attacks on the network and transport level. The effect of such attacks, on the IP,
TCP, UDP or ICMP network protocols, range from simple identification of the
operating systems used in your organization, to denial of service attacks on hosts
and servers on the network.
166
The SmartDefense Solution for an Active Defense
Denial of Service
Denial of Service (DoS) attacks are aimed at overwhelming the target with spurious
data to the point where it is no longer able to respond to legitimate service
requests. The attacks in this section exploit operating system bugs to remotely
crash machines.
For more information, see the SmartDefense HTML pages and online help.
IP and ICMP
This page allows you to enable a comprehensive sequence of layer 3 tests (IP and
ICMP protocols).
For example, the fragmentation timeout logs feature generates logs when detecting
packets purposefully fragmented for a FireWall bypassing or Denial of Service
attack.
For more information, see the SmartDefense HTML pages and online help.
TCP
VPN-1 Power is able to identify the basic IP based protocols and analyze a packet
in order to verify that it contains allowed options only.
In order to verify that TCP packets are legitimate, the following tests are
conducted:
•
protocol type verification
•
protocol header analysis
•
protocol flags analysis and verification
SYN Attack Protection prevents attacks in which TCP connection initiation packets
are sent to the server in an attempt to cause Denial of Service.
The sequence verifier is a mechanism matching the current TCP packet’s sequence
number against a TCP connection state. Packets that match the connection in
terms of the TCP session but have incorrect sequence numbers are either dropped
or stripped of data.
For more information, see the SmartDefense HTML pages and online help.
Chapter 6
SmartDefense 167
The SmartDefense Solution for an Active Defense
Fingerprint Scrambling
It is sometimes possible to identify the operating system used by a machine, or to
impersonate an existing connection, by means of a fingerprint that characterizes
the operating system or the connection. SmartDefense can prevent this by
distorting the fingerprint to make such identification impossible.
For more information, see the SmartDefense HTML pages and online help.
Successive Events
Successive Events detection provides a mechanism for detecting malicious or
suspicious events and notifying the security administrator.
Successive Events detection runs on the SmartCenter Server and analyzes logs from
VPN-1 Power enforcement modules by matching log entries to attack profiles.
The security administrator can modify attack detection parameters, turn detection
on or off for specific attacks, or disable the Successive Events feature entirely.
Logs which do not reach the SmartCenter Server (for example, local logs and logs
sent to the Log Server) are not analyzed.
For more information, see the SmartDefense HTML pages and online help.
DShield Storm Center
Storm Centers gather logging information about attacks. This information is
voluntarily provided by organizations from across the world for the benefit of all.
Storm Centers collate and present reports on real-time threats to network security
in a way that is immediately useful.
The SmartDefense Storm Center Module updates your organization with the latest
attack information from the Storm Centers, and allows you to contribute your attack
logs to their databases.
One of the leading Storm Centers is SANS DShield.org. Check Point SmartDefense
integrates with the SANS DShield.org Storm Center in two ways:
•
168
The DShield.org Storm Center produces a Block List report, which is a list of
address ranges that are worth blocking. This Block List is frequently updated.
The SmartDefense Storm Center Module retrieves and adds this list to the
Security Policy in a way that makes every update immediately effective.
The SmartDefense Solution for an Active Defense
•
You can decide to send logs to the Storm Center in order to help other
organizations combat the threats that were directed at your own network. You
can decide which logs to send by selecting the rules for which you want to send
logs.
For more information about the SmartDefense DShield Storm Center integration,
see “SmartDefense StormCenter Module” on page 181.
Port Scan
Port Scanning is a method of collecting information about open TCP and UDP ports
in a network. Gathering information is not in itself an attack, but the information
can be used later to target and attack vulnerable computers.
To offer a service to other computers, a host has to open a port for that service.
Ports often remain open from a default installation, and the administrator may not
know about them. This can leave the host vulnerable to attack. For example, if the
FTP service is left open by default, an attacker can try to guess the default
username and password in order to get access to the machine.
Port scanning can be performed either by a hacker using a scanning utility such as
nmap, or by a worm trying to spread itself to other computers. Port Scanning is
most commonly done by trying to access a port and waiting for a response. The
response indicates whether or not the port is open.
The Smartdefense Port Scanning feature does not block the scanning.
SmartDefense detects ports scans with one of three possible levels of detection
sensitivity. When a port scan is detected a log or alert is issued.
It is possible to block clients that SmartDefense detects as performing port
scanning, by configuring automatic SAM (Suspicious Activity Monitoring) alert rules
on the SmartCenter to block offending IPs. For information about the sam_alert
command see the Command Line Interface (CLI) guide.
Warning - An automatic sam_alert rule may expose legitimate hosts to a remote DoS
attack. An attacker could spoof a port scan from a legitimate IP, which would then be
blocked by the automatic SAM rule.
For more information, see the SmartDefense HTML pages and online help.
Dynamic Ports
A number of applications (such as FTP under heavy load, and SIP protocols) can
set up connections by opening ports dynamically. These ports can turn out to be
the same as those used by one of the pre-defined services in the SmartDashboard.
Chapter 6
SmartDefense 169
The SmartDefense Solution for an Active Defense
Use this page to define whether to drop a connection with a dynamically opened
port that is the same as a pre-defined service port. Also use this page to choose
whether to drop dynamic port connections that use low ports (below 1024).
For more information, see the SmartDefense HTML pages and online help.
Application Intelligence
These pages allow you to configure various protections at the application layer,
using SmartDefense's Application Intelligence capabilities.
Mail
The SMTP security server allows strict enforcement of the SMTP protocol. It
protects against malicious mail messages, provides SMTP protocol centered
security, prevents attempts to bypass the Rule Base using mail relays, and prevents
Denial of Service and spam mail attacks. Usually the security server is activated by
specifying resources or authentication rules in the Security Rule Base.
These pages allow you to select what types of enforcement will be applied to SMTP
connections passing through the security server. Clicking Configuration applies to all
connections will forward all SMTP connections to the SMTP security server and
enforce the defined settings on all connections, without having to define a resource
in the Rule Base. Clicking Configurations apply only to connections related to rule
base defined objects applies these configurations only to SMTP connections for
which a resource is defined in the Rule Base.
For more information, see the SmartDefense HTML pages and online help.
FTP
These pages allow you to configure various protections related to the FTP protocol.
For example, preventing FTP port overflow checks foils any attempt to use an FTP
server as an agent for a malicious operation.
For more information, see “FTP Security” on page 295, and also the SmartDefense
HTML pages and online help.
Microsoft Networks
These pages allow you to configure various protections at the application layer,
using SmartDefense's Application Intelligence capabilities.
For more information, see “Microsoft Networking Services (CIFS) Security” on
page 291, and also the SmartDefense HTML pages and online help.
170
The SmartDefense Solution for an Active Defense
Peer to Peer
SmartDefense can block Peer to Peer traffic by identifying the proprietary protocols
and preventing the initial connection to the Peer to Peer networks. This prevents
not only downloads, but also search operations. SmartDefense can identify the
protocol even if the peer to peer application switches port numbers. The detection
does not, for example, rely on identifying HTTP header signatures.
For more information, see the SmartDefense HTML pages and online help.
Instant Messengers
These pages allow you to block Instant Messaging applications that use VoIP
protocols. Instant Messaging applications have many capabilities, including voice
calls, message transfer, and file sharing.
For more information, see “Securing Instant Messaging Applications” on page 279,
and also the SmartDefense HTML pages and online help.
DNS
The DNS protocol is used to identify servers by their IP addresses and aliases. DNS
protocol messages can be transported over TCP or UDP.
This option checks that all the connections on the DNS port over UDP are
DNS-related. In addition, certain restrictions are imposed on the type of data
allowed in queries and answers.
For more information, see the SmartDefense HTML pages and online help.
VoIP
Voice and video traffic, like any other information on the corporate IP network, has
to be protected as it enters and leaves the organization. Possible threats to this
traffic are
•
Call redirections, where calls intended for the receiver are redirected to
someone else.
•
Stealing calls, where the caller pretends to be someone else.
•
Systems hacking using ports opened for VoIP connections
VoIP calls involve a whole series of complex protocols, each of which can carry
potentially threatening information through many ports.
Chapter 6
SmartDefense 171
The SmartDefense Solution for an Active Defense
SmartDefense makes sure that addresses of the caller and receiver are where they
are claimed to be, and that the caller and receiver are allowed to make and receive
VoIP calls. In addition, SmartDefense examines the contents of the packets passing
through every allowed port, to make sure they contain proper information. Full
stateful inspection on H.323, SIP, MGCP and SCCP commands ensures that all
VoIP packets are structurally valid, and that they arrive in a valid sequence.
For more information, see “Securing Voice Over IP (VoIP)” on page 213.
SNMP
SmartDefense enables you to protect against SNMP vulnerabilities by providing the
option of enforcing SNMPv3 (the latest SNMP version) while rejecting previous
versions. In addition, SmartDefense can allow all SNMP versions while dropping
requests with SNMPv1 and SNMPv2 default community strings. A monitor-only
mode makes it possible to track unauthorized traffic without blocking it.
For more information, see the SmartDefense HTML pages and online help.
172
SmartDefense Profiles
SmartDefense Profiles
Different gateways may need to guard against different types of threats that
requires different configurations. SmartDefense Profiles allow the administrator to
customize the SmartDefense configuration according to the needs of each gateway
in the community. A SmartDefense Profile may be installed on more than one
gateway.
There are several features that are not configured per profile but are set universally
for all gateways:
1. Spoofed Reset Protection – the services exclusion list will not be per profile
(since services are global and not per profile).
2. Successive Events – these settings are relevant for log servers and not for each
gateway.
3. DShield Storm Center – Report to DShield – these settings are not part of the
firewall and therefore cannot have different settings.
4. Definitions of patterns (worm catcher patterns, P2P/IM patterns) – the
definition is global and each pattern can be activated/deactivated in each
profile.
If a profile is not specified, the gateway is assigned the default profile. All gateways
earlier than NGX R60 use the default profile.
Up to 20 profiles may be created and SmartDefense Profiles are available for all
NGX R60 gateways and above.
Note - Every profile created takes 2 MB of RAM from the user console machine on both
Windows and Motif.
Profile Cloning
Creating a duplicate copy of an existing profile is called Profile Cloning.
Once a clone is created, changes can be made to customize the new version. This
is helpful when only a few changes are required from an existing profile and is
easier than creating a brand new profile.
Chapter 6
SmartDefense 173
SmartDefense Profiles
Logging
Activity is logged in Check Point’s SmartView Tracker. The SmartDefense Profile field
contains the profile that is assigned to the gateway or user of that particular entry.
This field is included in the SmartDefense query by default.
In versions older than NGX R62, the profile is listed in the Information field.
174
Configuring SmartDefense
Configuring SmartDefense
Configuring SmartDefense is simple and intuitive. Proceed as follows:
1. In the SmartDashboard toolbar, click the SmartDefense icon.
2. In the SmartDefense Settings window, select the SmartDefense category to view
information about the category. To view details of a specific attack, click [+] to
expand the branch, and select the attack.
3. Check the attacks you wish to defend against, and configure Settings for the
categories and the specific attacks.
4. Install the Security Policy. You need to reinstall the Security Policy in order to
implement changes to the SmartDefense configuration.
Updating SmartDefense with the Latest Defenses
To obtain updates of all the latest defenses from the SmartDefense website, open
the SmartDefense Settings > General page, and click Update SmartDefense.
Staying Vigilant
Of course your responsibility does not end with simply configuring SmartDefense
according to your network’s needs. The security administrator must vigilantly review
the records logged in Check Point’s SmartView Tracker. Knowledge of the threats
your SmartDefense has encountered is crucial to maintaining an active defense.
Chapter 6
SmartDefense 175
SmartDefense Services
SmartDefense Services
The SmartDefense Services tab enables the ability to update all available products
from a central location. The tab contains the following three views:
•
Download Updates
•
Advisories
•
Security Best Practices
Download Updates
In this tab you can review information regarding available updates to download.
Each entry in the table describes an updates package as follows:
1. VPN-1 NGX R62 - Describes SmartDefense and Web Intelligence updates for
the following network objects:
•
VPN-1 Power/UTM gateways
•
VPN-1 Power/UTM clusters
•
VPN-1 UTM Edge/Embedded gateways
•
VPN-1 Power VSX gateways
•
VPN-1 Power VSX clusters
2. InterSpect 1.x and 2.0 - Describes SmartDefense and Web Intelligence updates
for centrally managed InterSpect gateways of versions 1.0, 1.1, 1.5 and 2.0.
This entry will appear only if the gateways are defined in SmartDashboard.
3. InterSpect NGX - Describes SmartDefense and Web Intelligence updates for
centrally managed InterSpect gateways of version NGX.
This entry will appear only if the gateways are defined in SmartDashboard.
4. Connectra 2.0 - Describes SmartDefense and Web Intelligence updates for
centrally managed Connectra gateways of version 2.0.
This entry will appear only if the gateways are defined in SmartDashboard.
5. Connectra NGX - Describes SmartDefense and Web Intelligence updates for
centrally managed Connectra gateways of version NGX.
This entry will appear only if the gateways are defined in SmartDashboard.
176
SmartDefense Services
6. Express CI - Describes manual signature updates for gateways that are AntiVirus
installed. To implement this, make sure that AntiVirus is checked in the Check
Point Products list on the General Properties page of the gateway.
This entry will appear only if the gateways are defined in SmartDashboard.
7. Edge CI - Describes manual signature updates for VPN-1 Edge gateways that
are AntiVirus installed, these are defined on the Content Filtering page of the
gateway.
This entry will appear only if the gateways are defined in SmartDashboard
The following columns give information about each particular update:
1. Last Downloaded Update column:
This reflects the update that is currently downloaded in SmartCenter.
When clicking on the link, the highlights of the currently installed update will
be displayed.
(For the CI entries such information does not exist).
2. Available New Update column:
This reflects the latest available update on the download center.
When clicking on the link, the highlights of the newest update will be
displayed.
(For the CI entries such information does not exist).
3. Deployment Status column:
This shows which updated version is installed for each gateway, as well as the
gateway status:
a. Up to date - the gateway has the latest available update installed.
b. Out of date - the gateway does not have the latest update installed
c. Not available - there is no update currently installed on the gateway.
Advisories
In this tab you can see detailed descriptions and step-by-step instructions on how
to activate and configure the relevant defenses provided by Check Point products
and SmartDefense Updates. The view has two states:
1. When the admin is not logged in to the UserCenter: click on the Check Point
Reference column and a vulnerability description is displayed.
Chapter 6
SmartDefense 177
SmartDefense Services
2. When the admin is logged in to the UserCenter (via the Log in to UserCenter
link located at the top of the page), a full step-by-step solution to the described
attacks is provided.
Security Best Practices
In this tab you can see the latest security recommendations briefs from Check
Point.
Similar to the Advisories tab, this view also has two states - one when the admin is
logged in and another when the admin is not logged in (See “Advisories” on
page 177.)
178
Configuring SmartDefense Profiles
Configuring SmartDefense Profiles
Creating Profiles
To configure a new profile:
1. Click SmartDefense tab > Profile Management.
2. Click New > Create new profile.
3. Assign a profile name. Click OK.
4. Configure the profile settings by using the SmartDefense navigation tree. Once
a profile is selected, it remains selected when scrolling through the various
SmartDefense protections.
To clone a profile, proceed as follows:
1. Click SmartDefense tab > Profile Management.
2. Select an existing profile.
3. Click New > Clone selected profile. A clone of the selected profile appears in the
profile list. For example, if a profile named Default_Protection is selected and
cloned, the profile named Copy_of_Default_Protection appears in the Profile
Name field.
4. Click OK.
5. Configure the profile settings by using the SmartDefense navigation tree.
Assign a Profile to the Gateway
Assigning a profile to the gateway can be done in two ways:
•
from the gateway itself
•
from the SmartDefense tab
To assign a profile from the gateway itself:
1. Click Manage > Network Objects.
2. Select a gateway and click Edit.
3. Navigate to the SmartDefense page.
4. To disable SmartDefense on this gateway, select Do not apply SmartDefense on
this gateway.
Chapter 6
SmartDefense 179
Configuring SmartDefense Profiles
To assign a profile, select a profile form the list in the from down menu next to
Assign profile.
5. Click OK.
To assign a profile from the SmartDefense tab:
1. Click SmartDefense tab > Profile Assignment.
2. Select a gateway and click Edit.
3. Navigate to the SmartDefense page.
4. To disable SmartDefense on this gateway, select Do not apply SmartDefense on
this gateway.
To assign a profile, select a profile form the list in the from down menu next to
Assign profile.
5. Click OK.
View Protected Gateways by a Profile
To view a list of gateways that are protected by a specific profile, proceed as
follows:
1. Click SmartDefense tab > Profile Management.
2. Highlight a profile from the list and click Actions > Show Protected Gateways.
The Protected Gateways screen appears with the list of gateways that are
assigned to the selected profile.
180
SmartDefense StormCenter Module
SmartDefense StormCenter Module
In This Section
The Need for Cooperation in Intrusion Detection
page 181
Check Point Solution for Storm Center Integration
page 182
Planning Considerations
page 186
Configuring Storm Center Integration
page 187
The Need for Cooperation in Intrusion Detection
The range and sophistication of the techniques used by hackers and crackers to
penetrate private networks is increasing all the time. Very few organizations can
hope to maintain up-to-the-minute protection against the latest attacks. Network
Storm Centers are collaborative initiatives that have been set up to help the
beleaguered Security Administrator fight back. Storm Centers gather logging
information about attacks. This information is voluntarily provided by organizations
from across the world for the benefit of all. Storm Centers collate and present
report on real-time threats to network security in a way that is immediately useful.
Figure 6-3 Cooperation between organizations and the Storm Center
Chapter 6
SmartDefense 181
SmartDefense StormCenter Module
Check Point Solution for Storm Center Integration
In This Section
Introduction
page 182
How the Block List is Received
page 183
How Logs are Submitted to the Storm Center
page 184
What a Submitted Log Contains
page 184
Removing Identifying Information from the Submitted Log
page 185
How Authenticity is Assured
page 185
Size of Logs and Effect on VPN-1 Power Performance
page 186
Introduction
The SmartDefense Storm Center Module is included in the standard VPN-1 Power
product installation. It enables a two way information flow between the network
Storm Centers, and the organizations requiring network security information.
One of the leading Storm Centers is SANS DShield.org http://secure.dshield.org/.
DShield.org gathers statistics and presents it as a series of reports at
http://secure.dshield.org/reports.html.
Check Point SmartDefense integrates with the SANS DShield.org Storm Center in
two ways, illustrated in Figure 6-4.
182
•
The DShield.org Storm Center produces a Block List report, which is a list of
address ranges that are worth blocking. This Block List is frequently updated.
The SmartDefense Storm Center Module retrieves and adds this list to the
Security Policy in a way that makes every update immediately effective.
•
You can decide to send logs to the Storm Center in order to help other
organizations combat the threats that were directed at your own network. You
can decide which logs to send by selecting the Security rules and
SmartDefense/Web Intelligence protections for which you want to send logs.
SmartDefense StormCenter Module
Figure 6-4
How the Block List is Received and Logs are Submitted
How the Block List is Received
The Security Administrator configures the SmartDefense option Network Security >
DShield Storm Center > Retrieve and Block Malicious IPs. Malicious IP can be blocked
for all gateways, or for specific gateways.
An agent (daemon) on each VPN-1 Power Gateway for which malicious IP are to be
blocked receives the Block List of malicious IP addresses from
http://secure.dshield.org/block_list_info.html via HTTPS. Every refresh interval (the
default is three hours), the agent takes the Block List, and updates the Security
Policy with the IP address ranges in the Block List. This process is logged in the
SmartView Tracker, in the VPN-1 Power log, as shown in Figure 6-5.
Chapter 6
SmartDefense 183
SmartDefense StormCenter Module
Figure 6-5
Showing the retrieval of the Block List in the SmartView Tracker
How Logs are Submitted to the Storm Center
The Security Administrator decides which type of logs should be submitted. For
example, it is possible to specify that all logs of type Alert or User Defined Alert
will be submitted. Logs of detected attacks (such as HTTP Worm patterns) can also
be submitted.
A log submitting agent (daemon) on the SmartCenter Server generates two kinds of
logs. As well as regular logs, a compact log digest is created. The digest includes
only the number of Drops and Rejects per port.
The Storm Center tells the log submitting agent to send either regular logs, or
digests, or both kinds of log.
The log submitting agent sends to the Storm Center the logs chosen by the Security
Administrator, of the type requested by the Storm Center. Log submission is done
using HTTPS POST. The logs are compressed into a database.
What a Submitted Log Contains
The logs that are submitted to the Storm Center contain the following information:
184
SmartDefense StormCenter Module
•
Connection parameters: Source IP Address, Destination IP Address, Source
Port, Destination Port (that is, the Service), IP protocol (such as UDP, TCP or
ICMP).
•
Rule Base Parameters: Time, action.
•
A detailed description of the log.
For HTTP Worm patterns, the log contains the same connection parameters, the
same Rule Base parameters, and also the name of attack and the detected URL
pattern.
Submitted logs are SmartDefense logs, as shown in Figure 6-6.
Figure 6-6 Showing the submission of logs to the Storm Center in the SmartView
Tracker
Removing Identifying Information from the Submitted
Log
It is possible to delete identifying information from internal IP addresses in the
submitted log, by specifying a designated number of bits to mask.
The mask can be used to delete as many bits as desired from the internal IP
addresses. A zero bit mask obscures the whole of the IP address. A 32 bit mask
reveals the whole of the internal IP address. An 8 bit mask reveals 8 valid bits, and
converts an IP address such as 192.168.46.88 to 0.0.0.88.
How Authenticity is Assured
The Block List and the Submitted logs are securely transferred and authenticated
via SSL. The Certificate of the Storm Center Certificate Authority comes with the
Storm Center Module, and is stored locally. The locally stored certificate is used for
two purposes:
Chapter 6
SmartDefense 185
SmartDefense StormCenter Module
1. To check the authenticity of the origin of the received Block List, by verifying
the validity of the certificate received with the Block List.
2. To establish an SSL connection with the Storm Center when submitting logs,
while assuring that the logs are indeed sent to the Storm Center and to no one
else.
The Certificate Authority of SANS DShield.org is Equifax. The file name of the
locally stored certificate is equifax.cer, and it is stored in the conf directory of the
Storm Center Module installation.
To send logs to DShield.org, you must register with them. DShield.org authenticate
the submitters of logs with a username and password that submitters obtain when
registering.
Size of Logs and Effect on VPN-1 Power Performance
Receiving the Block List has no effect on VPN-1 Power performance because only
a very small amount of data is received.
The submitted log is only a small subset of the full SmartDefense log, and is
compressed. The size of the log depends on the log interval, and the maximum size
of the log database. As a rough guide, 10,000 lines of logs take up 200 KB.
Planning Considerations
Which Logs to send to the Storm Center
Storm Centers have a special interest in receiving logging information about:
1. Unwanted port 80 traffic reaching the organization.
2. The Drop All rule (the last Rule in the Rule Base, that drops any traffic not
explicitly allowed in previous rules).
3. Logs generated by blocking of malicious IPs.
4. SmartDefense and Web Intelligence protections.
Which Logs NOT to send to the Storm Center
Do not send logs from rules that log internal traffic.
186
SmartDefense StormCenter Module
Which Identifying Information to Remove from
Submitted Logs
Decide on what part of your organizations IP addresses to obscure from the
submitted logs. If all your internal addresses are private, non-routable addresses,
you may not feel it is necessary to mask the addresses. On the other hand, even
non-routable addresses can reveal information about your internal network topology.
Configuring Storm Center Integration
To Retrieve and Block Malicious IPs
1. VPN-1 Power Gateways and SmartCenter Server(s) must be able to connect to
the Storm Center using HTTPS. In the Security Rule Base, define an
appropriate Rule if necessary.
2. In SmartDefense, configure Network Security > DShield Storm Center > Retrieve
and Block Malicious IPs. You can block connections from IPs in the Block List at
all Gateways, or at selected Gateways
Note - Make sure that the Block List is enforced on perimeter Gateways ONLY.
3. If you are also submitting logs to DShield, and would like to report logs
generated by blocking malicious IPs, make the Track setting identical to the
Submit Logs of Type setting in SmartDefense DShield Storm Center > Report to
DShield.
4. Install the Security Policy.
Manual Configuration for Blocking Malicious IPs
The DShield Block List, when configured via SmartDefense, is enforced before the
Rule Base. Because DShield uses statistical analysis, and the Block List is made
up of /24 (Class C) networks, those IPs are not necessarily all malicious. Therefore,
to prevent reputable IP addresses from being blocked, you can manually add a
Block List Rule in the Security Rule Base.
1. In SmartDefense Network Security > DShield Storm Center, UNCHECK Retrieve
and Block Malicious IPs.
2. Add the Block List Rule, as shown in Figure 6-7.
Chapter 6
SmartDefense 187
SmartDefense StormCenter Module
•
Place the Block List rule as high as possible in the Security Rule Base, but
below all authentication rules, and any other rules for trusted sources that
should not be blocked.
•
If you want to retrieve and block malicious IPs only at particular gateways,
specify them in the Install On cell of the rule.
Note - Make sure that the Block List is enforced on perimeter Gateways ONLY.
•
If you are also submitting logs to DShield, and would like to report logs
generated by blocking malicious IPs, make the Track setting identical to the
Submit Logs of Type setting in SmartDefense DShield Storm Center > Report to
DShield.
Figure 6-7 The Block List Rule
Table 6-1
Source
Destination
Service
Action
Install On
Track
Comment
CPDShield
Any
Any
Drop
Policy
Targets
UserDefined
Block List
Rule
3. Install the Security Policy.
To Submit logs to DShield.org
1. To submit logs to DShield.org, you must register at
http://secure.dshield.org/cp/register.php. You will receive a username and
password. (You can receive the Block List without registering.)
2. DShield can supply you with reports and statistics about the logs you have
submitted. To see those reports, you need to login to DShield at
http://secure.dshield.org/cp/login.php.
3. VPN-1 Power Gateways and SmartCenter Server(s) must be able to connect to
the Storm Center using HTTPS. In the Security Rule Base, define an
appropriate Rule if necessary.
4. In SmartDefense, configure Network Security > DShield Storm Center > Report to
DShield. The option Submit all logs of type determines which logs will be sent to
the Storm Center. For example, it is possible to specify that all logs of type
Alert or User Defined Alert will be submitted. Set the Track option of any rule or
SmartDefense/Web Intelligence protection whose logs you wish to submit, to
the Track option defined here.
188
SmartDefense StormCenter Module
5. Configure the option Hide internal networks using this mask to prevent the
internal network topology from being exposed by the submitted logs. A mask of
0.0.0.0 reveals the whole of the internal IP address. A mask of 255.255.255.0
reveals 8 valid bits, and converts an IP address such as 192.168.46.88 to
0.0.0.88. Make sure that the Topology is correctly defined for all Gateways (in
the Gateway object Topology page).
6. Install the Security Policy.
Chapter 6
SmartDefense 189
SmartDefense StormCenter Module
190
Application Intelligence
Check Point Application Intelligence is a set of advanced capabilities,
integrated into VPN-1 Power and SmartDefense, which detect and prevent
application-level attacks. This section describes how to protect against
application-level attacks for each application protocol, and how to work with
anti-virus (CVP) and URL filtering (UFP) applications.
Chapter
Anti Virus Protection
7
In This Chapter
Introduction to Integrated Anti Virus Protection
page 194
Architecture
page 195
Configuring Integrated Anti Virus Scanning
page 196
Signature Update Mechanism
page 197
Understanding Scan By Direction and Scan By IP
page 198
Scanning by Direction: Choosing the Data to Scan
page 203
File Type Recognition
page 206
Continuous Download
page 207
Logging and Monitoring
page 208
File Size Limitations and Scanning
page 209
VPN-1 UTM Edge Anti Virus
page 211
193
Introduction to Integrated Anti Virus Protection
Introduction to Integrated Anti Virus
Protection
Viruses are a major threat to business. They have become more dangerous and
sophisticated, and have evolved into worms, blended threats (which use
combinations of malicious code and vulnerabilities for infection and spread), and
trojans.
Check Point Express CI (Content Inspection) gateways include integrated Anti Virus
technology.
As an integrated Anti Virus solution, no extra IT resources are required. Businesses
gain the benefits of the easy management using the familiar Check Point SMART
infrastructure that includes policy management, logging and monitoring. As a single
box solution, hardware management is also simplified.
Anti Virus protection is available for the HTTP, FTP, SMTP and POP3 protocols. By
default all protocols are scanned, and options for each protocol can be centrally
configured.
194
Architecture
Architecture
When Anti Virus scanning is enabled, traffic for the selected protocols is trapped in
the kernel and forwarded to the security server. The security server forwards the
data stream to the Anti Virus engine. The data is allowed or blocked based on the
response of the Anti Virus engine.
Anti Virus scanning is applied only to accepted traffic, that has been allowed by the
Security Policy.
With VPN-1 UTM an Anti Virus configuration makes CVP resource configuration
obsolete. In cases where both Anti Virus and CVP are used only Anti Virus will work.
Chapter 7
Anti Virus Protection 195
Configuring Integrated Anti Virus Scanning
Configuring Integrated Anti Virus Scanning
1. For all Check Point Express CI gateway objects, check Anti Virus in the Check
Point Products section of the General Properties page.
Figure 7-1 Check Point Products List
2. In the Topology page, define the gateway topology, specifying the internal
networks, and the DMZ.
3. Use the Security Rule Base to allow services. Anti Virus scanning is applied
only to accepted traffic.
4. In the Content Inspection tab select the services that should be scanned using
the options provided:
196
•
In the Anti Virus page, configure options for file handling and scan failures.
•
In the Signature Updates page, configure when to perform automatic
signature updates, or initiate a manual signature update.
•
In the SMTP, FTP, HTTP and POP3 pages, configure Anti Virus scanning
options for these services.
•
In the File Types page, configure whether to Scan, Block or Pass traffic
according to the file type, and configure continuous Download settings.
Signature Update Mechanism
Signature Update Mechanism
Note - If the Express CI gateway and/or the SmartCenter Server download from a Check
Point server, they must have http and https Internet connectivity and DNS must be properly
configured on them. To download signature updates verify that you have a valid Check Point
User Center username and password.
Automatic updates of the virus signature can be scheduled at any chosen interval.
Manual updates of virus signatures can be initiated at any time.
Prior to downloading automatic signature (you had a typo) updates, verify that you
have the following:
•
HTTP and HTTPs Internet connectivity is available and DNS is properly
configured.
•
A valid Check Point User Center username and password.
The following three signature update mechanisms are available. For both
mechanisms, the default update interval is 120 minutes:
•
Download signature updates every x minutes allows you to choose the update
interval. The default update interval is 120 minutes
•
Download from Check Point site indicates that each VPN-1 gateway (AKA
module) is responsible for contacting Check Point’s site to fetch Anti Virus
signatures. Updates are downloaded directly to the Check Point Express CI R57
gateways. This method will likely result in faster update times.
•
Download from My local SmartCenter Server indicates that updates are
downloaded only by the SmartCenter Server from the default Check Point
signature distribution server, and then redistributed by the SmartCenter Server
to all Check Point Express CI R57 gateways. This method is useful when
Internet access is not available for all gateways or when it is required that the
download only occur once for all the gateways.
Chapter 7
Anti Virus Protection 197
Understanding Scan By Direction and Scan By IP
Understanding Scan By Direction and Scan
By IP
In This Section
Definition of Scan By Direction and Scan By IP
page 198
Comparing Scan by Direction and by IP
page 199
Definition of Scan By Direction and Scan By IP
There are two ways to specify the files to be scanned: Scan By direction and Scan
by IP. In both cases, Anti Virus scanning is performed only on traffic that is allowed
by the Security Rule Base
Scan By Direction
Specifies whether to scan files passing to or from the external, internal and/or DMZ
networks.
This method (the default) is an intuitive way of specifying which files will be
scanned without having to specify hosts or networks.
Use this method if you wish to scan all traffic in a given direction. It is possible to
specify exceptions, that is, locations to or from which files will not be scanned.
Note - Scan By Direction works only when Check Point Express CI is connected as a
gateway, and is placed inline between the external and the Internal/DMZ networks. It does
not work when Check Point Express CI is connected as a node, in Proxy mode.
In addition, Scan By Direction only works when the Gateway topology is correctly defined.
Scan By IP Address
Scan by IP address allows you to define very precisely which traffic to scan. For
example, if all incoming traffic from external networks reaches the DMZ, Scan by
IP allows you to specify that only traffic to the FTP, SMTP, HTTP and POP3 servers
will be scanned, whereas Scan by Direction scans all traffic to the DMZ.
When choosing to Scan by IP address, you use a Rule Base to specify the source
and destination of the data to scan. For FTP, for each rule, you can choose to scan
either the GET or PUT methods, or both. For HTTP, for each rule, you can choose
to scan either the HTTP Request, or the HTTP Response, or both.
198
Understanding Scan By Direction and Scan By IP
Comparing Scan by Direction and by IP
Scan by Direction allows you to specify which files to scan according to where the
file (and not necessarily the connection) originated from and according to its
recipients location.
Scan by IP allows you to specify files to scan according to the connection they are
sent through and the protocol phase/command where applicable.
As a general rule, when you want most or all files in a given direction to be
Anti-Virus scanned, you should use Scan by Direction.
On the other hand, if you want to granularly specify a connection or part of a
connection’s source or destination to be scanned, you should use Scan by IP.
Comparing Scan by Direction and by IP for SMTP
Protocol
For SMTP, Scan by Direction and by IP are essentially the same. Figure 7-2 shows
that for SMTP, the files (data) are always sent in the same direction as the
connection. SMTP is used for sending mail. Protocols that are used for receiving
email (such as POP3 and IMAP) are not scanned when SMTP is selected.
Figure 7-2 Comparing Scan By Direction to Scan by IP address for SMTP
Chapter 7
Anti Virus Protection 199
Understanding Scan By Direction and Scan By IP
Comparing Scan by Direction and by IP for POP3
Protocol
Figure 7-3 shows that for POP3, the files (data) are always sent in the opposite
direction of the connection. POP3 is used for retrieving mail.
Figure 7-3 Comparing Scan By Direction to Scan by IP address for POP3
200
Understanding Scan By Direction and Scan By IP
Comparing Scan by Direction and by IP for FTP
Protocol
For FTP, the difference between Scan by IP and Scan by direction is illustrated in
Figure 7-4. When the FTP GET command is used, files are transferred in the
opposite direction to the connection. When the FTP PUT command is used, files
are transferred in the same direction as the connection. The Scan files by direction
option allows you to scan files, without having to consider the direction of the
connection.
Figure 7-4 Comparing Scan By Direction to Scan by IP address for FTP
Chapter 7
Anti Virus Protection 201
Understanding Scan By Direction and Scan By IP
Comparing Scan by Direction and by IP for HTTP
Protocol
For HTTP, the difference between Scan by IP and Scan by direction is illustrated in
Figure 7-5. When choosing to scan by IP, the Source and Destination of the
connection are specified, and also whether the Request, Response or both will be
scanned. This makes it possible to specify what will be scanned in a very precise
way.
Figure 7-5 Comparing Scan By Direction to Scan by IP address for HTTP
202
Scanning by Direction: Choosing the Data to Scan
Scanning by Direction: Choosing the Data to
Scan
If Scan by Direction is chosen, it is necessary to choose the direction of the data to
scan, depending on whether you wish to scan files to or from the internal networks
and the DMZ.
What is a DMZ?
The DMZ (demilitarized zone) is an internal network with an intermediate level of
trust. Its trust level lies between that of trusted internal networks, such as a
corporate private LAN, and that of untrusted external networks such as the
Internet.
Typically, the DMZ contains devices accessible to Internet traffic, such as Web
(HTTP) servers, FTP servers, SMTP (e-mail) servers, DNS servers and POP3 servers.
The Scan By Direction options allow you to specify a level of Anti Virus scanning
that is specific to the DMZ. For example, you can decide not to scan traffic passing
from external networks to the DMZ, while scanning traffic passing from the DMZ to
internal networks, and from the external to internal networks.
An internal interface can be defined as leading to the DMZ in the Check Point
Express CI Gateway topology.
Scan By Direction Options
The Scan By Direction options are as follows:
•
Incoming files arriving to (see Figure 7-6) - this refers to files arriving from
external interfaces.
•
the internal networks (1).
•
the DMZ (2).
•
the DMZ and internal networks (1 and 2).
Chapter 7
Anti Virus Protection 203
Scanning by Direction: Choosing the Data to Scan
Figure 7-6
•
Options for scanning Incoming files arriving to
Outgoing files leaving (see Figure 7-7) - this refers to files leaving through
external interfaces.
•
the internal networks (1).
•
the DMZ (2).
• the DMZ and internal networks (1 and 2).
Figure 7-7 Options for scanning Outgoing files leaving
•
Internal files (see Figure 7-8)
IF THERE IS NO DMZ
•
passing between all internal networks (1).
IF THERE IS A DMZ
204
•
passing between the DMZ and internal networks (2).
•
passing between all internal networks (i.e. between internal networks (1),
from the DMZ to internal networks (2), and from internal networks to the
DMZ (3)).
Scanning by Direction: Choosing the Data to Scan
Figure 7-8
Options for scanning Internal files
Chapter 7
Anti Virus Protection 205
File Type Recognition
File Type Recognition
Check Point Express CI has a built-in File Type recognition engine, which
positively identifies the types of files passed as part of the connection. This also
enables you to define a per-type policy for handling files of a given type.
It is possible to specify “safe” file types that will be allowed to pass through the
Check Point Express CI Gateway without being scanned for viruses. It is also
possible to configure file types that will be scanned or blocked. The following
actions can be configured for each file type:
•
Scan performs Anti Virus scanning for files of this type, according to the
settings in the different services pages. By default, all unrecognized file types
are scanned.
•
Block does not allow files of this type. There are file types that are preset to be
blocked according to SmartDefense advisories.
•
Pass allows files of this type to pass though the Check Point Express CI gateway
without being scanned for viruses. Files of this type are considered safe.
File types can be considered safe because they are not known to contain viruses.
For example, some picture and video files are considered safe. Other formats can
be considered safe because they are relatively hard to tamper with. What is
considered safe can change according to published threats, and depends on how
the administrator balances security versus performance considerations.
Check Point Express CI reliably identifies binary file types by examining the file
type signatures (magic numbers). Check Point Express CI does not rely on the file
extension (such as *.GIF) which can be spoofed. It also does not use the MIME
headers (such as image/gif) in HTTP and mail protocols, which can also be
spoofed.
206
Continuous Download
Continuous Download
The Anti Virus engine acts as a proxy which caches the scanned file before
delivering it to the client only for files that need to be scanned.
When large files are being scanned, if the whole file is checked before being made
available, the user may experience an unacceptably long delay before the file is
delivered. A similar problem may arise when using client applications with short
timeout periods (certain FTP clients for example) to download large files. If the
whole file is cached and scanned before being delivered, the client applications
may time out while waiting.
To address this, Continuous Download trickles information to the client while the
Anti Virus scanning is taking place. If a virus is found during the scan, the file
delivery to the client is terminated.
It is possible to specify file types for which Continuous Download will not take
place. Some file types (such as Adobe Acrobat PDF files and Microsoft Power
Point) can open on a client computer before the whole file has been downloaded. If
Continuous Download is allowed for those file types, and a virus is present in the
opened part of the file, it could infect the client computer.
Note - SMTP and POP3 support Continuous Download per the entire email message.
Chapter 7
Anti Virus Protection 207
Logging and Monitoring
Logging and Monitoring
Logging information about the Anti Virus scan is sent to the SmartCenter Server,
and can be viewed using SmartView Tracker. Information about the results is shown
in the logs.
In addition, there are logs for signature updates, new update checks and download
results.
Monitoring Anti Virus status is performed with SmartView Monitor. The Anti Virus
status will appear under the Firewall-1 product. This status contains information
about the currently installed signature file and the Anti Virus engine version. The
Anti Virus status also includes statistics about scanned files and found viruses.
Upon virus detection, users of VPN-1 NG with Application Intelligence R57 will
receive a log such as the following:
Upon updating Signature updates, users of VPN-1 NG with Application Intelligence
R57 will receive a log such as the following:
Update Status: up-to-date
Signature Version: 23.70.28
Update Source: SmartCenter
Information: activity: Anti Virus Signature Update
208
File Size Limitations and Scanning
File Size Limitations and Scanning
General Settings
The default settings in the Anti Virus window have been configured to prevent the
Anti Virus engine from overloading. It is recommended that you use the default
settings provided.
If the Anti Virus engine becomes overloaded you can use the options in the Anti
Virus window to determine:
•
whether you would like to take the chance of allowing files that have not been
scanned to pass. This option will leave you open to virus attacks.
•
whether you would like to block all files. If you select to block all files a
connectivity problem may arise.
File Handling
•
Maximum file size to scan limits the file size that will be allowed through the
gateway. If the file is a compressed archive, the limit applies to the file after
decompression (The Anti Virus engine decompresses archives before scanning
them). Before performing Anti Virus scanning, the gateway reassembles the
entire file and then scans it. The limit is meant to protect the gateway
resources and the destination client.
An archive is a file that contains one or more files in a compressed format.
Archives (and all other file types) are recognized by their binary signature (also
known as the “magic number”). By default, any file type that is not positively
identified as being non-archive, is assumed to be an archive, and the Anti Virus
engine tries to expand it.
•
When file exceeds limit determines whether to not scan the file or block it.
Note - An email is treated as an archive and as a result it is not affected when the file
exceeds the limit.
Chapter 7
Anti Virus Protection 209
File Size Limitations and Scanning
Archive File Handling
•
Maximum archive nesting level is used to limit the number of nested archives
(one within another). This limit protects the gateway and destination client from
attacks employing deep nesting levels.
•
Maximum compression ratio is used to prevent attacks that employ a small size
archive that decompresses into a very large file on target.
•
When archive file exceeds limit or extraction fails determines whether to not scan
the file or block it.
Scan Failure
210
•
When Anti Virus engine is overloaded or scan fails determines whether to not
scan the file or block it.
•
When Anti Virus engine fails to initialize determines whether to not scan the file
or block it.
VPN-1 UTM Edge Anti Virus
VPN-1 UTM Edge Anti Virus
With VPN-1 UTM Edge you can now enable Anti Virus protection from the General
Properties tab of the VPN-1 UTM Edge/Embedded gateway. The Anti Virus
protection is now contained within VPN-1 UTM Edge. The option is referred to as
Anti Virus Protection enabled. Selecting this option indicates that Anti Virus is
installed and that updates will be sent to the specific gateway.
With VPN-1 UTM Edge Anti Virus you can define maximum archive file sizes for
VPN-1 UTM Edge machines that will be scanned, and you can configure what to do
if these limits are exceeded and/or when the scan fails.
The VPN-1 UTM Edge Anti Virus feature enables you to update virus signatures,
either automatically or manually for VPN-1 UTM Edge machines and provides you
with the tools to configure how VPN-1 UTM Edge traffic will be scanned.
Note - It is important to configure a valid DNS server address on your management and
enforcement module in order for the signature update to work.
With the VPN-1 UTM Edge Anti Virus scanning policy you can select the service(s)
to and from which a source and/or destination will be scanned. Scanning specifies
the files to be scanned by means of a classic Rule Base that defines the source
and destination of the connection to be scanned. Use this method if you wish to
define very precisely which traffic to scan. For example, if all incoming traffic from
external networks reaches the DMZ, it is possible to specify that only traffic to the
Anti Virus servers will be scanned.
To configure Anti Virus to work on VPN-1 UTM Edge gateways, it must be
configured in the Edge Anti Virus section of the Content Inspection tab. The Edge
Anti Virus settings in the Content Inspection tab only work for Edge machines.
Chapter 7
Anti Virus Protection 211
VPN-1 UTM Edge Anti Virus
212
8
Chapter
Securing Voice Over IP (VoIP)
In This Chapter
The Need to Secure Voice Over IP
page 214
Introduction to the Check Point Solution for Secure VoIP
page 215
Control Signalling and Media Protocols
page 216
VoIP Handover
page 217
VoIP Application Intelligence
page 219
VoIP Logging
page 223
Securing SIP Based VoIP
page 225
Troubleshooting SIP
page 237
Securing H.323-Based VoIP
page 238
Securing MGCP-Based VoIP
page 261
Securing SCCP-Based VoIP
page 271
213
The Need to Secure Voice Over IP
The Need to Secure Voice Over IP
Many organizations are using IP connectivity over the Internet between different
branches of the company to carry not only data, but voice and video as well. This
eliminates the costs of long distance calls using traditional telephony. IP
connectivity can also be used for video conferences and for other uses that can
lead to significant cost savings for an organization.
Voice and video traffic, like any other information on the corporate IP network, has
to be protected as it enters and leaves the organization. Possible threats to this
traffic are
214
•
Stealing calls, where the caller pretends to be someone else (by registering the
calls in the name of another user).
•
Call hijacking, where calls intended for the receiver are redirected to the
hijacker.
•
Systems hacking using ports opened for VoIP connections
•
Denial of Service attacks, where a rogue phone floods the network with calls,
thereby interfering with proper use of the phone network.
Introduction to the Check Point Solution for Secure VoIP
Introduction to the Check Point Solution for
Secure VoIP
VPN-1 Power secures VoIP traffic in H.323, SIP, MGCP and SCCP environments.
VoIP calls involve a whole series of complex protocols, each of which can carry
potentially threatening information through many ports. Figure 8-1 gives an
overview of the VoIP protocols supported by VPN-1 Power.
Figure 8-1 Secured VoIP Protocols: SIP, H.323, MGCP and SCCP
VPN-1 Power makes sure that addresses of the caller and receiver are where they
are claimed to be, and that the caller and receiver are allowed to make and receive
VoIP calls. In addition, VPN-1 Power examines the contents of the packets passing
through every allowed port, to make sure they contain proper information. Full
stateful inspection on H.323, SIP, MGCP and SCCP commands ensures that all
VoIP packets are structurally valid, and that they arrive in a valid sequence.
Chapter 8
Securing Voice Over IP (VoIP) 215
Control Signalling and Media Protocols
Control Signalling and Media Protocols
A phone call on both an ordinary digital phone network and a VoIP network is made
up of media together with control signals. The voice conversation itself is the media
stream. Dial tones and ringing tones, for example, are an indication that call
control processes are taking place.
The various VoIP protocols all use very different technologies, though they have the
same aims. As illustrated by Figure 8-1 on page 215, VoIP protocols handle call
control (or gateway) control, and media.
•
Call Control (also called signalling) aspects of the call include setting up the
call, finding the peer, negotiating coding protocols, making the connection, and
ending the call.
•
Gateway control is the same as call control, but applies to communication
between VoIP devices called Gateways, rather than between endpoint phones.
These Gateways act as intermediaries on behalf of the phones.
•
Media is the actual voice. Both VoIP and ordinary phone networks use
RTP/RTCP for the media. RTP carries the actual media and RTCP carries status
and control information.
Control signals open both fixed (known) and dynamic ports. The parties to a call
then use control signals to negotiate dynamically assigned ports that each side will
open to receive the RTP/RTCP media stream.
216
VoIP Handover
VoIP Handover
The simplest method of communication between VoIP endpoints involves sending
both the signalling and media endpoint to endpoint. In many VoIP networks
however, the endpoints cannot know the location of their peers. In that case, the
call is managed by an entity that we will refer to as a handover device, which
allows a VoIP phone call to reach its peer.
Where a handover device is used, the signalling follows a different route through
the network than the media. Handover is done in
•
SIP by the Proxy and/or Registrar,
•
H.323 by the Gatekeeper and/or Gateway,
•
MGCP by the Call Agent (also called Media Gateway Controller),
•
SCCP by the CallManager.
In a regular phone network and in H.323, VPN-1 Power can identify a user via their
telephone number or IP address. In other VoIP networks VPN-1 Power can identify
a user in various other ways as well, such as an email address or a URL. The phone
makes itself known in the network by registering on an entity that is responsible for
mapping each user identity to an IP address. The endpoints are then able to make
calls.
When making a VoIP call, the endpoint making the call first uses control signals to
contact a handover device. This device in turn contacts the destination endpoint,
either directly, or via another handover device. After the call setup phase, the
RTP/RTCP media always passes endpoint to endpoint.
The example in Figure 8-2 illustrates a conversation that VoIP terminal A initiates
with VoIP Terminal B using handover. The handover device manages a group of
VoIP Phones (endpoints), including endpoints A and B.
Chapter 8
Securing Voice Over IP (VoIP) 217
VoIP Handover
Figure 8-2
Understanding handover
1. Endpoint A sends control signals to the handover device.
The handover device and the endpoints agree on the ports they will use to
communicate. The way this is done depends on the protocol and the topology.
2. The handover device ‘routes the control signal to Endpoint B.
3. The handover device provides A with the IP address and destination port of B.
4. A sends the media directly to B, endpoint to endpoint.
When to Enforce Handover
Enforcing handover using a VoIP Domain adds security by providing access control
for the VoIP signal protocols.
However, It is sometimes not possible to define a VoIP domain. The handover
device may be maintained by an external carrier, so that you do not know which
machines the handover device controls. It may also be the case that the handover
device is trusted. In these cases it is either impossible or unnecessary to enforce
the handover, and there is no need to define a VoIP Domain.
218
VoIP Application Intelligence
VoIP Application Intelligence
In This Section
Introduction to VoIP Application Intelligence
page 219
Restricting Handover Locations using a VoIP Domain
page 220
Controlling Signalling and Media Connections
page 221
Protocol Specific Application Intelligence
page 222
Introduction to VoIP Application Intelligence
VPN-1 Power secures VoIP networks by protecting against all common threats to
VoIP traffic. Theses threats include call hijacking, where calls intended for the
receiver are redirected to someone else, call theft, where the caller pretends to be
someone else, and network hacking using ports opened for VoIP connections. Other
threats are Denial of Service (DoS) attacks by sending malformed or fragmented
packets.
VPN-1 Power provides VoIP security by inspecting the VoIP control signals that pass
through the enforcement point. Using information derived from the control signals,
VPN-1 Power is able to do the following:
•
Restricting Handover Locations using a VoIP Domain.
•
Controlling Signalling and Media Connections.
•
Preventing Denial of Service Attacks
•
Protocol Specific Application Intelligence.
The following sections explain more about these checks.
Chapter 8
Securing Voice Over IP (VoIP) 219
VoIP Application Intelligence
Restricting Handover Locations using a VoIP
Domain
Handover devices are responsible for rerouting call control signals. VPN-1 Power
makes it possible to prevent the abuse of the redirection capabilities of the
signaling protocols. This is done by defining a VoIP Domain.
The handover device is allowed to route calls only to the endpoints in its VoIP
Domain. The VoIP Domain also controls the allowed direction of the call.
For example, in Figure 8-3, if A and B are in the VoIP domain of the handover
device C, VPN-1 Power ensures that A sends its media streams only to B, by
ensuring that the address of B that the handover device C provides to A (step 3 in
Figure 8-3), is in the VoIP Domain. This prevents unwanted callers getting through
the firewall.
Figure 8-3 VoIP Security by VPN-1 Power
220
VoIP Application Intelligence
Controlling Signalling and Media Connections
The control signals always pass through the VPN-1 Power enforcement point.
VPN-1 Power is therefore able to secure the call by opening RTP/RTCP ports only
for those endpoints that were negotiated during the signalling. It also keeps those
ports open only for as long as required, and closes them as soon as the call ends,
without waiting for a time-out. The order and direction of the packets is also
enforced.
VPN-1 Power closes the RTP/RTCP data connections because there is potentially a
major security problem in VoIP billing. The problem occurs because the control
connection and the media connections follow different routes. The module that is
responsible for the billing is the handover device, but the RTP, which is the voice
media itself, is not routed through this device. Instead, RTP is routed directly
between the IP Phones. The potential security problem is that IP Phones can send
VoIP control messages that indicates that the call is ended, but actually continue
sending and receiving the media (RTP connection).
VPN-1 Power ensures the security and integrity of billing processes by enforcing
the relationship between the control and media connections. VPN-1 Power inspects
the VoIP services, and deletes the media connection when the messages in the
control connection specify that the media connection must be ended.
If both endpoints are on the same side of the VPN-1 Power enforcement point,
VPN-1 Power is aware of this fact, and does not open any ports for the media.
Preventing Denial of Service Attacks
A rogue IP phone could make Denial of Service (DoS) attacks by flooding the
network with calls, thereby interfering with proper use of the phone network.
The SmartDefense Application Intelligence > VoIP page allows you to protect against
DoS attacks directed against VoIP networks. It does this by limiting the number of
call attempts per minutes that the VPN-1 Power Gateway will allow from any given
IP address. Calls from handover devices are not counted, because they make a
large number of calls.
Chapter 8
Securing Voice Over IP (VoIP) 221
VoIP Application Intelligence
Protocol Specific Application Intelligence
VPN-1 Power understands the complex VoIP protocols and performs application
layer filtering of SIP, H.323, MGCP and SCCP packets. See
222
•
“Application Intelligence for SIP” on page 228.
•
“Application Intelligence for H.323” on page 242.
•
“MGCP Network Security and Application Intelligence” on page 264.
•
“SCCP Network Security and Application Intelligence” on page 272
VoIP Logging
VoIP Logging
VPN-1 Power provides detailed, protocol specific logs for VoIP. If the Log VoIP
connection option is turned on in the Global Properties Log and Alert page. SIP,
H.323, MGCP and SCCP events are logged in the SmartView Tracker. The VoIP
specific log fields are:
•
Reg. IP-phones is for call registration events. For SIP and MGCP, this field
shows the URL (for example, example@checkpoint.com). For H.323 this field
shows the phone number (123456#7, for example)
•
Source IP Phone and Destination IP Phone logs call setup events.
•
Media Type flowing between the source and destination IP Phones. It can be
audio, video, instant messaging, applications, or unknown.
•
Information Logging information contains call information as well as security
information. For example port used, commands used and illegal direction, and
setup messages. For MGCP, the commands are shown.
There is also a predefined SmartView Tracker Voice Over IP log query.
If VoIP logging is not turned on, only standard logging will take place, showing the
source, destination, protocol and so on.
Chapter 8
Securing Voice Over IP (VoIP) 223
Protocol-Specific Security: SIP, H.323, MGCP and SCCP
Protocol-Specific Security: SIP, H.323,
MGCP and SCCP
The following sections deal with the specific security requirements of the VoIP
protocols supported by VPN-1 Power.
In This Section
224
Securing SIP Based VoIP
page 225
Securing H.323-Based VoIP
page 238
Securing MGCP-Based VoIP
page 261
Securing SCCP-Based VoIP
page 271
Securing SIP Based VoIP
Securing SIP Based VoIP
Related Information:
•
Before reading this section, read “Introduction to the Check Point Solution
for Secure VoIP” on page 215 to “Protocol-Specific Security: SIP, H.323,
MGCP and SCCP” on page 224.
•
The SIP protocol is described in this section only to the extent required to
secure SIP traffic using VPN-1 Power.
In This Section
SIP Architectural Elements in the Security Rule Base
page 225
Supported SIP RFCs and Standards
page 226
Secured SIP Topologies and NAT Support
page 227
Application Intelligence for SIP
page 228
SmartDefense Application Intelligence Settings for SIP
page 229
Synchronizing User Information
page 230
SIP Services
page 231
Using SIP on a Non-Default Port
page 231
ClusterXL and Multicast Support for SIP
page 232
Securing SIP-Based Instant Messenger Applications
page 232
Configuring SIP-Based VoIP
page 232
SIP Architectural Elements in the Security Rule
Base
SIP has the following architectural elements, all of which are supported by VPN-1
Power:
•
SIP Terminal(IP Phone) — Supports real-time, two way communication with
another SIP entity. It supports both signalling (that is, the SIP commands
themselves) and media. In SIP, only IP enabled phones can be used.
IP Phones are usually defined in SmartDashboard as a network of IP
Phones. There is normally no need to define network objects for individual
IP Phones.
Chapter 8
Securing Voice Over IP (VoIP) 225
Securing SIP Based VoIP
•
Proxy — Manages a number of IP phones. Contacts one or more clients or
next-hop servers and passes the call request further.
•
Redirect Server — Converts SIP URL address into zero or more new addresses,
and returns those addresses to the client. It does this before the VoIP
connection begins. It does not initiate requests or accept calls.
•
Registrar — A server that accepts REGISTER requests. A registrar is typically
co-located with a proxy or redirect server and MAY offer location services.
The Proxy and Registrar are handover devices. Handover devices are defined in
SmartDashboard as host nodes which manage a VoIP Domain. If you wish to limit
handover locations, define a VoIP Domain. A VoIP Domain will typically be a
network or group of networks. If the handover devices have the same IP address,
only one VoIP Domain need be defined, otherwise, a VoIP Domain must be defined
for each one.
To allow SIP conversations you need only create rules to allow the SIP control
signals through the VPN-1 Power Gateway. There is no need to define a media rule
that specifies which ports to open and which endpoints will talk. VPN-1 Power
derives this information from the signalling. Given a particular VoIP signalling rule,
VPN-1 Power automatically opens ports for the endpoint to endpoint RTP/RTCP
media stream.
Supported SIP RFCs and Standards
RFC 3261 - The most recent SIP RFC.
RFC 3372 - Session Initiation Protocol for Telephones (SIP-T). See “Configuring
SIP-T Support” on page 236.
RFC 3311 - UPDATE message.
RFC 2976 - INFO message.
RFC 3515 - REFER message.
RFC 3265 - SIP Events.
RFC 3262 - Reliability of Provisional Responses.
RFC 3428 - MESSAGE message.
MSN messenger over SIP.
SIP over TCP.
SIP over UDP.
226
Securing SIP Based VoIP
SIP early media.
SIP can be configured using the standard, dynamic and non standard ports.
Secured SIP Topologies and NAT Support
VPN-1 Power supports the SIP deployments listed in Table 8-1. It is possible to
configure NAT (either Hide or Static) for the phones in the internal network, and
(where applicable), for the proxy.
Table 8-1
Supported SIP Topologies
No NAT
NAT for Phones Hide/Static NAT
NAT for Proxy Static NAT
Peer to Peer
(Figure 8-4)
Yes
Yes
Not applicable
Proxy in External
(Figure 8-5)
Yes
Yes
Not applicable
The “Proxy” is any SIP handover device: Proxy and/or Registrar.
In the Peer to Peer, topology, both signalling and media pass endpoint to endpoint.
Where there is one or more handover devices, the signalling passes through one or
more Proxies or Registrars. Once the call has been set up, the media passes peer
to peer.
The SmartDashboard configuration depends on the topology, as described in
“Configuring SIP-Based VoIP” on page 232. You will also find there diagrams
showing the most widely used deployment topologies.
Figure 8-4 SIP Peer to Peer Topology
Chapter 8
Securing Voice Over IP (VoIP) 227
Securing SIP Based VoIP
Figure 8-5
SIP Proxy in Internet with NAT for Internal phones
Additional Conditions for Using NAT in SIP Networks
SIP can be used with Network Address Translation (NAT), with the following
conditions:
•
Hide NAT can be used for all types of calls (incoming, outgoing, internal and
external). However, Manual Hide NAT rules cannot be used with Hide NAT, for
incoming calls. For security reasons, when using Hide NAT for incoming calls,
the Destination of the VoIP call in the appropriate rule in the Security Rule
Base cannot be Any.
•
Where both endpoints are on the trusted side of the VPN-1 Power enforcement
point, calls cannot be made from the same source to two endpoints, where one
endpoint is NATed (either Static or Hide) and the other is not.
•
Bidirectional NAT of VoIP calls is not supported.
Application Intelligence for SIP
VPN-1 Power restricts handover locations and controls signalling and data
connections, as described in “VoIP Application Intelligence” on page 219. For SIP,
VPN-1 Power Application Intelligence ensures packets conform to RFC 3261 for
SIP over UDP and TCP, and inspects SIP-based Instant Messaging protocols. It
protects against Denial of Service (DoS) attacks, and against penetration attempts
such as connection hijacking and connection manipulation.
VPN-1 Power validates the expected usage of the SIP protocol. For example, if an
end of call message is sent immediately after the start of the call, the call will be
denied, because this behavior is characteristic of a DoS attack.
228
Securing SIP Based VoIP
Application Level checks include
•
Checking for binaries and illegal characters in the packets.
•
Strict RFC enforcement for header fields.
•
Restricting the length of header fields.
•
Removal of unknown media types.
SmartDefense Application Intelligence Settings for
SIP
Additional security checks for SIP connections can be configured via
SmartDefense, under Application Intelligence > VoIP > SIP. The following options are
available:
•
Verify SIP header content makes sure that the headers do not contain forbidden
characters. If found, the message is blocked.
•
Block calls using a proxy or a redirect server prevents calls to be made by means
of a SIP server. If this option is checked, only endpoint to endpoint calls are
allowed. The additional security obtained by configuring VoIP Domains in the
Security Rule Base is only possible for calls using a proxy or a redirect server.
•
Default proxy registration expiration time period: is the period of time for which
the firewall holds registration information from clients in its database. See
“Synchronizing User Information” on page 230. It should be greater or equal to
the registration time period of the client or the proxy (whichever is greater). If
the client does not send a user registration message, the registration
information is deleted after this time.
•
Block the destination from re-inviting calls prevents the destination from opening
additional data connections with IP addresses that are not the same as the first
data connection, while a call is still active.
•
Maximum invitations per call (from both directions) defines the maximum number
of participants that can take part in a conference call.
•
Block SIP-based video blocks all applications that use SIP to carry video. This
includes the video components of MSN Messenger, when it is configured to use
SIP. The default is not to block.
Chapter 8
Securing Voice Over IP (VoIP) 229
Securing SIP Based VoIP
•
Block SIP calls that use two different voice connections (RTP) for incoming audio
and outgoing audio applies to SIP implementations that use two different RTP
connections to transfer voice and/or video information between the two peers. If
your implementation does not use this scheme, check this option to make sure
that the firewall will allow only one of these connections.
•
Block SIP-based audio blocks all applications that use SIP to carry audio. This
includes the audio components of MSN Messenger when it is configured to use
SIP. The default is not to block.
•
Block SIP-based Instant Messaging blocks all applications that use SIP for
instant messaging. The default is to block. To selectively block applications
provided by MSN Messenger, do not check this option. Instead, configure
Instant Messengers > MSN over SIP. Some peer to peer applications also allow
Instant Messaging, and these can be blocked via Application Intelligence >
Peer to Peer.
•
Drop unknown SIP messages drops SIP messages that the firewall does not
recognize. By default this options is checked. If this option is unchecked, the
firewall accepts unrecognized messages but only if they conform to the SIP
RFC (they are properly formatted and contain the mandatory CALL-ID, FROM
and TO fields).
Synchronizing User Information
The user IP Phone sends SIP messages to the Redirect Server in order to register
itself on the network. Once a phone is registered, it can make calls.
These SIP messages cross VPN-1 Power, which reads them. The VoIP user
databases on VPN-1 Power and the Redirect Server are therefore always
synchronized with each other.
Registration makes it possible to initiate calls from outside the VPN-1 Power
enforcement point to phones whose addresses are translated using Hide NAT.
If the VPN-1 Power machine is rebooted, the VoIP user database is deleted. The
cpstop/cpstart commands do not delete the user database.
230
Securing SIP Based VoIP
SIP Services
Four predefined SIP services are available: sip, sip-tcp, and sip_any, sip-tcp_any.
For VoIP equipment that uses SIP TCP, use the sip-tcp and sip-tcp_any services.
When it uses UDP use the sip and sip_any services.
Note - The services sip and sip_any cannot be used in the same rule because they
contradict each other. The same is true for sip-tcp and sip-tcp_any.
When these services are used, registration message are tracked and a database is
maintained that includes the details of the IP phones and the users. If an incoming
call is made to a Hide NATed address, VPN-1 Power verifies that the user exists in
the sip registration database before allowing the call. This can prevent DoS attacks.
To see a list of the on-line IP phones, run the command
fw tab -t sip_registration -f.
•
sip and sip-tcp are used to enforce handover. Use a VoIP Domain in the source
or destination of the rule, together with the sip Service.
•
sip_any and sip-tcp_any are used if not enforcing handover. In that case, do not
place a VoIP Domain in the Source or Destination of the rule. Instead, use Any
or a network object, together with the sip_any or sip-tcp_any Service. If a VoIP
Domain is used with the sip_any or sip-tcp_any service, it is equivalent to the
sip service.
Using SIP on a Non-Default Port
SIP uses UDP port 5060 by default. However, SIP phones and SIP Proxies can be
configured to use a different port. VPN-1 Power can enforce SIP security on any
SIP port. To do so, a new UDP service must be defined in SmartDashboard. SIP
rules can then be defined in the Security Rule Base that use this new service. It is
possible to use both the newly defined service and the predefined services (sip and
sip_any) in the same Rule.
To configure a new SIP Service, proceed as follows.
1. From the SmartDashboard main menu, choose Manage > Services > New… >
UDP. In the UDP Service Properties window, give it a Name, and specify the new
SIP port.
2. Press Advanced…. In the Advanced UDP Service Properties window, choose
Protocol Type SIP_UDP, and press OK.
Chapter 8
Securing Voice Over IP (VoIP) 231
Securing SIP Based VoIP
3. Define a Rule in the Security Rule Base that uses this new service.
ClusterXL and Multicast Support for SIP
•
SIP calls can be made across a ClusterXL Gateway cluster in either High
Availability or Load Sharing modes. In Load Sharing Mode, Sticky Decision
Function must be enabled. For details, see the ClusterXL guide.
•
The fw_sip_allow_mcast (true, false) property allows or drops multicast RTP
traffic. Default value is false. This is a per-module property. To change the
value, run the following command on the module:
fw ctl set int fw_sip_allow_mcast
Securing SIP-Based Instant Messenger
Applications
For information about Securing SIP-Based Instant Messenger Applications in
general, and about MSN Messenger over SIP in particular, see “Securing Instant
Messaging Applications” on page 279.
Configuring SIP-Based VoIP
In This Section.
SIP Rules for a Peer to Peer no-Proxy Topology
page 233
SIP Rules for a Proxy in the External Network
page 234
Configuring SIP-Based Instant Messenger Applications
page 236
Configuring SIP-T Support
page 236
Note - Security rules can be defined that allow either bidirectional calls, or only incoming
or outgoing calls. The examples in the following sections show how to define bidirectional
rules
232
Securing SIP Based VoIP
SIP Rules for a Peer to Peer no-Proxy Topology
A peer to peer topology is shown in Figure 8-6.
Figure 8-6 SIP Peer to Peer Topology
1. For a peer to peer topology, define a rule that allows IP phones in Net_A to call
Net_B, and vice-verca, as follows:
Table 8-2
Source
Destination
Service
Action
Comment
Net_A
Net_B
Net_B
Net_A
sip or
sip-tcp
Accept
Bidirectional
calls
2. To define Hide NAT (or Static NAT) for the phones in the internal network, edit
the network object for Net_A. In the NAT tab, check Add Automatic Address
Translation Rules, and select the Translation method (Hide or Static)
3. Configure the SmartDefense options under Application Intelligence > VoIP > SIP
as required. For details, see “SmartDefense Application Intelligence Settings
for SIP” on page 229, or the online help.
4. Install the Security Policy.
Chapter 8
Securing Voice Over IP (VoIP) 233
Securing SIP Based VoIP
SIP Rules for a Proxy in the External Network
A SIP topology with a proxy in the external network is shown Figure 8-7. The
following procedure explains how to allow bidirectional calls between the SIP
phones in the internal network (Net_A), and phones in an external network (Net_B),
and how to define NAT for the internal phones.
Figure 8-7 SIP Proxy in External Network
1. Define the Network objects (Nodes or Networks) for the IP Phones that are
managed by the Handover device (SIP Proxy or Registrar), and are allowed to
make calls, and whose calls are tracked by the VPN-1 Power Gateway.
For the example in Figure 8-7, these are Net_A and Net_B.
2. Define the Network object for the Handover device (SIP_Proxy).
3. Define the VoIP Domain object. If the Proxy and Registrar (SIP_Proxy) are on
one machine with a single IP address, define only one VoIP Domain. If they
have different IP addresses, define a VoIP Domain for each IP address.
Right-click the Network Objects tree, and select New… > VoIP Domains > VoIP
Domain SIP Proxy.
234
Securing SIP Based VoIP
The definition of the VoIP Domain depends on whether or not you wish to
enforce handover locations for phones in the external network. For phones in
the internal network, handover should always be enforced.
Table 8-3
VoIP Domain Definition
With Handover
No Handover for
External Phones
Name
VoIP_Domain
VoIP_Domain_A
Related endpoints domain
Group containing
Net_A and Net_B
Net_A
VoIP Gateway installed at
SIP_Proxy
SIP_Proxy
4. Now define the rules. With full handover enforcement, define the following rule:
Table 8-4
Source
Destination
Service
Action
Comment
VoIP_Domain
Net_A
Net_A
VoIP_Domain
sip or
sip-tcp
Accept
Bidirectional calls.
Handover enforced.
If you do not wish to enforce handover for the external phones (in Net_B),
Define the following rules:
Table 8-5
Source
Destination
Service
Action
Comment
Net_A
Any
sip_any or
sip-tcp_any
Accept
Outgoing calls.
No handover enforced.
Any
VoIP_Domain_A
sip or
sip-tcp
Accept
Incoming calls.
Handover enforced.
For an explanation of the SIP services, see “SIP Services” on page 231.
5. To define Hide NAT (or Static NAT) for the phones in the internal network, edit
the network object for Net_A. In the NAT tab, check Add Automatic Address
Translation Rules, and select the Translation method (Hide or Static)
6. Configure the SmartDefense options under Application Intelligence > VoIP > SIP
as required. For details, see “SmartDefense Application Intelligence Settings
for SIP” on page 229, or the online help.
7. Install the Security Policy.
Chapter 8
Securing Voice Over IP (VoIP) 235
Securing SIP Based VoIP
Configuring SIP-Based Instant Messenger Applications
For information about configuring MSN Messenger over SIP, see “Configuring
SIP-based Instant Messengers” on page 286.
Configuring SIP-T Support
To configure support for RFC 3372 Session Initiation Protocol for Telephones
(SIP-T), proceed as follows:
1. Add the following line to $FWDIR/lib/user.def on the SmartCenter Server:
sipt_hosts = { < first_ip, second_ip> , < first_ip, second_ip> , ....
....,< first_ip, second_ip> } ;
first_ip and second_ip are the IP addresses between which (bi-directional)
SIP-T are allowed.
For example, to allow SIP-T between 192.1.1.1 and 192.1.1.2, and between
192.1.1.1 and 192.1.1.3 add the following line:
sipt_hosts = { < 192.1.1.1, 192.1.1.2> , < 192.1.1.1, 192.1.1.3> } ;
If the file does not exist, create it.
2. Save the file.
3. Install the Security Policy.
236
Troubleshooting SIP
Troubleshooting SIP
To see a list of all the online IP phones, you can view the list of phones that the
VPN-1 Power notes as having registered. Run the command
fw tab -t sip_registration -f
The output of this command is a list with the format
username; IP address
To obtain a lot of useful information about the current SIP calls, run the following
command:
fw tab -t sip_state -f
The output of the command lists all the calls with the following information for
each:
•
Control connection (source, destination).
•
RTP connection (endpoint IP addresses).
•
Call state (established, ended, registration).
•
Media type (audio, video, audio/video, application).
•
Number of reinvites (number of participants in a conference call).
Chapter 8
Securing Voice Over IP (VoIP) 237
Securing H.323-Based VoIP
Securing H.323-Based VoIP
Related Information:
•
Before reading this section, read “Introduction to the Check Point Solution
for Secure VoIP” on page 215 to “Protocol-Specific Security: SIP, H.323,
MGCP and SCCP” on page 224.
•
The H.323 protocol is described in this section only to the extent required
to secure H.323 traffic using VPN-1 Power.
In This Section
H.323 Architectural Elements in the Security Rule Base
page 238
Supported H.323 RFCs and standards
page 239
Secured H.323 Topologies and NAT Support
page 239
Application Intelligence for H.323
page 242
SmartDefense Application Intelligence Settings for H.323
page 243
Gatekeeper and Gateway Call Routing
page 243
H.323 Services
page 245
Configuring H.323-Based VoIP
page 246
H.323 Architectural Elements in the Security Rule
Base
VPN-1 Power supports the following H.323 architectural elements:
•
IP phones, which are IP devices that handle both signalling (that is, the H.323
commands themselves) and media. They connect to an H.323 gatekeeper.
IP Phones are defined in SmartDashboard, usually as a network of IP
Phones. There is normally no need to define network objects for individual
IP Phones.
238
•
Conventional telephones connect to an H.323 gateway. These are not IP
devices, and there is no need to define them in SmartDashboard.
•
A Gatekeeper manages a collection of H.323 devices such as phones. It
converts phone numbers to IP addresses. A Gatekeeper usually provide Gateway
services as well.
•
A Gateway provides interoperability between different networks. It translates
between the telephony protocol and IP.
Securing H.323-Based VoIP
The Gatekeeper and Gateway are handover devices. Handover devices are defined
in SmartDashboard as host nodes which manage a VoIP Domain. If you wish to
limit handover locations, define a VoIP Domain. A VoIP Domain will typically be a
network or group of networks. If the handover devices have the same IP address,
only one VoIP Domain need be defined. If these devices have different IP
addresses, a VoIP Domain must be defined for each one.
To allow H.323 conversations you need only create rules to allow the H.323 control
signals through the VPN-1 Power Gateway. There is no need to define a rule for the
media that specifies which ports to open and which endpoints will talk. VPN-1
Power derives this information from the signalling. Given a particular VoIP
signalling rule, VPN-1 Power automatically opens ports for the endpoint to endpoint
RTP/RTCP media stream.
Supported H.323 RFCs and standards
•
H.323 Versions 2, 3 and 4. Version 4.
•
H.225 Versions 2, 3 and 4. Version 4.
•
H.245 Versions 3, 5 and 7. Version 7.
Secured H.323 Topologies and NAT Support
VPN-1 Power supports the H.323 deployments listed in Table 8-6. It is possible to
configure NAT (either Hide or Static) for the phones in the internal network, and
(where applicable), for the Gateway/Gatekeeper.
Table 8-6
Supported H.323 Topologies
Endpoint to Endpoint
(Figure 8-8)
No NAT
NAT for Internal
Phones—
Hide/Static NAT
NAT for
Gateway/
Gatekeeper —
Static NAT
Yes
Yes
Not applicable
Chapter 8
Securing Voice Over IP (VoIP) 239
Securing H.323-Based VoIP
Table 8-6
Supported H.323 Topologies
No NAT
NAT for Internal
Phones —
Hide/Static NAT
NAT for
Gateway/
Gatekeeper —
Static NAT
Gateway/Gatekeeper in External
(Figure 8-9)
Yes
Yes
Not applicable
Gateway/Gatekeeper to
Gateway/Gatekeeper
(Figure 8-10)
Yes
Yes
Yes
Gateway/Gatekeeper in DMZ
(Figure 8-11)
Yes
Yes
Yes
•
Endpoint to Endpoint — the IP Phones communicate directly, without a
Gatekeeper or a Gateway (see Figure 8-8). NAT (both hide and static mode) can
be configured for the phones on the internal side of the VPN-1 Power Gateway.
No incoming calls can be made when Hide NAT is configured for the internal
phones.
Figure 8-8 H.323 Topology: Direct endpoint-to-endpoint communication
•
240
Gatekeeper/Gateway in External Network — The IP Phones use the services of a
Gatekeeper on the external side of the VPN-1 Power Gateway (see Figure 8-9).
This topology makes it possible to use the services of a Gatekeeper that is
maintained by another organization. It is possible to configure Hide NAT (or
Static NAT or no NAT) for the phones on the internal side of the VPN-1 Power
Gateway.
Securing H.323-Based VoIP
Figure 8-9
H.323 Topology: Gatekeeper/Gateway in External Network
•
Gatekeeper/Gateway in the DMZ — the same Gatekeeper/Gateway controls both
endpoint domains. This topology makes it possible to provide
Gatekeeper/Gateway services to other organizations (see Figure 8-10). Static
NAT (or no NAT) can be configured for the Gatekeeper/Gateway. Hide NAT (or
Static or no NAT) can be configured for the phones on the internal side of the
VPN-1 Power Gateway.
Figure 8-10 H.323 Topology: Gatekeeper/Gateway in the DMZ
•
Gatekeeper/Gateway to Gatekeeper/Gateway — each Gatekeeper/Gateway controls
a separate endpoint domain (see Figure 8-11). Static NAT can be configured for
one of the Gatekeepers/Gateways. For the phones, Hide NAT (or Static NAT) can
be configured for the phones on the internal or the external side of the VPN-1
Power Gateway (but not both).
Chapter 8
Securing Voice Over IP (VoIP) 241
Securing H.323-Based VoIP
Figure 8-11 H.323 Topology: Gatekeeper/Gateway to Gatekeeper/Gateway
Application Intelligence for H.323
VPN-1 Power supports H.323 version 4 and below, which includes H.225 version 4
and H.245 version 7. It performs the following application layer checks:
•
Strict enforcement of the protocol, including the order and direction of H.323
packets.
•
If the phone number sent is longer than 24 characters the packet is dropped.
This prevents buffer overruns in the server.
•
Dynamic ports will only be opened if the port is not used by another service.
For example: If the Connect message sends port 80 for the H.245 it will not be
opened. This prevents well-known ports being used illegally.
VPN-1 Power supports Fast Connect, an advanced H.323 capability that ensures
that audio is available as soon as the phone is answered. This feature is active by
default, and is always available.
242
Securing H.323-Based VoIP
SmartDefense Application Intelligence Settings for
H.323
The following additional Application Intelligence checks can be configured via
SmartDefense Application Intelligence > VoIP > H.323:
•
Block connections re-direction prevents conversations being handed over on both
sides. It must be unchecked in order to use Gatekeepers or Gateways.
•
Prevent blank source phone numbers for gatekeeper connections rejects RAS
connections in which the source phone number is blank. By default, they are
prevented. If a field that should be present in the packet is missing, the packet
is dropped.
•
Disable dynamic T.120 blocks application-sharing file transfer, used for white
board, chat, and application sharing in applications such as Microsoft
NetMeeting. T.120 is not allowed by default.
•
Block H.245 Tunneling prevents the encapsulation a H.245 message in any
Q.931 message. H.245 tunneling conserves resources, synchronizes call
signaling and control, and reduces call setup time. H.245 Tunneling should be
allowed, if the VoIP equipment supports it.
•
Disable dynamic opening of H.323 connections opened from RAS messages controls
the way the H323_ras service works. If the service is allowed in the Rule Base,
this setting controls whether control connections required by all H.323 sessions
will be dynamically opened by the firewall. If H.323 connections opened from
RAS messages are blocked, it is necessary to allow the H323 service in the Rule
Base. This setting applies only to connections that start with RAS (that is
allowed and inspected by the H323_ras service).
•
Drop H.323 calls that do not start with a SETUP message ensures that if this
option is selected, all H.323/Q.931 connections that do not start with a SETUP
message are dropped.
•
T120 timeout determines how long a dynamically opened T120 connection can
be idle. After this time, the connection is deleted. The default is 3600
seconds.
Gatekeeper and Gateway Call Routing
H.323 routing modes define which control protocols are allowed to pass between
the Gatekeepers or Gateways, and which are allowed to pass directly between the
endpoints. VPN-1 Power can be configured to allow one or more routing modes. To
understand routing modes, a basic understanding is required of H.323 protocols
and the sequence in which they are used.
Chapter 8
Securing Voice Over IP (VoIP) 243
Securing H.323-Based VoIP
Signaling and Media Protocols for H.323
The media in H.323 uses the RTP/RTCP and/or T.120 protocols. Signalling is
handled by the following H.323 protocols:
•
RAS manages registration, admission and status. Uses a fixed port: UDP1719.
•
Q.931 manages call setup and termination. Uses a fixed port: TCP1720.
•
H.245 negotiates channel usage and capabilities. Uses a dynamically assigned
port.
As an H.323 call is processed by a Gatekeeper, these protocols are used in
sequence and then the media passes. To end a call, the signaling protocols are
used in reverse order.
The protocol sequence for a Gateway is the same, other than the fact that when an
endpoint connects to the Gateway it does not use RAS.
Routing Modes
H.323 routing modes define which control protocols should pass between the
Gatekeepers or Gateways, and which between the endpoints. VPN-1 Power can be
configured to allow one or more of the routing modes. At least one of the routing
modes must be selected. If VPN-1 Power is configured to allow more than one
routing mode, the Gatekeeper/Gateway is free to decide which routing mode to use.
Figure 8-12 illustrates the three routing modes that can be selected.
Figure 8-12 Gatekeeper and Gateway Routing Modes
The routing modes illustrated in Figure 8-12 are as follows:
•
244
Direct mode is for Gatekeepers only, and not for Gateways. Only the RAS signals
pass through the Gatekeeper. All other signalling (Q.931 and H.245) as well as
the RTP/RTCP media passes directly endpoint to endpoint.
Securing H.323-Based VoIP
•
Call Setup (Q.931) mode allows RAS (used only by Gatekeepers) and Q.931 to
pass through the Gatekeeper/Gateway. H.245 and the RTP/RTCP media pass
endpoint to endpoint.
•
Call Setup (Q.931) and Call Control (H.245) mode allows RAS (for a Gatekeeper
only), Q.931 and H.245 to pass through the Gatekeeper/Gateway. Only the
RTP/RTCP media passes endpoint to endpoint.
H.323 Services
The following predefined services are available for use in H.323 rules. They can be
used to limit the protocols that are permitted during each stage of the H.323 call.
Separate rules can be defined for the different protocols:
Note - The services H323 and H323_any cannot be used in the same rule because they
contradict each other. Similarly, the services H323_ras and H323_ras_any cannot be used
in the same rule.
•
H323_ras_only allows only RAS. Cannot be used to make calls. If this service
is used, no Application Intelligence checks (payload inspection or modification)
are made. Do not use in the same rule as the H323_ras service.
•
H323_ras allows a RAS port to be opened, followed by a Q.931 port. Q.931
then opens a H.245 port if needed, which in turn opens ports for RTP/RTCP or
T.120. Use this service to do NAT on RAS messages. Do not use in the same
rule as the H323_ras_only service.
•
H323 allows a Q.931 to be opened, (and if needed, followed by a H.245 port,)
which in turn opens ports for RTP/RTCP or T.120. Do not use in the same rule
as the H323_any service.
•
H323_any is like the H323 service, but also allows the Destination in the rule
to be ANY rather than a network object. Only use H323_any if you do not know
the VoIP topology, and are not enforcing handover using a VoIP Domain. Do not
use in the same rule as the H323 service.
Chapter 8
Securing Voice Over IP (VoIP) 245
Securing H.323-Based VoIP
Configuring H.323-Based VoIP
In This Section
Choosing the Type of H.323-VoIP Domain
page 246
H.323 Rule for an Endpoint to Endpoint Topology
page 246
H.323 Rules for a Gatekeeper to Gatekeeper Topology
page 247
H.323 Rules for a Gateway to Gateway Topology
page 250
H.323 Rules for a Gatekeeper in the External Network
page 251
H.323 Rules for a Gateway in the External Network
page 253
H.323 Rules for a Gatekeeper in DMZ Topology
page 255
H.323 Rules for a Gateway in DMZ Topology
page 258
Choosing the Type of H.323-VoIP Domain
Configure a VoIP Domain for H.323 phones if they use the Gateway or Gatekeeper
to make calls. Choose either a Gateway or Gatekeeper object according to the
following criteria:
•
Use a VoIP Domain H.323 Gateway if the first packet that the device sees when
a call is initiated is a Q.931/H.225 packet, and not RAS.
•
Use a VoIP Domain H.323 Gatekeeper if the first packet that the device sees
when a call is initiated is a RAS/H.225 packet.
For an H.323 Gatekeeper, the VoIP Domain corresponds to the zone of that
Gatekeeper. A zone is a collection of terminals that are managed by a single
Gatekeeper. A zone has one and only one Gatekeeper.
If the Gatekeeper and Gateway have different IP addresses, define a VoIP Domain
for each one. If the Gateway and Gatekeeper are on single machine, and have the
same IP address, define only a single VoIP Domain H.323 Gatekeeper object.
H.323 Rule for an Endpoint to Endpoint Topology
An endpoint to endpoint topology is shown in Figure 8-13, with Net_A and Net_B
on opposite sides of the VPN-1 Power enforcement point. The following procedure
explains how to allow bidirectional calls between the phones in the internal network
(Net_A), and phones in an external network (Net_B), and how to define NAT for the
internal phones. No incoming calls can be made when Hide NAT is configured for
the internal phones.
246
Securing H.323-Based VoIP
Figure 8-13 H.323 Topology: Direct endpoint-to-endpoint communication
1. For this topology, define the following rule:
Table 8-7
Source
Destination
Service
Action
Net_A
Net_B
Net_B
Net_A
H323
Accept
2. To define Hide NAT (or Static NAT) for the phones in the internal network, edit
the network object for the internal network (Net_A). In the NAT tab, check Add
Automatic Address Translation Rules, and select the Translation method (Hide or
Static).
3. Configure the SmartDefense options under Application Intelligence > VoIP >
H.323 as required. For details, see “SmartDefense Application Intelligence
Settings for H.323” on page 243, or the online help.
4. Install the Security Policy.
H.323 Rules for a Gatekeeper to Gatekeeper Topology
A Gatekeeper to Gatekeeper topology is shown in Figure 8-14, with Net_A and
Net_B on opposite sides of the VPN-1 Power enforcement point. The following
procedure explains how to allow bidirectional calls between the phones in the
internal network (Net_A), and phones in an external network (Net_B), and how to
define NAT for the internal phones and the internal Gatekeeper (GK_A).
Chapter 8
Securing Voice Over IP (VoIP) 247
Securing H.323-Based VoIP
Figure 8-14 H.323 Topology: Gatekeeper to Gatekeeper
1. Define the Network objects (Nodes or Networks) for the phones which use the
Gatekeeper for registration, and are allowed to make calls, and whose calls are
tracked by the VPN-1 Power Gateway.
For the example in Figure 8-14, these are Net_A and Net_B.
2. Define the Network object for the Gatekeeper objects (GK_A and GK_B)
3. Define Security Rule Base rules either with or without a VoIP Domain.
If you wish to enforce handover, define VoIP Domains. Right-click the Network
Objects tree, and select New… > VoIP Domains > VoIP Domain H.323 Gatekeeper.
Define two VoIP Domain, as follows:
Table 8-8
Name
VoIP_Domain_A
VoIP_Domain_B
Related endpoints domain
Group containing
Net_A
Group containing
Net_B
VoIP installed at
GK_A
GK_B
4. In the Routing Mode tab, define permitted routing modes for the Gatekeepers.
For an explanation of the modes, see “Routing Modes” on page 244. It is
important to select at least one option.
248
Securing H.323-Based VoIP
5. Now define the rules. To enforce handover, define the following rule with VoIP
Domains:
Table 8-9
Source
Destination
Service
Action
Comment
VoIP_Domain_A
VoIP_Domain_B
VoIP_Domain_B
VoIP_Domain_A
H323_ras
Accept
Bidirectional calls.
Handover
enforced.
If you do not wish to enforce handover, define the following rules:
Table 8-10
Source
Destination
Service
Action
Comment
GK_A
GK_B
H323_ras_only
Accept
No handover.
Net_A
Net_B
Net_A
Net_B
H323
Accept
No handover.
When rules without a VoIP domain are defined, all connections other than
H323_ras are only allowed to be peer to peer.
For an explanation of the H.323 services, see “H.323 Services” on page 245.
6. To define Hide NAT (or Static NAT) for the phones in the internal network, edit
the network object for the internal network (Net_A). In the NAT tab, check Add
Automatic Address Translation Rules, and select the Translation method (Hide or
Static)
7. To define Static NAT for the Gatekeeper/Gateway in the internal network, repeat
step 6 for the Gatekeeper object (GK_A).
8. It is recommended to make the time-out of the H323_ras service the same or
greater than the Gatekeeper registration time-out. Configure the time-outs in
the Advanced Properties window of the Service object.
9. Configure the SmartDefense options under Application Intelligence > VoIP >
H.323 as required. For details, see “SmartDefense Application Intelligence
Settings for H.323” on page 243, or the online help.
10. Install the Security Policy.
Chapter 8
Securing Voice Over IP (VoIP) 249
Securing H.323-Based VoIP
H.323 Rules for a Gateway to Gateway Topology
A Gateway to Gateway topology is shown in Figure 8-15, with Net_A and Net_B on
opposite sides of the VPN-1 Power enforcement point. The following procedure
explains how to allow bidirectional calls between the phones in the internal network
(Net_A), and phones in an external network (Net_B), and how to define NAT for the
internal phones and the internal Gateway (GW_A).
Figure 8-15 H.323 Topology: Gateway to Gateway
1. Define the Network objects (Nodes or Networks) for the phones which are
allowed to make calls, and whose calls are tracked by the VPN-1 Power
Gateway.
For the example in Figure 8-15, these are Net_A and Net_B.
2. Define the Network object for the Gateway objects (GW_A and GW_B)
3. Define Security Rule Base rules with a VoIP Domain to enforce handover.
Right-click the Network Objects tree, and select New… > VoIP Domains > VoIP
Domain H.323 Gateway. Define two VoIP Domain, as follows:
Table 8-11
Name
VoIP_Domain_A
VoIP_Domain_B
Related endpoints domain
Group containing
Net_A
Group containing
Net_B
VoIP installed at
GW_A
GW_B
4. In the Routing Mode tab, define permitted routing modes for the Gateways. For
an explanation of the modes, see “Routing Modes” on page 244. It is important
to select at least one option.
250
Securing H.323-Based VoIP
5. Now define the rules. To enforce handover, define the following rule with VoIP
Domains:
Table 8-12
Source
Destination
Service
Action
Comment
VoIP_Domain_A
VoIP_Domain_B
VoIP_Domain_B
VoIP_Domain_A
H323
Accept
Bidirectional calls.
Handover enforced.
For an explanation of the H.323 services, see “H.323 Services” on page 245.
6. To define Hide NAT (or Static NAT) for the phones in the internal network, edit
the network object for the internal network (Net_A). In the NAT tab, check Add
Automatic Address Translation Rules, and select the Translation method (Hide or
Static)
7. To define Static NAT for the Gatekeeper/Gateway in the internal network, repeat
step 6 for the Gatekeeper/Gateway object (GK_A).
8. Configure the SmartDefense options under Application Intelligence > VoIP >
H.323 as required. For details, see “SmartDefense Application Intelligence
Settings for H.323” on page 243, or the online help.
9. Install the Security Policy.
H.323 Rules for a Gatekeeper in the External Network
An H.323 topology with a Gatekeeper in the Internet is shown in Figure 8-16, with
Net_A and Net_B on opposite sides of the VPN-1 Power enforcement point. The
following procedure explains how to allow bidirectional calls between the phones in
the internal network (Net_A), and phones in an external network (Net_B), and how
to define NAT for the internal phones.
Figure 8-16 H.323 Topology: Gatekeeper In External Network
Chapter 8
Securing Voice Over IP (VoIP) 251
Securing H.323-Based VoIP
1. Define the Network objects (Nodes or Networks) for the phones which use the
Gatekeeper for registration, and that are allowed to make calls, and whose calls
are tracked by the VPN-1 Power Gateway.
For the example in Figure 8-16, these are Net_A and Net_B.
2. Define the Network object for the Gatekeeper (GK_B)
3. Define Security Rule Base rules either with or without a VoIP Domain.
If you wish to enforce handover, define a VoIP Domain. Right-click the Network
Objects tree, and select New… > VoIP Domains > VoIP Domain H.323 Gatekeeper.
Define a VoIP Domain, as follows:
Table 8-13
Name
VoIP_Domain
Related endpoints domain
Group containing
Net_A and Net_B
VoIP installed at
GK_A
4. In the Routing Mode tab, define permitted routing modes for the Gatekeeper. For
an explanation of the modes, see “Routing Modes” on page 244. It is important
to select at least one option.
5. Now define the rules. To enforce handover, define the following rule with a VoIP
Domain:
Table 8-14
Source
Destination
Service
Action
Comment
Net_A
Net_B
VoIP_Domain
VoIP_Domain
Net_A
H323_ras
H323
Accept
Bidirectional calls.
Handover enforced.
If you do not wish to enforce handover, define the following rules:
Table 8-15
Source
Destination
Service
Action
Comment
Net_A
GK_B
H323_ras_only
Accept
No handover.
Net_A
Net_B
Net_A
Net_B
H323
Accept
No handover.
When rules without a VoIP domain are defined, all connections other than RAS
connections are only allowed to be peer to peer.
252
Securing H.323-Based VoIP
For an explanation of the H.323 services, see “H.323 Services” on page 245.
6. To define Hide NAT (or Static NAT) for the phones in the internal network:
•
Edit the network object for the internal network (Net_A). In the NAT tab,
check Add Automatic Address Translation Rules, and select the Translation
method (Hide or Static)
•
If defining Hide NAT, add a Node object with the Hide NAT IP address to
the Destination of the rule(s) defined in step 5.
7. It is recommended to make the time-out of the H323_ras service greater or
equal to the Gatekeeper registration time-out. Configure the time-outs in the
Advanced Properties window of the Service object.
8. Configure the SmartDefense options under Application Intelligence > VoIP >
H.323 as required. For details, see “SmartDefense Application Intelligence
Settings for H.323” on page 243, or the online help.
9. Install the Security Policy.
H.323 Rules for a Gateway in the External Network
An H.323 topology with a Gateway in the Internet is shown in Figure 8-17, with
Net_A and Net_B on opposite sides of the VPN-1 Power enforcement point. The
following procedure explains how to allow bidirectional calls between the phones in
the internal network (Net_A), and phones in an external network (Net_B), and how
to define NAT for the internal phones.
Figure 8-17 H.323 Topology: Gateway In External Network
1. Define the Network objects (Nodes or Networks) for the phones that are allowed
to make calls, and whose calls are tracked by the VPN-1 Power Gateway.
For the example in Figure 8-17, these are Net_A and Net_B.
Chapter 8
Securing Voice Over IP (VoIP) 253
Securing H.323-Based VoIP
2. Define the Network object for the Gateway (GW_B)
3. Define Security Rule Base rules with a VoIP Domain to enforce handover.
Right-click the Network Objects tree, and select New… > VoIP Domains > VoIP
Domain H.323 Gateway. Define a VoIP Domain, as follows:
Table 8-16
Name
VoIP_Domain
Related endpoints domain
Group containing
Net_A and Net_B
VoIP installed at
GW_A
4. In the Routing Mode tab, define permitted routing modes for the Gateway. For
an explanation of the modes, see “Routing Modes” on page 244. It is important
to select at least one option.
5. Now define the rules. To enforce handover, define the following rule with a VoIP
Domain:
Table 8-17
Source
Destination
Service
Action
Comment
Net_A
Net_B
VoIP_Domain
VoIP_Domain
Net_A
H323
Accept
Bidirectional calls.
Handover enforced.
For an explanation of the H.323 services, see “H.323 Services” on page 245.
6. To define Hide NAT (or Static NAT) for the phones in the internal network:
•
Edit the network object for the internal network (Net_A). In the NAT tab,
check Add Automatic Address Translation Rules, and select the Translation
method (Hide or Static)
•
If using Hide NAT, you must add a Node object with the Hide NAT IP
address to the Destination of the rule(s) defined in step 5.
7. Configure the SmartDefense options under Application Intelligence > VoIP >
H.323 as required. For details, see “SmartDefense Application Intelligence
Settings for H.323” on page 243, or the online help.
8. Install the Security Policy.
254
Securing H.323-Based VoIP
H.323 Rules for a Gatekeeper in DMZ Topology
A H.323-based VoIP topology where a Gatekeeper is installed in the DMZ is shown
in Figure 8-18. The following procedure explains how to allow bidirectional calls
between the phones in the internal network (Net_A), and phones in an external
network (Net_B), and how to define NAT for the internal phones and the
Gatekeeper in the DMZ (GK_DMZ).
Figure 8-18 H.323 Topology: Gatekeeper in the DMZ
1. Define the Network objects (Nodes or Networks) for the phones which use the
Gatekeeper for registration, and that are allowed to make calls, and whose calls
are tracked by the VPN-1 Power Gateway.
For the example in Figure 8-18, these are Net_A and Net_B.
2. Define the Network object for the Gatekeeper (GK_DMZ).
3. Define Security Rule Base rules either with or without a VoIP Domain.
If you wish to enforce handover, define VoIP Domains. Right-click the Network
Objects tree, and select New… > VoIP Domains > VoIP Domain H.323 Gatekeeper.
The definition of the VoIP Domain depends on whether or not you wish to
enforce handover locations for phones in the external network. For phones in
the internal network, handover should always be enforced.
Table 8-18
VoIP Domain Definition
With Handover
No Handover for
External Phones
Name
VoIP_Domain
VoIP_Domain_A
Related endpoints domain
Group containing
Net_A and Net_B
Net_A
VoIP installed at
GK_DMZ
GK_DMZ
Chapter 8
Securing Voice Over IP (VoIP) 255
Securing H.323-Based VoIP
4. In the Routing Mode tab, define permitted routing modes for the Gatekeeper. For
an explanation of the modes, see “Routing Modes” on page 244. It is important
to select at least one option.
5. Now define the rules. For full handover enforcement, define the following rule:
Table 8-19
Source
Destination
Service
Action
Comment
VoIP_Domain
Net_A
Net_B
Net_A
Net_B
VoIP_Domain
H323_ras
Accep
t
Bidirectional calls.
Handover enforced.
If you do not wish to enforce handover for the external phones (in Net_B),
define the following rules:
Table 8-20
Source
Destination
Service
Action
Comment
Net_A,
Net_B,
GK_DMZ
Net_A,
Net_B,
GK_DMZ
H323_ras_only
Accept
Outgoing calls.
No handover enforced.
Net_A
Net_B
Net_A
Net_B
H323
Accept
No Handover enforced.
When rules without a VoIP domain are defined, all connections other than
H323_ras are only allowed to be peer to peer.
For an explanation of the H.323 services, see “H.323 Services” on page 245.
6. To define Hide NAT (or Static NAT) for the phones in the internal network:
•
Edit the network object for Net_A. In the NAT tab, check Add Automatic
Address Translation Rules, and select the Translation method (Hide or Static).
•
If using Hide NAT, you must choose the Hide behind IP address option, and
type the IP address of the Hiding address of the phones in the internal
network.
•
If using Hide NAT, you must add a Node object with the Hide NAT IP
address to the Destination of the rule(s) defined in step 5.
7. To define Static NAT for the Gatekeeper in the DMZ, add manual NAT rules, as
follows:
•
256
Create a Node object for the Static address of the Gatekeeper (for example:
GK_DMZ_NATed).
Securing H.323-Based VoIP
•
Define the following manual NAT rules:
Table 8-21
Original
Translated
Comment
Source
Destination
Service
Source
Destination
Service
GK_DMZ
Net_B
*Any
GK_DMZ:
Static
=
=
Outgoing calls
Net_B
GK_DMZ_N
ATed
*Any
=
GK_DMZ:
Static
=
Incoming calls
•
As for all manual NAT rules, configure proxy-arps. In other words, you must
associate the translated IP address with the MAC address of the Check
Point Gateway interface that is on the same network as the translated
addresses. Use the arp command in Unix or the local.arp file in
Windows.
The command fw ctl arp displays the ARP proxy table on VPN-1 Power
Gateways that run on Windows. On Unix, use the arp -a command.
8. It is recommended to make the time-out of the H.323_ras service greater or
equal to the Gatekeeper registration time-out. Configure the time-outs in the
Advanced Properties window of the Service object.
9. Configure the SmartDefense options under Application Intelligence > VoIP >
H.323 as required. For details, see “SmartDefense Application Intelligence
Settings for H.323” on page 243, or the online help.
10. Install the Security Policy.
Chapter 8
Securing Voice Over IP (VoIP) 257
Securing H.323-Based VoIP
H.323 Rules for a Gateway in DMZ Topology
A H.323-based VoIP topology where a Gateway is installed in the DMZ is shown in
Figure 8-19. The following procedure explains how to allow bidirectional calls
between the phones in the internal network (Net_A), and phones in an external
network (Net_B), and how to define NAT for the internal phones and the Gateway in
the DMZ (GK_DMZ).
Figure 8-19 H.323 Topology: Gateway in the DMZ
1. Define the Network objects (Nodes or Networks) for the phones that are allowed
to make calls, and whose calls are tracked by the VPN-1 Power Gateway.
For the example in Figure 8-19, these are Net_A and Net_B.
2. Define the Network object for the Gateway (GW_DMZ).
3. Define Security Rule Base rules with or without a VoIP Domain to enforce
handover. Right-click the Network Objects tree, and select New… > VoIP
Domains > VoIP Domain H.323 Gateway.
Table 8-22
VoIP Domain Definition
With Handover
Name
VoIP_Domain
Related endpoints domain
Group containing
Net_A and Net_B
VoIP installed at
GK_DMZ
4. In the Routing Mode tab, define permitted routing modes for the Gateway. For
an explanation of the modes, see “Routing Modes” on page 244. It is important
to select at least one option.
258
Securing H.323-Based VoIP
5. Now define the rules for full handover enforcement:
Table 8-23
Source
Destination
Service
Action
Comment
VoIP_Domain
Net_A
Net_B
Net_A
Net_B
VoIP_Domain
H323
Accept
Bidirectional calls.
Handover enforced.
For an explanation of the H.323 services, see “H.323 Services” on page 245.
6. To define Hide NAT (or Static NAT) for the phones in the internal network:
•
Edit the network object for Net_A. In the NAT tab, check Add Automatic
Address Translation Rules, and select the Translation method (Hide or Static).
•
If using Hide NAT, you must choose the Hide behind IP address option, and
type the IP address of the Hiding address of the phones in the internal
network.
•
If using Hide NAT, you must add a Node object with the Hide NAT IP
address to the Destination of the rule(s) defined in step 5.
Chapter 8
Securing Voice Over IP (VoIP) 259
Securing H.323-Based VoIP
7. To define Static NAT for the Gateway in the DMZ, add manual NAT rules, as
follows:
•
Create a Node object for the Static address of the Gateway (for example:
GW_DMZ_NATed).
•
Define the following manual NAT rules:
Table 8-24
Original
Translated
Comment
Source
Destination
Service
Source
Destination
Service
GW_DMZ
Net_B
*Any
GW_DMZ:
Static
=
=
Outgoing
calls
Net_B
GW_DMZ_NATed
*Any
=
GW_DMZ:
Static
=
Incoming
calls
•
As for all manual NAT rules, configure proxy-arps. In other words, you must
associate the translated IP address with the MAC address of the Check
Point Gateway interface that is on the same network as the translated
addresses. Use the arp command in Unix or the local.arp file in
Windows.
The command fw ctl arp displays the ARP proxy table on VPN-1 Power
Gateways that run on Windows. On Unix, use the arp -a command.
8. Configure the SmartDefense options under Application Intelligence > VoIP >
H.323 as required. For details, see “SmartDefense Application Intelligence
Settings for H.323” on page 243, or the online help.
9. Install the Security Policy.
260
Securing MGCP-Based VoIP
Securing MGCP-Based VoIP
Note Before reading this section, read “Introduction to the Check Point Solution for Secure VoIP” on
page 215 to “Protocol-Specific Security: SIP, H.323, MGCP and SCCP” on page 224.
The MGCP protocol is described in this section only to the extent required to secure MGCP traffic using
VPN-1 Power.
The Need for MGCP
page 261
MGCP Protocol and Devices
page 262
MGCP, SIP and H.323
page 263
MGCP Network Security and Application Intelligence
page 264
Configuring MGCP-Based VoIP
page 266
The Need for MGCP
Regular phones are relatively inexpensive because they don't need to be complex;
they are fixed to a specific switch at a central switching location. IP phones and
devices, on the other hand, are not fixed to a specific switch, so they must contain
processors that enable them to function and be intelligent on their own,
independent from a central switching location. This makes the terminal (phone or
device) more complex, and therefore, more expensive.
The MGCP (Media Gateway Control Protocol) protocol is meant to simplify
standards for VoIP by eliminating the need for complex, processor-intense IP
telephony devices, thus simplifying and lowering the cost of these terminals.
MGCP interoperates with SIP and H.323, but does not replace them. MGCP
converts audio signals carried on telephone circuits (PSTN) to data packets carried
over the Internet or other packet networks.
Chapter 8
Securing Voice Over IP (VoIP) 261
Securing MGCP-Based VoIP
MGCP Protocol and Devices
MGCP is a protocol for controlling telephony gateways from external call control
devices called Call Agents (also known as Media Gateway Controllers).
MGCP is a master/slave protocol, which means it assumes limited intelligence at
the edge (endpoints) and intelligence at the core (Call Agent). In this it differs from
SIP and H.323, which are peer-to-peer protocols.
The MGCP assumes that the call control devices, or Call Agents, will synchronize
with each other to send commands to devices under their control called Media
Gateways. Call Agents can also connect directly to IP Phones. The Media Gateways
or IP Phones are expected to execute commands sent by the Call Agents.
Figure 8-20 shows the MGCP elements and a simplified call control process.
Figure 8-20 MGCP Elements
The Call Agent and Media Gateways are defined in SmartDashboard, usually as
Node objects. There is normally no need to define network objects for phones that
are managed using MGCP.
To allow MGCP conversations you need only create rules to allow the MGCP control
signals through the VPN-1 Power Gateway. There is no need to define a rule for the
media that specifies which ports to open and which endpoints will talk. VPN-1
Power derives this information from the signalling. Given a particular VoIP
signalling rule, VPN-1 Power automatically opens ports for the endpoint to endpoint
RTP/RTCP media stream.
262
Securing MGCP-Based VoIP
Call Agent or Media Gateway Controller
A Call Agent is a network device that
•
Provides call signaling, control and processing intelligence to the media
gateway.
•
Sends and receives commands to/from the media gateway.
Media Gateway
A Media Gateway is a network device that
•
Provides conversion between the audio signals carried on telephone circuits and
data packets carried over the Internet or over other packet networks.
•
Sends notification to the call agent about endpoint events.
•
Execute commands from the call agents.
Media Gateways normally support features such as conference calls, 3-way
brokering and supervisor inspection. All of these features are supported by the
predefined VPN-1 Power MGCP services (MGCP-CA and MGCP-MG).
MGCP, SIP and H.323
MGCP is not an alternative to SIP or H.323. MGCP interoperates with H.323 and
SIP.
SIP and H.323 are comparable protocols that provide call setup, call teardown, call
control, capabilities exchange, and supplementary features.
MGCP is a protocol for controlling media gateways from call agents. In a VoIP
system, MGCP can be used with SIP or H.323. SIP or H.323 will provide the call
control functionality and MGCP can be used to manage media establishment in
media gateways.
For example, in Figure 8-21, a host has an SCCP Call Agent on one interface, and
an H.323 gateway or SIP Proxy on a second interface.
1. A Call Agent provides signaling and accepts SIP or H.323 call setup requests.
2. The Call Agent uses MGCP to control the Media Gateway.
3. The Media Gateway establishes media sessions with other H.323 or SIP
endpoints.
Chapter 8
Securing Voice Over IP (VoIP) 263
Securing MGCP-Based VoIP
Figure 8-21 MGCP interoperation with SIP and H.323
MGCP Network Security and Application
Intelligence
VPN-1 Power provides full network level security for MGCP. VPN-1 Power enforces
strict compliance with RFC-2705, RFC-3435 (version 1.0) and ITU TGCP
specification J.171. In addition, all VPN-1 Power capabilities are supported, such
as inspection of fragmented packets, anti spoofing, protection against Denial of
Service attacks. Note however that NAT on MGCP devices is not supported.
VPN-1 Power restricts handover locations and controls signalling and data
connections, as described in “VoIP Application Intelligence” on page 219.
SmartDefense can perform additional content security checks for MGCP
connections, thereby providing a greater level of protection. MGCP specific
Application Intelligence security is configured via SmartDefense, under Application
Intelligence > VoIP > MGCP. Three options are available:
264
•
Blocked/Accepted Commands
•
Verify MGCP Header Content
•
Allow Multicast RTP Connections
Securing MGCP-Based VoIP
Blocked/Accepted Commands
There are nine pre-defined MGCP commands. Some commands are made by the
Call Agent, and others by the Gateway, as shown in Table 8-25. It is possible to
allow or disallow any command as dictated by the security needs.
Table 8-25 MGCP commands
Call Agent Commands
Gateway Commands
EndpointConfiguration (EPCF)
Notify (NTFY)
NotificationRequest (RQNT)
DeleteConnection (DLXC)
CreateConnection (CRCX)
RestartInProgress (RSIP)
ModifyConnection (MDCX)
DeleteConnection (DLCX)
AuditEndpoint (AUEP)
AuditConnection (AUCX)
In addition, it is possible to define additional proprietary commands, and whether
to allow or block those commands. By default, all undefined commands are
blocked.
VPN-1 Power verifies that the new commands are RFC compliant.
MGCP packets contain an optional SDP header. This header contains information
such as the destination port number, the destination IP address and the media type
(audio or video). The predefined MGCP commands MDCX and CRCX have an SDP
header.
When defining an MGCP command, it is possible to specify whether or not the
command contains an SDP header. VPN-1 Power knows how to parse the header
and check it has the correct syntax. If the destination address and port in the
header are allowed, VPN-1 Power allows the media connection through the
Gateway.
Verify MGCP Header Content
Use this option to block binary characters, in order to prevent executable binary
files being sent in the MGCP headers. This option also blocks various potentially
dangerous control characters, and the null character.
Chapter 8
Securing Voice Over IP (VoIP) 265
Securing MGCP-Based VoIP
Allow Multicast RTP Connections
RTP is the protocol used for VoIP media. Multicast RTP can be used for radio. If
server sends a packet with a multicast address, the Media Gateway opens a port,
and any client can listen to multicast on that port. Use this option to block or allow
MGCP multicasts.
Configuring MGCP-Based VoIP
Procedure for Configuring MGCP-Based VoIP
page 266
MGCP Rules for a Call Agent in the DMZ
page 267
MGCP Rules for a Call Agent in the Internal Network
page 268
MGCP Rules for a Call Agent in an External Network
page 269
Procedure for Configuring MGCP-Based VoIP
1. Configure the required options in SmartDefense under Application Intelligence >
VoIP > MGCP, and set the options appropriately.
2. Define the Network objects (Nodes or Networks) for the Media Gateways and IP
Phones that are controlled by the Call Agents.
3. Define a Group object for the VoIP endpoint domain. This is a group all the
Network objects defined in step 2.
4. Define the network object for the machine on which the Call Agent is installed.
5. Define the VoIP Domain object.
From the SmartDashboard menu, select Manage > Network Objects > New... >
VoIP Domains > VoIP Domain MGCP. Give the Domain object a Name. For the
Related endpoints domain choose the Group object defined in step 3. For the
VoIP installed at choose the network object defined in step 4.
6. Define the VoIP Rule(s) that are appropriate for the topology. Place both
predefined MGCP services in the Service column of the rule:
•
MGCP-CA is Call Agent service. It uses port 2727.
•
MGCP-MG is the Media Gateway service. It uses port 2427.
MGCP interoperates with H.323 and SIP. However, MGCP configuration is
independent of the other VoIP protocol configuration. Define separate rules for
MGCP and the other VoIP protocols.
The rules depend on the network topology. For details, see the following
sections:
266
Securing MGCP-Based VoIP
•
“MGCP Rules for a Call Agent in the DMZ” on page 267
•
“MGCP Rules for a Call Agent in the Internal Network” on page 268
•
“MGCP Rules for a Call Agent in an External Network” on page 269
7. Install the Security Policy.
MGCP Rules for a Call Agent in the DMZ
In a DMZ topology shown in Figure 8-22, the Media Gateways are in the internal
and external networks, and the Call Agent is in a DMZ network connected to a
separate interface of the VPN-1 Power enforcement point.
Figure 8-22 MGCP Call Agent in the DMZ
The rules in Table 8-26 allows any telephone managed by MG_Int and MG_Ext to
make calls to each other.
Table 8-26 MGCP rules for a Call Agent in the DMZ
Source
Destination
Service
Action
MG_Int
MG_Ext
VoIP_Call_Agent
mgcp_CA
mgcp_MG
Accept
VoIP_Call_Agent
MG_Int
MG_Ext
mgcp_CA
mgcp_MG
Accept
VoIP_Call_Agent is the VoIP Domain object with endpoint domain that includes
both MG_Int and MG_Ext. Create the VoIP Domain object as shown in Figure 8-23.
Add both Media Gateway objects to a Group object, and use it as the Related
endpoints domain. In the VoIP installed at field, put the Call Agent object.
Chapter 8
Securing Voice Over IP (VoIP) 267
Securing MGCP-Based VoIP
Figure 8-23 VoIP Domain of the MGCP Call Agent
MGCP Rules for a Call Agent in the Internal Network
In the topology shown in Figure 8-24, there are Media Gateways in the internal
network and in an external network. The Call Agent is in the internal network.
Figure 8-24 MGCP Call Agent in an Internal Network
268
Securing MGCP-Based VoIP
The rules in Table 8-27 allows any telephone managed by MG_Int and MG_Ext to
make calls to each other. Each rule allows calls in one direction.
Table 8-27 MGCP rules for a Call Agent in the internal network
Source
Destination
Service
Action
Comment
VoIP_Call_Agent
MG_Ext
mgcp_CA
mgcp_MG
Accept
Outgoing calls
MG_Ext
VoIP_Call_Agent
mgcp_CA
mgcp_MG
Accept
Incoming calls
VoIP_Call_Agent is the VoIP Domain object with endpoint domain that includes
both MG_Int and MG_Ext. Create the VoIP Domain object as shown in Figure 8-23
on page 268. Add both Media Gateway objects to a Group object, and use it as the
Related endpoints domain. In the VoIP installed at field, put the Call Agent object.
MGCP Rules for a Call Agent in an External Network
In the topology shown in Figure 8-25, there are Media Gateways in the internal
network and in an external network. The Call Agent is in the external network.
Figure 8-25 MGCP Call Agent in an External Network
Chapter 8
Securing Voice Over IP (VoIP) 269
Securing MGCP-Based VoIP
The first rule in Table 8-28 allows any telephone managed by MG_Int1 and
MG_Int2 to call any telephone managed by MG_Ext. The second rule allows calls in
the opposite direction. In this case, no VoIP Domain is needed, because the Call
Agent is in the external network. Make sure that in the VPN-1 Power Gateway
object Topology page, the interface that faces the Internet is defined as External.
Table 8-28 MGCP rules for a Call Agent in the internal network
Source
Destination
Service
Action
Comment
MG_Int1
MG_Int2
Call_Agent
mgcp_CA
mgcp_MG
Accept
Outgoing calls
Call_Agent
MG_Int1
MG_Int2
mgcp_CA
mgcp_MG
Accept
Incoming calls
Allowing Internal Calls When the Call Agent is in an External Network
If the Call Agent is in an external network, and you wish to allow internal calls
between phones managed by different Media Gateways behind the same interface
of the VPN-1 Power Gateway, you must define a VoIP Domain. This configuration is
illustrated in Figure 8-25 on page 269. The rules in Table 8-29 allow calls between
MG_int1 and MG_Int2.
Table 8-29 MGCP rules for a Call Agent in the internal network
Source
Destination
Service
Action
Comment
MG_Int1
MG_Int2
VoIP_Call_Agent
mgcp_CA
mgcp_MG
Accept
Outgoing calls
VoIP_Call_Agent
MG_Int1
MG_Int2
mgcp_CA
mgcp_MG
Accept
Incoming calls
VoIP_Call_Agent is the VoIP Domain object with endpoint domain that includes
both MG_Int1 and MG_Int2. Create the VoIP Domain object as shown in
Figure 8-23 on page 268. Add both Media Gateway objects to a Group object, and
use it as the Related endpoints domain. In the VoIP installed at field, put the Call
Agent object.
270
Securing SCCP-Based VoIP
Securing SCCP-Based VoIP
Note Before reading this section, read “Introduction to the Check Point Solution for Secure VoIP” on
page 215 to “Protocol-Specific Security: SIP, H.323, MGCP and SCCP” on page 224.
The SCCP protocol is described in this section only to the extent required to secure SCCP traffic using
VPN-1 Power.
In This Section
The SCCP Protocol
page 271
SCCP Devices
page 272
SCCP Network Security and Application Intelligence
page 272
ClusterXL Support for SCCP
page 273
Configuring SCCP-Based VoIP
page 273
The SCCP Protocol
Many Cisco® devices use the Cisco proprietary VoIP protocol, SCCP (Skinny Client
Control Protocol). The SCCP protocol is also licensed to a number of Cisco
partners.
SCCP uses TCP on port 2000 for the control signals. Media is transmitted using
RTP over UDP to and from a SCCP client or H.323 terminal for audio.
The protocol headers are binary headers (unlike MGCP, for example, which uses
text headers).
The SCCP protocol defines hundreds of messages. They can be broadly divided into
three groups:
•
Registration and management messages.
•
Media Control Messages.
•
Call Control Messages.
Chapter 8
Securing Voice Over IP (VoIP) 271
Securing SCCP-Based VoIP
SCCP Devices
SCCP has a centralized call-control architecture. The CallManager manages SCCP
clients (VoIP endpoints), which can be IP Phones or Cisco ATA analog phone
adapters. The CallManager controls all the features of the endpoints. It requests
information such as the station capabilities, and sends to the VoIP endpoints
information such as the button template, and the date/time.
The CallManagers are defined in SmartDashboard, usually as Node objects. The
networks containing directly-managed IP Phones are also defined in
SmartDashboard. There is normally no need to define network objects for individual
phones. Cisco ATA devices that are managed by a CallManager must be defined in
SmartDashboard, but the connected analog phones are not defined.
To allow SCCP conversations you need only create rules to allow the SCCP control
signals through the VPN-1 Power Gateway. There is no need to define a rule for the
media that specifies which ports to open and which endpoints will talk. VPN-1
Power derives this information from the signalling. Given a particular VoIP
signalling rule, VPN-1 Power automatically opens ports for the endpoint to endpoint
RTP/RTCP media stream.
SCCP Network Security and Application
Intelligence
VPN-1 Power provides full connectivity and network level and security for SCCP
based VoIP communication. All SCCP traffic is inspected, and legitimate traffic is
allowed to pass while attacks are blocked. All VPN-1 Power capabilities are
supported, such as anti- spoofing and protection against Denial of Service attacks.
Fragmented packets are examined and secured using kernel based streaming.
However, NAT on SCCP devices is not supported.
VPN-1 Power restricts handover locations, and controls signalling and data
connections, as described in “VoIP Application Intelligence” on page 219.
VPN-1 Power tracks state and verifies that the state is valid for all SCCP message.
For a number of key messages, it also verifies of existence and correctness of the
message parameters.
SmartDefense can perform additional content security checks for SCCP
connections, thereby providing a greater level of protection. Under Application
Intelligence > VoIP > SCCP, two options are available:
•
272
Verify SCCP Header Content blocks various potentially dangerous control
characters, and the null character.
Securing SCCP-Based VoIP
•
Block Multicast RTP Connections blocks SCCP multicasts. RTP is the protocol
used for VoIP media. Multicast RTP can be used for radio. If a server sends a
packet with a multicast address, the CallManager opens a port, and any client
can listen to multicast on that port.
ClusterXL Support for SCCP
SCCP calls can be made across a ClusterXL Gateway cluster. However, calls do not
survive failover.
Configuring SCCP-Based VoIP
Procedure for Configuring SCCP-Based VoIP
page 273
SCCP Rules for a CallManager in the DMZ
page 274
SCCP Rules for a CallManager in the Internal Network
page 275
SCCP Rules for a CallManager in an External Network
page 276
Procedure for Configuring SCCP-Based VoIP
1. Configure the SmartDefense settings for SCCP under Application Intelligence >
VoIP > SCCP.
2. Define the Network objects (Nodes or Networks) for the Cisco ATA devices or IP
Phones that are controlled by the CallManagers.
3. Define a Group object for the VoIP endpoint domain. This is a group all the
Network objects defined in step 2.
4. Define the network object for the machine on which the CallManager is
installed.
5. Define the VoIP Domain object.
From the SmartDashboard menu, select Manage > Network Objects > New… >
VoIP Domains > VoIP Domain SCCP. Give the Domain object a Name. For the
Related endpoints domain choose the Group object defined in step 3. For the
VoIP installed at choose the network object defined in step 4.
6. Define the VoIP Rule(s) that are appropriate for the topology. Place the
predefined SCCP service in the Service column of the rule:
SCCP interoperates with other VoIP protocols. However, SCCP configuration is
independent of the other VoIP protocol configuration. Define separate rules for
SCCP and the other VoIP protocols.
Chapter 8
Securing Voice Over IP (VoIP) 273
Securing SCCP-Based VoIP
The rules depend on the network topology. For details, see the following
sections:
•
“SCCP Rules for a CallManager in the DMZ” on page 274.
•
“SCCP Rules for a CallManager in the Internal Network” on page 275.
•
“SCCP Rules for a CallManager in an External Network” on page 276.
7. Install the Security Policy.
SCCP Rules for a CallManager in the DMZ
In a DMZ topology shown in Figure 8-26, the Cisco ATA devices or IP Phones are in
the internal and external networks, and the CallManager is in a DMZ network
connected to a separate interface of the VPN-1 Power enforcement point.
Figure 8-26 SCCP CallManager in the DMZ
The rules in Table 8-30 allows any telephone managed by ATA_Int and ATA_Ext to
make calls to each other.
Table 8-30 SCCP rules for a CallManager in the DMZ
Source
Destination
Service
Action
ATA_Int
ATA_Ext
VoIP_Call_Manager
SCCP
Accept
VoIP_Call_Manager
ATA_Int
ATA_Ext
SCCP
Accept
VoIP_Call_Manager is the VoIP Domain object with endpoint domain that includes
both ATA_Int and ATA_Ext. Create the VoIP Domain object as shown in Figure 8-27.
Add both Cisco ATA device or IP Phone objects to a Group object, and use it as the
Related endpoints domain. In the VoIP installed at field, put the CallManager object.
274
Securing SCCP-Based VoIP
Figure 8-27 VoIP Domain of the SCCP CallManager
SCCP Rules for a CallManager in the Internal Network
In the topology shown in Figure 8-28, there are Cisco ATA devices or IP Phones in
the internal network and in an external network. The CallManager is in the internal
network.
Figure 8-28 SCCP CallManager in an Internal Network
Chapter 8
Securing Voice Over IP (VoIP) 275
Securing SCCP-Based VoIP
The rules in Table 8-31 allows any telephone managed by ATA_Int and ATA_Ext to
make calls to each other. Each rule allows calls in one direction.
Table 8-31 SCCP rules for a CallManager in the internal network
Source
Destination
Service
Action
Comment
VoIP_Call_Manager
ATA_Ext
SCCP
Accept
Outgoing calls
ATA_Ext
VoIP_Call_Manager
SCCP
Accept
Incoming
calls
VoIP_Call_Manager is the VoIP Domain object with endpoint domain that includes
both ATA_Int and ATA_Ext. Create the VoIP Domain object as shown in Figure 8-27
on page 275. Add both Cisco ATA device or IP Phone objects to a Group object,
and use it as the Related endpoints domain. In the VoIP installed at field, put the
CallManager object.
SCCP Rules for a CallManager in an External Network
In the topology shown in Figure 8-29, there are Cisco ATA devices or IP Phones in
the internal network and in an external network. The CallManager is in the external
network.
Figure 8-29 SCCP CallManager in an External Network
The first rule in Table 8-32 allows any telephone managed by ATA_Int and in the
Skinny_LAN to call any telephone managed by ATA_Ext. The second rule allows
calls in the opposite direction. In this case, no VoIP Domain is needed, because the
276
Securing SCCP-Based VoIP
CallManager is in the external network. Make sure that in the VPN-1 Power
Gateway object Topology page, the interface that faces the Internet is defined as
External.
Table 8-32 SCCP rules for a CallManager in the internal network
Source
Destination
Service
Action
Comment
ATA_Int
Skinny_LAN
Call_Manager
SCCP
Accept
Outgoing calls
Call_Manager
ATA_Int
Skinny_LAN
SCCP
Accept
Incoming calls
Allowing Internal Calls When the CallManager is in an External
Network
If the CallManager is in an external network, and you wish to allow internal calls
between phones managed by different Cisco ATA devices or IP Phones behind the
same interface of the VPN-1 Power Gateway, you must define a VoIP Domain. This
configuration is illustrated in Figure 8-29 on page 276. The rules in Table 8-33
allow calls between ATA_Int and the IP Phones in Skinny_LAN.
Table 8-33 SCCP rules for a CallManager in the internal network
Source
Destination
Service
Action
Comment
ATA_Int
Skinny_LAN
VoIP_Call_Manager
SCCP
Accept
Outgoing calls
VoIP_Call_Manager
ATA_Int
Skinny_LAN
SCCP
Accept
Incoming calls
VoIP_Call_Manager is the VoIP Domain object with endpoint domain that includes
both ATA_Int and Skinny_LAN. Create the VoIP Domain object as shown in
Figure 8-27 on page 275. Add both Cisco ATA device or IP Phone objects to a
Group object, and use it as the Related endpoints domain. In the VoIP installed at
field, put the CallManager object.
Chapter 8
Securing Voice Over IP (VoIP) 277
Securing SCCP-Based VoIP
278
9
Chapter
Securing Instant Messaging
Applications
In This Chapter
The Need to Secure Instant Messenger Applications
page 280
Introduction to Instant Messenger Security
page 281
Understanding Instant Messengers Security
page 282
NAT Support for MSN Messenger over SIP
page 283
NAT Support for MSN Messenger over MSNMS
page 284
Logging Instant Messenger Applications
page 285
Configuring SIP-based Instant Messengers
page 286
Configuring MSN Messenger over MSNMS
page 288
Configuring Skype, Yahoo and ICQ and Other Instant Messengers page 289
279
The Need to Secure Instant Messenger Applications
The Need to Secure Instant Messenger
Applications
Common Instant Messenger capabilities are file transfer, remote collaboration and
remote assistance. File transfers for example are a potential source of virus and
worm infections. Traditional content filters do not look for Instant Messenger traffic
and as a result most of the new worms and Trojans use instant messenger and peer
to peer networks to propagate. Remote assistance allows help desk staff to control
the PC to improve the Total Cost of Ownership, and reduce MIS costs. However, it
can also used by hackers to take control of a remote computer.
The Instant Messaging protocols themselves have vulnerabilities that can be
exploited to cause a Denial of Service attack. For example, passing an over-long
user name and password for authorization may for some applications cause a buffer
overflow that could bring down the Instant Messenger server.
SIP is emerging as the de-facto standard for instant messaging applications in the
enterprise. There are several known security issues associated with SIP-based
instant messaging applications. These are similar to the vulnerabilities associated
with SIP when used for Voice Over IP (VoIP), with additional vulnerabilities caused
by the nature of Instant Messengers and the way that it is used in the enterprise.
280
Introduction to Instant Messenger Security
Introduction to Instant Messenger Security
Instant messenger applications allow communication and collaboration between
business users using various modes of communication, such as Instant Messaging,
Voice and Video, Application Sharing, White board, File Transfer, and Remote
Assistance.
Firewall and SmartDefense give powerful and flexible security for Instant
Messengers. MSN Messenger in particular, both in its SIP mode of operation, and
using the native MSNMS protocol, can be secured with an extra level of granularity.
It is possible to selectively block the audio, video or other selected capabilities of
MSN Messenger. It is also possible to block the audio and video streams of any
SIP-based Instant Messaging application. The Security rule base can be used to
allow communication to and from specified locations.
Firewall and SmartDefense secure all MSN Messenger over SIP topologies. MSN
Messenger over SIP requires the use of a SIP proxy, and does not support endpoint
to endpoint calls.
Chapter 9
Securing Instant Messaging Applications 281
Understanding Instant Messengers Security
Understanding Instant Messengers Security
To understand the principles of securing SIP-based Instant Messenger
communication, see Chapter 8, “Securing Voice Over IP (VoIP)”: “Introduction to
the Check Point Solution for Secure VoIP” on page 215 to “Securing SIP Based
VoIP” on page 225 (inclusive).
VPN-1 Power dynamically opens ports for the services used by Instant Messenger
applications. It keeps those ports open only for as long as required, and closes
them as soon as the call ends, without waiting for a time-out. The order and
direction of the packets is also enforced.
For detailed information about MSN Messenger and the protocols it uses, see the
Microsoft web pages at:
•
http://www.microsoft.com/technet/prodtechnol/winxppro/evaluate/insid01.mspx
•
http://www.microsoft.com/technet/prodtechnol/winxppro/plan/rtcprot.mspx
(recommended for technical reference)
Some Peer to Peer applications also have Instant Messenger capabilities, which can
be blocked or allowed. For details, see the HTML pages and online help for the
SmartDefense Application Intelligence > Peer to Peer category.
282
NAT Support for MSN Messenger over SIP
NAT Support for MSN Messenger over SIP
The Firewall and SmartDefense components of VPN-1 Power allow all SIP-based
MSN Messenger applications to work seamlessly with Static Network Address
Translation (NAT). Hide NAT is fully supported for instant messenger (chat) and
audio connections. For the other MSN Messenger applications, some Hide NAT
operations are not supported due to the inconsistent behavior of MSN Messenger.
Table 9-1 details how Hide NAT can be used with SIP-based MSN Messenger
applications.
Table 9-1
Support for Hide NAT with SIP-based MSN Messenger Capabilities
Hide NAT
Instant
Messaging
Application
Sharing
and
Whiteboard
File
Transfer
and
Remote
Assistance
Audio
Video and
Audio
Internal –> External
(outbound traffic)
Yes
Yes
No
Yes
No
External –> Internal
(inbound traffic)
Yes
No
Yes
Yes
No
Internal –> Internal
(internal traffic)
Yes
Yes
Yes
Yes
Yes
Chapter 9
Securing Instant Messaging Applications 283
NAT Support for MSN Messenger over MSNMS
NAT Support for MSN Messenger over
MSNMS
For MSN Messenger over MSNMS, Static and Hide Network Address Translation
(NAT), is supported for the Instant Messenger and File Transfer applications.
284
Logging Instant Messenger Applications
Logging Instant Messenger Applications
VPN-1 Power provides detailed, protocol specific logs for Instant Messenger
conversations. The following events are logged in SmartView Tracker:
Table 9-2
Logged MSN Messenger over SIP events in SmartView Tracker
Event or Application
SmartView Tracker
Field name
Value
Call registration
registered IP-phones
SIP address
Instant message
media type
instant messaging
Audio
media type
Audio
Video
media type
Video
Application sharing and Whiteboard
(MSN Messenger only)
media type
Application
File transfer
(MSN Messenger only)
media type
File_Transfer
Remote Assistant
(MSN Messenger only)
media type
Remote_Assistanc
e
The ports used when setting up and maintaining an Instant Messenger call can be
either fixed or dynamically assigned. They depend on the call setup sequence,
which varies with the event and application. The Service and Source Port fields of
the smartView Tracker log record shows the port numbers used.
Chapter 9
Securing Instant Messaging Applications 285
Configuring SIP-based Instant Messengers
Configuring SIP-based Instant Messengers
Firewall and SmartDefense makes it possible to block or allow all SIP-based instant
messenger applications. For MSN Messenger over SIP, more granular control is
possible.
Note - To understand how to configure SmartDashboard for a SIP Proxy topology, it is
highly recommended to first read “Configuring SIP-Based VoIP” on page 232.
To completely block MSN Messenger over SIP and other SIP-based instant
messenger applications, including the core instant Messaging capabilities, do not
allow the SIP service in the Security Rule Base.
To selectively block SIP-based instant messenger applications (while allowing the
core instant Messaging capabilities), proceed as follows:
1. Create a network group object that contains all clients that are allowed to work
with the SIP proxy (call it allowed_phones, for example).
2. Create a VoIP domain object for the SIP proxy (call it SIP_domain, for
example).
3. Define the rule that includes all the services that you wish to allow. The rule in
Table 9-3 includes all the relevant services, and allows calls in both directions.
Table 9-3
Example rule allowing SIP-based Instant Messengers
Source
Destination
Service
Action
Action
allowed_phones
SIP_domain
SIP_domain
allowed_phones
sip
sip_dynamic_ports
T.120
MSN_Messenger_File_Transfer
Accept
Log
The relevant service are:
286
•
sip allows the use of a proxy server and enforces handover via a VoIP
Domain. See “SIP Services” on page 231.
•
sip_dynamic_ports is required for all SIP-based instant messaging
applications
•
T.120 is needed for application sharing and whiteboard applications
•
MSN_Messenger_File_Transfer is used for the MSN Messenger File Transfer
application.
Configuring SIP-based Instant Messengers
4. If required, configure Static and/or hide NAT for MSN Messenger, taking into
account the limitations described in “NAT Support for MSN Messenger over
SIP” on page 283.
5. Configure the options under SmartDefense Application Intelligence > VoIP > SIP.
They apply for all SIP-based Instant Messengers such as MSN Messenger over
SIP:
•
Block SIP-based video blocks or allows all applications that use SIP to carry
video. This includes the video components of MSN Messenger, when it is
configured to use SIP. The default is not to block.
•
Block SIP-based audio blocks or allows all applications that use SIP to carry
audio. This includes the audio components of MSN Messenger when it is
configured to use SIP. The default is not to block.
•
Block SIP-based Instant Messaging blocks or allows all applications that use
SIP for instant messaging. The default is to block.
6. To selectively block applications provided by MSN Messenger over SIP,
configure the options in Application Intelligence > Instant Messengers > MSN
Messenger over SIP, as follows
•
Block file transfer rejects access to applications that transfer files.
•
Block application sharing rejects access to applications that share files.
•
Block white board rejects access to the White Board applications.
•
Block remote assistant rejects access to your computer with a remote
application
Chapter 9
Securing Instant Messaging Applications 287
Configuring MSN Messenger over MSNMS
Configuring MSN Messenger over MSNMS
To completely block MSN Messenger over MSNMS, including its core instant
Messaging capabilities, do not allow the MSNMS service in the Security Rule Base.
To selectively block MSNMS-based instant messenger applications (while allowing
its core instant Messaging capabilities), proceed as follows:
1. Define a Security Rule Base rule that allows the following services:
•
MSNMS, DNS (group), Microsoft-ds, https.
•
To allow MSN Messenger games, also allow http.
2. If required, configure Static and/or hide NAT for MSN Messenger, taking into
account the limitations described in “NAT Support for MSN Messenger over
MSNMS” on page 284.
3. Configure the SmartDefense
•
MSN Messenger over MSNMS
page, as follows:
Block video prevents the use of MSN Messenger video applications.
Note - The Block video option applies to the Video conferencing application. The Webcam
application (which uses dynamic ports) is always blocked, unless there a specific rule that
allows it.
•
Block audio prevents the use of MSN Messenger audio applications.
•
Block file transfer prevents the use of MSN Messenger file transfer
applications.
•
Block application sharing prevents the sharing of application through MSN
Messenger.
•
Block white board prevents the use of MSN Messenger White Board
applications.
•
Block remote assistant prevents the use of MSN Messenger White Board
remote assistance applications.
4. To block MSN messenger communication that uses HTTP, in the Web
Intelligence tab, under HTTP Protocol Inspection > Header Rejection, check the
MSN Messenger options.
288
Configuring Skype, Yahoo and ICQ and Other Instant Messengers
Configuring Skype, Yahoo and ICQ and Other
Instant Messengers
1. To allow Skype, Yahoo and ICQ and other Instant Messenger applications, follow
the instructions provided by the application vendors.
2. To block Skype, Yahoo! Messenger and ICQ, configure the SmartDefense options
under Application Intelligence > Instant Messengers.
3. Some peer to peer applications also have instant messenger capabilities. Block
or allow peer to peer applications using the options in Application Intelligence >
Peer to Peer.
Chapter 9
Securing Instant Messaging Applications 289
Configuring Skype, Yahoo and ICQ and Other Instant Messengers
290
Chapter
Microsoft Networking
Services (CIFS) Security
10
In This Chapter
Securing Microsoft Networking Services (CIFS)
page 292
Restricting Access to Servers and Shares (CIFS Resource)
page 293
291
Securing Microsoft Networking Services (CIFS)
Securing Microsoft Networking Services
(CIFS)
CIFS (Common Internet File System) is a protocol used to request file and print
services from server systems over a network.
The protocol is an extension of the Server Message Block (SMB) protocol. CIFS is
used as the underlying transport layer for the NETBIOS session (nbsession) service
over TCP using port 139. In Windows networking, CIFS is used over the
Microsoft-DS protocol (port 445) for networking and file sharing. More information
on CIFS can be found at http://samba.org/cifs/.
By default, a Windows server has default shares open for administrative purposes
(C$, ADMIN$, PRINT$) and so is an easy target for internal attacks such as
brute-force password attacks on file servers.
VPN-1 Power secures Microsoft Networking Services in the Inspection Module,
without requiring a Security Server. This meets the high performance requirements
of LAN security (Fast Ethernet and Gigabit Ethernet).
The CIFS resource can be used to enforce the following security checks on CIFS
connections:
292
•
Correctness of the protocol.
•
Preventing CIFS and NETBIOS messages issued by the client from pointing to
beyond message boundaries.
•
Restricting access to a list of CIFS servers and disk shares.
•
Logging disk share access.
Restricting Access to Servers and Shares (CIFS Resource)
Restricting Access to Servers and Shares
(CIFS Resource)
1. Define a new CIFS Resource
2. Configure the CIFS Resource. Allowed Disk\Print Shares is a list of allowed CIFS
servers and disk shares. Note that the use of wildcards is allowed. Use
Add/Edit/Delete to modify the list. For example to allow access to the disk share
PAUL on the CIFS server BEATLES proceed as follows:
Click Add and type BEATLES in the Server Name field and IPC$ in the Share
Name field. Click OK.
Click Add again and type BEATLES in the Server Name field and PAUL in the
Share Name field. Click OK.
3. Add a new rule. Under Service, add either nbsession or Microsoft-DS together
with the configured Resource.
Warning - Do not delete or change the protocol type of the services objects that do content
inspection. If the service is altered in this way the protection will not work.
4. Install the Security Policy.
Chapter 10
Microsoft Networking Services (CIFS) Security 293
Restricting Access to Servers and Shares (CIFS Resource)
294
Chapter
FTP Security
11
In This Chapter
Introduction to FTP Content Security
page 296
FTP Enforcement by the VPN-1 Power kernel
page 297
FTP Enforcement by the FTP Security Server
page 298
Configuring Restricted Access to Specific Directories
page 299
295
Introduction to FTP Content Security
Introduction to FTP Content Security
Content Security for FTP connections is provided both by the VPN-1 Power kernel
and the FTP Security Server.
CVP checking can be performed on FTP traffic. This is done by redirecting the FTP
traffic to a CVP server. This is configured in the FTP Resource object.
296
FTP Enforcement by the VPN-1 Power kernel
FTP Enforcement by the VPN-1 Power kernel
The VPN-1 Power kernel enforces RFC compliant use of the PORT commands
issued by the client, to ensure that no arbitrary syntax is sent. VPN-1 Power
enforces additional security limitations, including:
•
Proper use of the IP field in the PORT command. This verifies that an IP
address presented on a PORT command is identical to the source address of
the client. This protects against the FTP bounce attack. A monitor-only setting
for this protection is available using SmartDefense Application Intelligence > FTP
> FTP Bounce.
•
Proper use of the Port in the PORT command. Data connections to well-known
ports are not allowed.
•
Unidirectional data flow on the data connections. This is a second line of
defense to avoid using the data connection for non-FTP data that require
bi-directional data flow.
Chapter 11
FTP Security 297
FTP Enforcement by the FTP Security Server
FTP Enforcement by the FTP Security Server
The FTP Security Server provides a number of capabilities, as follows.
Control the Allowed Protocol Commands
Only a predefined list of FTP commands is allowed, which gives full control over
the character of the FTP traffic. Some seldom-used FTP commands may
compromise FTP application security and integrity, and so are blocked. These
include the commands SITE, REST, MACB, and mail commands such as MAIL and
MSND. The SITE command is enabled once, upon login, to allow common FTP
applications to work properly. Allowed FTP commands are controlled via
SmartDefense Application Intelligence > FTP > FTP Security Server > Allowed FTP
Commands
VPN-1 Power enables control over the desired mode of FTP traffic, both for passive
FTP, where the client initiates the data connection, and for active FTP, where the
server initiates the data connection. Typically, the firewall should block connections
initiated from outside the protected domain.
Maintaining Integrity of Other Protected Services
The FTP security Server validates the random ports used in PORT command by the
FTP client or by the FTP security server. This prevents a port being randomly
chosen that is in use by a defined service. This protects against the risk of data
connection initiation to another active/working service in the protected domain.
Avoiding Vulnerabilities in FTP Applications
An exploit could be placed in the value of the PORT command. PORT commands
are usually interpreted using string manipulation functions that cause security
risks. The FTP Security Server performs a sanity validation for the PORT command
parameter.
Content Security via the FTP Resource
It is possible to inspect FTP connections for viruses and malicious content by
integrate with third party OPSEC certified CVP and UFP applications. For details
see “Virus checking an FTP connection using CVP” on page 308.
298
Configuring Restricted Access to Specific Directories
Configuring Restricted Access to Specific
Directories
It is possible to allow only file downloads (by specifying GET as an allowed method)
or only uploads (by specifying PUT as an allowed method), or both in an FTP
resource.
It is also possible to restrict connections to a particular path and/or filename. This
protects against exposure of the FTP server's file system.
The following procedure restricts access to a specific directory on the FTP Server
when uploading files from the internal network, but allows files to be downloaded
from anywhere on the FTP Server to the internal network.
Two resources must be created. One for upload, and one for download.
1. Create an FTP Resource to allow file downloads (Manage > Resources, click New
> FTP...).
In the General tab, Name the resource (Download, for example), and choose a
Tracking Option (such as Log).
In the Match tab, type the allowed directory path using wildcards, for example,
* to allow any directory and filename. Under Methods, select GET.
2. Create an FTP Resource to allow file uploads.
In the General tab, Name the resource (Upload, for example), and choose a
Tracking Option.
In the Match tab, type the allowed directory path and filename, using wildcards.
For example /uploads/*. Under Methods, select PUT.
Chapter 11
FTP Security 299
Configuring Restricted Access to Specific Directories
Define a Rule to allow file uploads, and another Rule to allow file downloads. For a
LAN called Alaska_LAN and an FTP Server in the DMZ called Alaska.DMZ.ftp, the
rules should look similar to the ones in Table 11-1.
Table 11-1 Example Rules for FTP Upload and Download
Source
Destination
Service
Action
Track
Install On
Time
Comment
Alaska
_Lan
Alaska.DMZ
.ftp
ftp->Upload
Accept
Log
*Policy
Targets
Any
ftp
upload to
/uploads/*
Alaska
_Lan
Alaska.DMZ
.ftp
ftp->Upload
Accept
Log
*Policy
Targets
Any
ftp
download
from*
3. Install the Security Policy.
300
12
Chapter
CVP and UFP Content Security
In This Chapter
The Need for Content Security
page 302
Check Point Solution for Content Security
page 303
Configuring Content Security
page 313
Advanced CVP Configuration: CVP Chaining and Load Sharing
page 322
301
The Need for Content Security
The Need for Content Security
Protecting corporate resources is a major concern of most businesses. Blocking
undesirable content is an important part of a corporate security policy. For
example:
•
Computer viruses, Trojans and ActiveX components containing malicious code
can bring down entire networks.
•
Viewing undesirable Web content wastes time and resources.
Access control firewalls prevent unauthorized traffic from passing through the
gateway. However, hackers also attempt to misuse of allowed traffic and services.
Some of the most serious threats in today's Internet environment come from attacks
that attempt to exploit the application layer. Access control devices cannot easily
detect malicious attacks aimed at these services.
302
Check Point Solution for Content Security
Check Point Solution for Content Security
In This Section
Introduction to Content Security
page 303
Security Servers
page 304
Deploying OPSEC Servers
page 305
CVP Servers for Anti-Virus and Malicious Content Protection
page 306
Using URL Filtering (UFP) to Limit Web Surfers
page 309
The TCP Security Server
page 312
Introduction to Content Security
VPN-1 Power provides Content Security by integrating with best-of-breed OPSEC
certified applications that complement the VPN-1 Power Content Security
capabilities. OPSEC applications enable organizations to choose the content
screening applications that best meet their needs, while managing Content Security
centrally, as part of the security policy. These applications:
•
Protect against network viruses, by scanning data and URLs to prevent viruses,
malicious Java and ActiveX components, and other malicious content from
entering your organization.
•
Prevent users browsing to undesirable web sites, by filtering URLs.
•
Provide auditing capabilities and detailed reports
For a listing of OPSEC Content Security solutions, see
http://www.opsec.com/solutions/sec_content_security.html.
Content security applications like virus scanners inspect the content of individual
packets for specific services,
The Content Vectoring Protocol (CVP) is an API specification developed by Check
Point that is mainly used for integration with anti-virus servers. This API defines an
asynchronous interface to server applications that perform file content validation.
An important feature of this is scanning files for viruses or harmful applets as they
pass through firewalls. CVP defines a client/server relationship that enables
different VPN-1 Power enforcement points to share a common content validation
server.
Chapter 12
CVP and UFP Content Security 303
Check Point Solution for Content Security
The URL Filtering protocol (UFP) is used to block user access to forbidden Web
sites, allowing administrators to define undesirable or inappropriate types of Web
sites. No configuration is required at the client machine. It is useful where
companies wish to avoid a loss of employee productivity. In Service Provider
environments, it can be offered as an add-on to Internet services, where it may be
used for parental restriction of child Web surfing, or on behalf of businesses that
have an inherent distrust of Internet content.
Security Servers
Security Servers are Check Point processes that are integrated into VPN-1 Power.
They are user mode processes that perform Content Security for
•
HTTP
•
FTP
•
SMTP
There is also a generic TCP Security Server. Security Servers employ many ways of
enforcing Content Security, including, for example, checking whether the
connections for these protocols are well formed, stripping script tags for HTTP,
email address translation for SMTP and file name matching for FTP.
As well as Content Security, Security Servers also perform Authentication. The
Authentication functions of the Security Servers are covered in “Authentication” on
page 47.
How a Security Server Mediates a Connection
Figure 12-1 shows how the Security Servers mediate a connection. The HTTP
Security Server is used as an example, but the method is the same for all Security
Servers.
When a packet is matched to a Rule which contains a Resource, the Inspection
Module diverts (also called “folds”) a connection to a Security Server. The Security
Server performs the Application Security checks, and if necessary diverts the
connection to a Content Vectoring Protocol (CVP) server application or a URL
Filtering (UFP) server application. The Security Server then returns the connection
to the Inspection Module, which opens a second connection that is sent on the
destination HTTP Server.
304
Check Point Solution for Content Security
Figure 12-1 How the Security Server mediates a connection
The source IP address that appears to the destination server is the IP address of
the client that originally opened the connection. The connection leaves the security
server with the source IP address of the VPN-1 Power enforcement module, and the
outbound kernel performs NAT so that the source IP address is that of the original
client.
Deploying OPSEC Servers
OPSEC solutions, such as CVP and UFP servers are deployed on dedicated servers
(Figure 12-2). These servers are typically either placed in the DMZ, or on a private
network segment. This allows fast, secure connections between the CVP servers and
the VPN-1 Power Gateway.
Performing scanning at the network perimeter is both safer and more efficient than
performing the scanning at the desktop or the application servers.
Chapter 12
CVP and UFP Content Security 305
Check Point Solution for Content Security
Figure 12-2 OPSEC Server Integration with VPN-1 Power
CVP Servers for Anti-Virus and Malicious Content
Protection
In This Section
CVP and Anti-Virus Protection for SMTP and HTTP Traffic
page 306
How a connection is handled by the HTTP Security Server
page 307
Improving CVP Performance for Web Traffic
page 307
Virus checking an FTP connection using CVP
page 308
CVP and Anti-Virus Protection for SMTP and HTTP
Traffic
To perform virus scanning, the HTTP or SMTP security server transfer packets from
the VPN-1 Power Gateway to another server running an OPSEC Certified virus
scanner. This method uses the Content Vectoring Protocol (CVP) to transfer packets
to and from an OPSEC virus scanning server.
The virus scanning CVP server determines if there is a virus. If it finds a virus it
can either:
•
306
Return the file to the VPN-1 Power Gateway with the offending content
removed (if the CVP server is allowed to modify content), or
Check Point Solution for Content Security
•
Drop the file (if the CVP server is not allowed to modify content).
CVP uses TCP port 18181, by default.
How a connection is handled by the HTTP Security
Server
The following discussion describes how the HTTP Security Server handles a
connection on which CVP checking is performed. The VPN-1 Power Gateway that
runs the HTTP Security Server acts as a proxy, and so is not an active participant
in the connection.
The connection request/response process without a CVP server is:
1. HTTP client to HTTP server (request)
2. HTTP server to HTTP client (response)
The data which needs to be checked is carried in the response which comes from
the Web server, so when a CVP server is used the response is always checked. In
that case, the connection request/response process is:
1. HTTP client to HTTP server (request)
2. HTTP server to CVP server (response)
3. CVP server to HTTP client (response)
Normally, only the HTTP responses, which come from the Web server, are sent to
the CVP Server for checking. However, you also may wish to protect against
undesirable content in the HTTP request, for example, when inspecting peer-to-peer
connections. In this case, the connection request/response process is
1. HTTP client to CVP server (request)
2. CVP server to HTTP server (request)
3. HTTP server to CVP server (response)
4. CVP server to HTTP client (response)
The HTTP Security Server can be configured to send HTTP headers to the CVP
server, as well as the HTTP message data.
Improving CVP Performance for Web Traffic
HTTP Security Server performance can be significantly improved by ensuring that
safe traffic is not sent to the CVP server. This reduces the amount of traffic sent to
the CVP server, and reduce the number of connections opened with the CVP server.
Chapter 12
CVP and UFP Content Security 307
Check Point Solution for Content Security
However, sending all content for CVP checking gives more certain protection.
VPN-1 Power considers safe, picture and video files that are non-executable,
because they do not normally contain viruses.
The HTTP Security Server identifies safe content by actually examining the
contents of a file. It does not rely on examining the URL (for file extensions such
as *.GIF) nor does it rely on checking the MIME type (such as image/gif) in the
server response.
For configuration details, see “Configuring CVP Checking for Web Traffic with
Improved Performance” on page 317.
Virus checking an FTP connection using CVP
Virus scanning on FTP connections can be performed by transferring the file to a
third party anti-virus application using the CVP protocol.
Figure 12-3 illustrates how VPN-1 Power implements CVP for virus checking in an
FTP connection.
Figure 12-3 CVP Inspection process during an FTP Connection
The relevant rule for the connection specifies a resource that includes Content
Vectoring Protocol (CVP) for anti-virus checking.
1. The FTP client establishes a connection via port 21 to the FTP server.
2. The Inspection Module monitors port 21 for GET and PUT commands, and
determines that the CVP Server must be invoked.
308
Check Point Solution for Content Security
3. When the client initiates a data transfer over port 20, the Inspection Module
folds the connection into the FTP Security Server.
4. The FTP Security Server sends the file to be inspected to the CVP Server.
5. The CVP Server scans the FTP files and returns a Validation Result message,
notifying the FTP Security Server of the result of the scan.
6. The CVP Server returns a clean version of the file to the FTP Security Server.
7. The FTP Security Server determines whether to transfer the file, based on the
Validation Result message, and takes the action defined for the resource, either
allowing or disallowing the file transfer.
8. If allowed, the FTP Security Server relays the FTP file on to the FTP server.
Using URL Filtering (UFP) to Limit Web Surfers
In This Section
Understanding URL Filtering
page 309
URL Filtering Using the HTTP Security Server
page 310
Enhanced UFP Performance Mode
page 311
Choosing the URL Filtering Mode
page 312
Understanding URL Filtering
The security administrator can choose to prevent access to specific destinations on
the Internet in order to allow access only to appropriate Web page information, and
make it impossible to access particular Web sites, or download certain file types.
This is done with the help of third party, OPSEC certified URL SmartCenter
applications. The security administrator can define a corporate Security Policy that
includes URL screening, in order to block undesirable Web pages, and record the
types of URLs accessed for internal analysis and reporting needs.
A URL Filtering Protocol (UFP) server is used to maintain a list of URLs and their
categories. As a user requests a URL, VPN-1 Power checks that URL against a UFP
Server, which returns the category under which the URL falls. In SmartDashboard,
permitted categories can be selected. Access to the Web page is allowed if the URL
is in a permitted category.
Chapter 12
CVP and UFP Content Security 309
Check Point Solution for Content Security
UFP uses TCP port 18182 by default.
Note - A basic URL filtering capability is built into VPN-1 Power. It can be used to block a
specific list of URLs without a UFP server. For details, see “Basic URL Filtering” on
page 366.
VPN-1 Power can integrate with OPSEC certified solutions in two ways:
•
Enhanced UFP Performance mode (called Enhanced UFP Performance in the URI
Resource) uses VPN-1 Power kernel inspection together with a dedicated UFP
daemon (aufpd). However, in this mode it is not possible to use CVP and UFP
checking on the same connection.
•
The ordinary UFP checking mode uses the VPN-1 Power HTTP Security Server
to mediate UFP connections. This can add significantly to the response time
seen by clients that browse web sites, in comparison to the Enhanced UFP
Performance mode.
For configuration details, see “Configuring URL Filtering with a UFP Server” on
page 318. An explanation follows that describes how these two modes work.
URL Filtering Using the HTTP Security Server
Figure 12-4 illustrates how VPN-1 Power performs URL Filtering of an HTTP
connection using the HTTP Security Server and a UFP server.
Figure 12-4 URL Filtering (UFP) Process for an HTTP Connection
1. Client invokes a connection through the VPN-1 Power Inspection Module.
310
Check Point Solution for Content Security
2. The HTTP Security Server uses UFP to send the URL to be categorized to the
third-party UFP Server.
3. The UFP Server inspects the file and returns a Validation Result message,
notifying the security server of the result of the inspection.
4. Based on the Validation Result message, the Inspection Module either allows or
disallows the viewing of that particular Web page.
Enhanced UFP Performance Mode
Figure 12-5 illustrates how enhanced URL Filtering (UFP) performance of an HTTP
connection works.
Figure 12-5 Enhanced URL Filtering (UFP) process, using kernel inspection
1. Web client invokes a connection through the VPN-1 Power Inspection Module.
2. The kernel Inspection Module puts up a barrier that prevents the web clients
receiving a response from the Web Server before a confirmation is received from
the UFP server.
3. HTTP requests destined for the Web Server go through VPN-1 Power
uninterrupted.
4. At the same time as step 3, the Inspection Module extracts the URL, and the
AUFPD daemon establishes a UFP session with the UFP server to categorize the
URL.
Chapter 12
CVP and UFP Content Security 311
Check Point Solution for Content Security
5. Based on the Validation Result message, AUFPD tells the Inspection Module
whether or not to block the URL.
6. If the URL is permitted, the barrier is removed, and the HTTP response from
the Web Server is allowed through VPN-1 Power.
7. If the URL is blocked, the HTTP response is rejected.
Choosing the URL Filtering Mode
“Enhanced UFP Performance Mode” and “URL Filtering Using the HTTP Security
Server” are different ways of doing UFP Filtering. When deciding the method to
employ, you must balance performance against security.
When the Enhanced UFP Performance mode is used, users browsing Web sites
experience significantly improved response times, as compared to UFP checking
using the VPN-1 Power HTTP Security Server. However, in this mode (called
Enhanced UFP Performance in the URI Resource), it is not possible to use CVP and
UFP checking on the same connection.
The TCP Security Server
Malicious content can potentially be carried in any TCP service, not only SMTP,
HTTP and FTP.
The TCP Security Server is used to perform CVP or UFP Content Security by a third
party OPSEC compliant application, on any TCP Service.
For configuration details, see “Performing CVP or UFP Inspection on any TCP
Service” on page 321.
312
Configuring Content Security
Configuring Content Security
In This Section
Resources: What They Are and How to Use Them
page 313
Creating a Resource and Using it in the Rule Base
page 314
Configuring Anti-Virus Checking for Incoming Email
page 315
Configuring CVP Checking for Web Traffic with Improved Performance
page 317
Configuring URL Filtering with a UFP Server
page 318
Performing CVP or UFP Inspection on any TCP Service
page 321
Advanced CVP Configuration: CVP Chaining and Load Sharing
page 322
Resources: What They Are and How to Use Them
To perform Content Security via the Security Rule Base, an object called a
Resource is defined in SmartDashboard (Figure 12-6). Resources are used to
match a specific kind of application layer content, in other words, to specify what
content you are looking for, and to perform some action on the content.
Figure 12-6 A URI Resource, showing the General tab
Using a Resource turns on either kernel inspection or the security servers,
depending on what the resource is used for.
Chapter 12
CVP and UFP Content Security 313
Configuring Content Security
For instance, a rule can be created that will drop the connection and generate an
alert if there are GETs or PUTs in an FTP transfer or if a specifically named file is
part of the transfer. Another rule can drop email addresses or attachments while
allowing the rest of the content through.
To specify the content you are looking for, regular expressions and wildcards can be
used in the Resource.
The Resource is triggered when a Rule includes the Resource, and a packet
matching that rule is encountered. A Resource is applied per Service. If a
connection matches the source and destination of the rule and the match
parameters of the Resource, then both the Action in the Rule and the Action in the
Resource are applied.
Creating a Resource and Using it in the Rule Base
1. To create a resource, select the Resources branch of the objects tree. Select the
Resource Type, right click, select a resource type, such as New URI... or New
SMTP....
2. Define the resource parameters in the General tab, and in the other tabs as
required.
3. To use service with a resource in a rule, right click in the Service column of the
rule, right click, and select Add with Resource.... In the Service with Resource
window, select the service, and then select the Resource that will operate on
the service. Click OK.
If a connection matches the source and destination of the rule and the match
parameters of the Resource, then both the Action in the Rule and the Action in the
Resource are applied.
314
Configuring Content Security
Configuring Anti-Virus Checking for Incoming Email
The goal is to check incoming mail for viruses, as illustrated in Figure 12-7. SMTP
mail arrives from the Internet to a mail relay server (Mail_relay) in a DMZ segment.
Before the mail is forwarded to the internal mail server (Mail_server), it undergoes
virus checking in the anti virus server (Anti_virus_server). Outgoing mail is sent
from the mail server towards the internet.
Figure 12-7 Sample Configuration - illustrating Anti-Virus Checking for Incoming Email
General Procedure
1. Create a host object for the machine on which the third-party OPSEC Server
application is installed.
2. Create an OPSEC Application object to represent the OPSEC application server,
and associate it with the host object created in step 1.
3. Define an SMTP resource that uses the OPSEC Application object, and
associate it with the OPSEC Application object created in step 2. Specify the
matching, and the content checking to be done.
4. Define rules that use the resource.
Chapter 12
CVP and UFP Content Security 315
Configuring Content Security
Implementation
1. Create a host object (e.g. Anti_virus_server) for the machine on which the
third-party OPSEC Server application is installed.
2. Create an OPSEC Application object to represent the OPSEC application server,
and associate it with the host object created in step 1. Initialize Secure Internal
Communication between the OPSEC Application and the SmartCenter Server. In
the CVP Options tab, verify that FW1_cvp is selected, and click OK.
3. Define an SMTP resource that uses the OPSEC object, and associate it with the
OPSEC Application object created in step 2. Specify the matching, and the
content checking to be done.
In the General Tab, give the Resource a Name (such as virus_check). Choose the
Mail Delivery and the Error Mail Delivery options, and the Exception Tracking.
In the Match tab, for the Sender put *, and for the Recipient put
*@your_domain, (for example *@company.com).
In the Action1 tab, define the Rewriting Rules, if any.
In the Action2 tab, define the Attachment handling, if any. Define the largest
allowed email attachment.
4. In the CVP tab, check Use CVP (Content Vectoring Protocol), select the CVP
Server defined in step 1, and define the CVP Server Options and Reply Order.
Click OK. A message may appear regarding stripping MIME of type
“message/partial'”. Accepting the MIME strip of type “message/partial” will
result in a configuration change to the Action2 tab. The Strip MIME of Type
field will contain message/partial. Stripping the Multipurpose Internet Mail
Extension (MIME) type of message/partial will not allow multiple-part messages
to be accepted for scanning.
5. Define a pair of rules that will perform virus checking on incoming mail, and a
rule to allow outbound email. The rules should look similar to the ones in
Figure 12-8.
6. Install the Security Policy.
316
Configuring Content Security
Figure 12-8 Example Rules for SMTP Virus Scanning
Table 12-1
Source
Destination
Service
Action
Track
Install On
Comment
Any
mail_relay
smtp
Accept
Log
Corporate_gw
Incoming
email
to mail relay
mail_relay
mail_server
smtp->
virus_check
Accept
Log
Corporate_gw
Incoming
email
virus scan
mail_server
Any
smtp
Accept
Log
Corporate_gw
Outgoing email
Configuring CVP Checking for Web Traffic with
Improved Performance
The performance of the CVP server when inspecting HTTP connections can be
enhanced by ensuring that only unsafe file types are sent to the CVP server for
inspection. For background information, see “Improving CVP Performance for Web
Traffic” on page 307.
Proceed as follows:
1. Create a host object for the machine on which the CVP Server application is
installed.
2. Create an OPSEC Application object to represent the CVP server, and associate
it with the host object created in step 1.
3. Define a URI resource that uses the OPSEC Application object, and associate it
with the OPSEC Application object created in step 2. Give it a name (such as
Internal.HTTP.CVP), specify the matching, and the content checking to be
done.
4. In the CVP tab, select Send only unsafe file types to the CVP server, and the other
required CVP options.
5. Associate the Resource with the HTTP Service, and place it in a Rule in the
Security Rule Base. See the sample rule shown in Table 12-2.
Table 12-2 Sample URI Resource in a Rule Base
Source
Destination
Service
Action
Internal_LAN
Any
http->Internal.HTTP.CVP
Accept
Chapter 12
CVP and UFP Content Security 317
Configuring Content Security
Configuring URL Filtering with a UFP Server
VPN-1 Power checks web connection attempts using URL Filtering Protocol (UFP)
servers. UFP servers maintain lists of URLs and their appropriate categories (i.e.
permitted or denied).
URL databases can be updated to provide a current list of blocked sites. All
communication between VPN-1 Power and the URL Filtering server uses the URL
Filtering Protocol.
Rule Match in UFP Modes
There are differences in rule matching behavior between UFP rules in Enforce URI
Capabilities mode (that use the kernel) and rules in Enhance UFP Performance mode
(that use the HTTP Security server). For background information about these two
modes, see “Using URL Filtering (UFP) to Limit Web Surfers” on page 309.
•
In Enforce URI Capabilities mode, the connection is matched to the Source,
Destination, Service, and UFP category of the Resource in the rule.
If the connection does not match to all these, the connection is compared to
successive rules in the Rule Base until a match is found.
•
In Enhance UFP Performance mode, the connection is matched only to the
Source, Destination, and Service in the rule. The connection is not matched to
the UFP category. If the connection matches the Source, Destination, and
Service in the rule, it is not matched to any other rule further down the Rule
Base.
In this mode, if connection matches the UFP category, the Action in the rule is
performed. If the connection does not match the UFP category, the opposite of
the Action specified in the Rule is performed.
What this means is that you may only have one rule with an Enhance UFP
Performance resource, for a given Source/Destination/Service. In the Match tab of
the resource, you must include all UFP categories. The Action in the rule takes
place if any of the selected categories match the connection.
If using Enforce URI Capabilities mode in a UFP resource, you may have more than
one rule with a resource using this mode, for a given Source/Destination/Service.
However, in order to have a simpler and less error-prone Rule Base, it is
recommended to use only one resource, as for the Enhance UFP Performance.
318
Configuring Content Security
For example, consider the following rules:
Table 12-3
No.
Source
Destination
Service
Action
1
Any
Any
Resource with UFP Category “Drugs”
Drop
2
Any
Any
Resource with UFP Category “Alcohol”
Drop
If a connection fits the UFP category of “Alcohol”:
•
In Enhance UFP Performance mode, the connection matches on Rule 1 and the
connection is Accepted — which is not the desired behavior.
•
In Enforce URI Capabilities mode, the connection matches on Rule 2 and the
connection is Dropped.
The correct way to build this rule in a way that will work in all modes, and for
greater simplicity, is as follows:
Table 12-4
No.
Source
Destination
Service
Action
1
Any
Any
Resource with UFP Categories “Drugs”
and “Alcohol”
Drop
Chapter 12
CVP and UFP Content Security 319
Configuring Content Security
Configuring URL Filtering
This procedure describes how to configure a URL Filtering using the VPN-1 Power
kernel or using the Security Server. For background information, see “Using URL
Filtering (UFP) to Limit Web Surfers” on page 309.
1. Create a host object for the machine on which the third-party OPSEC Server
application is installed.
2. Create an OPSEC Application object (Alaska_HTTP_UFP) to represent the
OPSEC application server, and associate it with the host object created in step
1.
3. Create a new URI resource that uses the OPSEC Application object, and
associate it with the OPSEC Application object created in step 2.
4. To perform URL Filtering using the VPN-1 Power kernel, select Enhance UFP
Performance.
To perform URL Filtering using the Security Server, select Enforce URI
capabilities, and select URI Match Specification Type: UFP.
In the Match tab, select the UFP server object that was created in step 2. Check
the appropriate Categories. Some UFP Servers show just two categories: Blocked
and Not Blocked. Others show many categories.
Figure 12-9 shows a restrictive resource that matches one of the many
categories.
Figure 12-9 Match tab for a URI Resource for UFP
320
Configuring Content Security
5. Associate the Resource with the HTTP Service, and place it in a Rule in the
Security Rule Base. See the sample rules shown in Table 12-5.
The Action in Rule 1 is Drop because the resource matches on Blocked
categories. If the resource were to match on Not Blocked categories, the
Actions in Rules 1 and 2 would be reversed: Allow in Rule 1, and Drop in Rule
2.
Rule 2 is required for the Enforce URI Capabilities mode. For the Enhance UFP
Performance mode it is recommended to avoid problems in cases where more
than one URI resource is used in the Rule Base.
Table 12-5 Sample UFP Rule Base Policy
No.
Source
Destination
Service
Action
1
Any
Any
http->Alaska_HTTP_UFP
Drop
2
Any
Any
http
Accept
Performing CVP or UFP Inspection on any TCP
Service
To configure CVP or UFP inspection on any TCP service:
1. In the TCP Service Properties, Advanced tab, check Enable for TCP Resource.
2. Create a TCP Resource. In the General tab, choose CVP or UFP, and the
Exception Track method.
3. Configure settings in the CVP or UFP tab.
4. Add a Rule to the Rule Base, and in the Service column, select Add with
Resource,
5. In the Service with Resource window, select the TCP service configured in step
1. under Resource, select the resource created in step 2.
6. Install the Security Policy.
For background information, see “The TCP Security Server” on page 312.
To configure CVP inspection for email, see “Configuring Anti-Virus Checking for
Incoming Email” on page 315.
To configure CVP and UFP inspection for Web traffic, see “Configuring Web Content
Protection” on page 376.
Chapter 12
CVP and UFP Content Security 321
Advanced CVP Configuration: CVP Chaining and Load Sharing
Advanced CVP Configuration: CVP Chaining
and Load Sharing
In This Section
Introduction to CVP Chaining and Load Sharing
page 322
CVP Chaining
page 322
CVP Load Sharing
page 324
Combining CVP Chaining and Load Sharing
page 325
Configuring CVP Chaining and Load Sharing
page 325
Introduction to CVP Chaining and Load Sharing
Traffic that crosses the VPN-1 Power enforcement point can be checked using CVP
servers. CVP checking is available for Web, Mail, FTP and TCP traffic. For detailed
explanations, see:
•
“CVP and Anti-Virus Protection for SMTP and HTTP Traffic” on page 306.
•
“Virus checking an FTP connection using CVP” on page 308.
It is possible to chain CVP servers in order to combine functionality, and to perform
load sharing between CVP servers, in order to speed up CVP checking.
CVP Chaining
CVP servers can be chained for the purpose of combining functionality. Chaining is
useful when each of the CVP servers performs a different task, such as scanning for
viruses, or blocking large email attachments. In the configuration shown in
Figure 12-10, the VPN-1 Power Security Server invokes the first, second, and third
CVP servers in turn.
322
Advanced CVP Configuration: CVP Chaining and Load Sharing
Figure 12-10CVP server chain
Chained CVP servers are invoked in the order chosen by the administrator in the
CVP Group object. When choosing a chaining order, consider whether there are any
security or connectivity issues. For example, in Figure 12-10, you may wish the
virus scanning to take place first.
The order in which the chained servers are called, is relative to the response of the
server. This is the case whether the server is on the unprotected (external interface)
side of the VPN-1 Power enforcement point or on the protected (internal interface)
side.
For example, in Figure 12-10, consider a user at an internal FTP client who is
downloading a file from an external FTP server. CVP checking is done on the
response from the FTP server (that is, on the downloaded file) in the order defined
in the CVP group object.
There is one exception to this order. The HTTP Security server allows CVP checking
to be done on the HTTP request. CVP checking of HTTP requests is performed by
the CVP servers in the reverse of the order specified in the CVP Group object.
CVP chaining works only if all servers in the chain are available. If one or more of
the servers is unavailable, the whole CVP session is dropped. This is because
skipping one of the servers may contradict the security policy. For example, the
security policy may specify that both virus scanning and blocking of large
attachments are mandatory.
Chapter 12
CVP and UFP Content Security 323
Advanced CVP Configuration: CVP Chaining and Load Sharing
CVP Load Sharing
Identical CVP servers can be configured to share the load among themselves. Load
sharing can speed up CVP checking by allowing many CVP sessions to run
simultaneously on more than one CVP server.
Two load sharing methods are available:
•
In the round robin method, the VPN-1 Power Security Server sends each new
CVP session to a different CVP server in turn.
•
In the random method, the VPN-1 Power Security Server sends each new CVP
session to a randomly chosen CVP server.
It is possible to configure a load sharing suspension period for a CVP server that
does not respond. During that period of time, that CVP server does not take part in
the load sharing group.
CVP load sharing is implemented by defining a Resource that invokes a group of
CVP servers. The order in round robin mode is configured in the CVP Group object.
Figure 12-11 shows two CVP servers that share the load among themselves.
Figure 12-11Load sharing between CVP servers
324
Advanced CVP Configuration: CVP Chaining and Load Sharing
Combining CVP Chaining and Load Sharing
It is possible to combine CVP chaining and load sharing. Figure 12-12 shows three
CVP servers. Two perform load sharing between themselves, and the load sharing
group is chained with another CVP server.
It is possible to put a load sharing group into a CVP chain, but it is not possible to
perform load sharing between chained CVP groups.
Figure 12-12A chained Load-Sharing CVP server group
Configuring CVP Chaining and Load Sharing
1. For each CVP server, define a CVP Server object.
To define a CVP Server object, right click in the Servers and OPSEC Application
tree, and select New > OPSEC Application.... In the OPSEC Application Properties
window, General tab, make sure that the selected Server Entities include CVP.
2. Define a CVP Group object. A CVP Group object contains CVP server objects,
and is used in the same way as an OPSEC Application object for a CVP server.
To define a CVP Group object, right click the Servers and OPSEC Application tree,
and select New > CVP Group.
3. In the CVP Group Properties window, add the CVP servers to the group.
4. Choose the Work distribution method: Either Load sharing or Chaining.
5. If you chose Load sharing, define the Load sharing method, and the Load sharing
suspend timeout, if any.
6. Create a Resource object. In the Resources tree, right click and select one of
the following: New > URI..., New > SMTP..., New > FTP..., or New > TCP.... Define
the content security capabilities.
Chapter 12
CVP and UFP Content Security 325
Advanced CVP Configuration: CVP Chaining and Load Sharing
7. In the CVP Server field in the CVP tab of the Resource object, select the CVP
Group defined in step 2.
8. In the Security Rule Base, define a rule that uses the Resource.
9. Save and install the Security Policy.
326
13
Chapter
Services with Application
Intelligence
In This Chapter
DCE-RPC
page 329
SSLv3 Service
page 330
SSHv2 Service
page 331
FTP_BASIC Protocol Type
page 332
Domain_UDP Service
page 333
Point-to-Point Tunneling Protocol (PPTP)
page 334
Blocking Visitor Mode (TCPT)
page 336
327
Introduction to Services with Application Intelligence
Introduction to Services with Application
Intelligence
There are a number of TCP services that perform content inspection, rather than
merely checking port numbers.
Services that do content inspection are those that have a defined Protocol Type in
the TCP Service Properties>Advanced window. either nbsession or Microsoft-DS
together with the configured Resource.
Warning - Do not delete or change the protocol type of the services objects that do content
inspection. If the service is altered in this way the content inspection may not work.
328
DCE-RPC
DCE-RPC
DCE-RPC (Distributed Computing Environment- remote procedure call) is a
technology used for calling a procedure on a remote machine.
Unlike other services that are associated with a specific TCP or UDP port, DCE-RPC
uses dynamically assigned port numbers assigned by the Endpoint Mapper.
DCE-RPC uses the Endpoint Mapper mechanism, for the purpose of dynamically
assigning a port number to specific applications, A client that wishes to connect to
a DCE-RPC application typically connects to TCP135 (default RPC Endpoint
Mapper port) and provides the Endpoint Mapper with a UUID number interface. In
return, the Endpoint Mapper provides the client a port to which the client can
connect.
SmartView Tracker logs UUID interfaces, which makes it possible to identify
non-common UUID interfaces. UUID interfaces can be used to enforce security
rules.
Chapter 13
Services with Application Intelligence 329
SSLv3 Service
SSLv3 Service
It is possible to verify that SSL client connections are using version 3 or higher of
the SSL protocol in order to prevent security problems known with earlier versions
of SSL. SSLv3 enforcement is enabled using the ssl_v3 service.
If the ssl_v3 service is used in a rule, and an SSLv2 connection is attempted, the
connection is rejected.
Many internet browsers use SSLv2. To allow their connections to pass through
VPN-1 Power, use the HTTPS service in the Rule Base.
330
SSHv2 Service
SSHv2 Service
It is possible to verify that SSH connections are using version 2 or higher of the
protocol in order to prevent security problems known with earlier versions of SSH.
SSHv2 enforcement is enabled using the ssh_version_2 service.
If the SSHv2 service is used in a rule, SSHv1 connections are dropped.
Chapter 13
Services with Application Intelligence 331
FTP_BASIC Protocol Type
FTP_BASIC Protocol Type
FTP_BASIC is a new protocol type. This protocol type enforces a reduced set of the
FTP security checks done by the regular FTP protocol type. Using FTP_BASIC
eliminates known connectivity problems with FTP implementations that are not
fully RFC compliant. The following checks are NOT enforced by FTP_BASIC, and
are enforced by the FTP protocol type:
332
•
That every packet is terminated with a newline character, so that the PORT
command is not split across packets. This protects against the FTP Bounce
attack.
•
Data connections to or from well-known ports are not allowed, to prevent the
FTP data connection being used to access some other service.
•
Bidirectional traffic on the data connection is not allowed, as it can be used
improperly.
Domain_UDP Service
Domain_UDP Service
The Domain_UDP service provides access control for DNS.
•
DNS performance when using this service has been improved. Many DNS
connections are for queries which comprise one request and one reply packet.
VPN-1 Power normally maintains virtual DNS connections for the period of the
UDP timeout. DNS verification speed can be improved by telling VPN-1 Power
to delete the connection as soon as it receives the reply packet. To do this,
change the property delete_on_reply (false) to true using the Database Tool.
•
DNS logs are more informative. For example, the domain of the device making
a DNS query is now shown in the Information column.
•
DNS verification of EDNS queries is supported. This allows use of BIND. EDNS
headers are allowed if they contain all zeros, other than the field that controls
the packet length (maximum payload size).
Chapter 13
Services with Application Intelligence 333
Point-to-Point Tunneling Protocol (PPTP)
Point-to-Point Tunneling Protocol (PPTP)
Point-to-Point Tunneling Protocol (PPTP) is a network protocol for creating Virtual
Private Networks (VPNs) over the Internet. It was developed jointly by Microsoft
Corporation and several remote access vendor companies.
PPTP sets up secure client to client connection via a PPTP server. The connection
is made up of TCP/PPTP control connections and the GRE data connections, GRE
being the actual VPN tunnel.
VPN-1 Power secures PPTP while allowing Hide NAT as well as Static NAT for PPTP
connections. VPN-1 Power can also enforce compliance to the PPTP protocol. If
enforcement is turned on, PPTP packets are checked for compliance with RFC
2637, including message type, and packet length. Also, if the PPTP control
connection closes, the GRE tunnel is also closed.
Configuration for PPTP
1. Define an object for the PPTP client that originates the connection, and an
object for the PPTP server (not the destination client).
2. To allow PPTP connections through the VPN-1 Power Gateway you must define
a PPTP rule in the Security Rule Base using the pptp_tcp service. In the
service column use either the pptp_tcp or Any (by default the pptp_tcp Service
object is set to Match for Any in the Advanced Service Properties).
Table 13-1
Source
Destination
Service
Action
pptp_client
pptp_server
TCP: pptp_tcp
Accept
3. To enforce compliance to the PPTP protocol and allow Hide NAT, turn on
enforcement in SmartDefense Application Intelligence > VPN Protocols > Point to
Point Tunneling Protocol. Static NAT is supported even with the enforcement
turned off. SmartDefense enforcement is turned on by default for new
installations. For upgrades it is turned off.
334
Point-to-Point Tunneling Protocol (PPTP)
4. For enforcement modules of version NG with Application Intelligence (R55) or
lower, or if enforcement is turned off, an additional rule is needed to allow the
GRE tunnel:
Table 13-2
Source
Destination
Service
Action
pptp_client
pptp_server
pptp_client
pptp_server
??:GRE
Accept
Advanced Configuration
It is possible to configure strict enforcement of the PPTP protocol using the
pptp_strict_enforcement database property. However, this may cause connectivity
problems because many PPTP applications do not rigorously conform to RFC 2637.
Using the GUIdbedit database tool, go to: Table > Managed Objects > asm >
AdvancedSecurityObject. Open this object, look for the line containing
pptp_strict_enforcement in the value column, and change the value from the false
(the default) to true.
Chapter 13
Services with Application Intelligence 335
Blocking Visitor Mode (TCPT)
Blocking Visitor Mode (TCPT)
Introduction to TCPT
Visitor Mode and the TCP tunneling protocol (TCPT) were developed by Check Point
to allow SecureClient connections from behind any gateway device with a restrictive
outgoing Security Policy. An example of such as Security Policy is one that allows
only HTTP and HTTPS (SSL) outgoing traffic, and prevents the various protocols
(such as IKE) required for the secure connections.
Why Block Visitor Mode and Outgoing TCPT?
The VPN-1 Power administrator can decide to block Visitor Mode by implementing
a very restrictive outgoing Security Policy that allows ordinary HTTPS connections
and disallows TCPT connections passing on the same port.
Visitor Mode and Incoming TCPT are allowed via the Gateway object. See the
Advanced Configuration chapter of the VPN-1 Power guide for details.
How VPN-1 Power identifies TCPT
VPN-1 Power performs content inspection in order to identify TCPT packets and
reject them if necessary. It does not merely check the port.
The default port used by TCPT is 443, which is the same port used by SSL. This
can be changed. (See “How to change the port used to block outgoing TCPT” on
page 337.)
When to Block Outgoing TCPT
Only block TCPT if there is a rule that allows the port used by TCPT, for example,
port 443. If there is no rule that allows the port used by TCPT, then it will be
implicitly blocked, and there is no need explicitly block it.
There are a number of services that perform content inspection, rather than merely
checking port numbers. If you block outgoing TCPT, and there is a rule that allows
a service that uses the same port as TCPT, and that service performs content
inspection, then both TCPT and that service will be blocked. The exception is the
SSLv3 service. A rule that allows SSLv3, permits only SSL version 3 connections,
and rejects TCPT.
336
Blocking Visitor Mode (TCPT)
Services that do content inspection are those that have a defined Protocol Type in
the TCP Service Properties>Advanced window.
Configuration of Visitor Mode Blocking
How to Block Visitor Mode (Blocking Outgoing TCPT)
To block outgoing TCPT, use the Database Tool on the SmartCenter Server, and
locate, and change the following property for every VPN-1 Power enforcement
module for which you wish to block outgoing TCPT:
disable_outgoing_tcpt (false)
Change the value of the property to true.
How to change the port used to block outgoing TCPT
To change the port used to block TCPT, use the Database Tool and locate the
following global property on the SmartCenter Server:
tcpt_outgoing_port (443)
Change the value of the property to the required port number.
Chapter 13
Services with Application Intelligence 337
Blocking Visitor Mode (TCPT)
338
Web Security
This section describes the VPN-1 Power Web Content capabilities, and the Web
Intelligence add-on for VPN-1 Power that provides high performance attack
protection for web servers and applications.
Chapter
Web Intelligence
14
In This Chapter
The Need for Web Attack Protection
page 342
The Web Intelligence Solution for Web Attack Protection
page 343
Web Intelligence Technologies
page 344
Web Intelligence Online Updates
page 345
Web Intelligence Security and Usability
page 346
Web Intelligence Protections
page 351
Web Content Protections
page 352
Understanding HTTP Sessions, Connections and URLs
page 353
Connectivity Versus Security Considerations
page 356
Web Security Performance Considerations
page 358
Backward Compatibility Options for HTTP Protocol Inspection
page 360
Web Intelligence License Enforcement
page 361
341
The Need for Web Attack Protection
The Need for Web Attack Protection
Web servers and web applications have evolved from their origins as serving simple
static content. Today, web servers and applications can create dynamic pages,
invoke applications, and communicate with databases to produce useful content for
users. With most web server platforms bundling applications with the server, even
the simplest web sites interact with web applications.
Figure 14-1 Multiple Security Vulnerabilities in the N-Tier Web Architecture
With almost all organizations allowing web traffic (TCP port 80) through their
perimeter firewall, hackers are increasingly focusing their attacks on web servers
and applications. Many attacks today exploit security weaknesses in the different
layers of the modern web architecture, often termed as the N-tier web architecture.
These attacks range from defacing the primary web interface, getting an embedded
web application on a server to do unintended functions, installing malicious
applications, to tricking the backend database to send information back to the user.
Similar to network security, web security is only as strong as the weakest link. To
build secure web applications, web developers must design security in every aspect
of the web application. Unfortunately, many enterprise web applications were not
designed with holistic security in mind. Worse, an organization may only design
web security into only some of the web servers that are made accessible to the
outside world.
342
The Web Intelligence Solution for Web Attack Protection
The Web Intelligence Solution for Web
Attack Protection
Check Point Web Intelligence enables customers to configure, enforce and update
attack protections for web servers and applications. Web Intelligence protections
are designed specifically for web-based attacks, and complement the network and
application level protections offered by SmartDefense. In addition, Web Intelligence
Advisories published online by Check Point provide information and add new attack
defenses.
Web Intelligence not only protects against a range of known attacks, varying from
attacks on the web server itself to databases used by web applications, but also
incorporates intelligent security technologies that protect against entire categories
of emerging, or unknown, attacks.
Unlike web firewalls and traditional intrusion protection systems, Web Intelligence
provides proactive attack protections. It ensures that communications between
clients and web servers comply with published standards and security best
practices, restricts hackers from executing irrelevant system commands, and
inspects traffic passing to web servers to ensure that they don't contain dangerous
malicious code. Web Intelligence allows organizations to permit access to their web
servers and applications without sacrificing either security or performance.
Chapter 14
Web Intelligence 343
Web Intelligence Technologies
Web Intelligence Technologies
Web Intelligence is based on Check Point's Stateful Inspection, Application
Intelligence, and Malicious Code Protector technologies, so that it is possible to
block not only specific attacks, but also entire categories of attacks, while allowing
legitimate traffic to pass.
344
•
Malicious Code Protector is a Check Point patent-pending technology that blocks
hackers from sending malicious code to target web servers and applications. It
can detect malicious executable code within web communications by
identifying not only the existence of executable code in a data stream but its
potential for malicious behavior. Malicious Code Protector is a kernel-based
protection delivering almost wire-speed performance.
•
Application Intelligence is a set of technologies that detect and prevent
application-level attacks by integrating a deeper understanding of application
behavior into network security defenses.
•
Stateful Inspection analyzes information flow into and out of a network so that
real-time security decisions can be based on communication session
information as well as on application information. It accomplishes this by
tracking the state and context of all communications traversing the firewall
gateway, even when the connection involves complex protocols.
Web Intelligence Online Updates
Web Intelligence Online Updates
Web intelligence is an add-on for VPN-1 Power. Customers who purchase the
SmartDefense Subscription service can automatically update both SmartDefense
and Web Intelligence with a single click. Updates are released frequently, and are
obtained from the Check Point SmartDefense site:
http://www.checkpoint.com/techsupport/documentation/smartdefense/index.html
Customers with a valid subscription license also receive special SmartDefense
Advisories that provide updated SmartDefense and Web Intelligence attack
protections, as well as information, tools and best practice methods to mitigate
different attacks.
Tip - It is recommended to keep your gateway version up-to-date, as the newest defenses are
incorporated into the latest version of Check Point software.
Chapter 14
Web Intelligence 345
Web Intelligence Security and Usability
Web Intelligence Security and Usability
Web Intelligence provides a number of Security and Usability enhancements that
make it a very effective tool for configuring, enforcing and updating attack
protections for web servers and applications.
In This Section
Web Server Focused Security
page 346
Enforcement Granularity
page 346
Configuration Flexibility
page 347
Variable Security Levels
page 348
Monitor-Only Mode
page 348
Customizable Error Page
page 349
Web Server Focused Security
Web Intelligence focuses on protecting web servers against attacks. As such, web
server objects are defined, and protections are applied either to all web servers, or
to selected web servers. Any gateway or host object can be defined as a web server.
Enforcement Granularity
It is possible to vary the scope of the protection. A protection can be applied to
selected web servers, or to all web servers.
Figure 14-2 Protection Scope and Action Settings
346
Web Intelligence Security and Usability
Configuration Flexibility
The Web Server View page in SmartDashboard gives a convenient global view of
every Web Intelligence protection. The configuration state of every protection on
every web server can be viewed and changed.
Protections can be also be enabled/disabled from the individual protection page in
Web Intelligence, and via the web server object. The protections can be applied via
the web server object if the protection scope in Web Intelligence is set to apply to
specific web servers.
Figure 14-3 The Web Intelligence Web Server View, and the Web Server object.
Chapter 14
Web Intelligence 347
Web Intelligence Security and Usability
Variable Security Levels
To provide good protection with a minimum number of false positives, a number of
advanced defenses (Malicious Code Protector, Cross Site Scripting, SQL Injection
and Command Injection) have three possible security levels. By moving a slider,
you can choose the appropriate trade-off between a high detection rate on the one
hand and a lowest possible level of false positives on the other.
Figure 14-4 Variable protection level slider
Monitor-Only Mode
All Web Intelligence protections have a monitor-only option, which detects and
tracks unauthorized traffic without blocking it (see Figure 14-2). Intrusions are
logged in SmartView Tracker.
The monitor-only option is helpful when deploying a Web Intelligence protection for
the first time, to evaluate the effectiveness of the protection without interrupting
connectivity. Monitor-only mode also makes it possible to have an audit-only
deployment.
Special Monitor-Only Mode
When all active Web Intelligence protections are in monitor-only mode, connections
that contain non-HTTP compliant data will not be rejected. In this special mode,
Web Intelligence does not affect traffic at all. In contrast, when only some of the
active protections are in monitor mode-only, non-HTTP compliant traffic will be
rejected.
This special operating mode is especially helpful when deploying Web Intelligence
for the first time, to evaluate its effectiveness without interrupting connectivity, or
when troubleshooting a problem that is related to Web Intelligence blocking traffic.
348
Web Intelligence Security and Usability
Monitor-Only Per Web Server
All protections on a particular web server can be set to monitor-only. This makes it
possible to put a new web server in place and investigate which protections it
needs, while ensuring that connectivity is maintained.
To configure monitor-only per web server, use the Check Point Database Tool
(GUIdbedit, located in the SmartConsole installation directory). Using GuiDBedit,
search for the web server name, and then look for the field
web_server_monitor_only and set it to TRUE.
Customizable Error Page
Many Web Intelligence protections give the administrator the ability to define an
error page that can be sent back to the user whose browsing was blocked (see
Figure 14-5). This page (in conjunction with SmartView Tracker) can be used to
pinpoint the exact reason that caused the connection to be closed.
Figure 14-5 HTML Error Page Configuration
Chapter 14
Web Intelligence 349
Web Intelligence Security and Usability
This makes it possible to quickly nail down and eliminate the attack, before it can
spread. The security administrator can fix the problem even before users know
about it, or if the users notice the problem first, they can call the Help Desk about
it. Alternatively, users can be given information in the web page about how to fix
the problem themselves, which is of great benefit to overworked support staff.
The administrator can customize the page with text and a logo. To help pinpoint the
reason that caused the connection to be closed, the page shows two IDs: a Reject
ID and an Error ID.
Note - Activating the Error Page decreases performance for Web traffic to which this
feature is applied.
Reject ID
The Reject ID that appears on the Error page is intended to deliver information to
the administrator without exposing it to a potential attacker.
The Reject ID is unique for each rejected connection. The Reject ID also appears
in the SmartView Tracker, and allows the administrator to correlate between an
error and a log record of a specific connection. The log record contains attack
information, such as “Cross site scripting detected”.
Error Description ID
The Error description ID is a standard ID that is used to identify the attack. It
appears in the SmartView Tracker log, and corresponds to a SecureKnowledge
solution about the attack. For example, the following could appear in the
Information column of the SmartView Tracker log: “WSE0030002 cross site
scripting detected in request”. The WSE0030002 is the Error description ID, and
a SecureKnowledge search for that ID will locate information about the attack.
The administrator can choose whether or not to display the Error Description ID on
the error page. It is not recommended to display it because the information could
be misused by an attacker.
350
Web Intelligence Protections
Web Intelligence Protections
Web Intelligence protections are organized into a number of protection classes.
Note - Details about individual protections can be found in the Web Intelligence GUI, and
in the online help.
Table 14-1 Web Intelligence Protection Classes
Protection Class
Explanation
Malicious Code
These protections allow you to prevent attacks that run
malicious code on Web Servers (or clients).
Application Layer
This class of protections prevents hackers from introducing
text, tags, commands, or other characters that a web
application will interpret as special instructions.
Introducing them in forms or URLs can allow a hacker to
steal private data, redirect a communication session to a
malicious web site, steal information from a database, gain
unauthorized access, or execute restricted commands.
Information Disclosure
These protections prevent an attacker gathering information
about a web site. The goal of the attacker is to get the web
server to reveal information that can be used to tailor an
attack.
HTTP Protocol
Inspection
HTTP Protocol Inspection provides strict enforcement of
the HTTP protocol, ensuring these sessions comply with
RFC standards and common security practices.
Web Intelligence and ClusterXL Gateway Clusters
Web Intelligence features on a ClusterXL gateway cluster do not survive failover.
This means that if ClusterXL is providing Web Intelligence protections, and a
cluster member fails, HTTP connections through the failed member are lost.
Chapter 14
Web Intelligence 351
Web Content Protections
Web Content Protections
VPN-1 Power provides Web Content Security via its OPSEC partners. This allows
URL filtering and Network Virus Protection using Check Point best-of-breed
partners. For details, see “CVP and UFP Content Security” on page 301.
VPN-1 Power also provides a number of integrated web security capabilities that
are configured via the Security Rule Base. These include a number of URL-based
protections, and the ability to secure XML Web Services (SOAP) on Web Servers.
For details, see Chapter 15, “Web Content Protection”.
352
Understanding HTTP Sessions, Connections and URLs
Understanding HTTP Sessions, Connections
and URLs
To understand how to best use VPN-1 Power web security and Web Intelligence
protections, it is important to understand some basic terms and concepts regarding
HTTP sessions, HTTP connections, and URLs.
An HTTP session is made up of an HTTP request and an HTTP response. In other
words:
HTTP Session = HTTP Request + HTTP Response
Both the HTTP request and the HTTP response have a header section and a body
section.
HTTP Request Example
Header section
The URL is marked in bold for clarity.
GET http://www.site.com/path/file.html?param1=val1&param2=value2 HTTP/1.1
Host: www.site.com
Range: 1000-2000
Cookie: cookiename=A172653987651987361BDEF
Chapter 14
Web Intelligence 353
Understanding HTTP Sessions, Connections and URLs
Body section
<Some content (usually a filled form which will be submitted)>
HTTP Response Example
Header section
HTTP 200 OK
Content-Encoding: gzip
Content-Type: text/html
Transfer-encoding: chunked
Content-Disposition: http://alternative.url.com
Body section
<Some content (usually an HTML page or a binary file)>
HTTP Connections
HTTP/1.1 encourages the transmission of multiple requests over a single TCP
connection. Each request must still be sent in one contiguous message, and a
server must send responses (on a given connection) in the order that it received the
corresponding requests.
The following is an example of an HTTP request connection:
Request # 1
Header section
Post /Hello/ HTTP/1.1
Host: www.walla.co.il
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT5.0)
Pragma: no-cache
Content-length: 20
Connection: Keep-alive
Request #1 Body
This my example body
Request # 2
Header section
Get /scripts/ HTTP/1.1
Host: www.walla.co.il
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT5.0)
Pragma: no-cache
Content-length: 0
Connection: Keep-alive
354
Understanding HTTP Sessions, Connections and URLs
Understanding URLs
A URL is made up of the Host, Path and Query parameters. In the URL in
Figure 14-6, the Host is http://www.elvis.com, the Path is /alive/qc.html, and the
Query is everything else. VPN-1 Power and Web intelligence can filter the URL on
these parameters and decide whether to allow the HTTP request containing a
particular URL.
Figure 14-6Example URL showing Host, Path and Query components
Chapter 14
Web Intelligence 355
Connectivity Versus Security Considerations
Connectivity Versus Security
Considerations
Web Intelligence can be tuned for greater web server security at the expense of
connectivity, or vice versa.
Monitor-Only Mode
All Web Intelligence protections have a monitor-only mode which makes it possible
to evaluate how the protection will affect connectivity, by examining logs to spot
traffic that Web Intelligence has detected as being dangerous. All this, while
allowing uninterrupted traffic flow.
Protection for Specific Servers
All Web Intelligence defenses can be activated for specific web servers. If the
protection is problematic on a particular web server, it can be turned off for that
specific web server.
Variable Security Levels
Some of the advanced defenses (Cross Site Scripting, Command Injection, SQL
injection and Malicious Code Protector) have variable security level settings. If a
connectivity problem arises on a specific web server the security level can be
lowered for that web server.
Connectivity Implications of Specific Protections
HTTP protocol inspection settings that are too severe can affect connectivity to and
from valid web servers.
356
•
HTTP Format sizes protection restricts URL lengths, header lengths or the
number of headers. This is good practice because these elements can be used
to perform a Denial of Service attack on a web server. However, These
restrictions can potentially block valid sites. Applying the protection for specific
web servers can solve the connectivity problems.
•
ASCII only Request Header protection can block connectivity to web pages that
have non-ASCII characters in URLs. Applying the protection for specific web
servers can solve the connectivity problems.
Connectivity Versus Security Considerations
•
HTTP methods - Some standard and non-standard HTTP methods are unsafe,
because they can be used to exploit vulnerabilities on a web server. Microsoft
WebDAV methods (used for Outlook Express access to Hotmail), for example,
have certain security issues, but blocking them can prevent use of important
applications. Applying the protection for specific web servers can solve the
connectivity problems.
Chapter 14
Web Intelligence 357
Web Security Performance Considerations
Web Security Performance Considerations
In This Section
Protections Implemented in the Kernel Vs. Security Server
page 358
Protections with a Higher Performance Overhead
page 359
Adjusting the Number of Allowed Concurrent HTTP Connections page 359
Protections Implemented in the Kernel Vs. Security
Server
Web Intelligence provides a wide range of security features for web servers. All Web
Intelligence features are implemented in the kernel Inspection Module, which
means that users benefit from very high performance.
VPN-1 Power provides a number of web security capabilities that do not require the
Web Intelligence add-on. These capabilities make use of the HTTP Security Server.
The performance provided by the HTTP Security Server is not as high as that
provided by the kernel. These capabilities are available by defining a URI Resource
and using it the Security Rule Base. They are listed in Table 14-2.
Table 14-2 Web security capabilities that do not require the Web Intelligence Add-On
358
Web security capability
See
Integration with CVP servers for
Anti-Virus protection.
“CVP Servers for Anti-Virus and
Malicious Content Protection” on
page 306.
URL filtering (via a UFP server) with
enhanced security checks.
“Using URL Filtering (UFP) to Limit
Web Surfers” on page 309
Blocking URL-based attacks by source
and destination
“Filtering URLs, Schemes and
Methods by Source and Destination”
on page 365.
Integrated URL filtering of a limited
list of sites.
“Basic URL Filtering” on page 366
Web Security Performance Considerations
Table 14-2 Web security capabilities that do not require the Web Intelligence Add-On
Web security capability
See
HTML weeding: Stripping script tags,
Applet tags, ActiveX, FTP links and
port Strings.
“Java and ActiveX Security” on
page 367.
HTTP Response scanning: Blocking
Java Code.
“Java and ActiveX Security” on
page 367
Securing XML Web Services (SOAP).
“Securing XML Web Services (SOAP)”
on page 368.
Protections with a Higher Performance Overhead
Web Intelligence default protections are optimized to blend high security and
performance.
Activating the following features decreases performance for Web traffic to which
these features are applied:
•
Custom HTML error pages.
•
Header Spoofing, where headers are rewritten.
•
ASCII Only Response Headers, where the HTTP response is inspected.
Adjusting the Number of Allowed Concurrent HTTP
Connections
It is possible to adjust the resources available for HTTP connections on the VPN-1
Power gateway. If traffic volume is greater then 1000 concurrent connections, you
can increase the allowed maximum number of concurrent HTTP connections.
Conversely, if there is a problem installing the Security Policy due to a lack of
memory, you can decrease the allowed maximum number of concurrent
connections.
From the SmartDashboard main menu, select Policy> Global Properties, and then
SmartDashboard Customization > Configure. In the Advanced Configuration window,
select FireWall-1 > Web Security > Tuning. Adjust the value of the parameter
http_max_concurrent_connections. The default value is 1000.
Chapter 14
Web Intelligence 359
Backward Compatibility Options for HTTP Protocol Inspection
Backward Compatibility Options for HTTP
Protocol Inspection
Web Intelligence performs high performance kernel-level inspection of all
connections passing through enforcement modules of version NG with Application
Intelligence (R55W) or higher.
On enforcement modules of lower version, there is a choice. In Web Intelligence,
under HTTP Protocol Inspection, it is possible to choose whether to perform HTTP
protocol inspection using the kernel for optimized performance, or using the HTTP
Security Server for strict protocol enforcement. The three options are:
1. Configurations apply to all connections: Perform optimized protocol enforcement
The following HTTP protocol inspection options are enforced by the kernel on
all connections (if active): HTTP Format sizes, ASCII Only Request, Header
Rejection, and General HTTP Worm Catcher. Note that in this option, the ASCII
Only Response Headers protection is not performed. If a connection matches a
rule in the Rule Base that activates the Security Server, the Security Server
performs these options (if activated).
2. Configurations apply to all connections: Perform strict protocol enforcement
The HTTP protocol inspection options are enforced by the Security Server.
3. Configurations apply only to connections related to resources used in the Rule Base
For connections related to resources used in the Rule Base, the HTTP protocol
inspection options are enforced by the Security Server. For all other
connections, the options are not enforced.
360
Web Intelligence License Enforcement
Web Intelligence License Enforcement
A gateway or gateway cluster requires a Web Intelligence license if it enforces one
or more of the following protections:
•
Malicious Code Protector
•
LDAP Injection
•
SQL Injection
•
Command Injection
•
Directory Listing
•
Error Concealment
•
ASCII Only Request
•
Header Rejection
•
HTTP Methods
The actual license required depends on the number of Web servers protected by the
gateway or gateway cluster. The available licenses are shown in Table 14-3.
Table 14-3 Web Intelligence Licenses
Maximum Number
of Web Servers
SKU for Gateways
SKU for Gateway
Clusters
3
CPMP-WIT-3-NGX
CPMP-HWIT-3-NGX
10
CPMP-WIT-10-NGX
CPMP-HWIT-10-NGX
Unlimited
CPMP-WIT-U-NGX
CPMP-HWIT-U-NGX
For gateway clusters, a single regular gateway license is required for any one of the
cluster members, and a cluster license for each of the other cluster members.
For R60 and higher versions, the correct licensing is enforced by counting the
number of Web Servers that are protected by each Gateway. This number is
calculated using the setting in the Protected by field of the Web Server page of the
Web Server object. If *All is specified, the number of counted Web servers is
incremented for all gateways that enforce Web Intelligence features.
For version R60 and higher versions, if the correct license is not installed, it is not
possible to Install a Policy on any gateway. When upgrading, be aware of this
change of behavior.
Chapter 14
Web Intelligence 361
Web Intelligence License Enforcement
Web Intelligence licenses are installed on and attached to the SmartCenter Server.
The SmartCenter Server allocates licenses to gateways in an optimal way. For
example, if three gateways A, B, and C, protect 3, 7, and 35 Web servers
respectively, and the SmartCenter Server has three licenses: one for 3 Web servers,
one for 10 and a third for an unlimited number. The licenses are allocated as in
Table 14-4.
Table 14-4 Example Web Intelligence License Allocation
Gateway
Number of protected
Web Servers
Allocated license
A
3
CPMP-WIT-3-NG
B
7
CPMP-WIT-10-NG
C
35
CPMP-WIT-U-NG
Licenses cannot be accumulated. For example, if a gateway protects six Web
servers, the gateway requires one CPMP-WIT-10-NG license. It is not possible to
use two CPMP-WIT-3-NG licenses.
362
Chapter
Web Content Protection
15
In This Chapter
Introduction to Web Content Protection
page 364
Web Content Security via the Security Rule Base
page 365
Securing XML Web Services (SOAP)
page 368
Understanding HTTP Sessions, Connections and URLs
page 369
Connectivity Versus Security Considerations for Web Surfers
page 372
Factors that Affect HTTP Security Server Performance
page 374
Configuring Web Content Protection
page 376
363
Introduction to Web Content Protection
Introduction to Web Content Protection
This chapter discusses the following Web Security capabilities of VPN-1 Power:
•
Integrated web security capabilities that are configured via the Security Rule
Base. These include a number of URL-based protections.
•
The ability to secure XML Web Services (SOAP) on Web Servers.
Web Intelligence is an add-on for VPN-1 Power that provides high performance
attack protection for web servers and applications. It provides proactive attack
protection by looking for malicious code and ensuring adherence to protocols and
security best practice. For details about Web Intelligence, see “Web Intelligence”
on page 341.
Web Content Security via OPSEC partners allows network virus protection and URL
filtering using best-of-breed Check Point partners. For details, see “CVP and UFP
Content Security” on page 301.
364
Web Content Security via the Security Rule Base
Web Content Security via the Security Rule
Base
In This Section
What is a URI Resource?
page 365
Filtering URLs, Schemes and Methods by Source and Destination page 365
Basic URL Filtering
page 366
URL Logging
page 366
Java and ActiveX Security
page 367
VPN-1 Power provides some web security capabilities that are configured via the
Security Rule Base, rather than using Web Intelligence. These include a number of
URL-based protections.
What is a URI Resource?
Web security via the Security Rule Base is implemented by defining a
SmartDashboard object called a URI Resource, and using it in the Security Rule
Base. Resource objects are explained in “Resources: What They Are and How to
Use Them” on page 313.
URI stands for Uniform Resource Identifier. A URI is more-or-less identical to the
familiar URL (Uniform Resource Locator).
Filtering URLs, Schemes and Methods by Source
and Destination
It is possible to block URL based attacks such as Code Red and Nimda using a URI
resource. Attacks from and to a specified source and destination can be blocked.
HTTP methods (such as GET and POST) and schemes (such as http, ftp, and
mailto) can also be blocked.
URL patterns are specified using regular expressions. The URL can be broken into
filterable components using the Host, Path and Query parameters that are specified
in the Match tab.
For configuration details, see “Blocking URL-based Attacks using a URI Resource”
on page 376.
Chapter 15
Web Content Protection 365
Web Content Security via the Security Rule Base
Basic URL Filtering
Basic URL Filtering capability is integrated into VPN-1 Power. Use this capability
to restrict user access to as many as 50 URLs, without having to define a separate
resource for each URL.
This method is not recommended for large URL lists, because the list of banned
sites must be defined in a file, and then manually edited and maintained, which is
difficult for a large list of banned sites.
For configuration details, see “Configuring Basic URL Filtering” on page 378.
More comprehensive URL Filtering is available using third party OPSEC-certified
applications (see “Using URL Filtering (UFP) to Limit Web Surfers” on page 309).
URL Logging
Normally, a logged connection shows the source or destination Web server and
domain (for example http://foo.bar.com).
It is possible to generate extra URL logging information by performing kernel
inspection on the HTTP connection, rather than using a URI Resource, which gives
a less detailed log. This shows in the log the full path and query of the requested
URL, not just the name of the Web server (e.g.
http://foo.bar.com/products/servlet/Satellite?pagename=1234). Do this by defining
a URI resource and selecting Optimize URL Logging.
For configuration details about logging URLs, either by performing kernel
inspection on the HTTP connection, or using a URI Resource, see “Configuring
URL Logging” on page 377.
366
Web Content Security via the Security Rule Base
Java and ActiveX Security
VPN-1 Power is able to protect web surfers by controlling incoming Java and
ActiveX code according to specific conditions, such as host, URL, or authenticated
user name.
Capabilities of Java and ActiveX screening include the following:
•
Stripping ActiveX tags from HTML pages.
•
Stripping Java applet tags from HTML pages.
•
Blocking Java attacks by blocking suspicious back connections.
More comprehensive scanning of Java, ActiveX and other executables can be
accomplished with content security applications from OPSEC certified vendors.
To screen for Java and ActiveX, you need to define a URI resource and add it to a
Security Rule Base rule. See “Creating a Resource and Using it in the Rule Base”
on page 314.
Chapter 15
Web Content Protection 367
Securing XML Web Services (SOAP)
Securing XML Web Services (SOAP)
VPN-1 Power provides some web security capabilities that are configured via the
Security Rule Base, rather than using Web Intelligence. These include the securing
of XML Web Services (SOAP).
XML Web services (using XML Schema and SOAP) allow program-to-program
communication, and represent an important new way of communicating using
Internet protocols and standards. This is in contrast to Web pages (using HTML and
DHTML), which can be used for person-to-program communication, and email and
Instant Messaging (using protocols such as SMTP and MIME) which are for
person-to-person communication.
The Simple Object Access Protocol (SOAP) provides a way for applications to
communicate with each other over the Internet, independent of platform. SOAP
relies on XML to define the format of the information and then adds the necessary
HTTP headers to send it.
XML passes information using commands called Methods that are intended to run
on the destination computer.
VPN-1 Power uses a Security Server to prevent potential attacks by verifying that
the HTTP, XML, SOAP methods in SOAP requests conform to the RFC. VPN-1
Power also checks that only a predefined list of acceptable methods is being
passed in the SOAP packet.
The way that VPN-1 Power treats SOAP packets is defined in a URI resource that
uses HTTP. The URI specifies whether a SOAP packet passing though the
enforcement point will always be accepted, or only the Methods specified in a
predefined file will be accepted.
The SOAP processing defined in the URI resource is performed only if the HTTP
connection carrying the SOAP message was already accepted by the rule in which
the URI resource is used. In other words, the connection must match the rule, and
the rule Action cannot be Reject or Drop.
For configuration details, see the online help in the URI Resource Properties —
SOAP tab.
368
Understanding HTTP Sessions, Connections and URLs
Understanding HTTP Sessions, Connections
and URLs
To understand how to best use VPN-1 Power web security and Web Intelligence
protections, it is important to understand some basic terms and concepts regarding
HTTP sessions, HTTP connections, and URLs.
An HTTP session is made up of an HTTP request and an HTTP response. In other
words:
HTTP Session = HTTP Request + HTTP Response
Both the HTTP request and the HTTP response have a header section and a body
section.
HTTP Request Example
Header section
The URL is marked in bold for clarity.
GET http://www.site.com/path/file.html?param1=val1&param2=value2 HTTP/1.1
Host: www.site.com
Range: 1000-2000
Cookie: cookiename=A172653987651987361BDEF
Chapter 15
Web Content Protection 369
Understanding HTTP Sessions, Connections and URLs
Body section
<Some content (usually a filled form which will be submitted)>
HTTP Response Example
Header section
HTTP 200 OK
Content-Encoding: gzip
Content-Type: text/html
Transfer-encoding: chunked
Content-Disposition: http://alternative.url.com
Body section
<Some content (usually an HTML page or a binary file)>
HTTP Connections
HTTP/1.1 encourages the transmission of multiple requests over a single TCP
connection. Each request must still be sent in one contiguous message, and a
server must send responses (on a given connection) in the order that it received the
corresponding requests.
The following is an example of an HTTP request connection:
Request # 1
Header section
Post /Hello/ HTTP/1.1
Host: www.walla.co.il
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT5.0)
Pragma: no-cache
Content-length: 20
Connection: Keep-alive
Request #1 Body
This my example body
Request # 2
Header section
Get /scripts/ HTTP/1.1
Host: www.walla.co.il
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT5.0)
Pragma: no-cache
Content-length: 0
Connection: Keep-alive
370
Understanding HTTP Sessions, Connections and URLs
Understanding URLs
A URL is made up of the Host, Path and Query parameters. In the URL in
Figure 15-1, the Host is http://www.elvis.com, the Path is /alive/qc.html, and the
Query is everything else. VPN-1 Power and Web intelligence can filter the URL on
these parameters and decide whether to allow the HTTP request containing a
particular URL.
Figure 15-1Example URL showing Host, Path and Query components
Chapter 15
Web Content Protection 371
Connectivity Versus Security Considerations for Web Surfers
Connectivity Versus Security
Considerations for Web Surfers
To tune connectivity versus security for web surfers, you need to adjust certain
database properties.
Allowing or Restricting Content
The Content Disposition Header
The Content-Disposition header in the HTTP Response header suggests to the
client a location where the client should save content (such as a file) carried in the
HTTP response. This location can potentially point to a crucial OS file on the
client. Some clients may take up this suggestion without question and save the
content to that location.
By default, the Content-Disposition header is not allowed. To allow it, from the
SmartDashboard main menu, select Policy> Global Properties, and then
SmartDashboard Customization > Configure. In the Advanced Configuration window,
select FireWall-1 > Web Security > Security. To allow the Content-Disposition header,
check http_allow_content_disposition.
Partial Range Requests
Partial range requests allow the content in an HTTP response to be split over more
than one response. However, content security checks are only completely effective
if the responses are not split in this way.
Adobe Acrobat® uses HTTP ranges to allow pages of Acrobat PDF files to be viewed
as soon as they are downloaded. Not allowing ranges means that the whole file
must be downloaded before it can be viewed. Some download managers also use
HTTP ranges.
Range requests in HTTP requests, and range responses in HTTP responses are not
allowed by default. To allow ranges, from the SmartDashboard main menu, select
Policy> Global Properties, and then SmartDashboard Customization > Configure. In the
Advanced Configuration window, select FireWall-1 > Web Security > Security > Content
Security. To allow range request, check http_allow_ranges.
372
Connectivity Versus Security Considerations for Web Surfers
Content Compression
Compressing content in HTTP responses is a way of increasing the speed of the
connection. However, content security checks such as HTML weeding and CVP
checking cannot be performed on compressed content.
The Content-Encoding and Content-Type headers in the HTTP response indicate
whether or not the content is compressed, for example: Content-Encoding: gzip,
Content-Type: application/gzip.
The http_disable_content_enc and http_disable_content_type database
properties control whether or not to allow data in the HTTP response to be
compressed. If these properties are false (the default value), compression of
content in an HTTP response is not allowed. Both these properties can be either
true or false. One may be true when the other is false. Each one affects it own
header.
These properties only affect content on which one or more of the following content
security checks are performed: HTML weeding, blocking Java code, CVP, SOAP.
To change the value of this property, in SmartDashboard, edit the Global Properties
in the SmartDashboard Customization > Advanced Configuration page, under Web
Security.
Chapter 15
Web Content Protection 373
Factors that Affect HTTP Security Server Performance
Factors that Affect HTTP Security Server
Performance
On multiple CPU machines, running more than one instance of the HTTP Security
Server increases the performance seen by users. This is because each Security
Server uses a different CPU. Run at least one Security Server instance for each
CPU (see “How To Run Multiple Instances of the HTTP Security Server” on
page 375).
It may well be worthwhile to run more than one Security Server even in a single
CPU machine, in order to allow more concurrent connections. However, this will
increase the memory usage.
The Number of Simultaneous Security Server
Connections
Each Security Server allows up to 1024 file descriptors, which limits the number of
simultaneous connections. In an ordinary connection, packets pass in both
directions through the VPN-1 Power enforcement module, as follows:
1. Web client to VPN-1 Power to web server (request).
2. Web server to VPN-1 Power to web client (response).
512 descriptors are available for use in each direction, so that a total of 512
simultaneous connections are possible.
Where a CVP or UFP server is used, packets in each connection pass through
VPN-1 Power three times:
1. Web client to VPN-1 Power to web server (request).
2. Web server to VPN-1 Power to CVP/UFP server (response).
3. CVP/UFP server to VPN-1 Power to web client (response).
Therefore the available file descriptors are split three ways, so that a total of 341
simultaneous connections are possible.
374
Factors that Affect HTTP Security Server Performance
How To Run Multiple Instances of the HTTP
Security Server
To run multiple instances of the HTTP Security Server:
1. Edit $FWDIR/conf/fwauthd.conf, and include the line
80
in.ahttpd
wait
-2
The last digit on the line is the number of instances of the Security Server. In
this example, there are two instances of the HTTP Security Server.
2. Restart the VPN-1 Power enforcement module (cpstart).
Chapter 15
Web Content Protection 375
Configuring Web Content Protection
Configuring Web Content Protection
In This Section
Blocking URL-based Attacks using a URI Resource
page 376
Configuring URL Logging
page 377
Configuring Basic URL Filtering
page 378
Blocking URL-based Attacks using a URI Resource
All URL-based attacks such as Code Red and Nimda can be blocked using a URI
resource in SmartDashboard. Each resource can block one attack. For background
information, see “Securing XML Web Services (SOAP)” on page 368.
Proceed as follows:
1. Create a new URI Resource, and give it a name (such as Alaska.Web.Protection)
2. In the General tab, select
•
Use this resource to: Enforce URI capabilities
•
Connection Methods: Normally Transparent and Proxy are selected
•
URI Match Specification Type: Wild Cards
3. Specify the URL pattern, using regular expressions in the Match tab. For
example, to block Code Red, use the following values:
•
Host: *
•
Path: \.ida\?
•
Query: *
4. If you wish to specify a replacement URL to redirect the connection if the
pattern is found, specify a Replacement URI in the Action tab.
5. Associate the Resource with the HTTP Service, and place it in a Rule in the
Security Rule Base. See the sample rules shown in Table 15-1.
Table 15-1 Sample URI Resource in a Rule Base
376
No.
Source
Destination
Service
Action
1
Any
Any
http->Alaska.Web.Protection
Drop
2
Any
Any
http
Accept
Configuring Web Content Protection
The Action in Rule 2 is the opposite of the Action in Rule 1. Rule 2 is required
for the Enforce URI Capabilities mode. For the Enhance UFP Performance mode it
is recommended to avoid problems in cases where more than one URI resource
is used in the Rule Base.
Configuring URL Logging
1. Create a URI Resource.
2. Log URL in the connection in one of the following ways:
•
To log the URLs including the URL paths and query, by performing kernel
inspection: In the General tab of the URI Resource Properties window, select
Optimize URL Logging.
•
For basic URL logging using the Security Server: In the General tab of the
URI Resource Properties window, select Enforce URI Capabilities.
The Exception Track option specifies how to track connections that match
this rule but fail the content security checks. An example of an exception is
a connection with an unsupported scheme or method.
3. Place the URI Resource in a rule with the Action Accept.
4. Select Log in the Track column. This logs the URL of all connections that
match this rule.
For background information, see “URL Logging” on page 366.
Chapter 15
Web Content Protection 377
Configuring Web Content Protection
Configuring Basic URL Filtering
To prevent access to selected forbidden Web sites, proceed as follows:
1. Specify a list of forbidden sites in a file that lists the site URIs. The URI
specification file is an ASCII file consisting of a list of lines. Each line has the
format:
ip-address /path category
•
ip-address is the IP address of the Web server to be matched. Host names
can be used, but DNS must be enabled and configured on the VPN-2 Pro
gateway.
•
/path is optional. Use it to restrict a particular directory in a site.
•
category is an optional parameter that can be any Hex number. It is not
currently used.
Make sure there is no white space after the category. The last line in the file
must be blank. For example:
192.168.56.78
/games
192.168.25.58
The file should contain no more than a thousand records.
2. Define a Resource that uses this file.
3. Use this Resource in a Rule, for all HTTP Traffic.
4. Define the Action as Reject.
For background information, see “Basic URL Filtering” on page 366.
378
Appendices
This section describes how the VPN-1 Power machine protects itself and the
networks behind it upon activation, and the command line interface.
Appendix
Security Before
VPN-1 Power Activation
A
In This Appendix
Achieving Security Before VPN-1 Power Activation
page 382
Boot Security
page 383
The Initial Policy
page 386
Default Filter and Initial Policy Configuration
page 389
381
Achieving Security Before VPN-1 Power Activation
Achieving Security Before VPN-1 Power
Activation
There are several scenarios in which a computer does not yet have a VPN-1 Power
Security Policy installed, and is vulnerable. Two features provide security during
these situations: Boot Security, which secures communication during the boot
period, and Initial Policy, which provides security before a Security Policy is
installed for the first time. As an outcome, there is no instant of time when the
computer is left unprotected.
382
Boot Security
Boot Security
During the boot process, there is a short period of time (measured in seconds)
between the point when the computer is capable of receiving communication (and
can be attacked) and the point when the Security Policy is loaded and is enforced.
During this time, VPN-1 Power Boot Security feature protects both the internal
networks behind the VPN-1 Power Gateway, and the computer itself. Boot Security
is provided by two elements working together:
•
Control of IP Forwarding on boot
•
The Default Filter
The Default Filter also provides protection in a scenario where VPN-1 Power
processes are stopped for maintenance.
Control of IP Forwarding on Boot
For networks protected by a VPN-1 Power enforcement module, protection is
available at boot by disabling IP forwarding in the OS kernel. This ensures that
there will never be a time when IP Forwarding is active at a time when no Security
Policy is enforced. This ensures that networks behind the gateway are safe.
Disabling IP Forwarding protects networks behind the VPN-1 Power computer, but
it does not protect the VPN-1 Power computer itself. For this purpose, VPN-1
Power implements a Default Filter during the period of vulnerability.
The Default Filter
The sequence of actions for a VPN-1 Power Gateway when booting with the Default
Filter, is illustrated in Figure A-1:
•
Computer boots up.
•
Boot security takes effect (Default Filter loads and IP Forwarding is disabled).
•
Interfaces are configured.
•
VPN-1 Power services start.
The computer is protected as soon as the Default Filter loads.
Appendix A
Security Before VPN-1 Power Activation 383
Boot Security
Figure A-1
How a Default Filter Protects the VPN-1 Power Gateway computer
There are five Default Filters:
•
General - accepts no inbound communication (this is the default option).
•
Drop Filter - accepts no inbound or outbound communication. This filter drops
all communications into and out of the gateway during a period of vulnerability.
Note, however, that if the boot process requires that the gateway communicate
with other hosts, then the Drop Filter should not be used.
•
Default Filter for IPSO allowing SSH incoming communication to support
remote Administration.
•
Default Filter for IPSO allowing HTTPS incoming communication to support
remote Administration.
•
Default Filter for IPSO allowing SSH and HTTPS incoming communication to
support remote Administration.
The appropriate Default Filter should be selected based on platform and
communication needs. The general filter is selected by default.
The Default Filter also provides anti-spoofing protection for the VPN-1 Power
Gateway. It makes sure that packets whose source are the VPN-1 Power Gateway
computer itself have not come from one of its interfaces.
384
Boot Security
Using the Default Filter for Maintenance
It is possible to stop VPN-1 Power processes for maintenance while at the same
time protecting the VPN-1 Power Gateway and the internal network.
During maintenance, the Default Filter allows open connections to the Gateway to
remain open, without dropping them.
Appendix A
Security Before VPN-1 Power Activation 385
The Initial Policy
The Initial Policy
Until the VPN-1 Power administrator installs the Security Policy on the Gateway for
the first time, security is enforced by an Initial Policy. The Initial Policy operates by
adding “implied rules” to the Default Filter. These rules forbid most of the
communication but allows the communication needed for the installation of the
Security Policy. The Initial Policy also protects a Gateway during Check Point
product upgrades, or when a SIC certificate is reset on the module, or in the case
of a Check Point product license expiration.
Note - During a Check Point upgrade, a SIC certificate reset, or license expiration, the
Initial Policy overwrites the user-defined policy.
The sequence of actions during boot of the VPN-1 Power Gateway computer until a
Security Policy is loaded for the first time, is illustrated in Figure A-2.
386
•
Computer boots up.
•
Default Filter loads and IP Forwarding is disabled.
•
Interfaces are configured.
•
VPN-1 Power services start.
•
Initial policy is Fetched from the Local Module.
•
SmartConsole clients connect or Trust is established, and the Security Policy is
installed.
The Initial Policy
Figure A-2
Initial Policy- Until the First Policy Installation
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 Power module
are on the same computer, the Initial Policy allows CPMI communication only. This
permits SmartConsole clients to connect to the SmartCenter Server.
Appendix A
Security Before VPN-1 Power Activation 387
The Initial Policy
In a distributed configuration, where the Primary SmartCenter Server is on one
computer and the VPN-1 Power module is on a different computer, the Initial
Policy allows the following:
•
Primary SmartCenter Server computer — allows CPMI communication for
SmartConsole clients.
•
VPN-1 Power Gateway — allows cpd and fwd communication for SIC
communication (to establish trust) and for Policy installation.
In a distributed configuration, the Initial Policy on the VPN-1 Power module does
not allow CPMI connections. The SmartConsole will not be able to connect to the
SmartCenter Server, if the SmartConsole must access the SmartCenter Server
through a Gateway running the Initial Policy.
There is also an Initial Policy for a Secondary SmartCenter Server (Management
High Availability). This Initial Policy allows CPMI communication for SmartConsole
clients and allows cpd and fwd communication for SIC communication (to establish
trust) and for Policy installation.
388
Default Filter and Initial Policy Configuration
Default Filter and Initial Policy
Configuration
In This Section
Verifying the Default Filter or Initial Policy is Loaded
page 389
Change the Default Filter to a Drop Filter
page 390
User-Defined Default Filter
page 390
Using the Default Filter for Maintenance
page 390
To Unload a Default Filter or an Initial Policy
page 391
If You Cannot Complete Reboot After Installation
page 391
Command Line Reference for Default Filter and Initial Policy
page 392
Verifying the Default Filter or Initial Policy is
Loaded
You can verify that the Default Filter and/or Initial Policy are indeed loaded as
follows:
1. Boot the system.
2. Before installing another Security Policy, type the following command:
$FWDIR/bin/fw stat
The command’s output should show that defaultfilter is installed for the
Default Filter status. It should show that InitialPolicy is installed for the
Initial Policy.
Appendix A
Security Before VPN-1 Power Activation 389
Default Filter and Initial Policy Configuration
Change the Default Filter to a Drop Filter
For a typical setup there are two Default Filters: defaultfilter.boot and
defaultfilter.drop. They are located in $FWDIR/lib.
1. Copy over and rename the relevant desired Default Filter Inspect file
(defaultfilter.boot or defaultfilter.drop) to $FWDIR/conf/defaultfilter.pf
2. Compile the Default Filter by running the command:
fw defaultgen
The output will be in $FWDIR/state/default.bin
3. Run fwboot bootconf get_def to print the Default Filter file path.
4. Copy default.bin to the Default Filter file path.
5. If the Security Policy has not yet been installed, run cpconfig to regenerate the
Initial Policy.
User-Defined Default Filter
For administrators with Inspect knowledge, it is possible to define your own Default
Filter as follows:
1. Create an Inspect script named defaultfilter.pf in $FWDIR/conf:
Warning - Ensure that the script does not perform any of the following functions:
•
Logging
•
Authentication
•
Encryption
•
Content security
2. Continue from step 2 of “Change the Default Filter to a Drop Filter” on
page 390.”
You must ensure that your Security Policy does not interfere with the boot process.
Using the Default Filter for Maintenance
It is sometimes necessary to stop VPN-1 Power processes for maintenance, and it
is impractical to disconnect the VPN-1 Power Gateway computer from the network
(for example, the computer may be at a remote location). The
390
Default Filter and Initial Policy Configuration
cpstop -fwflag -default and cpstop -fwflag -proc commands allow VPN-1
Power processes to be temporarily stopped for remote maintenance without
exposing the computer to attack.
To Unload a Default Filter or an Initial Policy
To unload a Default Filter or an Initial Policy from the kernel, use the same
command that is used for unloading a regular policy. Do this only if you are certain
that you do not need the security provided by the Default Filter or an Initial Policy.
•
To unload the Default Filter locally, run the fw unloadlocal command.
•
To unload an Initial Policy from a remote SmartCenter machine, run the
following command on the SmartCenter Server:
fwm unload <hostname>
where hostname is the SIC_name of the Module.
If You Cannot Complete Reboot After Installation
In certain configurations the Default Filter may prevent the VPN-1 Power Gateway
computer from completing the reboot following installation.
First, examine the Default Filter and verify that the Default Filter allows traffic that
the computer need to boot.
If the boot process cannot complete successfully, remove the Default filter as
follows:
1. Reboot in
2000).
single user
mode (for UNIX) or
Safe Mode With No Networking
(for Windows
2. Ensure that the Default Filter does not load in future boots. Use the command
fwbootconf bootconf Set_def
3. Reboot.
Appendix A
Security Before VPN-1 Power Activation 391
Default Filter and Initial Policy Configuration
Command Line Reference for Default Filter and
Initial Policy
control_bootsec
Enables or disables Boot Security. The command affects both the Default Filter and
the Initial Policy.
Usage
$FWDIR/bin/control_bootsec [-r] [-g]
Table A-1
options control_bootsec
Options
Meaning
-r
Removes boot security
-g
Enables boot security
fwboot bootconf
Use the fwboot bootconf command to configure boot security options. This
command is located in $FWDIR/boot.
Usage
$FWDIR/bin/fwboot bootconf
Table A-2
392
<command> [value]
options fwboot bootconf
Options
Meaning
Get_ipf
Reports whether VPN-1 Power controls IP
Forwarding.
• Returns 1 if IP Forwarding control is enabled
on boot.
• Returns 0 if IP Forwarding is not controlled on
boot.
Default Filter and Initial Policy Configuration
Table A-2
options fwboot bootconf
Options
Meaning
Set_ipf 0/1
Turns off/on control of IP forwarding for the next
boot.
0 - Turns off
1 - Turns on
Get_def
Returns the full path to the Default Filter that will
be used on boot.
Set_def <filename>
Will load <filename> as the Default Filter in the
next boot. The only safe, and recommended, place
to put the default.bin file is $FWDIR\boot. (The
default.bin filename is a default name.)
Note - Do NOT move these files
comp_init_policy
Use the comp_init_policy command to generate and load, or to remove, the Initial
Policy.
This command generates the Initial Policy. It ensures that it will be loaded when
the computer is booted, or any other time that a Policy is fetched, which would also
occur at cpstart, or with the fw fetch localhost command. After running this
command, cpconfig will add an Initial Policy if there is no previous Policy
installed.
Usage
$FWDIR/bin/comp_init_policy [-u | -g]
Appendix A
Security Before VPN-1 Power Activation 393
Default Filter and Initial Policy Configuration
Table A-3
options comp_init_policy
Options
Meaning
-u
Removes the current Initial Policy, and ensures
that it will not be generated in future when
cpconfig is run.
-g
(Can be used if there is no Initial Policy. If there
is, make sure that after removing the policy, you
delete the $FWDIR\state\local\FW1\ folder.)
Generates the Initial Policy and ensures that it will
be loaded the next time a policy is fetched (at
cpstart, or at next boot, or via the fw fetch
localhost command). After running this
command, cpconfig will add an Initial Policy when
needed.
The comp_init_policy -g command will only work if there is no previous Policy. If
there is, make sure that after removing the policy, you delete the folder
$FWDIR\state\local\FW1\. The $FWDIR/state/local/FW1 folder contains the policy
that will be fetched when fw fetch localhost is run.
The fw fetch localhost command is the command that installs the local policy in
cpstart. comp_init_policy creates the initial policy, but has a safeguard such that
the initial policy will not overwrite a regular user policy (since initial policy is only
used for fresh installations or upgrade). For this reason, you must delete the
$FWDIR\state\local\FW1\ directory if there is a previous policy, otherwise
comp_init_policy will detect that there is already a user policy there, and will not
overwrite it.
If you do not delete the previous policy, yet perform the following commands …
comp_init_policy -g + fw fetch localhost
comp_init_policy -g + cpstart
comp_init_policy -g + reboot
… the original policy will still be loaded.
394
Default Filter and Initial Policy Configuration
cpstop -fwflag -default and cpstop -fwflag -proc
To stop all VPN-1 Power processes but leave the Default Filter running, use
cpstop -fwflag -default. To stop all VPN-1 Power processes but leave the Security
Policy running, use cpstop -fwflag -proc.
To stop and start all Check Point processes, use
commands should be used with caution.
On Win32 platforms, use the
Point Services.
Services
applet in the
cpstop
and
Control Panel
cpstart.
These
to stop and start Check
Usage
cpstop -fwflag [-default | -proc]
Table A-4
Options for fwflag
Options
Meaning
-default
Kills VPN-1 Power processes (fwd, fwm, vpnd, snmpd
etc.). Logs, kernel traps, resources, and all security
server connections stop working.
The Security Policy in the kernel is replaced with the
Default Filter.
-proc
Kills VPN-1 Power processes (fwd, fwm, vpnd etc.). Logs,
kernel traps, resources, and all security server
connections stop working.
The Security Policy remains loaded in the kernel.
Therefore allow/reject/drop rules that do not use
resources, but only service, continue working.
Appendix A
Security Before VPN-1 Power Activation 395
Default Filter and Initial Policy Configuration
396
B
Appendix
VPN-1 Power Command Line
Interface
The following command line commands relate to the Firewall components of VPN-1
Power. They are documented in the Command Line Interface (CLI) Guide.
Table B-1
Firewall-related Command Line Interface
Command
Description
comp_init_policy
Generates and loads (or removes) the Initial Policy.
fw
The fw commands are used for working with various
aspects of VPN-1 Power. All fw commands are
executed on the VPN-1 Power enforcement module.
fw isp_link
Takes down (or up) one of the redundant ISP links.
fw monitor
A powerful built-in tool to simplify the task of
capturing network packets at multiple capture points
within the Firewall chain.
fw tab
View kernel table contents and change the contents
of dynamic tables. Static tables cannot be changed.
fw stat
Displays the content of state tables on the target
hosts in various formats. For each host, the default
format displays the host name and a list of all tables
with their elements.
397
Table B-1
398
Firewall-related Command Line Interface (continued)
Command
Description
fw ver
Displays the VPN-1 Power major and minor version
number and build number.
sam_alert
Executes VPN-1 Power SAM (Suspicious Activity
Monitoring) actions according to information received
through Standard input. This tool is for executing
SAM actions with the User Defined alerts
mechanism. Normally run on on the SmartCenter
Server.
svr_webupload_config
This utility is used to configure the Eventia Reporter
web upload script.
THIRD PARTY TRADEMARKS AND COPYRIGHTS
Entrust is a registered trademark of Entrust Technologies, Inc. in the United
States and other countries. Entrust’s logos and Entrust product and service
names are also trademarks of Entrust Technologies, Inc. Entrust
Technologies Limited is a wholly owned subsidiary of Entrust Technologies,
Inc. FireWall-1 and SecuRemote incorporate certificate management
technology from Entrust.
Verisign is a trademark of Verisign Inc.
The following statements refer to those portions of the software copyrighted
by University of Michigan. Portions of the software copyright © 1992-1996
Regents of the University of Michigan. All rights reserved. Redistribution and
use in source and binary forms are permitted provided that this notice is
preserved and that due credit is given to the University of Michigan at Ann
Arbor. The name of the University may not be used to endorse or promote
products derived from this software without specific prior written permission.
This software is provided “as is” without express or implied warranty.
Copyright © Sax Software (terminal emulation only).
The following statements refer to those portions of the software copyrighted
by Carnegie Mellon University.
Copyright 1997 by Carnegie Mellon University. All Rights Reserved.
Permission to use, copy, modify, and distribute this software and its
documentation for any purpose and without fee is hereby granted, provided
that the above copyright notice appear in all copies and that both that
copyright notice and this permission notice appear in supporting
documentation, and that the name of CMU not be used in advertising or
publicity pertaining to distribution of the software without specific, written
prior permission.CMU DISCLAIMS ALL WARRANTIES WITH REGARD TO
THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL CMU BE LIABLE
FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY
DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR
OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH
THE USE OR PERFORMANCE OF THIS SOFTWARE.
The following statements refer to those portions of the software copyrighted
by The Open Group.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE OPEN
GROUP BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE
OR OTHER DEALINGS IN THE SOFTWARE.
The following statements refer to those portions of the software copyrighted
by The OpenSSL Project. This product includes software developed by the
OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/).
THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND
ANY * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT
SHALL THE OpenSSL PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR
ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
THE POSSIBILITY OF SUCH DAMAGE.
The following statements refer to those portions of the software copyrighted
by Eric Young. THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS''
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT
SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE. Copyright © 1998 The Open Group.
The following statements refer to those portions of the software copyrighted
by Jean-loup Gailly and Mark Adler Copyright (C) 1995-2002 Jean-loup Gailly
and Mark Adler. This software is provided 'as-is', without any express or
implied warranty. In no event will the authors be held liable for any damages
arising from the use of this software. Permission is granted to anyone to use
this software for any purpose, including commercial applications, and to alter
it and redistribute it freely, subject to the following restrictions:
1. The origin of this software must not be misrepresented; you must not claim
that you wrote the original software. If you use this software in a product, an
acknowledgment in the product documentation would be appreciated but is
not required.
2. Altered source versions must be plainly marked as such, and must not be
misrepresented as being the original software.
3. This notice may not be removed or altered from any source distribution.
The following statements refer to those portions of the software copyrighted
by the Gnu Public License. This program is free software; you can
redistribute it and/or modify it under the terms of the GNU General Public
License as published by the Free Software Foundation; either version 2 of the
License, or (at your option) any later version. This program is distributed in
the hope that it will be useful, but WITHOUT ANY WARRANTY; without even
the implied warranty of MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE. See the GNU General Public License for more
details.You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software Foundation, Inc.,
675 Mass Ave, Cambridge, MA 02139, USA.
The following statements refer to those portions of the software copyrighted
by Thai Open Source Software Center Ltd and Clark Cooper Copyright (c)
2001, 2002 Expat maintainers. Permission is hereby granted, free of charge,
to any person obtaining a copy of this software and associated
documentation files (the "Software"), to deal in the Software without
restriction, including without limitation the rights to use, copy, modify, merge,
publish, distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to the
following conditions: The above copyright notice and this permission notice
shall be included in all copies or substantial portions of the Software. THE
SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS
OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
GDChart is free for use in your applications and for chart generation. YOU
Check Point Software Technologies Ltd.
U.S. Headquarters: 800 Bridge Parkway, Redwood City, CA 94065, Tel: (650) 628-2000 Fax: (650) 654-4233, info@CheckPoint.com
International Headquarters: 3A Jabotinsky Street, Ramat Gan, 52520, Israel, Tel: 972-3-753 4555 Fax: 972-3-575 9256, http://www.checkpoint.com
MAY NOT re-distribute or represent the code as your own. Any redistributions of the code MUST reference the author, and include any and all
original documentation. Copyright. Bruce Verderaime. 1998, 1999, 2000,
2001. Portions copyright 1994, 1995, 1996, 1997, 1998, 1999, 2000,
2001, 2002 by Cold Spring Harbor Laboratory. Funded under Grant P41RR02188 by the National Institutes of Health. Portions copyright 1996,
1997, 1998, 1999, 2000, 2001, 2002 by Boutell.Com, Inc. Portions relating
to GD2 format copyright 1999, 2000, 2001, 2002 Philip Warner. Portions
relating to PNG copyright 1999, 2000, 2001, 2002 Greg Roelofs. Portions
relating to gdttf.c copyright 1999, 2000, 2001, 2002 John Ellson
(ellson@graphviz.org). Portions relating to gdft.c copyright 2001, 2002 John
Ellson (ellson@graphviz.org). Portions relating to JPEG and to color
quantization copyright 2000, 2001, 2002, Doug Becker and copyright (C)
1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, Thomas G. Lane.
This software is based in part on the work of the Independent JPEG Group.
See the file README-JPEG.TXT for more information. Portions relating to
WBMP copyright 2000, 2001, 2002 Maurice Szmurlo and Johan Van den
Brande. Permission has been granted to copy, distribute and modify gd in
any context without fee, including a commercial application, provided that
this notice is present in user-accessible supporting documentation. This
does not affect your ownership of the derived work itself, and the intent is to
assure proper credit for the authors of gd, not to interfere with your
productive use of gd. If you have questions, ask. "Derived works" includes all
programs that utilize the library. Credit must be given in user-accessible
documentation. This software is provided "AS IS." The copyright holders
disclaim all warranties, either express or implied, including but not limited to
implied warranties of merchantability and fitness for a particular purpose,
with respect to this code and accompanying documentation. Although their
code does not appear in gd 2.0.4, the authors wish to thank David Koblas,
David Rowley, and Hutchison Avenue Software Corporation for their prior
contributions.
Licensed under the Apache License, Version 2.0 (the "License"); you may
not use this file except in compliance with the License. You may obtain a
copy of the License at http://www.apache.org/licenses/LICENSE-2.0
The curl license
COPYRIGHT AND PERMISSION NOTICE
Copyright (c) 1996 - 2004, Daniel Stenberg, <daniel@haxx.se>.All rights
reserved.
Permission to use, copy, modify, and distribute this software for any purpose
with or without fee is hereby granted, provided that the above copyright
notice and this permission notice appear in all copies.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO
EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR
ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
IN THE SOFTWARE.
Except as contained in this notice, the name of a copyright holder shall not
be used in advertising or otherwise to promote the sale, use or other dealings
in this Software without prior written authorization of the copyright holder.
The PHP License, version 3.0
Copyright (c) 1999 - 2004 The PHP Group. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, is permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this
list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation and/
or other materials provided with the distribution.
3. The name "PHP" must not be used to endorse or promote products
derived from this software without prior written permission. For written
permission, please contact group@php.net.
4. Products derived from this software may not be called "PHP", nor may
"PHP" appear in their name, without prior written permission from
group@php.net. You may indicate that your software works in conjunction
with PHP by saying "Foo for PHP" instead of calling it "PHP Foo" or "phpfoo"
5. The PHP Group may publish revised and/or new versions of the license
from time to time. Each version will be given a distinguishing version
number. Once covered code has been published under a particular version
of the license, you may always continue to use it under the terms of that
version. You may also choose to use such covered code under the terms of
any subsequent version of the license published by the PHP Group. No one
other than the PHP Group has the right to modify the terms applicable to
covered code created under this License.
6. Redistributions of any form whatsoever must retain the following
acknowledgment:
"This product includes PHP, freely available from <http://www.php.net/>".
THIS SOFTWARE IS PROVIDED BY THE PHP DEVELOPMENT TEAM ``AS
IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT
NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
EVENT SHALL THE PHP DEVELOPMENT TEAM OR ITS CONTRIBUTORS
BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
This software consists of voluntary contributions made by many individuals
on behalf of the PHP Group. The PHP Group can be contacted via Email at
group@php.net.
For more information on the PHP Group and the PHP project, please see
<http://www.php.net>. This product includes the Zend Engine, freely
available at <http://www.zend.com>.
This product includes software written by Tim Hudson (tjh@cryptsoft.com).
Copyright (c) 2003, Itai Tzur <itzur@actcom.co.il>
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
Redistribution of source code must retain the above copyright notice, this list
of conditions and the following disclaimer.
Neither the name of Itai Tzur nor the names of other contributors may be
used to endorse or promote products derived from this software without
specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.
The material in document is provided with "RESTRICTED RIGHTS." Software
and accompanying documentation are provided to the U.S. government
("Government") in a transaction subject to the Federal Acquisition
Regulations with Restricted Rights. The Government's rights to use, modify,
reproduce, release, perform, display or disclose are
restricted by paragraph (b)(3) of the Rights in Noncommercial Computer
Software and Noncommercial Computer Soft-ware Documentation clause at
DFAR 252.227-7014 (Jun 1995), and the other restrictions and terms in
paragraph (g)(3)(i) of Rights in Data-General clause at FAR 52.227-14,
Alternative III (Jun 87) and paragraph (c)(2) of the Commer-cial
Copyright (c) 1998, 1999, 2000 Thai Open Source Software Center Ltd
Computer Software-Restricted Rights clause at FAR 52.227-19 (Jun 1987).
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights to
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies
of the Software, and to permit persons to whom the Software is furnished to
do so, subject to the following conditions: The above copyright notice and this
permission notice shall be included in all copies or substantial portions of the
Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS
OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Copyright © 2003, 2004 NextHop Technologies, Inc. All rights reserved.
Confidential Copyright Notice
Except as stated herein, none of the material provided as a part of this
document may be copied, reproduced, distrib-uted, republished,
downloaded, displayed, posted or transmitted in any form or by any means,
including, but not lim-ited to, electronic, mechanical, photocopying,
recording, or otherwise, without the prior written permission of NextHop
Technologies, Inc. Permission is granted to display, copy, distribute and
download the materials in this doc-ument for personal, non-commercial use
only, provided you do not modify the materials and that you retain all copyright and other proprietary notices contained in the materials unless
otherwise stated. No material contained in this document may be "mirrored"
on any server without written permission of NextHop. Any unauthorized use
of any material contained in this document may violate copyright laws,
trademark laws, the laws of privacy and publicity, and communications
regulations and statutes. Permission terminates automatically if any of these
terms or condi-tions are breached. Upon termination, any downloaded and
printed materials must be immediately destroyed.
Use of the material in this document by the Government constitutes
acknowledgment of NextHop's proprietary rights in them, or that of the
original creator. The Contractor/Licensor is NextHop located at 1911
Landings Drive, Mountain View, California 94043. Use, duplication, or
disclosure by the Government is subject to restrictions as set forth in
applicable laws and regulations.
Disclaimer Warranty Disclaimer Warranty Disclaimer Warranty Disclaimer
Warranty
THE MATERIAL IN THIS DOCUMENT IS PROVIDED "AS IS" WITHOUT
WARRANTIES OF ANY KIND EITHER EXPRESS OR IMPLIED. TO THE
FULLEST EXTENT POSSIBLE PURSUANT TO THE APPLICABLE LAW,
NEXTHOP DISCLAIMS ALL WARRANTIES,
EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, IMPLIED
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
PURPOSE, NON INFRINGEMENT OR OTHER VIOLATION OF RIGHTS.
NEITHER NEXTHOP NOR ANY OTHER PROVIDER OR DEVELOPER OF
MATERIAL CONTAINED IN THIS DOCUMENT WARRANTS OR MAKES ANY
REPRESEN-TATIONS REGARDING THE USE, VALIDITY, ACCURACY, OR
RELIABILITY OF, OR THE RESULTS OF THE USE OF, OR OTHERWISE
RESPECTING, THE MATERIAL IN THIS DOCUMENT.
Limitation of Liability
UNDER NO CIRCUMSTANCES SHALL NEXTHOP BE LIABLE FOR ANY
DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL
DAMAGES, INCLUDING, BUT NOT LIMITED TO, LOSS OF DATA OR PROFIT,
ARISING OUT OF THE USE, OR THE INABILITY TO USE, THE MATERIAL IN
THIS DOCUMENT, EVEN IF NEXTHOP OR A NEXTHOP AUTHORIZED
REPRESENTATIVE HAS ADVISED OF THE POSSIBILITY OF SUCH
DAMAGES. IF YOUR USE OF MATERIAL FROM THIS DOCUMENT RESULTS
IN THE NEED FOR SERVICING, REPAIR OR CORRECTION OF EQUIPMENT
OR DATA, YOU ASSUME ANY COSTS THEREOF. SOME STATES DO NOT
ALLOW THE EXCLUSION OR LIMITATION OF INCIDENTAL OR
CONSEQUENTIAL DAMAGES, SO THE ABOVE LIMITATION OR EXCLUSION
MAY NOT FULLY APPLY TO YOU.
Trademark Notice
Copyright © ComponentOne, LLC 1991-2002. All Rights Reserved.
The trademarks, service marks, and logos (the "Trademarks") used and
displayed in this document are registered and unregistered Trademarks of
NextHop in the US and/or other countries. The names of actual companies
and products mentioned herein may be Trademarks of their respective
owners. Nothing in this document should be construed as granting, by
implication, estoppel, or otherwise, any license or right to use any Trademark
displayed in the document. The owners aggressively enforce their intellectual
property rights to the fullest extent of the law. The Trademarks may not be
used in any way, including in advertising or publicity pertaining to distribution
of, or access to, materials in
this document, including use, without prior, written permission. Use of
Trademarks as a "hot" link to any website is prohibited unless establishment
of such a link is approved in advance in writing. Any questions concerning
the use of these Trademarks should be referred to NextHop at U.S. +1 734
222 1600.
BIND: ISC Bind (Copyright (c) 2004 by Internet Systems Consortium, Inc.
("ISC"))
Copyright 1997-2001, Theo de Raadt: the OpenBSD 2.9 Release
PCRE LICENCE
PCRE is a library of functions to support regular expressions whose syntax
and semantics are as close as possible to those of the Perl 5 language.
Release 5 of PCRE is distributed under the terms of the "BSD" licence, as
specified below. The documentation for PCRE, supplied in the "doc"
directory, is distributed under the same terms as the software itself.
Written by: Philip Hazel <ph10@cam.ac.uk>
University of Cambridge Computing Service, Cambridge, England. Phone:
U.S. Government Restricted Rights
+44 1223 334714.
Copyright (c) 1997-2004 University of Cambridge All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright notice, this
list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation and/
or other materials provided with the distribution.
* Neither the name of the University of Cambridge nor the names of its
contributors may be used to endorse or promote products derived from this
software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY
OF SUCH DAMAGE.
Index
A
CVP
Access Control
definition 29
ActiveX 367
Address Translation Rule Base 93
Anti Virus 193
Anti-spoofing
and NAT 97
configuring 43
planning considerations 39
SmartDefense
configuration 166
understanding 33
Anti-virus protection
for HTTP 306
for SMTP 315
understanding CVP 306
Application Intelligence 344
Application Layer 351
Architecture of VPN-1 Power 29
D
B
E
Boot Security 383
default filter 383
IP Forwarding 383
boot security
IP Forwarding 383, 392
enable_propfind_method 372
Error page 349
C
Fingerprint scrambling 168
FTP Commands
limiting using resource 298
fw isp_link 130
FW1_clntauth 73
fwauthd.conf 73
CIFS
Configuring protection 293
inspection 291, 292
Code Red 365
Content Security
Connectivity versus
security 372
FTP configuration 299
Performed by Services 336
September 2006
chaining 322
for any TCP service 321
for FTP 308
for HTTP 306
for SMTP
configuring 315
Improving performance 317
Load Sharing 322
Default Filter 383
Default Security Policy
verifying that it is
loaded 389
Definitions of patterns 173
DShield Storm Center 173
DVMRP (Distance Vector
Multicast Routing Protocol) 36
F
H
H.323 215
configuration 246
Gatekeeper 238
Gateway 238
IP phones 238
NAT Support 239
Protocols 244
routing modes 244
services 245
SmartDefense 243
topologies 239
VoIP Domain 246
Handover 217
VoIP Domain 220
when to enforce 218
Hide NAT 90
HTTP
concurrent connections 359
protocol Inspection 351
Sessions 353
http_allow_content_disposition 3
72
http_allow_ranges 372
http_disable_content_enc 373
http_disable_content_type 373
I
IGMP 36
Implied Rules
definition 32
when to edit 41
Information Disclosure 351
Instant Messaging 279
Internet Service Provider. See ISP
Redundancy
IP addresses, private and
public 87
IP Forwarding 383
ISP Redundancy
ClusterXL support 132
configuring 137
deployment, choosing 136
deployments 131
403
dialup support 132
DNS configuration 138
how it works 127
incoming connections 128
link monitoring 127
link status 130
modes, choosing 136
modes, understanding 126
NAT, Hide 127, 140
NAT, Static 128, 140
need 124
outgoing connections 127
overview 125
script 129
SmartView Monitor 127
J
Java 367
L
Licensing
Web Intelligence 361
Load agents port property 152
M
Malicious Activity Detection
(MAD) 168
Malicious Code 351
Malicious Code Protector 344
Match 30
MGCP 215
configuration 266
securing 261
SmartDefense 264
with H.323 and SIP 263
Monitor-only 348
considerations 356
for all active protections 348
per Web server 349
MSN Messenger
over MSNMS,
configuration 288
over MSNMS, NAT
support 284
404
over SIP, configuration 286
over SIP, NAT support 283
securing 281
Multicast
addressing 36
configuration 44
protocols 36
securing 35
N
NAT
anti-spoofing 97
arp commands 99
automatic and manual 91
bidirectional 94
definition 88
disabling in VPNs 99
for H.323 239
for SIP 228
Hide address 101
Hide NAT 90
Hide NAT for all internal
networks 92
Hide, planning for 100
IP pools 117
port translation
configuring 106
understanding 97
private and public
addresses 87
Rule Base 93
rule match 93
Static NAT 89
static routes 97
Static, planning for 100
understanding automatic 95
Nimda 365
O
Online Updates 345
OSPF 36
P
PIM (Protocol-Independent
Multicast) 36
Port scan 169
Protection scope 346
Q
QuickUFP. See UFP
enhancing performance
R
Resource
creating 314
Resources
definition 313
URI resource definition 365
RFC 1918 87
RTP/RTCP 216
Rule Base. See Security Rule
Base
S
SCCP 215
configuring 273
securing 271
SmartDefense 272
Security Before VPN-1 Power
Activation 382
Security Levels 348
Security Policy 30
Security Rule Base
basic rules 40
elements 31
match 30
using X11 in 41
Security Server
FTP 298
how it works 304
HTTP
CVP 306
CVP performance 307
Security servers 304
Sequence verifier 160
Services
DNS 333
H.323 245
PPTP 334
SIP 231
SSHv2 331
SSLv3 330
TCPT 336
X11 41
SIP 215
architectural elements 225
logging 223
NAT support 227, 228
Proxy 226
Redirect Server 226, 230
Registrar 226
RFCs 226
services 231
SmartDefense 229
Terminal (IP Phone) 225
topologies 227
Troubleshooting 237
SmartDefense
architecture 164
DoS attack protection 167
H.323 243
Malicious Activity Detection
(MAD) 168
MGCP 264
SCCP 272
sequence verifier 160
SIP 229
subscription service 163
updating 175
SmartDefense Profiles 173
Configuring 179
Logging 174
Profile Cloning 173
SOAP 368
Spoofed Reset Protection 173
Stateful Inspection 29, 344
Static NAT 89
Successive Events 173
U
X
UFP
X11 service, using in Rule
Base 41
enhancing performanceconcept 309
enhancing performanceconfiguration 318
for any TCP service 321
How it works 309
rule match behavior 318
URL Filtering
basic 366
using UFP 309
V
version number
displaying 398
Visitor Mode 336
VoIP
DoS protection 221
Handover 217
logging 223
VoIP Domain
Handover 220
VPN-1 Power version number
displaying 398
W
Web
N-tier architecture 342
vulnerabilities 342
Web Intelligence
ClusterXL compatibility 351
connectivity
Implications 356
Licensing 361
performance
implications 359
security levels 348
Technologies 344
Web Server View 347
T
Telephony
protection 221
threats 214
405
406
Download PDF
Similar pages