Firewall R75 Administration Guide pdf

9 Rules and the Rule Base ...10 Rule Base Elements ...10 Implied Rules ...11 Order of Rule Enforcement ...11 Example Access Control Rule ...11 Special Considerations for Access Con

15 December 2010

Administration Guide

Firewall

R75

© 2010 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:

Refer to the Copyright page (http://www.checkpoint.com/copyright.html) for a list of our trademarks

Refer to the Third Party copyright notices (http://www.checkpoint.com/3rd_party_copyright.html) for a list of relevant copyrights and third-party licenses

Check Point is engaged in a continuous effort to improve its documentation

Please help us by sending your comments

(mailto:cp_techpub_feedback@checkpoint.com?subject=Feedback on Firewall R75 Administration Guide)

Contents

Important Information 3

Access Control 9

Check Point Access Control Solution 9

Rules and the Rule Base 10

Rule Base Elements 10

Implied Rules 11

Order of Rule Enforcement 11

Example Access Control Rule 11

Special Considerations for Access Control 11

Defining Access Control Rules 13

Defining an Access Control Policy 13

Preventing IP Spoofing 14

Configuring Anti-Spoofing 15

Excluding Specific Internal Addresses 16

Legal Addresses 16

Multicast Access Control 17

Multicast Routing Protocols 17

Dynamic Registration Using IGMP 17

IP Multicast Group Addressing 17

Per-Interface Multicast Restrictions 18

Configuring Multicast Access Control 19

Cooperative Enforcement 19

Enforcement Mode 20

NAT Environments 20

Monitor Only Deployment Mode 20

Configuring Cooperative Enforcement 20

End Point Quarantine (EPQ) - Intel® AMT 21

Configuring End Point Quarantine (EPQ) 21

Authentication 26

Configuring Authentication 26

How the Gateway Searches for Users 26

Authentication Schemes 27

Check Point Password 27

Operating System Password 27

RADIUS 27

SecurID 29

TACACS 30

Undefined 31

Authentication Methods 31

User Authentication 31

Session Authentication 32

Client Authentication 34

Creating Users and Groups 39

Creating User Groups 39

Creating a User Template 39

Creating Users 40

Installing User Information in the Database 40

Configuring Authentication Tracking 40

Configuring Policy for Groups of Windows Users 40

Network Address Translation 41

NAT Modes 41

Static NAT 42

Hide NAT 42

NAT Rule Base 44

Rule Match Order 44

Automatic and Manual NAT Rules 45

Bidirectional NAT 45

Understanding Automatically Generated Rules 45

Planning Considerations for NAT 46

Hide Versus Static 46

Automatic Versus Manual Rules 46

Choosing the Hide Address in Hide NAT 47

Specific Deployment Considerations 47

Configuring NAT 48

General Steps for Configuring NAT 48

Basic Configuration - Network Node with Hide NAT 49

Sample Configuration (Static and Hide NAT) 50

Sample Configuration (Using Manual Rules for Port Translation) 51

Advanced NAT Configuration 51

Connecting Translated Objects on Different Interfaces 51

Internal Communication with Overlapping Addresses 51

Security Management Behind NAT 54

IP Pool NAT 55

ISP Redundancy 60

ISP Redundancy Overview 60

ISP Redundancy Operational Modes 61

Monitoring the ISP Links 61

How ISP Redundancy Works 62

ISP Redundancy Script 63

Manually Changing the Link Status (fw isp_link) 63

ISP Redundancy Deployments 63

ISP Redundancy and VPNs 65

Considerations for ISP Link Redundancy 66

Choosing the Deployment 66

Choosing the Redundancy Mode 67

Configuring ISP Link Redundancy 67

Introduction to ISP Link Redundancy Configuration 67

Registering the Domain and Obtaining IP Addresses 67

DNS Server Configuration for Incoming Connections 68

Dialup Link Setup for Incoming Connections 68

SmartDashboard Configuration 68

Configuring Default Route for ISP Redundancy Gateway 70

ConnectControl - Server Load Balancing 71

Introduction to ConnectControl 71

Load-Balancing Methods 71

ConnectControl Packet Flow 72

Logical Server Types 72

HTTP 72

Other 74

Considering Logical Server Types 74

Persistent Server Mode 74

Persistency By Server 75

Persistency By Service 75

Persistent Server Timeout 75

Server Availability 76

Load Measuring 76

Configuring ConnectControl 76

Bridge Mode 78

Introduction to Bridge Mode 78

Limitations in Bridge Mode 78

Configuring Bridge Mode 79

Bridging Interfaces 79

Configuring Anti-Spoofing 79

Displaying the Bridge Configuration 79

CoreXL Administration 81

CoreXL 81

Supported Platforms and Features 81

Default Configuration 81

Performance Tuning 82

Processing Core Allocation 82

Allocating Processing Cores 82

Configuring CoreXL 85

Command Line Reference 85

Affinity Settings 85

fwaffinity.conf 85

fwaffinty_apply 86

fw ctl affinity 87

fw ctl multik stat 88

Anti-Virus and URL Filtering 89

Anti-Virus Protection 89

Introduction to Integrated Anti-Virus Protection 89

Architecture 89

Configuring Integrated Anti-Virus Scanning 89

Database Updates 90

Understanding Anti-Virus Scanning Options 91

Configuring Anti-Virus 97

Logging and Monitoring 99

UTM-1 Edge Anti-Virus 99

URL Filtering 100

Introduction to URL Filtering 100

Terminology 100

Architecture 100

Configuring URL Filtering 101

Anti-Spam and Mail 102

Introduction to Anti-Spam and Mail Security 102

Mail Security Overview 103

Anti-Spam 103

Adaptive Continuous Download 105

Configuring Anti-Spam 105

Configuring a Content Anti-Spam Policy 105

Configuring an IP Reputation Policy 105

Configuring a Block List 106

Configuring Anti-Spam SMTP 106

Configuring Anti-Spam POP3 106

Configuring Network Exceptions 106

Configuring an Allow List 107

Selecting a Customized Server 107

Anti-Spam on UTM-1 Edge Devices 107

Bridge Mode and Anti-Spam 108

Configuring Anti-Virus Protection for Mail 108

Configuring Mail Anti-Virus 108

Configuring Zero Hour Malware Protection 109

Configuring SMTP and POP3 109

Configuring File Types 110

Configuring Settings 110

Configuring a Disclaimer 110

Anti-Spam Logging and Monitoring 110

Reporting False Positives to Check Point 111

Anti-Spam Tracking and Reporting Options 111

SmartView Tracker 112

SmartView Monitor 112

SmartReporter 112

Securing Voice Over IP 113

Introduction to the Check Point Solution for Secure VoIP 113

Control Signaling and Media Protocols 114

VoIP Handover 114

When to Enforce Handover 115

VoIP Application Intelligence 115

Introduction to VoIP Application Intelligence 115

Restricting Handover Locations Using a VoIP Domain 115

Controlling Signaling and Media Connections 116

Preventing Denial of Service Attacks 116

Protocol-Specific Application Intelligence 116

VoIP Logging 117

Protocol-Specific Security 117

Securing SIP-Based VoIP 117

Securing H.323-Based VoIP 127

Configuring H.323-Based VoIP 132

Securing MGCP-Based VoIP 142

Securing SCCP-Based VoIP 147

Securing Instant Messaging Applications 152

The Need to Secure Instant Messenger Applications 152

Introduction to Instant Messenger Security 152

Understanding Instant Messenger Security 153

NAT Support for MSN Messenger over SIP 153

NAT Support for MSN Messenger over MSNMS 153

Logging Instant Messenger Applications 154

Configuring SIP-based Instant Messengers 154

Configuring MSN Messenger over MSNMS 155

Configuring Skype, Yahoo, ICQ and More 155

Microsoft Networking Services Security 156

Securing Microsoft Networking Services (CIFS) 156

Restricting Access to Servers and Shares (CIFS Resource) 156

FTP Security 158

Introduction to FTP Content Security 158

FTP Enforcement by the Firewall Kernel 158

FTP Enforcement by the FTP Security Server 158

Control Allowed Protocol Commands 158

Maintaining Integrity of Other Protected Services 159

Avoiding Vulnerabilities in FTP Applications 159

Content Security via the FTP Resource 159

Configuring Restricted Access to Specific Directories 159

Content Security 161

Introduction to Content Security 161

Security Servers 161

Deploying OPSEC Servers 162

CVP Servers for Anti-Virus and Malicious Content Protection 163

Using URL Filtering to Limit Web Surfers 165

TCP Security Server 167

Configuring Content Security 168

Resources: What They Are and How to Use Them 168

Creating a Resource and Using it in the Rule Base 168

Configuring Anti-Virus Checking for Incoming Email 169

Configuring CVP for Web Traffic Performance 170

Configuring URL Filtering with a UFP Server 170

Performing CVP/UFP Inspection on any TCP Service 172

Advanced CVP Configuration: CVP Chaining and Load Sharing 173

Introduction to CVP Chaining and Load Sharing 173

CVP Chaining 173

CVP Load Sharing 174

Combining CVP Chaining and Load Sharing 174

Configuring CVP Chaining and Load Sharing 175

Services with Application Intelligence 176

Introduction to Services with Application Intelligence 176

DCE-RPC 176

SSLv3 Service 177

SSHv2 Service 177

FTP_BASIC Protocol Type 177

Domain_UDP Service 177

Point-to-Point Tunneling Protocol (PPTP) 177

Configuring PPTP 178

Blocking Visitor Mode (TCPT) 178

Introduction to TCPT 178

Why Block Visitor Mode and Outgoing TCPT? 178

How the Firewall Identifies TCPT 178

When to Block Outgoing TCPT 179

Blocking Visitor Mode (Blocking Outgoing TCPT) 179

Changing the Port Used to Block Outgoing TCPT 179

Web Content Protection 180

Introduction to Web Content Protection 180

Web Content Security in the Rule Base 180

What is a URI Resource? 180

Filtering URLs 180

Basic URL Filtering 181

URL Logging 182

Java and ActiveX Security 182

Securing XML Web Services (SOAP) 182

Understanding HTTP Sessions, Connections and URLs 183

HTTP Request Example 183

HTTP Response Example 183

HTTP Connections 184

Understanding URLs 184

Connectivity or Security: Web Surfers 184

Allowing or Restricting Content 184

Content Compression 185

HTTP Security Server Performance 185

Simultaneous Security Server Connections 186

Running Multiple Instances of HTTP Security Server 186

Appendix A: Security Before Firewall Activation 187

Achieving Security Before firewall Activation 187

Boot Security 187

Control of IP Forwarding on Boot 187

The Default Filter 188

Changing the Default Filter to a Drop Filter 188

Defining a Custom Default Filter 189

Using the Default Filter for Maintenance 189

The Initial Policy 189

Managing Default Filter and Initial Policy 190

Verifying Default Filter or Initial Policy Loading 190

Unloading Default Filter or Initial Policy 191

Troubleshooting: Cannot Complete Reboot 191

Command Line Reference 191

Index 195

Chapter 1

Access Control

In This Chapter

Check Point Access Control Solution

A Security Gateway at the network boundary inspects and provides access control for all traffic Traffic that does not pass though the gateway is not controlled

Figure 1-1 Traffic Inspection at the Network Boundary

A security administrator is responsible for implementing company security policy The Security Management Server enables administrators to enforce security policies consistently across multiple gateways To do this, the administrator defines a company-wide security policy Rule Base using SmartDashboard and installs it to the Security Management Server SmartDashboard is a SmartConsole client application that administrators use to define and apply security policies to gateways Granular security policy control is possible by applying specific rules to specific gateways

A Security Gateway provides secure access control because of its granular understanding of all underlying services and applications traveling on the network Stateful Inspection technology provides full application level awareness and comprehensive access control for more than 150 predefined applications, services and protocols as well as the ability to specify and define custom services

Rules and the Rule Base

Rules and the Rule Base

A Security Policy consists of an ordered set of rules, collectively known as the Rule Base A well defined

security policy is essential to any effective security solution The fundamental principle of the Rule Base is that all actions that are not explicitly permitted are prohibited

Each rule in the Rule Base specifies the source, destination, service, and action to be taken for each

session A rule also specifies how the events are tracked Events can be logged, and then trigger an alert message Reviewing traffic logs and alerts is an crucial aspect of security management

Rule Base Elements

A rule is made up of the following Rule Base elements (not all fields are relevant to a given rule):

Table 1-1 Rule Base Elements

You can negate source and destination parameters, which means that a

given rule applies to all connection sources/destinations except the

specified location You may, for example, find it more convenient to specify

that the a rule applies to any source that is not in a given network To

negate a connection source or destination, right click on the appropriate rule cell and select Negate Cell from the options menu

VPN Allows you to configure whether the rule applies to any connection

(encrypted or clear) or only to VPN connections To limit a rule to VPN connections, double-click on the rule and select one of the two VPN options

Service Allows you to apply a rule to specific predefined protocols or services or

applications You can define new, custom services

Action Determines whether a packet is accepted, rejected, or dropped If a

connection is rejected, the firewall sends an RST packet to the originator

of the connection and the connection is closed If a packet is dropped, no response is sent and the connection eventually times out For information

on actions that relate to authentication, see Authentication (on page 26)

Track Provides various logging options (see the R75 Security Management

Administration Guide

(http://supportcontent.checkpoint.com/documentation_download?ID=1166

7))

Install-On Specifies the Security Gateway on which the rule is installed There may

be no need to enforce certain rules on every Security Gateway For example, a rule may allow certain network services to cross only one particular gateway In this case, the specific rule need not be installed on

other gateways (see the R75 Security Management Administration Guide

(http://supportcontent.checkpoint.com/documentation_download?ID=1166

7))

Time Specifies the time period (for Activate On and Expire On), the time of day,

and the days (every day, day of week, day of month) that the rule is enforced

Rules and the Rule Base

Implied Rules

Apart from rules explicitly defined by an administrator, the Security Gateway also creates implied rules, which are derived from Global Properties definitions Implied rules enable certain connections to occur to and from the gateway using a variety of different services The firewall places implied rules either first, last,

or immediately before last rule in the Rule Base

Examples of implied rules include rules that enable Security Gateway control connections and outgoing packets originating from the Security Gateway

To view implied rules:

1 Add at least one rule to the rule base

2 Click View > Implied Rules

The Firewall tab displays the Implied Rules in addition to the user-defined rules

Order of Rule Enforcement

The Security Gateway inspects packets and applies rules in a sequential manner When a Security Gateway receives a packet from a connection, it inspects the packet and applies the first rule in the Rule Base, then the second rule and so on

Once all elements in a given rule match the information contained the packet (source, destination, service, etc.), the Security Gateway stops the inspection and immediately applies that rule If no applicable rule is found in the Rule Base, the traffic is automatically blocked

It is essential that you understand the concept of rule processing The firewall always enforces the first

matching rule to any given packet This may not necessarily the rule that best applies to the traffic

It is important to carefully plan your Rule Base and place rules in the appropriate order The best practice is

to place rules that apply to very specific conditions at the beginning of the Rule Base More general rules should be places toward the end of the Rule Base

Rules are processed in the following order:

1 First Implied Rule: This rule cannot be modified or overwritten in the Rule Base No rules can be

placed before it

2 Explicit Rules: These are administrator-defined rules, which may be located anywhere between the first

and the next to last implied rules

3 Next to Last Implied Rules: These are a more specific implied rules that are applied before the last

implied rule is enforced

4 Last Implied Rule: This is the default rule, which typically rejects all packets without logging

Example Access Control Rule

The following screen shot shows a typical access control rule, as seen in the Firewall tab of

SmartDashboard This rule states that HTTP connections that originate from the branch office that are

directed to any destination, will be accepted and logged

Figure 1-2 Typical access control rule

Special Considerations for Access Control

This section describes Access Control scenarios

Simplicity

The key to effective firewall protection is a simple Rule Base One of the greatest dangers to the security of your organization is misconfiguration For example, a user may try to sneak spoofed, fragmented packets past your firewall if you have accidentally allowed unrestricted messaging protocols To keep your Rule

Rules and the Rule Base

Base simple, ensure that it is concise and therefore easy to understand and maintain The more rules you have, the more likely you are to make a mistake

Basic Rules

When creating rules, ensure that you allow only traffic that you want Consider traffic initiated and crossing the firewall from both the protected and unprotected sides of the firewall

The following basic access control rules are recommended for every Rule Base:

 A Stealth Rule to prevent direct access to the Security 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 such access attempts

Remember that the fundamental concept behind the Rule Base is that actions that are not explicitly

permitted are prohibited

Rule Order

Rule order is a critical aspect of an effective Rule Base Having the same rules, but putting them in a

different order, can radically alter the effectiveness of your firewall It is best to place more specific rules first and more general rules last This order prevents a general rule from being applied 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, it is recommended to create a

demilitarized zone (DMZ) The DMZ isolates all servers that are accessible from untrusted sources, such as the Internet, so that if one of those servers is compromised, the intruder only has limited access to other externally accessible servers Servers in the DMZ are accessible from any network, and all externally

accessible servers should be located in the DMZ 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

X11 Service

The X11 (X Window System Version 11) graphics display system is the standard graphics system for the

Unix environment To enable X11, you must create a specific rule using the X11 service If you select Any

as the Source or Destination, the X11 service is not included because when using the X11 service, the

GUI application acts as the server rather than the client

Editing Implied Rules

Implied rules are defined in the Global Properties window > Firewall Implied Rules page In general, there

is no need to change predefined implied rules It is often best to leave some of the rules unselected so that the property can be controlled with greater granularity through the Rule Base For example, you may want to allow ICMP pings across certain gateways only

The following are the recommended settings for implied rules:

Table 1-2 Recommended Settings for Firewall Implied Rules

Setting

Accept control connections First

Accept Remote Access control connections First

Accept SmartUpdate connections First

Accept outbound packets originating from the gateway Unselected

Rules and the Rule Base

Accept Domain Name Over UDP (Queries) Unselected

Accept Domain Name over TCP (Zone transfer) Unselected

Accept ICMP requests Unselected

Accept dynamic address DHCP traffic First

Accept VRRP packets originating from cluster members

(VSX Nokia VRRP)

First

Defining Access Control Rules

To define access control rules, perform the following steps using SmartDashboard:

1 Define network objects for each network and host using SmartDashboard

2 Click the Firewall tab in SmartDashboard

3 From the SmartDashboard menu, select Rules > Add Rule and then select either Bottom, Top, Below,

or Above

4 Double-click the Name column, type a Rule Name and click OK

5 Right-click in the Source column and select Add

6 Select a network object and click OK

7 Right-click in the Destination column and select Add Objects

8 Select a network object and click OK

9 Right-click in the VPN column and select Edit Cell

10 Select a VPN match condition and click OK

11 Right-click in the Service column and select Add

12 Select a service or a service group and click OK

13 Right-click in the Action column and select Accept, Drop, or Reject

14 Right-click in the Track column and select Add

15 Select one of the tracking options

16 Right-click in the Install On column and select Add

17 Select one of the Install on options

18 Right click in the Time column and select Add if you want to add a time frame to the rule

19 Configure the Time Properties and click OK

Defining an Access Control Policy

The Access Control policy is required to:

 Allow internal users access to the Internet

 Allow all users access to the servers on the DMZ network

 Protect the network from outsiders

Preventing IP Spoofing

The policy also requires two basic rules: a Stealth rule and a Cleanup rule

Figure 1-3 Typical Network with Access Control Policy

Preventing IP Spoofing

If your network is not protected against IP address spoofing, your access control rules are ineffective and it

is easy for attackers to gain access by changing the source address of the packet For this reason, ensure that you configure anti-spoofing protection on every interface of the Security Gateway, including internal interfaces

IP spoofing occurs when an intruder attempts to gain unauthorized access by changing a packet's IP

address to appear as though it originated from network node with higher access privileges

Note - It is important to ensure that all communication originates from

its apparent source

Anti-spoofing protection verifies that packets originate from and are destined to the correct interfaces on the gateway It confirms which packets actually come from the specified internal network interface It also

verifies that once a packet is routed, it goes through the proper interface

Preventing IP Spoofing

A packet coming from an external interface, even if it has a spoofed internal IP address, is blocked because the firewall anti-spoofing feature detects that the packet arrived from the wrong interface

Figure 1-4 Anti-Spoofing Process

On Alaska_GW, the firewall ensures that:

 All incoming packets to interface IF1 come from the Internet

 All incoming packets to interface IF2 come from Alaska_LAN or, Alaska_RND_LAN or Florida_LAN

On Alaska_RND_GW, the firewall ensures that:

 All incoming packets to interface IF3 come from Alaska_LAN, Florida_LAN or the Internet

 All incoming packets to interface IF4 come from Alaka_RND_LAN

When configuring anti-spoofing, you need to specify in the interface topology definitions whether the

interfaces lead to the Internet (defined as External) or an internal network (defined as Internal)

Configuring Anti-Spoofing

It is important to configure anti-spoofing protection on every interface of every Security Gateway, including internal interfaces

Configuring Anti-Spoofing for External Interfaces

To define a valid address for external interfaces:

1 In SmartDashboard, select Manage > Network Objects

2 Select a gateway and click Edit

3 From the list of pages, click Topology

4 Click Get > Interfaces to obtain interface information of the gateway machine

5 Click Accept

If SmartDashboard cannot retrieve the topology information, check that the gateway General Properties are listed correctly and that the gateway, the Security Management server, and the SmartDashboard all have functioning communications

6 In the Topology page, select the interface to the Internet and click Edit

7 In the Interface Properties window, open the Topology tab

8 Select External (leads out to the Internet)

9 Select Perform Anti-Spoofing based on interface topology

10 Under Anti-Spoofing action is set to, select one of the following:

Preventing IP Spoofing

 Prevent - to block packets that have been spoofed

 Detect - to allow packets that have possibly been spoofed This option is used for monitoring

purposes and should be used in conjunction with one of the tracking options It serves as a tool for learning the topology of a network without actually rejecting packets

11 Don't check packets from is used to ensure anti-spoof checks do not take place for addresses from

certain internal networks coming into the external interface

To use this option, select the checkbox and select from the drop-down list a network object that

represents those internal networks with valid addresses If the network object that you need is not in the

list, click New and define the Internal Network object that you need

Objects selected in the drop-down list are disregarded by the anti-spoofing enforcement mechanism

12 In the Spoof Tracking option, select Log and then click OK

Configuring Anti-Spoofing for Internal Interfaces

To define a valid address for internal interfaces:

1 In SmartDashboard, select Manage > Network Objects

2 Select the Check Point gateway and click Edit

3 In the gateway window, select Topology

4 In the Topology window, click Get > Interfaces to obtain interface information of the gateway machine

5 Under the Name column, select the internal interface and click Edit

6 In the Interface Properties window, click Topology, and then select Internal (leads to the local

network)

7 Under IP Addresses behind this interface, do one of the following:

 If there is only one network behind the interface, select 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 consists of

all the networks behind the interface by selecting Specific and the group

8 Select Perform Anti-Spoofing based on interface topology

9 Under Anti-Spoofing action is set to, select one of the following:

 Prevent - to block packets that have been spoofed

 Detect - to allow packets that have possibly been spoofed This option is used for monitoring

purposes and should be used in conjunction with one of the tracking options It serves as a tool for learning the topology of a network without actually rejecting packets

10 Under Spoof Tracking, select Log and click OK

11 Repeat step 1 to step 8 for all internal interfaces

12 Install the security policy: Policy > Install

Excluding Specific Internal Addresses

In some cases, it may be necessary to allow packets with source addresses that belong to an internal

network to enter the gateway through an external interface This may be useful if an external application assigns internal IP addresses to external clients In this case, you can specify that anti-spoofing checks are not made on packets from specified internal networks

Legal Addresses

Legal addresses are those addresses that are permitted to enter a Security Gateway interface Legal

addresses are determined by the network topology When configuring the firewall anti-spoofing protection,

the administrator specifies the legal IP addresses behind the interface The Get Interfaces with Topology

option automatically defines the interface and its topology and creates network objects the firewall obtains this information by reading routing table entries

Multicast Access Control

Multicast Access Control

Multicast IP transmits a single message to a predefined group of recipients an example of this is distributing real-time audio and video to a set of hosts that have joined a distributed conference

Multicast is similar to radio and TV where only those people who have tuned their tuners to a selected

frequency receive the information With multicast you hear the channel you are interested in, but not the others

IP multicasting applications send one copy of each datagram (IP packet) and address it to a group of

computers that want to receive it This technique sends datagrams to a group of recipients (at the multicast address) rather than to a single recipient (at a unicast address) The routers in the network forward the datagrams to only those routers and hosts that want to receive them

The Internet Engineering Task Force (IETF) has developed multicast communication standards that define:

 Multicast routing protocols

 Dynamic registration

 IP multicast group addressing

Multicast Routing Protocols

Multicast routing protocols communicate information between multicast groups Examples of multicast

routing protocols include Protocol-Independent Multicast (PIM), Distance Vector Multicast Routing Protocol (DVMRP), and Multicast Extensions to OSPF (MOSPF)

Dynamic Registration Using IGMP

Hosts use the Internet Group Management Protocol (IGMP) to let the nearest multicast router know if they want to belong to a particular multicast group Hosts can leave or join the group at any time IGMP is defined

in RFC 1112

IP Multicast Group Addressing

The IP address area has four sections: Class A, Class B, Class C, and Class D Class A, B, and C

addresses are used for unicast traffic Class D addresses are reserved for multicast traffic and are allocated dynamically

The multicast address range 224.0.0.0 through 239.255.255.255 is used only for the group address or

destination address of IP multicast traffic Every IP datagram whose destination address starts with 1110 is

an IP multicast datagram

Figure 1-5 Multicast Address

Just as a radio is tuned to receive a program that is transmitted at a certain frequency, a host interface can

be tuned to receive datagrams sent to a specific multicast group This process is called joining a multicast group

The remaining 28 bits of the multi-case address range identify the multicast group to which the datagram is sent Membership in a multicast group is dynamic (hosts can join and leave multicast groups) The source address for multicast datagrams is always the unicast source address

Reserved Local Addresses

Multicast group addresses in the 224.0.0.0 through 224.0.0.255 range are assigned by the Internet

Assigned Numbers Authority (IANA) for applications that are never forwarded by a router (they remain local

on a particular LAN segment)

Multicast Access Control

These addresses are called permanent host groups The following table shows examples of reserved Local Network Multicast Groups

Table 1-3 Local Network Multicast Groups Examples

Multicast Address Purpose

224.0.0.1 All hosts An ICMP Request (ping) sent to this group should be

answered by all multicast capable hosts on the network Every multicast capable host must join this group at start up on all of its multicast capable interfaces

224.0.0.2 All routers All multicast routers must join this group on all of its

multicast capable interfaces

224.0.0.4 All DVMRP routers

224.0.0.5 All OSPF routers

224.0.0.13 All PIM routers

For additional information on reserved multicast addresses, refer to the IANA website

(http://www.iana.org/assignments/multicast-addresses)

Per-Interface Multicast Restrictions

A multicast enabled router forwards multicast datagrams from one interface to another When you enable multicast on a Security Gateway running on SecurePlatform, you can define multicast access restrictions on each interface These restrictions specify which multicast groups (addresses or address ranges) to allow or

to block Enforcement is performed on outbound multicast datagrams

When access is denied to a multicast group on an interface for outbound IGMP packets, inbound packets are also denied

Figure 1-6 Gateway with Per Interface Multicast Restrictions

When access restrictions for multicast datagrams are not defined, inbound multicast datagrams entering a gateway from one interface are allowed out of all other interfaces

In addition to defining per interface access restrictions, you must define a rule in the Rule Base that allows multicast traffic and services, and the destination defined in this rule must allow the required multicast

groups

Cooperative Enforcement

VPN Connections

Multicast traffic can be encrypted and sent across VPN links defined using multiple VPN tunnel interfaces (virtual interfaces associated with the same physical interface)

Configuring Multicast Access Control

To configure multicast access control:

1 Select a gateway object in SmartDashboard

2 On General Properties page, ensure that the gateway version is specified correctly

3 On the Topology page, select an interface and click Edit

4 On the Multicast Restrictions tab of the Interface Properties page, select Drop Multicast packets by

the following conditions

5 Select a multicast policy for the interface:

 Drop multicast packets whose destination is in the list

 Drop all multicast packets except those whose destination is in the list

6 Click Add to add a multicast address range The Add Object window opens, with the Multicast

Address Ranges object selected in the list

7 Click New > Multicast Address Range The Multicast Address Range Properties window opens

8 Provide a name for this range

9 Define either an IP address Range or a Single IP Address that are in the 224.0.0.0 to

239.255.255.255 range

10 Click OK The named Multicast Range appears in the Add Object window

11 Click OK The named Multicast Range appears in the Interface Properties > Multicast Restrictions

window

12 Click OK to close the Interface Properties window and again to close the gateway window

13 In the Rule Base, add a rule that allows the multicast address range As the Destination of the rule,

specify the range defined in step 5

14 Save and install the security policy: Policy > Install

Cooperative Enforcement

Cooperative Enforcement works with Check Point Endpoint Security servers This feature utilizes the

Endpoint Security server compliance capability to verify connections arriving from various hosts across the internal network

Endpoint Security server is a centrally managed, multi-layered Endpoint Security solution that employs policy-based security enforcement for internal and remote PCs Easily deployed and managed, the Endpoint Security server mitigates the risk of hackers, worms, spyware, and other security threats

Features such as predefined policy templates, an intuitive Web-based management interface, and PC

firewall and application privilege controls, enable administrators to develop, manage, and enforce

Cooperative Enforcement quickly and easily

Using Cooperative Enforcement, any host initiating a connection through a gateway is tested for

compliance This increases the integrity of the network because it prevents hosts with malicious software components from accessing the network

This feature acts as a middle-man between hosts managed by an Endpoint Security server and the

Endpoint Security server itself It relies on the Endpoint Security server compliance feature, which defines whether a host is secure and can block connections that do not meet the defined prerequisites of software components

The following is a typical Cooperative Enforcement workflow:

1 A host opens a connection to the network through a firewall gateway The first packet from the client to the server is allowed It is only on the first server's reply to the client that the Cooperative Enforcement feature begins to perform

2 The firewall checks for host compliance in its tables and queries the Endpoint Security server, if

required

Cooperative Enforcement

3 Upon receiving a reply, connections from compliant hosts are allowed and connections from

non-compliant hosts are blocked

When activating the cooperative enforcement feature on a gateway, the following implied rules are

automatically enabled:

1 Allow all firewall GUI clients to connect to the Endpoint Security server via HTTP or HTTPS (port 80 or 443)

2 Allow all internal clients to access the Endpoint Security server via the firewall for heartbeats

3 Allow the firewall to communicate with the Endpoint Security server on port 5054

If additional access permissions are required (such as allow external clients to connect to the Endpoint Security server, or for other machines to access the administration portion of the Endpoint Security server), explicit rules should be defined

Cooperative Enforcement feature is not supported by all the NAT configurations

For Cooperative Enforcement to work in a NAT environment, the gateway and the Endpoint Security Server must relate to the same IP address of a specific client Therefore, when NAT is used, if NAT is causing the Client IP received by gateway to be different than the Client IP received by the Endpoint Security Server, Cooperative Enforcement will not work properly

Monitor Only Deployment Mode

In the Monitor Only deployment mode, the firewall requests authorization statuses from the Endpoint

Security server but, regardless of the received statuses, connections are not dropped In addition (if

configured by the administrator) the Cooperative Enforcement feature generates logs regardless of the deployment mode

Configuring Cooperative Enforcement

To configure Cooperative Enforcement:

From the gateway's Cooperative Enforcement page, select Authorize clients using Endpoint Security

Server to enable Cooperative Enforcement

1 Select Monitor Only for traffic to pass successfully and to track only connections that would otherwise

have been dropped

2 Track unauthorized client status allows you to set the appropriate track or alert option The default setting is Log

3 In the Endpoint Security Server Selection section, select which Endpoint Security server will be used:

 To use this machine, select Use Endpoint Security Server installed on this machine

 To use another machine, select a server from the Select Endpoint Security Server drop down menu Click New to create a new server

4 In the Client Authorization section, select one of the following methods:

 Check authorization of all clients: Inspects all clients

 Bypass authorization of the following clients: Permits all clients in the selected groups

drop-down list to pass without inspection

 Check authorization only of the following clients: Verifies the authorization of clients from the

selected groups drop-down list

End Point Quarantine (EPQ) - Intel® AMT

End Point Quarantine (EPQ) - Intel® AMT

End Point Quarantine (using Intel® AMT) gives the administrator the ability to place a malicious user's

machine under quarantine whenever malicious activity takes place according to the security policy

configuration

EPQ isolates the malicious machine by installing a security policy on the machine where the malicious

activity originated The policy restricts both inbound and outbound traffic flowing from that machine As a result, the machine is isolated from the rest of the network and is prevented from causing any further

EPQ is supported on SecurePlatform and Linux platforms

Configuring End Point Quarantine (EPQ)

You configure EPQ by modifying the AMT.conf file, located in the $FWDIR/conf folder This file defines the

actions taken against any source initiating any malicious action

To work with EPQ configuration, open $FWDIR/conf /AMT.conf with a text editor

The following is an example of an AMT.conf file

- Activate the feature by changing the flag to true and

define the subnets the feature is enabled on

Connection Authentication Data

To define connection authentication, modify AMT.conf to include data similar to the following example:

End Point Quarantine (EPQ) - Intel® AMT

:authentication (

- Define the authentication method using on of the

following:

no_tls - clear text

tls - only server authentication

mutual_tls - client and server authentication

:method (no_tls)

- User name and password are required for all methods

:user_name ("admin")

:user_pass ("Myadmin1!")

- Server Certificate is only required when tls is the

chosen authentication method

:server_certificate (

:server_cert_name ("server certificate name")

:server_cert_path ("server certificate path")

)

- Client certificate is only relevant on Linux when

mutual_tls is the chosen authentication method

:client_certificate (

:cert_name ("certificate name")

:cert_pass ("certificate pass")

)

)

Quarantine Policy Data

To define quarantine policy data authentication, modify AMT.conf to include code similar to the following example:

End Point Quarantine (EPQ) - Intel® AMT

You can configure up to 29 rules for incoming traffic and up to 29 rules outgoing traffic

The policy name must begin with "CP_" and cannot exceed six letters Numbers and other characters are not permitted

Note - It is recommended not to change the default policy name

Encrypting the Password

To encrypt the password, execute the following command: epq -o set_password

This command will not change the password but will encrypt the password so it is not in the clear Running this command a second time however, will change the password It is recommended to save and store your password in a safe place since there is no undo option

End Point Quarantine (EPQ) - Intel® AMT

Malicious Activity Script and Alert

The sam_alert tool executes specified actions according to information received via the log mechanism

This tool is intended to execute FW-1 SAMv2 actions with user defined alerts mechanism

-O print the input of this tool to Standard output (for pipes)

-S Match the SAM server to be contacted Default is localhost

-t timeout The time period (in seconds) for which the action will be enforced

The default is forever

-f target The firewalls on which to run the operation Default is All

-n name Fill in the SAM name field Default is empty

-c comment Fill in the SAM comment field Default is empty

-o originator Fill in the SAM originator field Default is "sam_alert"

-l Logs to issue for connections matching the specified criteria Either

r/egular, a/lert Default is None

-a Action to apply on connections matching specified criteria Either

d/rop, r/eject, n/otify, b/ypass, q/uarantine, i/nspect

-C Close all existing connections that match the criteria

-ip Use IP addresses as criteria parameters

-eth Use MAC addresses as criteria parameters

-src Match the source address of connections

-dst Match the destination address of connections

-srv Match specific source, destination, protocol and service

-any Match either the source or destination address of connections

sam_alert Configuration

To configure sam_alert using SmartDashboard:

1 Click Policy > Global Properties > Log and Alert > Alert Commands

2 In one of the unused Run UserDefined script fields, enter the following script command:

sam_alert -v2 -a r -t 60 -ip -src

This is a sample script Keep in mind the following points:

 The feature will only work if the action (-a) is r (reject) or d (drop)

 -t 60 can be changed

 -ip and -src represent that we only want to block an attacker that sends something malicious

3 Install policy

End Point Quarantine (EPQ) - Intel® AMT

Logging Activity

The script is run when a malicious action is logged

Note - Actions are not logged by default The User Defined alert must

be enabled for each threat for the sam_alert script to be activated

The log as it appears in SmartView Tracker

The first log entry represents that the end point host, Broadwater, has been quarantined The second log

represents that the end point host, broadwater, has been released from quarantine and authorized to be part of the network

To quarantine a machine manually, execute the following command:

epq -o < status | list | is_amt | enable | disable [-l lastPolicyHandle] > -i AMTdeviceIP [policyFileName]

Table 1-4 Arguments for epq

status Display the status of the policies and rules

list List the quarantined end-point computers

is_amt Allows the user to check if there is AMT on the machine

enable Activates the policy

disable Deactivates the policy being enforced

-l lastPolicyHandle This is the last known policy to be activated

-i AMTdeviceIP The IP address of the end-point computer you want to

quarantine

policyFileName The file name of the file containing the policy you want to

enforce (default location is $FWDIR/conf/AMT.conf)

Chapter 2

Authentication

This section presents background information and procedures for working with user authentication

Authentication confirms the identity of valid users authorized to access your company network Staff from different departments are assigned access permissions based on their level of responsibility and role within the organization Authentication ensures that all users trying to access the system are valid users, but does not define their access rights

In This Chapter

Configuring Authentication

On the Security Gateway, you can configure authentication in one of two places:

 In the Gateway Properties window of a gateway in Authentication In the Authentication page, you can allow access to users who authenticate with a Check Point Password, SecurID, OS Password,

RADIUS server, or TACACS server Authentication using Client Certificates from the Internal Certificate

Authority is enabled by default in addition to the selected method

 Some blades have their own authentication settings Configure this in the Gateway Properties window

of a gateway under <name of the blade> > Authentication For example, configure the authentication method for IPSec VPN clients in Gateway Properties > IPSec VPN > Authentication.If you select an

authentication method for the blade, that is the method that all users must use to authenticate to that blade You can configure other authentication methods that users must use for different blades on different pages

If you do not make a selection on the Authentication page for a specific blade, the Security Gateway

takes authentication settings for the blade from the main gateway Authentication page

Note - In previous releases there was no option to configure an

authentication setting for a specific blade But from R75 and higher, if you configure an authentication method for a specific blade, the settings on this page do not apply at all to that blade

How the Gateway Searches for Users

If you configure authentication for a blade from the main Security Gateway Legacy Authentication page,

the Security Gateway searches for users in a standard way when they try to authenticate The gateway searches:

1 The internal users database

Authentication Schemes

2 If the specified user is not defined in this database, the gateway queries the SmartDirectory (LDAP)

servers defined in the Account Unit one at a time, and according to their priority

3 If the information still cannot be found, the gateway uses the external users template to see if there is a match against the generic profile This generic profile has the default attributes applied to the specified user

If you configure an authentication method for a specific blade, the gateway searches for users according to the user groups that are used for authorization in that blade

For example, in Mobile Access, the gateway looks at the Mobile Access policy to see which user groups are part of the policy When the gateway tries to authenticate a user, it starts to search for users in the

databases related to those user groups

In IPSec VPN, the gateway looks at the Remote Access VPN Community to see which user groups are included It starts to search for users in the databases related to those user groups

Advantages of a search based on the authentication scheme include:

 Faster results

 You can have users with the same username in unrelated groups The gateway will know which user is relevant for the blade based on the user groups

Authentication Schemes

Security Gateways authenticate individual users using credentials and manages them using different

authentication schemes All of the authentication schemes require the provision of a user name and

password While some schemes involve storing the passwords on the gateway, others are stored on

external servers

The following sections describe the various authentication schemes supported by Check Point

Check Point Password

The Security Gateway can store a static password in the local user database of each user configured in Security Management server No additional software is required

Operating System Password

The Security Gateway can authenticate using the user name and password that is stored on the operating system of the machine on which the Security Gateway is installed You can also use passwords that are stored in a Windows domain No additional software is required

Configuring a Security Gateway to use RADIUS Authentication

To configure a Security Gateway to use RADIUS authentication:

1 In SmartDashboard, create a RADIUS Host object by selecting Manage > Network Objects > New >

Node > Host

2 Name the Host object and assign it an IP address

Authentication Schemes

3 Create a RADIUS Server object by selecting Manage > Server and OPSEC Applications > New >

RADIUS, and configure the following:

a) Name the RADIUS Server object

b) Associate the RADIUS Server object with the RADIUS Host object created in step 1

c) Assign the Service by selecting either the RADIUS on port 1645 or NEW-RADIUS on port 1812 service (The default setting is RADIUS, however the RADIUS standards group recommends using

NEW-RADIUS, because port 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) Select either 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

4 Right-click the gateway object and select Edit >Authentication

5 Enable RADIUS authentication

6 Define a user group by selecting Manage > Users & Administrators > New > User Group (for

example, RADIUS_Users)

7 Enable RADIUS authentication for Security Gateway users by selecting Manage > Users and

Administrators > New > User by Template > Default

8 Enable RADIUS authentication for users without Security Gateway user accounts by creating an

External User Profile Select Manage > Users and Administrators > New > External User Profile >

Match all users or Match by domain To support more than one external authentication scheme,

define your External User Profiles with the Match By Domain setting

9 For all User Profiles and Templates, configure the following:

a) In the General tab, type 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) In the Personal tab, adjust the Expiration Date

c) In the Authentication tab, select RADIUS from the drop-down list

d) In the Groups tab, add the User Profile to the RADIUS group

10 Verify that communication between the firewall and the RADIUS server are not defined in the Address Translation Rule Base

11 Save, verify, and install the policy

Granting User Access Using RADIUS Server Groups

The Security Gateway enables you to control access for authenticated RADIUS users, based on the

administrator's assignment of users to RADIUS groups These groups are used in the Security Rule Base to restrict or grant access to users to specific resources Users are unaware of the groups to which they

belong

To use RADIUS groups, you must define a return attribute in the RADIUS user profile of the RADIUS server

This attribute is returned to the Security Gateway and contains the group name (for example, RAD_<group

to which the RADIUS users belong>) to which the users belong Although other RADIUS attributes can be

used, by default the Class attribute is used (IETF RADIUS attribute number 25)

To grant access using RADIUS server groups:

1 On the Security Gateway, follow step 1 to step 4 in Configuring a Security Gateway to use RADIUS ("Configuring a Security Gateway to use RADIUS Authentication" on page 27)

2 Create an External User Profile by selecting Manage > Users and Administrators > New > External

User Profile > Match all users This is the generic* user

3 In the Authentication tab, select RADIUS as the Authentication Scheme and then select the created

RADIUS server (not the node) from the drop-down list

Authentication Schemes

4 Define the required RADIUS user groups by selecting Manage > Users & Administrators > New >

User Group The name of the group must be in the format: RAD_<group to which the RADIUS users belong> Ensure the group is empty

5 Create the required Rule Base rules to allow access to RADIUS users

6 Save the changes, and exit SmartDashboard

7 Run cpstop on the Security Management server

8 On the Security Management server, use the Graphical Database Tool (GUIdbEdit) to change the value

of the add_radius_groups attribute from false to true

9 Run cpstart on the Security Management server

10 Install the policy

11 On the RADIUS server, modify the RADIUS users to include a class RADIUS attribute on the users

Return list that corresponds to the user group that they access

To use a different attribute instead of the class attribute, do one of the following:

1 On the Security Gateway, use GUIdbEdit to modify the value of the firewall_properties attribute

radius_groups_attr to the new RADIUS attribute

2 On the RADIUS server, ensure that you use the same RADIUS attribute (on the users' Return list that corresponds to the Firewall user group that they access)

Associating a RADIUS Server with Security Gateway

You can associate users with the Radius authentication server in the User PropertiesAuthentication tab

You can also associate a gateway with a Radius server so that this overrides the User to Radius server

association This is performed by editing the database using the dbedit command

To associate one or more Radius servers to a gateway:

1 Run the dbedit command as follows:

modify network_objects <gw obj> radius_server

servers:<radius obj>

2 To switch off the Radius to the Security Gateway association so that the user always authenticates to

the Radius server specified in the User Properties Authentication tab, switch off another attribute in the database by running the dbedit command:

modify users <user obj> use_fw_radius_if_exist false

SecurID

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 approximately every minute When a user attempts to authenticate

to a protected resource, the one-time use code must be validated by the ACE/server

Using SecurID, the Security Gateway 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 gateway acts as an ACE/Agent 5.0 and directs all access requests to the RSA ACE/server for authentication For additional information on agent configuration, refer to ACE/server documentation

There are no specific parameters required for the SecurID authentication scheme

Configuring a Security Gateway to use SecurID Authentication

To configure a Security Gateway to use SecurID:

1 Generate and copy the sdconf.rec file from the ACE/Server to:

 /var/ace/sdconf.rec on UNIX, Linux or IPSO

 %SystemRoot%\System32\sdconf.rec on Windows

2 In SmartDashboard, right-click the gateway object and select Edit >Authentication page

Authentication Schemes

3 Enable SecurID authentication

4 Define a user group by selecting Manage > Users & Administrators > New > User Group (for

example, SecurID_Users)

5 Enable SecurID authentication for Security Gateway users by selecting Manage > Users and

Administrators > New > User by Template > Default

6 Enable SecurID authentication for users without Security Gateway user accounts by creating an

External User Profile Select Manage > Users and Administrators > New > External User Profile >

Match all users or Match by domain If you support more than one external authentication scheme, set

up your External User Profiles with the Match By Domain setting

7 For all User Profiles and Templates, configure the following:

a) In 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) In the Personal tab, change the Expiration Date

c) In the Authentication tab, select SecurID from the drop-down list

d) In the Groups tab, add the User Profile to the SecurID group

8 Verify that communication between the firewall and the ACE/Server are not NATed in the Address

Translation Rule Base

9 Save, verify, and install the policy

Note - When a Security Gateway has multiple interfaces, the SecurID

agent on the Security Gateway sometimes uses the wrong interface IP

to decrypt the reply from the ACE/Server, and authentication fails

To overcome this problem, place a new text file, named sdopts.rec, in

the same directory as sdconf.rec The file should contain the CLIENT_IP=<ip> line, where <ip> is the primary IP address of

the Security Gateway, as defined on the ACE/Server This is the IP address of the interface to which the server is routed

TACACS

Terminal Access Controller Access Control System (TACACS) provides access control for routers, network access servers and other networked devices through one or more centralized servers

TACACS is an external authentication scheme that provides verification services Using TACACS, the

Security Gateway 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 Kerberos secret key authentication TACACS encrypts the user name,

password, authentication services and accounting information of all authentication requests to ensure

secure communication

Configuring a Security Gateway to use TACACS+Authentication

To configure a Security Gateway to use TACACS+:

1 In SmartDashboard, create a TACACS Host object by selecting Manage > Network Objects > New >

Node > Host

2 Name the Host object and assign it an IP address

3 Create a TACACS server by selecting Manage > Server and OPSEC Applications > New…>

TACACS…, and configure the following:

a) Name the TACACS server object

b) Associate the TACACS server object with the TACACS Host object created in step 1

c) Select 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 selected in step c

4 Right-click the gateway object and select Edit > Authentication

Authentication Methods

5 Enable TACACS authentication

6 Define a user group by selecting Manage > Users & Administrators > New > User Group (for

example, TACACS_Users)

7 Enable TACACS authentication for Security Gateway users by selecting Manage > Users and

Administrators > New > User by Template > Default

8 Enable TACACS authentication for users without Security Gateway user accounts by creating an

External User Profile Select either Manage > Users and Administrators > New > External User

Profile > Match all users or Match by domain If more than one external authentication scheme is

supported, set up your External User Profiles using the Match By Domain setting

9 For all User Profiles and Templates, configure the following:

a) In 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) In the Personal tab, change the Expiration Date

c) In the Authentication tab, select TACACS from the drop-down list

d) In the Groups tab, add the User Profile to the TACACS group

10 Verify that communication between the firewall and the TACACS server is not NATed in the Address Translation Rule Base

11 Save, verify, and install the policy

Undefined

The authentication scheme for a user can be defined as undefined If a user with an undefined

authentication scheme is matched to a Security Rule with some form of authentication, access is always denied

to the target server

The following is a typical User Authentication method workflow:

1 The Security Gateway intercepts the communication between the client and server

2 The Security Gateway prompts the user for a user name and password

3 If the user successfully authenticates, the gateway passes the connection to the remote host If incorrect credentials are presented, the user is prompted to re-enter the data After a predefined number of

unsuccessful connection attempts, the connection is dropped

4 The remote host prompts the user for a user name and password

Note - When configuring user objects, you can set the locations that

they are allowed to access, however, this can lead to a conflict with security rules that require some form of authentication See also:

Resolving Access Conflicts (on page 37)

Authentication Methods

Configuring User Authentication

To configure user authentication:

1 Configure authentication for required users and groups and install the user database For detailed

information, refer to Creating Users and Groups (on page 39)

2 Define a user authentication access rule as follows:

a) Right-click in the Source column, select Add object > Add legacy user access and then select the

group

b) To restrict the location of authenticating users, select Restrict To and the host, group of hosts,

network or group of networks that users can access in the Location section of the same window c) In the Service field, select the services you wish to authenticate

d) In the Action column, select Legacy > User Auth

3 Double-click the Action column to edit the User Authentication Action Properties

4 If required, adjust the User Authentication session timeout from the Authentication page of the

Security Gateway object

5 Install the security policy: Policy > Install

Importance of Rule Order in User Authentication

When defining user authentication rules for Telnet, FTP, HTTP, and RLOGIN services, if there are other non-authentication rules that use these services, ensure that the user authentication rule is located last amongst these rules

Session Authentication

Session Authentication can be used for any service, however, a Session Authentication agent is required to retrieve a user's identity The Session Authentication agent is normally installed on the authenticating client, whereby the person who initiates the connection to the destination host, supplies the authentication

credentials Session authentication 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, thereby allowing the user at that machine to provide the user name and password

The following is a typical Session Authentication workflow:

1 The user initiates a connection directly to the server

2 The Security Gateway intercepts the connection

3 The Session Authentication agent challenges the user for authentication data and returns this

information to the gateway

4 If the authentication is successful, the Security Gateway allows the connection to pass through the

gateway and continue to the target server

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 also Resolving Access Conflicts (on page 37)

Configuring Session Authentication

To configure session authentication:

1 If using the Session Authentication Agent, install and configure it for all machine desktops with Session Authentication enabled

2 Configure the users and groups for authentication, and install the user database Refer to Creating Users and Groups (on page 39) for more information

3 From the Authentication page, edit the Check Point Gateway object that represents the gateway and enable the required authentication schemes The gateway must support all of the user defined

Authentication Methods

authentication schemes For example, if some users must provide a Check Point password, and others RADIUS authentication, select both schemes

4 Define a Session Authentication access rule by doing the following:

a) Right-click in the Source column, select Add object > Add legacy user access and then the

group Do not close the window

b) To restrict the location of authenticating users, in the Location section of the same window, select

Restrict To and the host, group of hosts, network or group of networks that users can access

c) In the Service field, select the services you want to authenticate

d) In the Action column, select Legacy > Session Auth

5 Double-click the Action column to edit the User Authentication Action Properties

6 If required, adjust the Failed Authentication Attempts settings for Session Authentication in the

Authentication page of the Global Properties

7 Install the security policy

Installing and Configuring Session Authentication Agent

To install and configure the Session Authentication Agent:

1 Install the Session Authentication agent from the DVD

 If the Session Authentication agent is installed on the authenticating client, users who want to

connect to the destination host provide the authentication credentials

 If Session Authentication agent is installed on the destination machine or on some other machine in the network, the user at the machine on which the Agent is installed is prompted to provide

authentication credentials

2 On Windows machines, double-click the Session Authentication agent icon in the system tray The

Session Authentication window

3 Click Configure The Configuration window opens and displays the Passwords tab Specify how often

the user is prompted to provide their password One-time passwords (such as SecurID) cannot be

cached

4 Select one of the following options:

 Every request: The user is prompted for a password each time that the Security Gateway requests

authentication Each time that the user initiates a session for which a Session Authentication Rule applies, the user is prompted for the password No password caching occurs

 Once per session: The user is prompted for the password once per Session Authentication Agent

session Once the user provides the password, the Session Authentication agent caches the

password indefinitely This option cannot be used with one-time passwords If the Session

Authentication Agent session is closed and then restarted, the user must provide the password

again

 After minutes of inactivity: Similar to the Once per session option, however, the user is

prompted again for the password if there has been no authentication request over a specified time interval

5 In the Configuration window, select the Allowed FireWall-1 tab and specify the Security Gateways for

which the Session Authentication agent can provide authentication services

6 Select one of the following options:

 Any IP Address: The Session Authentication agent can provide authentication services for any

Security Gateway

 IP Address: The Session Authentication agent can provide authentication services for only a

Security Gateway running on a user-specified IP address (you can specify up to three IP

addresses)

7 In the Configuration window, select the Options tab and specify whether to allow clear passwords and

to resolve addresses

8 Select the appropriate option and click OK

Starting the Session Authentication Agent

To start the Session Authentication Agent:

1 From the Windows system tray, select the minimized Session Authentication Agent icon

Authentication Methods

2 Configure the Session Authentication Agent and/or receive authentication requests from a Security Gateway

Client Authentication

Client Authentication can authenticate any service It enables access from a specific IP address for an

unlimited number of connections The client user performs the authentication process, but it is the client machine that is granted access Client Authentication is less secure than user authentication because it permits access for multiple users and connections from authorized IP addresses or hosts Authorization is performed on a per machine basis for services that do not have an initial login procedure The advantages

of Client Authentication are that it can be used for an unlimited number of connections, for any service, and

is valid for any length of time

Note - When configuring user objects, you can set the locations that

users can access, however, this can cause problems with security rules that require some form of authentication See also Resolving Access Conflicts (on page 37)

Client Authentication works with all sign on methods The following table shows how different sign on

methods provide choice when selecting an authentication method for authenticated and other services For sign on methods other than Manual Client Authentication, the gateway is transparent to the users and they authenticate directly to the destination host

Table 2-5 Client Authentication Sign On Methods

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

The following are the two Client Authentication sign on options:

 Standard Sign on: Enables users to access all services permitted by the rule without authenticating for

each service

 Specific Sign on: Enables users to access only the services that they specify when they authenticate,

even if the rule allows more than one service If the user wants to use another service, they must authenticate for that specific service

re-At the end of an authentication session, the user can sign off When a user signs off, they are disconnected from all services and the remote host

Manual Sign On

Manual Sign On is available for any service that is specified in the Client Authentication rule The user must first connect to the gateway and authenticate in one of the following two ways:

1 Through a Telnet session to the gateway on port 259

2 Through an HTTP connection to the gateway on port 900 and a Web browser The requested URL must

include the gateway name and the port number, for example, http://Gateway:900

a) The following example shows Client Authentication using a Standard Manual Sign On method In this example, before opening a connection to the destination host, the user fbloggs first

authenticates to london, the Security Gateway

(3) Specific Sign On Enter your choice: 1

User authorized for standard services (1 rules)

Connection closed by foreign host

b) The following example shows Client Authentication using a Specific Manual Sign On method In this

example, two services are specified: rstat and finger (each one to a different host)

tower 3% telnet london 259

(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

Wait mode is a Client Authentication feature for Manual Sign On when the user initiates a client

authenticated connection with a Telnet session on port 259 on the gateway

Wait mode eliminates the need to open a new Telnet session in order to sign off and withdraw client

authentication privileges In Wait mode, the initial Telnet session connection remains open so long as client authentication privileges remain valid Client authentication privileges are withdrawn when the Telnet

session is closed

The Security Gateway keeps the Telnet session open by pinging the authenticating client If for some reason the client machine stops running, the gateway closes the Telnet session and client authentication privileges from the connected IP address are withdrawn

Enable Wait mode works only with client authentication rules that specify Standard Sign On In Enable Wait mode, client authentication rules that require Specific Sign On are not applied

Authentication Methods

Partially Automatic Sign On

Partially Automatic Sign On is available for authenticated services (Telnet, FTP, HTTP and RLOGIN) only if they are specified in the client authentication rule If the user attempts to connect to a remote host using one

of the authenticated services, they must authenticate with User Authentication When using Partially

Automatic Client Authentication, ensure that port 80 is accessible on the gateway machine

Fully Automatic Sign On

Fully Automatic Sign On is available for any service only if the required service is specified in the client authentication rule If the user attempts to connect to a remote host using an authenticated service (Telnet, FTP, HTTP, and RLOGIN), they must authenticate with User Authentication If the user attempts to connect

to a remote host using any other service, they must authenticate through a properly installed Session

Authentication agent When using Fully Automatic Client Authentication, ensure that port 80 is accessible on the gateway machine

Agent Automatic Sign On

Agent Automatic Sign On is available only if the required service is specified in the Client Authentication rule, and the Session Authentication agent is properly installed

If a user attempts to connect to a remote host using any service, they must authenticate through a Session Authentication agent

Single Sign On

Single Sign On is available for any service only if the required service is specified in the Client

Authentication rule and UserAuthority is installed

Single Sign On is a Check Point address management feature that provides transparent network access The Security Gateway consults the user IP address records to determine which users are logged on to any given IP address When a connection matches a Single Sign On enabled rule, the gateway 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

Configuring Client Authentication

To configure basic client authentication:

1 Configure the required users and groups for authentication and install the user database Refer to

Creating Users and Groups (on page 39) for details

2 From the Authentication page, edit the Check Point Gateway object that represents the Security

Gateway and enable the required authentication schemes The gateway must support all of the user defined authentication schemes For example, if some users must provide a Check Point password, and others RADIUS authentication, select both schemes

3 Define a Client Authentication access rule as follows:

a) Right-click in the Source column, select Add object > Add legacy user access and then the

group Do not close the window

b) To restrict the location of authenticating users, in the Location section of the same window, select

Restrict To and the host, group of hosts, network or group of networks that users can access

c) In the Service field, select the services you want to authenticate

d) In the Action column, select Legacy > Client Auth

4 For Partially or Fully Automatic Client Authentication, ensure that port 80 is accessible on the gateway machine

5 Double-click in the Action column to edit the Client Authentication Action Properties The settings for

Requires Sign On and Sign On Method are described in Client Authentication (on page 34)

6 Place all Client Authentication Rules above the rule that prevents direct connections to the Security Gateway (the Stealth Rule) to ensure that they have access to the Security Gateway

Authentication Methods

7 If required, adjust the Failed Authentication Attempts settings for Client Authentication in the

Authentication page of the Global Properties window

8 Install the security policy

Enabling 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 eliminates the need to open a new Telnet session in order to sign off and withdraw client

authentication privileges

To enable Wait mode:

1 From the Authentication page, edit the Check Point Gateway object that represents the Security Gateway and select Enable Wait Mode for Client Authentication In Client Authentication Wait mode,

the Security Gateway monitors the Telnet connection to port 259 of the gateway by pinging the user's host

2 Define rules to enable pinging as follows:

 Enable the echo-request service from the Security Gateway to the user's host

 Enable the echo-reply service from the user's host to the Security Gateway

Resolving Access Conflicts

When configuring users, you define those locations that they can access However, by doing so, you

disallow access to all unspecified locations, which can cause conflicts with security rules that require

authentication

For example, if a rule grants authenticated access to users from Marketing_net to Finance_net, but in the

user's Location tab connections are only permitted within Marketing_net, the firewall does not know whether

to allow the authentication request when the user tries to connect to Finance_net

You can specify how to resolve this conflict by editing the Authentication Action Property of this rule You can define this property for both the Source and Destination of the rule

To resolve access conflicts:

1 Right-click the Action field of a rule using some form of authentication and select Edit Properties

2 Do one of the following:

 To apply the more restrictive access privileges specified in the rule and in the Location tab of each user's User Properties window, select Intersect with User Database

 To allow access according to the location specified in the rule, select Ignore User Database

Authorizing All Standard Sign On Rules

By default, the Partially or Fully Automatic sign on methods open one rule following successful

authentication (the rule for which the sign on was initiated) For example, if a user successfully authenticates according an automatic sign on rule, the user can work with the services and destinations permitted only by that rule

You can configure Security Gateway to automatically open all Standard Sign On rules following successful authentication using Partially or Fully Automatic Sign On If a user successfully authenticates according to

an automatic sign on rule, then all Standard Sign On rules that define that user and source are available The user can then work with all of the services and destinations permitted by the relevant rules; the Security Gateway knows which user is at the client, and additional authentication is not necessary

To authorize all relevant Standard Sign On Rules following successful Partially or Fully Automatic

authentication, use the GUIdbedit Database Tool to change a setting in the database

To authorize all standard sign on rules:

1 Access the GUIdbedit Database Tool from the same directory on your local drive as where

SmartConsole is installed

2 Open GUIdbedit

3 Search for the automatically_open_ca_rules field

4 Set the value to true The new value takes effect after you install the security policy

Authentication Methods

Changing the Client Authentication Port Number

To change the Client Authentication port number:

1 Stop Check Point services by running the cpstop command

2 Modify the port number in the Manage > Service > Show > TCP Services window for the following

These are special Check Point services provided as part of the Client Authentication feature

3 Use a simple text editor to edit the $FWDIR/conf/fwauthd.conf file Change the port number of the

Client Authentication application to the same port number defined in step 2

4 Do one of the following:

 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

Important - Do not change anything else in these lines

5 Ensure that there is no rule that blocks the connection to the new port

6 Restart Check Point services by running the cpstart command

For additional information on configuring Client Authentication, see Configuring Client Authentication (on page 36)

Allowing Encrypted Client Authentication

To configure Encrypted Client Authentication for HTTPS Connections:

1 On the Security Gateway, execute cpstop on the Security Gateway

2 Edit fwauthd.conf, located in the $FWDIR/conf directory Add :defaultCert to the following line:

900 fwssd in.ahclientd wait 900 ssl:defaultCert

Note - defaultCert is a nickname included in the Certificate List on a

Security Gateway To check the nickname of your gateway, open the

VPN page of the Gateway Properties window and see the Certificates List

1 Save and close the file

2 Run cpstart

3 Open SmartDashboard

4 Create a rule following rule

Creating Users and Groups

Any user group Internal Web

server

https Client Auth

(Partially automatic or Manual mode)

Note - This Rule also permits HTTPS traffic between the client and the

Web server following successful authentication

5 Install the policy

Continue with the following procedure using the client browser

1 Using the client browser, enter https:// <gateway URL>:900

2 Click Yes to trust the Security Gateway certificate

3 Type the Security Gateway user name

4 Click OK

5 Click Yes

6 Enter the gateway password

7 Click Submit

8 Type the URL address: https://<Internal_Web_Server_IP_address>

9 Click Yes You are now authenticated on both to the Security Gateway and your internal Web server

Creating Users and Groups

Authentication rules are defined by user groups rather than individual users Therefore, you must first define users and then add them to groups in order to define authentication rules You can define users with the Security Gateway proprietary user database or with an LDAP server For details on incorporating LDAP,

refer to SmartDirectory (LDAP) and User Management in the R75 Security Management Administration

Guide (http://supportcontent.checkpoint.com/documentation_download?ID=11667)

The following procedure describes how to create a group, create Security Gateway user accounts from a template, add users to the group and install user information in the database For additional information on

creating users and groups, refer to the Security Management Overview in the R75 Security Management

Administration Guide (http://supportcontent.checkpoint.com/documentation_download?ID=11667)

Creating User Groups

To create a user group:

1 In SmartDashboard, select User Groups from the Users and Administrators tab of the Objects tree

2 Right-click and select New Group The Group Properties window opens

3 Assign the group a name

Creating a User Template

To create a user template:

1 In the SmartDashboard Objects tree, select the Users and Administrators tab

2 Right-click Templates and select New Template The User Template Properties window opens

3 Assign the template a name

4 In the Groups tab, add user groups All users in these groups will get the properties of this template

5 In the Authentication tab, select the appropriate authentication scheme for the user

6 In the remaining tabs, enter the required properties of the user template

After you create a template, any user that you create based on a given template inherits that template's properties, including membership in groups If you modify a template's properties, those changes will only affect future users created using that template Users previously created using that template are not

affected

Configuring Authentication Tracking

Creating Users

To create users:

1 In the Users branch of the objects tree, right-click and select Edit The User Properties window opens

2 Enter the user data You can change the properties that the user inherited from the template for that user only without changing the template

Installing User Information in the Database

Users and groups can be installed separately from the Rule Base, meaning that you can update users and groups without reinstalling the Rule Base

To install the user database, select Policy > Install Database from the SmartDashboard menu

Configuring Authentication Tracking

Successful and unsuccessful authentication attempts can be monitored in SmartView Tracker or using other tracking options, for example, email and alerts Authentication tracking can be configured for the following types of authentication attempts:

 Failed authentication attempts: Can be tracked for all forms of authentication

To track failed authentication attempts:

 In the Authentication page of a gateway object, set the Authentication Failure Track property to

define the tracking option when authentication failures occur

 Successful authentication attempts: Can be tracked for Client Authentication

To track successful authentication attempts:

1 In the Client Authentication Action Properties window, set the Successful Authentication Tracking

property to define the tracking option for all successful Client Authentication attempts

2 To set this option, right-click in the Action column of the Client Authentication rule The default setting is

Log

To track all authentication attempts:

1 Select an option in the Track column of any rule that uses some form of authentication The Set by

Rule tracking option can only be added 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 has no effect and failed authentication attempts are still logged in SmartView Tracker However, setting the rule to Alert causes an Alert to be sent for each failed authentication attempt

Configuring Policy for Groups of Windows Users

You can create policy rules for groups of users that are not defined on the Security Management Server, but are defined either on the Windows-based gateway host or in the Windows trusted domain

To configure policy for groups of Windows users:

1 Enable this feature using the Graphical Database Tool (GUIdbEdit)

2 Change the value of the add_nt_groups attribute to true (This attribute is located under the

firewall_properties object in the properties table.)

3 Ensure that the user belongs to a Windows user group

4 In the SmartDashboard, create a user group with the name: Windows_<Windows user group> The

group may be empty

5 Define a Generic User Profile for each user that uses an operating system password as its

authentication scheme