Download pdf - StoneGate Firewall Reference Guide 4.3

StoneGate Reference Guide

SMC 4.3 and Firewall/VPN 4.3

Legal Information

End-User License AgreementThe use of the products described in these materials is subject to the then current end-user license agreement, which can be found at the Stonesoft website:www.stonesoft.com/en/support/eula.html

General Terms and Conditions of Support and Maintenance ServicesThe support and maintenance services for the products described in these materials are provided pursuant to the general terms for support and maintenance services and the related service description, which can be found at the Stonesoft website:www.stonesoft.com/en/support/view_support_offering/terms/

Replacement ServiceThe instructions for replacement service can be found at the Stonesoft website:www.stonesoft.com/en/support/view_support_offering/return_material_authorization/

Hardware WarrantyThe appliances described in these materials have a limited hardware warranty. The terms of the hardware warranty can be found at the Stonesoft website:www.stonesoft.com/en/support/view_support_offering/warranty_service/

Trademarks and PatentsThe products described in these materials are protected by one or more of the following European and US patents: European Patent Nos. 1065844, 1259028, 1271283, 1289183, 1289202, 1313290, 1326393, 1379046, 1330095, 131711, 1317937 and 1443729 and US Patent Nos. 6,650,621; 6 856 621; 6,885,633; 6,912,200; 6,996,573; 7,099,284; 7,127,739; 7,130,266; 7,130,305; 7,146,421; 7,162,737, 7,234,166, 7,260,843, 7,280,540 and 7,302,480 and may be protected by other EU, US, or other patents, or pending applications. Stonesoft, the Stonesoft logo and StoneGate, are all trademarks or registered trademarks of Stonesoft Corporation. All other trademarks or registered trademarks are property of their respective owners.

SSL VPN Powered by PortWise

DisclaimerAlthough every precaution has been taken to prepare these materials, THESE MATERIALS ARE PROVIDED "AS-IS" and Stonesoft makes no warranty to the correctness of information and assumes no responsibility for errors, omissions, or resulting damages from the use of the information contained herein. All IP addresses in these materials were chosen at random and are used for illustrative purposes only.

Copyright © 2008 Stonesoft Corporation. All rights reserved. All specifications are subject to change.

Revision: SGRG_20080604

www.stonesoft.com/en/support/eula.html

www.stonesoft.com/en/support/view_support_offering/terms/index.html

www.stonesoft.com/en/support/view_support_offering/return_material_authorization/index.html

www.stonesoft.com/en/support/view_support_offering/warranty_service/index.html

Table of Contents

INTRODUCTION

CHAPTER 1 Using StoneGate Documentation 15

How to Use This Guide 16

Typographical Conventions 16Documentation Available 17Product Documentation 17Support Documentation 18System Requirements 18

Contact Information 18

Licensing Issues 18Technical Support 18Your Comments 18Other Queries 18

CHAPTER 2 What’s New? 19

New Features in SMC 4.3 20

New Features in Firewall/VPN 4.3 23

New Features in SOHO Firewalls 23

CHAPTER 3 General Firewall Principles 25

The Role of the Firewall 26

Hazards of Networking 26The Firewall as Protection 26Example Solution 27

Firewall Technologies 28

Packet Filters 28Proxy Firewalls 30Stateful Inspection 31StoneGate and Multi-Layer Inspection 31

Firewall Functions 33

Access Control 33

Monitoring and Logging 33Network Address Translation (NAT) 33Authentication 34Virtual Private Networks (VPN) 34Secure Socket Layer Virtual Private Networks (SSL

VPN) 34Content Screening and Unified Threat

Management 35

Requirements for Modern Firewalls 36

High Availability 36Scalability 37High Throughput 37Centralized Management 37

Firewall Weaknesses 38

Lack of Administration 38Internal Attacks 38

CHAPTER 4 StoneGate Architecture 39

StoneGate Security Platform Overview 40

StoneGate Components 41

StoneGate Management Center 43Management Server 43Log Servers 44Monitoring Server 44Management Clients 45

Firewall Engines 45SOHO Firewall Engines 46Certificates 46Licenses 47

StoneGate Main Features 47

Advanced Traffic Inspection 47Built-in Load Balancing and High Availability 48Integration with StoneGate IPS 48Multi-Link Technology 48QoS and Bandwidth Management 49

3

Reporting Tools 50Unified StoneGate Management Center 51Virtual Private Networks (VPNs) 51

CHAPTER 5 StoneGate Firewall/VPN Deployment 53

Deployment Overview 54

Firewall Deployment 55

Positioning Firewalls 55Internal Networks 55DMZ Network 56External Network 57

StoneGate Management Connections 59

Management Center Deployment 59

Positioning the Management Server 60Positioning Log Servers 60Positioning Management Clients 61

SETTING UP STONEGATE

CHAPTER 6 Management Client Basics 65

Introduction 66

General Tools 66

Main Toolbar 66Status Bar 67Element Search 67Bookmarks 68Online Help 69

System Status View 70

System Summary 70Status Tree 71Info Panel 71Graphical Monitoring 72

Overview 73

Status Icons and Colors 74

Configuration View 78

Logs View 79

Policy Editing View 82

CHAPTER 7 Administrator Accounts 85

Overview to Administrator Accounts 86

Configuration of Administrator Accounts 87

Default Elements 88Predefined Account with Unrestricted Permissions 88Predefined Administrator Roles 88Predefined Access Control Lists 88

Configuration Workflow 89Task 1: Create a New Administrator Role 89Task 2: Create a New Access Control List 89Task 3: Configure Administrator Password Policy 90Task 4: Create a New Administrator Element or Monitoring User Element 91

Using Administrator Accounts 92

Customizing Log Color Settings 92RADIUS Authentication 92

Examples of Administrator Accounts 92

Creating Accounts with Predefined Administrator Roles 93

Creating Accounts with a New Access Control List 93

CHAPTER 8 Network Elements and Services 95

Introduction to Network Elements and Services 96

Network Element Types 96

Address Range Elements 96Alias Elements 96Expression Elements 97Firewall Elements 97

SOHO Firewall Element 97Single Firewall Element 97Firewall Cluster Element 98

Group Elements 98Host Elements 98IPS Elements 98SSL VPN Elements 98Network Elements 98Router Elements 99

4

Server Elements 99Management Server Element 99Log Server Elements 99Authentication Server Elements 99Active Directory Server Elements 99LDAP Server Elements 100Content Inspection Server (CIS) elements 100DNS Server Elements 100DHCP Server Element 100Monitoring Server Element 100

Traffic Handler Elements 100NetLink 100Multi-Link 101Server Pool 101

Services 101

CHAPTER 9 SOHO Firewall Configuration 103

Overview to SOHO Firewall Configuration 104

Configuration of SOHO Firewalls 104

Default Elements 105Configuration Workflow 105

Task 1: Create SOHO Firewall Element(s) 105Task 2: Select the Interface Types 106Task 3: Define the Interface Settings 106Task 4: Define General Wireless Channel Settings 106Task 5: Configure the Main Site Firewall 106Task 7: Install the SOHO Firewall Appliance 107

Using a SOHO Firewall 107

Configuring Wireless Connections 107

Example of a SOHO Firewall Deployment 109

Setting up Several SOHO Firewalls 109

CHAPTER 10 Single Firewall Configuration 111

Overview to Single Firewall Configuration 112

Configuration of Single Firewalls 112

Dynamic Firewall Interface Addresses 112Configuration Workflow 113

Task 1: Create a Single Firewall Element 113Task 2: Define Physical Interfaces 113Task 3: Define VLAN Interfaces 113Task 4: Define IP Addresses 114

Task 5: Install the Firewall Engine 114Task 6: Install a Firewall Policy 114

Using a Single Firewall 115

Using Multi-Link 115Internal DHCP Server 115Running Automatic Tests 116Sending SNMP Traps 117

Example of a Single Firewall Deployment 117

Setting up a Single Firewall 117Adding a New Interface to an Existing

Configuration 118

CHAPTER 11 Firewall Cluster Configuration 121

Overview to Firewall Cluster Configuration 122

Benefits of Clustering 122Communication Between the Nodes 122Hardware 123

Configuration of Firewall Clusters 123

Load Balancing 123Standby Operation 124Network Interfaces 124Clustering Modes 125Configuration Workflow 127

Task 1: Create a Firewall Cluster Element 127Task 2: Create Physical Interfaces 127Task 2: Define VLAN Interfaces 127Task 3: Configure Interfaces 128Task 4: Install the Firewall Engines 129Task 5: Install a Firewall Policy 129

Using a Firewall Cluster 129

Using Multi-Link 130Using VLANs 131Running Automatic Tests 132Sending SNMP Traps 133Advanced Configuration of Clustering 134

Tuning Node Synchronization 134Security Level for State Synchronization 135About Manual Load Balancing 136

Examples of Firewall Cluster Deployment 137

5

Setting up a Firewall Cluster 137Adding a Node to a Firewall Cluster 139

CHAPTER 12 Routing and Antispoofing 141

Overview to Routing and Antispoofing 142

Configuration of Routing and Antispoofing 142

Routing on Single and Clustered Firewalls 142Routing on SOHO Firewalls 143Reading the Routing and Antispoofing Trees 143Multi-Link Routing for Single and Clustered

Firewalls 145Default Elements 145Configuration Workflow 146

Task 1: Add Router or NetLink 146Task 2: Add Network(s) 146Task 3: Modify Antispoofing Rules 146Task 4: Refresh Firewall Policy 147

Using Routing and Antispoofing 147

Policy Routing 147Static IP Multicast Routing 147Modifying Antispoofing 147

Examples of Routing 148

Routing Traffic with Two Interfaces 148Routing Internet Traffic with Multi-Link 148Routing Traffic to Networks That Use Same Address

Space 149

ACCESS CONTROL POLICIES

CHAPTER 13 Firewall Policies 153

Overview to Firewall Policies 154

Policy Hierarchy 154How StoneGate Examines the Packets 154

Configuration of Policy Elements 156


Task 1: Create a Template Policy 158Task 2: Create a Policy 159Task 3: Create a Sub-Policy 159

Task 4: Add Rules 161Task 5: Validate the Policy 161Task 6: Install the Policy 161

Using Policy Elements 162

Connectionless Packet Inspection 162Continue Rules 162Policy Snapshots 162

Examples of Policy Element Use 163

Protecting Essential Communications 163Improving Readibility and Performance 163Restricting Administrator Editing Rights 164

CHAPTER 14 Access Rules 165

Overview to Access Rules 166

Configuration of Access Rules 167

Considerations for Designing Access Rules 169Default Elements 169Configuration Workflow 171

Task 1: Define the Source and Destination 171Task 2: Define the Service 171Task 3: Select the Action 172Task 4: Select Rule Options 173Task 5: Add User Authentication 174Task 6: Restrict the Time When the Rule Is En-forced 175Task 7: Restrict the Rule Match Based on Source VPN 175

Using Access Rules 175

Adding Comments to Rules 175Allowing System Communications 175Configuring Default Settings for Several Rules 176

Using Continue Rules to Set Logging Options 177Using Continue Rules with Protocol Agents 177

Using Aliases in Access Rules 178Validating Rules 178

Examples of Access Rules 178

Example of Rule Order 178Example of Continue Rules 180

CHAPTER 15 Inspection Rules 183

Overview to Inspection Rules 184

6

Configuration of Inspection Rules 184

Considerations for Designing Inspection Rules 187


Task 1: Add Situations 188Task 2: Limit the Situations by Severity 189Task 3: Define the Source and Destination 189Task 4: Define the Protocol 189Task 5: Select the Action 190Task 6: Set the Options for the Rule 190Task 7: Restrict the Time When the Rule is En-forced 191

Using Inspection Rules 191

Adding Comments to Inspection Rules 191Setting Default Options for Several Inspection

Rules 191Validating Rules 191

Example of Inspection Rules 191

Eliminating a False Positive 191

CHAPTER 16 Network Address Translation (NAT) Rules 193

Overview to NAT 194

Static Source Translation 194Dynamic Source Translation 195Static Destination Translation 196Destination Port Translation 196

Configuration of NAT 197

Considerations for Designing NAT Rules 198Default Elements 199Configuration Workflow 199

Task 1: Define Source, Destination, and Service 199Task 2: Define Address Translation 199Task 3: Define the Firewall(s) that Apply the Rule 200Task 4: Check Other Configurations 200

Using NAT and NAT Rules 200

NAT and System Communications 201Example of a Situation Where a Contact Address is Needed 201

Contact Addresses and Locations 202Outbound Load Balancing NAT 203Proxy ARP and NAT 203Protocol Agents and NAT 204Validating NAT Rules 204

Examples of NAT 204

Dynamic Source Address Translation Example 204Static Address Translation Example 205NAT with Hosts in the Same Network 205

CHAPTER 17 Protocol Agents 207

Overview to Protocol Agents 208

Connection Handling 208Protocol Validation 209NAT in Application Data 209

Configuration of Protocol Agents 209

Configuration Workflow 210Task 1: Create a Custom Service with a Protocol Agent 210Task 2: Set Parameters for the Protocol Agent 210Task 3: Insert the Service in Access Rules 210

Using Protocol Agents 211

FTP Agent 211H.323 Agent 212HTTP Agents 213ICMP Agent 214MSRPC Agent 214NetBIOS Agent 215Oracle Agent 215Remote Shell (RSH) Agent 216Services in Firewall Agent 217SIP Agent 217SMTP Agent 218SSH Agent 218SunRPC Agent 219TCP Proxy Agent 219TFTP Agent 220

Examples of Protocol Agent Use 221

Preventing Active Mode FTP 221

7

Logging URLs Accessed by Internal Users 221

CHAPTER 18 User Authentication 223

Overview to User Authentication 224

Configuration of User Authentication 226

User Databases 226Authentication Services 228Default Elements 228Configuration Workflow 229

Task 1: Create an External Authentication Server Element 229Task 2: Create an External LDAP Server Element 229Task 3: Create an Authentication Service Element 230Task 4: Add a Domain 230Task 5: Add Users and User Groups 230Task 6: Add Authentication to Access Rules 231

Using Authentication 232

RADIUS Authentication 232TACACS+ Authentication 233

Examples of User Authentication 233

Using the Internal Database for Authenticating Users 233

Using StoneGate with a Microsoft Active Directory Server 234

Using SecurID Authentication with StoneGate VPN Clients 234

CHAPTER 19 Virus Scanning 237

Overview to Virus Scanning 238

Configuration of Virus Scanning 238

Configuration Workflow 238Task 1: Activate the Anti-Virus Feature for a Fire-wall 238Task 2: Select Traffic for Inspection with Access Rules 238

Using Virus Scanning 239

Integrated Scanning vs. a Content Inspection Server 239

Limitations of Virus Scanning on Clusters 239

CHAPTER 20 Content Inspection 241

Overview to Content Inspection 242

Configuration of Content Inspection 243


Task 1: Create a CIS Server Element 244Task 2: Create a Custom Service for Content In-spection Server Redirection 244Task 3: Define Access Rules for Redirection 244Task 4: Configure NAT Rules for Content Inspec-tion Server Redirection 245

Using Content Inspection 245

Example of Content Inspection 247

Inspecting Internal User’s Web Browsing and File Transfers 247

CHAPTER 21 Situations 249

Overview to Situations 250

Configuration of Situations 250

Situation Contexts 251Protocol-Specific Contexts 251System Contexts 252


Task 1: Create a Custom Situation Element 252Task 2: Add a Context for the Situation 252Task 3: Associate Tags with the Situation 253Task 4: Associate the Situation with a Vulnerability 253

Using Situations 253

Examples of Custom Situations 254

Detecting the Use of Forbidden Software 254

CHAPTER 22 Blacklisting 255

Overview to Blacklisting 256

Risks of Blacklisting 256Whitelisting 256

Configuration of Blacklisting 257

Configuration Workflow 257Task 1: Define Blacklisting in Access Rules 258

8

Task 2: Define Analyzer-to-Firewall or Analyzer-to-Sensor Connections 258Task 3: Define Inspection Rules in the IPS Policy 258

Using Blacklisting 258

Manual Blacklisting 259Monitoring Blacklisting 259

Examples of Blacklisting 259

Blacklisting Traffic from a Specific IP Address Manually 259

Automatic Blacklisting with IPS 260

TRAFFIC MANAGEMENT

CHAPTER 23 Multi-Link Configuration 263

Overview to Multi-Link Configuration 264

Configuration of Multi-Link 264

Load Balancing 265Standby NetLinks for High Availability 265NetLink Monitoring 266Configuration Workflow 266

Task 1: Create NetLink Elements 266Task 2: Configure Routing for NetLinks 267Task 3: Combine NetLinks into Outbound Multi-Link Elements 267Task 4: Create Access Rules to Apply QoS Class 267Task 4: Create NAT Rules for Outbound Traffic 267

Using Multi-Link 268

Using Multiple Outbound Multi-Link elements 268

Examples of Multi-Link 268

Preparing for ISP Breakdown 268Save and install the policy to transfer the changes

to the engine. 269Excluding a NetLink from Handling a QoS Class of

Traffic 269Balancing Traffic According to Link Capacity 269Balancing Traffic between Internet

Connections 270

CHAPTER 24 Server Pool Configuration 271

Overview to Server Pool Configuration 272

Configuration of Server Pools 272

Multi-Link for Server Pools 273Default Elements 274Configuration Workflow 274

Task 1: Define Hosts 274Task 2: Combine Hosts into a Server Pool Element 274Task 3: Configure the External DNS Server 274Task 4: Create an Inbound Load Balancing Rule 275Task 5: Set up Server Pool Monitoring Agents 275

Using Server Pools 275

Dynamic DNS (DDNS) Updates 275Using Server Pool Monitoring Agents 276

Examples of Server Pools 278

Load Balancing for Web Servers 278Setting up Multi-Link and Dynamic DNS

Updates 279

CHAPTER 25 Bandwidth Management and Traffic Prioritization 281Overview to Bandwidth Management and Traffic

Prioritization 282

Bandwidth Management 282Traffic Prioritization 282Effects of Bandwidth Management and

Prioritization 283

Configuration of Limits, Guarantees and Priorities for Traffic 283


Task 1: Define QoS Classes 285Task 2: Define QoS Policies 285Task 3: Assign QoS Classes to Traffic 286Task 4: Define QoS for Firewall Interfaces 286

Using Bandwidth Management and Prioritization 287

Implementation Options 287Designing QoS Policies 288Assigning QoS Classes to Traffic 288

9

Communicating Priorities with DSCP Codes 289Managing Bandwidth of Incoming Traffic 290

Examples of Bandwidth Management and Prioritization 291

Ensuring Quality of Important Communications 291

Preparing for ISP Breakdown 292Limiting the Total Bandwidth Required 293

LOGS, ALERTS, AND REPORTS

CHAPTER 26 Filters 297

Overview to Filters 298

Configuration of Filters 298

Matching Log Data with Filters 299Default Elements 299Configuration Workflow 300

Task 1: Create a New Filter 300Task 2: Select Fields 300Task 3: Select Operations 301Task 4: Add Field Values 303Task 5: Define Handling of Missing Fields 303Task 6: Define A Type for the Filter 305

Using Filters 305

Temporary Filters and Browsing Logs Interactively 306

Examples of Filters 306

Creating a Temporary Filter in the Logs View 306Creating a Filter for Logs Concerning Authenticated

Users 306Creating a Filter for Pings in a Network Excluding a

Host 306

CHAPTER 27 Log Management 309

Overview to Log Management 310

Logs View 310Log Entries 310Alert Entries 310Audit Entries 311

Configuration of Log Management 311


Task 1: Set Log Spooling Policy 313Task 2: Set Logging Options 314Task 3: Configure Log Pruning 315Task 4: Define Log Tasks 316

Using Log Management 317

Log Files 318Additional Archive Directories 318Enabling/Disabling Diagnostics 318Acknowledging Alerts 318Alert Escalation 319Exporting Log Data to Syslog Servers 319

Examples of Log Management 319

Archiving Old Logs 319Filtering Out Irrelevant Logs 320

CHAPTER 28 Alert Escalation 323

Overview to Alert Escalation 324

Configuration of Alert Escalation 324

Default Elements 325Default System Situations 326

Configuration Workflow 326Task 1: Define Custom Alerts 326Task 2: Define Alert Chains 326Task 3: Define Alert Policies 328Task 4: Configure Alert Channels 329

Using Alert Escalation 330

Designing Alert Policies and Alert Chains 330Using a Custom Script for Alert Escalation 331

Examples of Alert Escalation 332

Disabling All Alert Escalation for a Specific Situation 332

Escalating Alerts Based on Responsibilities 333

CHAPTER 29 Reports 335

Overview to Reports 336

Configuration of Reports 337

Default Elements 339

10

Configuration Workflow 340Task 1: Create a New Report Design 340Task 2: Define the Report Design’s Properties 341Task 3: Select Report Sections 342Task 4: Select Report Items 343

Using Reports 344

Generating Reports 344Using Filters with Reports 345Exporting Reports 345

PDF Report Files 345Tab-Delimited Text Report Files 346Post-Processing Report Files 348

Using the System Report 349

Examples of Reports 349

Creating a New Report Design from Predefined Report Designs 349

Creating a Report of VPN Users 349

VIRTUAL PRIVATE NETWORKS

CHAPTER 30 Overview to VPNs 353

Introduction to VPNs 354

IPsec VPNs 355

Tunnels 355Security Associations (SA) 355Internet Key Exchange (IKE) 355Perfect Forward Secrecy (PFS) 356AH and ESP 356Authentication 357Tunnel and Transport Modes 358

VPN Topologies 358

CHAPTER 31 VPN Configuration 361

Overview to VPN Configuration 362

Configuration of VPNs 362

VPN Certificates 364The Internal Certificate Authority 365External Certificate Authorities 365Certificate Revocation Lists 365


Task 1: Define the Gateway Settings 367Task 2: Define the Gateway Profile 367Task 3: Define the Security Gateways 367Task 4: Define the Protected Sites 368Task 5: Create Certificates 368Task 6: Define the VPN Profile 369Task 7: Define the VPN Element 369Task 8: Modify the Firewall Policy 370Task 9: Configure VPN Clients and External Gate-ways 372

Using VPNs 372

VPN Logs 372Using a Dynamic IP Address for a VPN

Endpoint 372Using a NAT Address for a VPN Endpoint 373Supported Authentication and Encryption

Methods 373Message Digest Algorithms 374Authentication Methods 375Encryption Algorithms 376FIPS 140-2 Mode 377

Configuring VPNs with External Gateways 377Clustering and VPNs 379Multi-Link VPN 379

Examples of VPN Configurations 380

Creating a VPN Between Three Offices 380Creating a VPN for Mobile Users 382Creating a VPN when NAT Is Used 383

ADMINISTRATION

CHAPTER 32 Categories 389

Overview to Categories 390

Configuration of Categories 390


Task1: Create Categories 390Task 2: Associate Elements with Categories 391Task 3: Select a Category to Filter the Displayed El-

11

ements 391

Using Categories 391

Examples of Categories 392

Creating Separate Categories for Different Sites 392

Combining Categories 392

CHAPTER 33 Incident Cases 393

Overview to Incident Cases 394

Configuration of Incident Cases 394

Configuration Workflow 394Task 1: Create an Incident Case 394Task 2: Attach Data 395Task 3: Attach Players 395Task 4: Write Journal Entries 395Task 5: Close the Incident Case 395

Using Incident Cases 396

Investigation by One Administrator 396Investigation by More Than One Administrator 396Investigation of a False Positive 396

Example of an Incident Case 397

APPENDICES

APPENDIX A StoneGate-Specific Ports 401

APPENDIX B Command Line Tools 407

APPENDIX C Predefined Aliases 423

APPENDIX D Regular Expression Syntax 427

APPENDIX E Log Field Values 439

APPENDIX F Schema Updates for External LDAP Servers 457

APPENDIX G Advanced Log Server Configuration 459

APPENDIX H Server Pool Monitoring Agents 465

APPENDIX I SNMP Traps and MIBs 483

APPENDIX J Guidelines for Building Network Security 497

APPENDIX K Multicasting 505

Legal Information 513

Glossary 529

Index 563

12

Introduction

CHAPTER 1 Using StoneGate Documentation

Welcome to StoneGate™ High Availability Firewall/VPN solution by Stonesoft Corporation. This chapter describes how to use this Guide and related documentation. It also provides directions for obtaining technical support and giving feedback about the documentation.

The following sections are included:

How to Use This Guide, on page 16 Documentation Available, on page 17 Contact Information, on page 18

15

How to Use This GuideThis StoneGate Reference Guide provides information that helps administrators of StoneGate installations to understand the system and its features. It provides descriptions of all the configuration tools and gives examples on what you can do with the system.This guide is divided into several sections. The chapters in the first section provide a general introduction to StoneGate and firewalls. The sections that follow each include the chapters related to one feature area. The last section provides detailed reference information in tabular form, and some guideline information.For other available documentation, see Documentation Available, on page 17.

Typographical ConventionsThe following typographical conventions are used throughout the guide:

We use the following ways to indicate important or additional information:

Note – Notes provide important information that may help you complete a task.

Caution – Cautions provide important information that you must take into account before performing an action to prevent critical mistakes.

Tip: Tips provide information that is not crucial, but may still be helpful.

TABLE 1.1 Typographical Conventions

Formatting Informative Uses

Normal text This is normal text.

User Interface textText you see in the User Interface (buttons, menus, etc.) and any other interaction with the user interface are in bold-face.

References, termsCross-references and first use of acronyms and terms are in italics.

Command lineFile names, directories, and text displayed on the screen are monospaced.

User input User input on screen is monospaced bold-face.

Command parametersCommand parameter names are in monospaced italics.

16 Chapter 1: Using StoneGate Documentation

Documentation AvailableStoneGate technical documentation is divided into two main categories: Guide Books and Support Documentation. StoneGate Firewall/VPN and StoneGate IPS have their separate sets of manuals, despite the fact that they are managed through the same user interface. Only the Administrator’s Guide and the Online Help system cover both the Firewall/VPN and IPS products.

Product DocumentationThe table below lists the available product documentation.

PDF versions of the guides are available on the Management Center CD-ROM and at http://www.stonesoft.com/support/.

TABLE 1.2 Product Documentation

Guide Description

Reference Guide

Explains the operation and features of StoneGate comprehensively. Demonstrates the general workflow and provides example scenarios for each feature area. Available for StoneGate Firewall/VPN and StoneGate IPS.

Installation GuideInstructions for planning, installing, and upgrading a StoneGate system. Available for StoneGate Firewall/VPN and StoneGate IPS.

Online Help

Detailed instructions for the configuration and use of StoneGate. Accessible through the Help menu and by using the Help button or the F1 key in any window or dialog. Available in the StoneGate Management Client and the StoneGate Monitoring Client. An HTML-based system is available in the StoneGate SSL VPN Administrator through help links and icons.

Administrator’s Guide

Describes how to configure and manage a StoneGate system step-by-step. Available as a combined guide for both StoneGate Firewall/VPN and StoneGate IPS, and as separate guides for StoneGate SSL VPN and StonGate IPsec VPN Client.

User’s GuideInstructions for end-users. Available for the StoneGate IPsec VPN Client and the StoneGate Monitoring Client.

Appliance Installation GuideInstructions for physically installing and maintaining StoneGate appliances (rack mounting, cabling etc.). Available for all StoneGate hardware appliances.

How to Use This Guide 17

http://www.stonesoft.com/support/

Support DocumentationThe StoneGate support documentation provides additional and late-breaking technical information. These technical documents support the StoneGate Guide books, for example, by giving further examples on specific configuration scenarios.The latest StoneGate technical documentation is available on the Stonesoft website at http://www.stonesoft.com/support/.

System RequirementsThe system requirements for running StoneGate, including the approved network interfaces, supported operating systems, and other such hardware and software requirements for StoneGate engines and the Management Center can be found at http://www.stonesoft.com/en/products_and_solutions/products/fw/Certified_Servers/ (see the technical requirements section at the bottom of the page).The hardware and software requirements for the version of StoneGate you are running can also be found in the Release Notes included on the Management Center CD-ROM and on the software download page at the Stonesoft website.

Contact InformationFor street addresses, phone numbers, and general information about StoneGate and Stonesoft Corporation, visit our website at http://www.stonesoft.com/.

Licensing IssuesYou can view your current licenses at the License Center section of the Stonesoft website at https://my.stonesoft.com/managelicense.do.For license-related queries, e-mail [email protected].

Technical SupportStonesoft offers global technical support services for Stonesoft’s product families. For more information on technical support, visit the Support section at the Stonesoft website at http://www.stonesoft.com/support/.

Your CommentsWe want to make our products fulfill your needs as well as possible. We are always pleased to receive any suggestions you may have for improvements.• To comment on software and hardware products, e-mail [email protected].• To comment on the documentation, e-mail [email protected].

Other QueriesFor queries regarding other matters, e-mail [email protected].

18 Chapter 1: Using StoneGate Documentation


http://www.stonesoft.com

https://my.stonesoft.com/managelicense.do

mailto:[email protected]





http://www.stonesoft.com/en/products_and_solutions/products/fw/Certified_Servers/


CHAPTER 2 What’s New?

This section lists major changes since the previous release. Most new or reworked features in the software are listed here. Changes that do not significantly affect the way StoneGate is configured are not listed. For a full list of changes in the software, consult the Release Notes.


New Features in SMC 4.3, on page 20 New Features in Firewall/VPN 4.3, on page 23 New Features in SOHO Firewalls, on page 23

19

New Features in SMC 4.3

Administrator Account ImprovementsYou can now activate password quality checks that enforce password guidelines for Administrator accounts. You can also activate automatic logging out of administrators that have been inactive for a set period of time.• For more details, see Administrator Accounts, on page 85.

Automatic License UpgradeStoneGate licenses indicate a maximum software version that the license entitles you to install. You can now activate automatic checks for new license versions and have the licenses upgraded automatically to the highest available version that your organization is entitled to. When you are ready to upgrade the software, there is no need for manual license upgrades.• For more details, see the Administrator’s Guide or the Online Help.

Automatic Memory AllocationDue to restrictions of the Java platform, the memory allocations for the StoneGate Management Center servers are fixed. In some cases, the default allocations were not sufficient and administrators had to edit configuration files manually. Now, the installer checks the available memory and automatically increases the allocations if there is enough memory installed. A minor portion of the memory is left unallocated for the system to use. This is done at each installation and upgrade.It is still possible to edit the configuration files manually in the rare cases that further adjustments are needed. For the minimum requirements, see the SMC Release Notes.• For more details on editing the memory allocations manually, visit the StoneGate

Technical Knowledge Base at www.stonesoft.com/support.

Antispoofing Configuration ImprovementAntispoofing now allows setting network definitions as “Absolute”. When the option is set, antispoofing allows all addresses included in the network even if there is a more specific definition for some address behind a different interface.• For more details, see the Administrator’s Guide or the Online Help.

Bookmark ImprovementsYou can now add your bookmarks into the main toolbar in the Management Client. This allows you to customize the toolbar shortcuts to give you quick access to any view.The separate sidebar for managing Bookmarks has been removed, and bookmarks can now be managed in the same way as other elements in the Configuration view, in a dedicated Bookmarks branch of the element tree.• For more details, see the Administrator’s Guide or the Online Help.

20 Chapter 2: What’s New?


Diagram ImprovementsThere are now two types of diagrams: IP Diagrams for network topology documentation and Connectivity Diagrams for monitoring the system components and system communications graphically. Both types of diagrams can be generated automatically. By default, Connectivity Diagrams are generated automatically as you select components in the System Status view.• For more details, see the Administrator’s Guide or the Online Help.

Hardware Monitoring for StoneGate AppliancesYou can now monitor the hardware status (such as fan speed, temperature, RAID and NIC status) of compatible StoneGate appliances through the Management Client. All appliances do not provide all types of information. All appliance models are not supported. This feature requires Firewall/VPN and IPS engine software version 4.3.• For more details, see Management Client Basics, on page 65.

Log Browsing ImprovementsThere is a new way to browse log entries in the Logs view. The customizable Details view fills the main panel with an overview of one log entry at a time. This format allows you to see all necessary details related to that entry at one glance.The log entry table has a new Service column that shows the Service that corresponds to the traffic in the log entry. The log entries’ columns can now resolve the data for display as StoneGate elements (active by default) for a clearer, more visual display.• For more details, see the Administrator’s Guide or the Online Help.

Policy Handling ImprovementsUsefulness of the rule tags that identify rules has been improved: the rule tag now contains a static part that allows the rule to be identified and linked to even after it has been edited. Each rule tag also has a new variable part that marks the revisions of the rule, but which is ignored when a static reference to the rule is needed.

Example: A rule tag that reads @123.5 will change to @123.6 when the rule is edited.You can now select several consecutive Access Rules in a policy and create a Sub-Policy out of them through the right-click menu.Also, history information is now available for individual rules (Info panel).• For more details, see the Administrator’s Guide or the Online Help.

Policy ValidationYou can now run various validation checks in the policy views and at policy installations. The checks include, for example, searches for duplicate rules and rules that can never match because of the policy structure.

New Features in SMC 4.3 21

The warnings and errors displayed at policy installation are now shown in a separate panel from the policy installation progress display. You can disable warnings related to rule validation based on rule or issue type.• For more details, see the Administrator’s Guide or the Online Help.

Printing ChangesDirect printing is being progressively phased out. Instead, a “Print to PDF” action is used to provide a more versatile and reliable output across the various supported platforms. A PDF reader (such as the free Adobe Acrobat Reader) must be installed on the computer that runs the Management Client to view and print out the information.

Search for Unused ElementsThere is a new search tool that allows you to list all elements in the system that are not used in any configuration, and may therefore be potentially obsolete. This helps you clean up the system of unnecessary clutter.• For more details, see the Administrator’s Guide or the Online Help.

Statistics ImprovementsNew Overviews are collections of Statistical charts and tables, which you can arrange in a grid for easy monitoring of several statistical charts at once. You can save several Overviews to have quick access to different favorite displays. The Overviews make obsolete the single statistical chart that was previously shown in the Status/Statistics view (that view is now called System Status view to reflect its new role).Some new statistical items are available for information that is derived from log data.You can now also select one of a few available Statistical items for display in the Info view of an engine.• For more details, see Management Client Basics, on page 65.

StoneGate SSL VPN Logs and Monitoring IntegrationYou can now connect your StoneGate SSL VPN appliance to the Management Center to centrally monitor the status and logs of the SSL VPN appliances. Any changes to the SSL VPN configuration are still done through a Web browser as before. This feature requires SSL VPN engine software version 1.2.• For more details, see the Administrator’s Guide or the Online Help.

System ReportA new type of report is available. The System report gathers information about the StoneGate configuration and formats it into a summary. The report helps you check the system’s correspondence to internal guidelines and provide information required by external auditors.• For more details, see Reports, on page 335.


Tools Icon MenuMany of the view-specific actions that had their own icon in a secondary toolbar have now been collected into a view-specific menu that opens through a Tools icon that depicts a spoked wheel. The menu displays a textual label along with the icons, making it easier to see all available actions at a glance.

New Features in Firewall /VPN 4.3

Deep Inspection - Support for Additional ProtocolsDeep inspection now supports also the IMAP, POP3, and SMTP protocols in addition to the previously supported protocols (SIP and HTTP). To activate deep inspection for these protocols, activate deep inspection for these protocols in the Access Rules and make sure the Inspection Rules cover the relevant Situations.

DHCP ServerSingle firewalls now have an integrated DHCP server for assigning IP addresses to local clients.• For more details, see the Administrator’s Guide or the Online Help.

Virus ScanningIntegrated anti-virus is now available as part of the StoneGate UTM appliance solution.• For more details, see Virus Scanning, on page 237.

New Features in SOHO Firewalls

Direct Internet Access Blocking for Corporate InterfacesThe Corporate interface type previously always allowed direct outgoing connections to the Internet. Starting from SMC 4.2.3, there is an option to either allow or disallow direct Internet connections (access to/from the VPN tunnel is still always allowed).• For more details, see the Administrator’s Guide or the Online Help.

New Features in Firewall/VPN 4.3 23


CHAPTER 3 General Firewall Principles

This chapter introduces and discusses the underlying security principles of firewalls in general. In this chapter we will discuss what firewalls are, which different types of firewalls there are, how they are used, what they are capable of, as well as what their possible weaknesses are.


The Role of the Firewall, on page 26 Firewall Technologies, on page 28 Firewall Functions, on page 33 Requirements for Modern Firewalls, on page 36 Firewall Weaknesses, on page 38

25

The Role of the FirewallIt is difficult to give an all-inclusive, yet simple definition of a firewall, but here we shall present some outlines that help form a picture of features and functions they have. First, we’ll take a look at which types of threats—in addition to the opportunities—the modern network environment contains, and how firewalls can respond to these concerns.

Hazards of NetworkingInternet can be seen today both as an opportunity and a threat. Today, as corporations are more and more dependent on their Internet connections, they are also becoming more and more frequently attacked from the outside by way of exploiting those very connections; be it by adventurous hackers or professional information thieves.In general, it could be said that there is no rhyme or reason to network attacks, and no network is small enough to be safe. Any system can become the target of an attacker, and no matter what the motives for the attack are, the consequences can be severe. Attackers may grab data to sell as mailing lists, to use for credit or financial access, to add to corporate profiles, or to cripple competitors. They may take over computing resources and use them for their financial gain. They may also destroy data for many reasons, including vindictiveness, an urge to show off, or even just boredom.In addition to such external attacks, internal network attacks are also a serious issue. Although firewalls can limit access between any separate networks, it is beyond the scope of firewalls to give protection against attacks by authorized persons located within the protected network. Other aspects of the corporate security policy must cover that type of risk.You do not want unauthorized parties to get their hands on confidential data. You also want to ensure that information remains intact, so that no one can alter crucial data unnoticed. And of course, you want your data and resources to be available whenever needed. These three parameters—confidentiality, integrity, and availability—are the main goals of any credible security policy. Firewalls can help to achieve these objectives in the network environment by blocking unauthorized persons from having access to sensitive data, computer memory and processing power.

The Firewall as ProtectionThe advantages of the Internet in communication and business cannot be attained without proper protection from hostile attackers and without confidence that private information remains private. Firewalls are a cornerstone in the defense strategy that aims at eliminating the misuse of confidential data and resources by any unauthorized parties. A firewall is just one, albeit important, element in the overall corporate security policy.Firewalls regulate communication on data networks; or more precisely, between networks with different security levels. Their main purpose is to control the traffic that passes through from one network to another, and deny access to network resources

26 Chapter 3: General Firewall Principles

from undesired or potentially harmful packets and connections—as far as they are distinguishable from allowed traffic. Although an advanced firewall can do much more than filter packets based on sources and destinations, some threats are most efficiently tackled by complimenting the firewall with intrusion detection or intrusion prevention systems (IDS/IPS), content inspection servers (CIS), and anti-virus gateways.The principle of access control is ideally expressed as whatever is not expressly permitted is denied. By default, nobody and nothing must be permitted entry to the protected network. That means that in order for any traffic to be allowed into the network, it must first satisfy a specifically designed rule that permits limited access. Typically, internal network clients are granted a more unrestricted access to external networks, but outbound connections must also be controlled.Some advantages that firewalls can provide include:• Firewalls can protect the corporate intranet from undesired traffic, including

everything from malicious attackers to unsolicited e-mail (spam), on the basis of the corporate security policy implemented by the network administrators.

• Firewalls can secure sensitive corporate information and resources within a local area network (LAN). This insulates departments such as Research & Development, or Human Resources from other company departments, limiting the access within any one area to authorized users only.

• Firewalls can concentrate network security policies at a single point, a “choke point”. When policies or administrators change, the instructions, configurations, and passwords need only be changed in one place. One must, however, ensure that the firewall doesn’t turn out to be a single point of failure.

Firewalls can also be used for other purposes, such as monitoring network traffic and the use of network resources, authenticating users, managing network bandwidth and implementing virtual private networks (VPN). These functions will be covered in more detail in section Firewall Functions, on page 33 and in subsequent chapters.The firewall offers a reasonable amount of protection against Internet intruders, on the condition that the security policies enforced by the firewalls are carefully designed, and there are no loopholes or back doors. Firewalls can only control traffic that actually passes through them; even the most carefully planned firewall system is undermined by a single back door—say, a modem connection from the intranet to the Internet—that allows traffic to circumvent the firewall. See Appendix J, Guidelines for Building Network Security for background information on designing network security.

Example SolutionFigure 3.1 illustrates an example scenario where the demilitarized zone (DMZ) contains a publicly available pool of servers protected by a firewall. Other firewalls guard particularly sensitive networks within the company intranet, such as those of the Research and Development, Human Resources, and Accounting departments. This multi-layer protection is called defense in depth.

The Role of the Firewall 27

Illustration 3.1 An Example Firewall Deployment in a Corporate Network

This type of solution means there is no direct access from the Internet into the internal network. Anyone trying to access internal resources from the Internet would have to pass through at least one firewall. For example, a company mail server can be located on the firewall-protected DMZ, allowing SMTP-based traffic to that machine but not to the protected intranet.

Firewall TechnologiesOn the firewall market there is a wide range of both software-based and hardware-based firewall solutions from lightweight, personal firewalls to scalable enterprise-wide systems. Software-based solutions are usually installed on standard hardware, whereas hardware-based appliances are typically proprietary in nature. Either way, the firewalls can be categorized by the way they handle network traffic. In this section we give an overview of the existing firewall technologies, and show you how StoneGate fits on that map.Traditionally, firewalls can be divided into three main groups:• packet filtering firewalls• application-level proxy firewalls• stateful inspection firewalls.Next, we will briefly compare each technology, and bring out their fortes and drawbacks.

Packet FiltersThe packet filtering firewall, based on the header information of the packets it receives, allows or denies access to or from the network that it is guarding. Packet filtering firewalls check each packet and can be implemented by most common routing devices.


Packet filters typically contain access control lists (ACLs) to monitor the following header data:• source IP address• destination IP address• source port• destination port• ICMP message type• protocol• packet size • various header flags.By combining these parameters, complex policies can be enforced by the packet filter. Packet filters tend to have high performance, because their inspection involves very simple parameters at the network layer of the TCP/IP stack. They typically only inspect up to the network layer, as show in Figure 3.2. With more complex environments, however, the performance of packets filters drops significantly as every packet of every connection is checked against the access control rules.

Illustration 3.2 Packet Filtering Model

In conclusion, packet filtering is neither very flexible nor generally very secure because the network layer lacks the context of each packet. This type of filtering can be easily fooled with techniques such as fragmented packets, or bogus or invalid IP address information. Packet filters cannot protect against malicious contents in higher levels of the protocol stack, or examine the actual data portion. Thus, they are often used in combination with application-level proxies. Packet filtering is commonly used also in routers at the network perimeters.


Proxy FirewallsProxy firewalls are firewalls running application proxy services. This means that the server establishes a second, different connection to the destination network on behalf of the host from the source network—if the packet meets the security policy criteria for it to pass through. In other words, proxy firewalls mediate communications between two different devices located on different networks.This type of firewall is fully application-aware, and therefore very secure, but at the same time there’s a trade-off in performance due to the additional overhead required to maintain separate connections and to inspect packets up to the application layer.

Illustration 3.3 Proxy Firewall Model

Proxy firewalls can cache information, such as HTML pages, to increase the performance somewhat, but the application layer awareness still continues to affect performance.Firstly, application level checking and duplicate connections can drain system resources, affecting firewall performance. Secondly, the number of services used by a proxy firewall is an issue. Since every service needs its own proxy, the proxy list is always in some sense incomplete, and new applications and services are hard to keep up with. Traffic inspection takes place at the highest layer of the TCP/IP stack. The necessity of inspecting every layer before returning back down to the physical layer can cause bottlenecks in busy networks.


Stateful InspectionStateful inspection technology was developed to overcome the limitations of packet filtering firewalls. Stateful inspection firewalls use additional criteria, such as historical data about the connection, in determining whether to allow or deny access. They track the established connections and their states in dynamic state tables and ensure that the connections comply with the security policies.By applying connection status and context information to current connections and packets, some packets are denied access before being further inspected at a higher level, which increases performance. Furthermore, since stateful inspection understands the context of connections (and therefore can relate the returning packets to appropriate connections), connections already determined to be “secure” can be allowed without further examination. This is especially important with services such as telnet and FTP. Stateful inspection operates just beneath the network layer (in practice, the inspection takes place between the data link layer and network layer). Stateful inspection firewalls have a rather limited capability to inspect data at the application layer. Stateful inspection systems also try to keep state tables for every connection protocol, whether it is conceivable or not.

Illustration 3.4 Stateful Inspection Model

StoneGate and Multi-Layer InspectionWith StoneGate, Stonesoft introduces a new firewall technology called Multi-Layer Inspection. Like stateful inspection, StoneGate uses state tables to track connections and judge whether a packet is a part of an established connection or not. However, it also features application-layer inspection by implementing specific Protocol Agents, when necessary, for enhanced security. Thus, StoneGate can inspect data all the way up to the application layer to decide whether a packet is granted access or not.


Moreover, StoneGate can also act as a packet filter for types of connections that do not require the security considerations of stateful inspection.

Illustration 3.5 Multi-layer Inspection Model

The state of connections provides valuable information for assessing incoming packets. Any packet must be either accepted directly by the policy, be a part of a previously accepted connection, or of a related connection. Whenever packets arrive, the firewall checks them against active connections before proceeding through the rules of the security policy. If a connection has a registered state, all the packets following the opening packet can pass the firewall securely without having to traverse the policy. By default, most rules in StoneGate security policies implement stateful inspection methods, but the administrator can flexibly configure rules with simple packet filtering for certain types of traffic. For example, SNMP traps from server systems and network devices can pass through the firewall to a management network on the basis of simple packet filtering in case there is no need to enforce a more strict inspection. This kind of flexibility enhances the firewall performance.Additionally, application level security can be applied to specific rules in the security policy when needed. Multi-Layer Inspection is capable of providing this type of security without the performance degradation of conventional proxy firewalls. StoneGate can implement application level inspection without the need to handle two separate connections. This is achieved with the Protocol Agents, which can be assigned to certain types of traffic.Protocol Agents are also used to handle complex connections (e.g., Oracle or FTP), to redirect traffic to content inspection servers, to enforce protocol standards, and to modify data payload if necessary. The FTP Protocol Agent, for example, can inspect the


control connection and only allow packets containing valid FTP commands. It can also be configured to redirect traffic to a CIS for content screening and to modify IP addresses in the payload in case network address translation is required. The Protocol Agents are covered in more detail in Chapter 17, Protocol Agents.In brief, StoneGate Multi-Layer Inspection combines application layer inspection, stateful inspection, and packet filtering technologies flexibly for added security without adversely affecting system performance. The different functions these firewall technologies can perform will be discussed in the next section.

Firewall FunctionsA firewall can have several different functions on a network. Although their main function is to control network access, firewalls can typically be configured for other basic network security tasks and even for more complex monitoring and filtering functions.

Access ControlThe primary task of any firewall is to control access to data resources, so that only authorized connections are allowed. Access control is enforced in access rules, which are combined into policies. The rules collected into policies reflect the corporate network security policy.

Monitoring and LoggingFirewalls can be used to measure and monitor traffic load and attributes. A very important firewall feature is the ability to log monitored traffic. Properly recorded log data can be used to detect intruders and establish evidence to use against attackers. That kind of forensic evidence may prove to be invaluable in case hacking leads to lawsuits.More commonly, logging is used to track the use of network resources, building a case for required services or hardware. Logging also helps administrators detect and troubleshoot network misconfigurations or failures. For more information on logging, See Log Management, on page 309.

Network Address Translation (NAT)Network address translation (NAT) is a feature that enables the firewall to modify the IP headers of packets it forwards. It was originally created to alleviate the problem of the rapidly diminishing IP address space. Changing the network address of the originating (internal) network has an added benefit; the private IP addresses of hosts and the structure of an internal network can be concealed by a firewall. In fact, NAT enables even hiding an entire network behind a single public IP address.As handy as NAT can be in terms of scarce public IP addresses and security, it is important to understand that NAT is not primarily a security feature. It is simply a method of modifying packets that lends itself to security applications. For more


information on network address translation, See Network Address Translation (NAT) Rules, on page 193.

AuthenticationFirewalls are often used to authenticate users accessing network resources from other locations. The various authentication methods ensure that the users trying to connect really are who they claim to be. These methods may involve a third-party authentication service based on standard protocols like RADIUS or TACACS+, but it can also be based on the originating IP address or other parameters, such as usernames and passwords. For more information on authentication, see User Authentication, on page 223.

Virtual Private Networks (VPN)Virtual private networks (VPN) conceal and encrypt traffic between end-points to establish a virtual, secure tunnel through an insecure, typically public, network. Firewalls are used at the tunnel end-points as security gateways (SGW) to encrypt and decrypt data passing between them, creating a gateway-to-gateway VPN. VPNs can also be established between a client machine, such as a remote laptop and the firewall. Figure 3.6 illustrates a simple gateway-to-gateway VPN.

Illustration 3.6 Simple VPN Example

As seen in the illustration, when traffic (a “Hello!” message) leaves Site A, it is encrypted by the firewall. Anyone who intercepts this traffic in transit can only see the encrypted messages. Once the traffic reaches the Site B gateway, the packet is decrypted and re-shaped into its original form. When concealing the traffic this way, any number of computers at the different sites can share resources and communicate with each other safely over the Internet. For more information on virtual private networks, see Chapter 30, Overview to VPNs.

Secure Socket Layer Virtual Private Networks (SSL VPN)Like virtual private networks, the secure socket layer virtual private networks (SSL VPNs) also conceal and encrypt traffic between end-points to establish a virtual, secure tunnel through an insecure network.


However, the difference between the VPN and the SSL VPN is, that SSL VPN provides secure clientless access by utilizing the SSL encryption features included in all modern Web browsers, allowing users to access resources without additional software installation, whereas VPN relies on the installation and use of specific client software.For more information on secure socket layer virtual private networks, refer to SSL VPN Administrator’s Guide.

Content Screening and Unified Threat ManagementContent screening includes measures such as virus detection, Web content filtering, intrusion detection, or some other check of the actual data being transferred. When several such features are combined together with a firewall, the solution is often called unified threat management (UTM). StoneGate offers a UTM solution that includes a virus checking and deep packet inspection for the network traffic (including basic URL filtering). By combining several features, a UTM solution simplifies the physical network setup and makes the administration simpler.UTM firewalls are generally used in environments where the traffic load stays moderate even at peak times. Firewalls are less often used as the primary tool for multiple forms of content inspection in large-scale enterprise systems because of the demands on hardware performance under a heavy traffic flow. Instead, large-scale firewall installations are often more cost-effective when used in combination with content inspection servers (CIS), which allow content inspection services to be run on a dedicated server that can be configured, scaled, and exchanged independently from the firewall.The firewall redirects the traffic to the CIS, which either strips anything deemed malicious from the packet or drops the packet altogether, according to what the security rules in force on the CIS define. Unwanted content can be removed before packets enter the internal network (see Figure 3.7).

Illustration 3.7 Content Screening with CIS

For instance, incoming SMTP e-mail traffic could be forwarded from the firewall to the CIS for virus and content checking. The CIS removes suspicious content and the “scrubbed” packets are returned back to the firewall for routing to their final destination.


CIS can also be used to control traffic flow to the opposite direction. The HTTP based Web traffic from internal Web servers can be sent from the firewall to a CIS, which can then examine the destination site’s address (URL). If the CIS decides the site is on the list of “inappropriate” sites, the traffic is denied. Approved traffic continues to the requester.

Requirements for Modern FirewallsAs the volume and the importance of Internet traffic keeps growing, it is important that the firewalls are able to meet this growth. This section presents an overview of the types of demands firewalls must meet in rapidly changing network environments.

High AvailabilityAvailability of network services is crucial to user satisfaction and employee productivity. Advanced clustering technologies prevent firewalls from being “bottlenecks” or single points of failure. Firewalls are clustered when two or more firewall nodes function as a single, virtual entity and enforce identical security policies. StoneGate has built-in clustering, so there is no need to set up and maintain additional hardware or software. The performance of each node in a cluster contributes to the total throughput, eliminating bottlenecks and providing a fault tolerant and reliable firewall. Traffic from a failed node can be switched over to other nodes transparently. The firewall cluster can even handle traffic during maintenance.

Illustration 3.8 Eliminating Firewalls as Single Point of Failure through Clustering

In Figure 3.8, we see how a firewall cluster controls all traffic from the Internet to the internal networks. If the firewalls were not clustered, any maintenance break or malfunction would result in loss of connectivity. All traffic to and from the Internet would be halted. In a cluster, other nodes keep the traffic flowing if one or more nodes go offline.


Availability can be further enhanced by balancing the Internet traffic between several Internet service providers (ISPs). These load balancing features can maintain a connection even when the line it uses goes down, as the traffic can be automatically directed through alternative routes.

ScalabilityAs traffic volumes grow, congestion starts to disturb the flow of network traffic sooner or later. The firewall is by definition a “choke point”, through which all traffic must pass. Therefore, it is crucial that the throughput of the firewall will not become the limiting factor for network connections. The possibility to cluster firewalls means that new firewall nodes can be added flexibly as traffic volumes grow, thereby enhancing the load balancing of traffic. Good scalability is especially important if the firewall is used for advanced traffic inspection, such as virus scanning or intrusion detection and prevention.

High ThroughputGigabit network environments are becoming more and more common, and the firewalls will be required to cope with this evolution. Clustering of firewall nodes also contributes to better throughput, as does the load balancing of multiple ISP links.

Centralized ManagementNo knowledgeable network administrator just sets up a firewall, trusting it will guard the network and forget about it ever exists. More measures are required to keep intruders from compromising security and to adjust to the varying needs of the users in the network. This is where a centralized management system can significantly save the administrator’s time.Centralized management of firewalls, VPNs, and intrusion detection systems (IDS) allows the administrator to do multiple tasks using the same familiar interface, making it easier to combine information from different systems.All networks benefit from centrally managed firewall security policies, be they geographically widespread, multi-national, or smaller networks. Corporate security policies often co-exist with site-specific rules to provide the required degree of granularity in the implementation of a network security policy. The implementation of corporate-wide, complicated security policies requires a great deal of flexibility from the firewall management system.Centralized and efficient management of administrator rights can also be seen as a way to minimize the possibility of human error. To avoid unintentional confusion or harm, access to firewall configuration and policies must be carefully planned according to the administrators’ responsibilities.The capability of remote installation and configuration is another important feature that will become more crucial in the evolving complicated and distributed network solutions.

Requirements for Modern Firewalls 37

Firewall WeaknessesKnowing the benefits that firewalls can offer is most useful when you are equally aware of their weaknesses. A balanced approach is essential to form effective corporate security policies. You must have a good picture of the whole security framework to decide what other measures are needed in addition to firewalls.

Lack of AdministrationComplex network environments with multiple Internet interfaces for VPN, remote access, e-business, and cache servers have increased the demand for administrators and administrative skills. This is in part because firewalls cannot provide effective security without careful attention and maintenance.A firewall must be thoughtfully installed and configured. Security policies need periodic evaluation and regular updates. Too often a firewall gathers dust in a corner for years without a professional administrator. Often only after an attack and serious or complete data loss occurs, is it recognized that the system needs to be actively administered.

Internal AttacksHaving well-designed and maintained firewalls is definitely a key ingredient to good network security. But firewalls, content inspection servers, and other devices examining packets at the network perimeter are ineffective against internal attacks. By some estimates, around 60 percent of all network attacks, including data theft, loss of resources, or destruction of data are launched from within the corporation. These kinds of attacks are much more difficult to defend against, and require different approaches than firewalls or other perimeter defenses. The implementation of the corporate security policy must address these issues through, for example, security training of employees and host-based virus protection. Intrusion detection systems (IDS), if properly deployed and maintained, can offer another layer of defense against malicious traffic that cannot be blocked with firewalls.


CHAPTER 4 StoneGate Architecture

This chapter describes the StoneGate architecture and familiarizes you with the different system components and the way they operate with each other. We will also take a look at the fundamentals of StoneGate’s clustering and high availability technologies as well as the other main features.


StoneGate Security Platform Overview, on page 40 StoneGate Components, on page 41 StoneGate Main Features, on page 47

39

StoneGate Security Platform OverviewStoneGate High Availability Firewall/VPN is a firewall and Virtual Private Networking (VPN) solution with built-in high availability features. StoneGate combines the best traits of several firewall techniques to provide security, performance, and robustness. StoneGate’s clustering features eliminate the firewall as a potential single point-of-failure. StoneGate’s patented Multi-Link technology can extend high availability to network connections as well.

Illustration 4.1 Unified StoneGate Security Platform

StoneGate Firewall/VPN is an integral part of the StoneGate Security Platform that provides clustered high availability firewalls, advanced VPN, and intrusion detection and response features. The entire security system can be managed through a single user interface that provides, for example, remote upgrades, a unified logging and alerting system, as well as extensive reporting features.

40 Chapter 4: StoneGate Architecture

StoneGate ComponentsStoneGate High Availability Firewall and VPN components are illustrated in Figure 4.2.

Illustration 4.2 StoneGate System Components

The StoneGate Management Center can manage both the StoneGate Firewall/VPN and StoneGate IPS products, and monitor StoneGate SSL VPN. Therefore, it is easy to add StoneGate components to the system later on. The different components are described in Table 4.1.

TABLE 4.1 StoneGate System Components

Component Description

Firewall/VPN engine (one or more)

The StoneGate Firewall/VPN engines provide network protection, VPN access, intrusion detection and prevention for some protocols, and optionally virus scanning services.SOHO Firewall engines provide secure VPN access between a branch office and a main corporate site and Internet access for visitors.


The StoneGate distributed architecture allows deploying the system components effectively to different network environments. With a single user interface, the entire StoneGate system can be easily and comprehensively managed, regardless of the number or physical locations of the firewalls. To ensure StoneGate system security, all communications between system components are authenticated and encrypted with the Secure Sockets Layer/Transport Layer Security (SSL/TLS) protocol. Digital certificates issued by the Management Server are used as proof of identity.The firewall engines feature an integrated operating system, specifically designed for being secure and easily manageable. There is no need for separate operating system patches or upgrades on the firewalls; all software on the engines is upgraded during the firewall software upgrade, which can be done remotely through the Management Client.

StoneGate Management Center (SMC)

Management Server: Used for controlling the StoneGate system. Usually only one is needed even in very large and geographically distributed systems. One or more backup Management Servers can be installed for swift disaster recovery.

Log Server: Used for storing the log data received from the firewalls, and for alerting the administrators in case of critical events. One to several can be deployed as necessary. Also one to several backup Log Servers can be installed for each Log Server for swift disaster recovery.

Monitoring Server: Optional component that provides restricted access to Monitoring Clients. Several can be deployed, although there is usually no need to have more than one.

Management Client (one or more)

Graphical tool used for configuring, managing and monitoring the entire StoneGate system.

Monitoring Client (several)The Monitoring Client provides restricted log and policy snapshot browsing through the Monitoring Server. It provides no other access.

TABLE 4.1 StoneGate System Components (Continued)



StoneGate Management CenterThe StoneGate Management Center is composed of the following components:• Management Server.• Log Server.• Monitoring Server (optional).• Management Clients.• Monitoring Clients (optional).The Management Server and the Log Server can be located on the same machine, or they may be distributed on separate locations. The Management Server receives commands and data from the Management Client and relays the necessary information to the firewall engines. Monitoring and log data from the firewalls is filtered through the Log Server and sent to the Management Client for display.

Management ServerThe Management Server is the central point of administration. The Management Server provides the following services:• Administration: the Management Server is the central point of all administration

tasks. Administrators perform all main administration tasks through a connection to the Management Server.

• Configuration database: the Management Server stores all configuration information for the firewalls and other system components in an embedded database. Those parts of the configuration information that concern each particular firewall is transferred to that firewall when an administrator commands a firewall policy installation.

• System commands: the Management Server relays the control commands given in the Management Client to the appropriate firewall engines.

• Monitoring: the Management Server keeps track of the operating state of the system components and can automatically notify you when the monitoring connection is lost.

• Automated tasks: the Management Server independently carries out administration tasks that are scheduled to run at certain times.

• Certificate authority (CA): the Management Server has a basic CA that issues all certificates that system components require for secure system communications. This CA can also be used to sign other certificates, for example, for VPNs.

• User database: the Management Server can store user information needed for end-user authentication in an internal LDAP database (you can alternatively use an external LDAP server).

It is critical to back up the Management Server database regularly using the Management Client and to transfer the backup file to a different, safe storage place either manually or as automatic tasks you schedule in the system. If the Management Server data is lost and you have no backup, the engines continue to operate with the currently installed configuration, but changes to the configuration are not possible


until all of the configuration information is manually recreated on the Management Server.Optionally, one or more backup Management Servers can be installed (separate license required) to ensure the configuration information is backed up. A backup Management Server allows controlling the firewalls without delays and without loss of configuration information if the primary Management Server is physically damaged, loses power, or becomes otherwise unusable. The main benefit is that the synchronization is done automatically without the need to transfer the information through backup files that must be manually restored on the other system.

Log ServersLog Servers manage and store the log and alert entries generated by the firewalls and other StoneGate components. They provide the following services:• Log viewing: Log Servers provide the required information directly to the

Management Clients based on the queries administrators make.• Statistical data: Log Servers receive and relay the status and statistical monitoring

information from the firewalls and store summaries of the raw data for reporting.• Report data: Log Servers process the raw log and statistical data and provide the

results to the Management Server, which combines the data into reports for viewing.

• Log pruning: Log Servers can automatically dismiss unnecessary log entries that may be generated.

• Alert notifications: Log Servers can notify administrators about new alerts in the system, for example, by sending out an e-mail or an SMS text message.

Log and Alert entries from StoneGate Firewall/VPN engines, StoneGate IPS, and StoneGate SSL VPN can be handled by the same Log Server. Multiple Log Servers may be deployed, which is particularly useful in geographically distributed systems.Similar to Management Servers, you can also define backup Log Server(s) for each Log Server that you have for swift disaster recovery (separate license required for each). When the primary fails, engines can automatically start to send any new logs and monitoring data to the secondary Log Server where they can be viewed.

Monitoring ServerThe Monitoring Server is an optional component (separate license required) that can be used to provide a restricted access to log data and policy snapshots for the Monitoring Client users. This kind of access is well-suited for MSP customers, for example. The Monitoring Client can only access the Monitoring Server, which relays the log information from a single Log Server defined for that user. The Monitoring Server can also enforce filtering of the relayed data.


Management ClientsThe Management Client is the tool for all day-to-day configuration and management tasks, including:• Configuring firewall nodes and VPN security gateways.• Designing firewall policies.• Managing user authentication services.• Monitoring log data and system operation.• Changing the operating status of the firewalls.• Upgrading firewall engines remotely.All commands and configuration changes made in the Management Client are relayed through the Management Server. The Management Client never connects to the firewall engines directly.A large number of Management Clients can be deployed anywhere in the network, and several administrators can be logged in at the same time. An administrator can use the same Management Client to manage and monitor both the StoneGate Firewall/VPN products and the StoneGate IPS, and to monitor the StoneGate SSL VPN. Thus, the entire network security infrastructure can be managed via the same user interface using shared configuration definitions.

Firewall EnginesThe firewall engines are the combination of the physical device and the firewall software, which runs on an integrated, hardened Linux-based operating system. The hardware of the engines can be StoneGate appliances (that also have the software pre-installed) or Intel-based standard hardware that fulfills the hardware requirementsFirewall engines have the following representations in the Management Client:• The Firewall element is a container for the main configuration information directly

related to the firewall.• The individual firewall engines are shown as one or more Nodes under the main

Firewall element in some views of the Management Client.A firewall cluster consists of multiple firewall engines functioning as a single entity. A StoneGate cluster can have 1 to 16 firewall engines. Clustering provides high availability and load balancing, which results in reliability and high performance of the system. This way, a single point of failure is avoided as the firewall cluster continues operation even if one or more of the nodes fail or are taken offline for maintenance. Clustering is supported on all platforms, except SOHO firewall appliances.All the firewalls are configured and managed through the Management Server. All configuration information is loaded to the firewalls from the Management Server when a firewall policy is installed. After receiving a configuration, the engines do not require any contact with the Management Server to operate, but work independently or in cooperation with the other engines in the cluster until it receives a different configuration or command from the Management Server. The firewalls periodically send logs, statistical information, and updates on their operating state to the Log Server, but still continue to operate normally even if the Log Server contact fails.


The software on the firewalls can be upgraded remotely through the Management Client. There is no need to physically access the firewalls to upgrade them. This gives time and cost benefits, particularly in larger organizations and in MSP environments, by eliminating the need to travel on-site to upgrade the firewalls. Each firewall node runs a test subsystem, which allows you to define and enable additional tests to monitor and respond to conditions on the firewall nodes. For example, if a network interface fails, the node can switch itself offline and send an alert to the administrators, leaving the other nodes to handle the traffic.

SOHO Firewall EnginesSOHO Firewalls are a special class of StoneGate firewall engines that provide access only to the corporate network and to the Internet. The SOHO Firewall engines are always StoneGate appliances. SOHO Firewalls are meant for remote deployment at low-traffic sites. SOHO Firewalls do not support advanced StoneGate firewall features such as Multi-Link or clustering.SOHO Firewalls are configured and managed through the Management Server in the same way as other firewalls. A special SOHO Firewall element represents the configuration of a SOHO Firewall in the Management Client. The configuration information is transferred to the SOHO Firewalls from the Management Server when the configuration is applied to the engines. As other firewalls, also SOHO Firewalls send information on their operating state to the Management Server and logs to the Log Server. They operate normally even if the Log Server contact fails. SOHO Firewalls also support remote software upgrades through the Management Client.

CertificatesFor security reasons, all communications between the system components are automatically encrypted and authenticated using the Secure Sockets Layer/Transport Layer Security (SSL/TLS) protocol. SSL/TLS uses digital certificates for authentication and encrypted connections for confidentiality. The StoneGate internal Certificate Authority (CA) on the Management Server handles the signing of the system component certificates.Certificates are always created with an expiration date. StoneGate internal certificates are, by default, valid for three years. By default, the firewall engine certificates are automatically renewed before they expire. With SOHO Firewalls, you must make initial contact manually to renew the certificates and to re-establish the trust relationship between the SOHO Firewall and the Management Server.


LicensesLicenses provide your system a proof of purchase. Components remain in a disabled state until they are properly licensed. Each Management Center server and each firewall and IPS engine must be separately licensed in your Management Center. You license the components by importing a license file that you create at the Stonesoft website using a proof code provided to you by Stonesoft.SOHO Firewall engines are an exception to this rule: SOHO firewalls do not have separate licenses. You can add SOHO Firewalls to your system if your current Management Server license allows you to configure new engines. If your Management Server license contains a restriction on how many components it can manage, one engine licensing unit allows a maximum of five SOHO Firewall elements or one engine element of any other type.All licenses include a maximum version on which they are valid, so you may need to regenerate the licenses when you upgrade to a new major release of the software. Upgrades are included in support contracts. You can either regenerate the licenses at the Stonesoft website or configure in the Management Client that the licenses are regenerated and installed automatically.Evaluation licenses are valid for 30 days. Purchased licenses do not expire unless otherwise noted.

StoneGate Main FeaturesThis section briefly describes the main features of the Firewall/VPN system. Most of the advanced StoneGate features are not supported for SOHO Firewalls.

Advanced Traffic InspectionStoneGate’s Multi-Layer packet and connection verification process ensures maximum security without compromising system throughput. This advanced traffic inspection process is not available for SOHO Firewalls.The firewall’s policies determine when to use stateful connection tracking, packet filtering, or application-level security. The system expends the resources necessary for application-level security only when the situation so demands and without unnecessarily slowing or limiting network traffic.Some connections can be selected for inspection of the data content against harmful or otherwise undesired patterns in connections. The deep packet inspection features provide IPS-type capabilities right on the firewall, and help in finding and stopping malicious or suspicious network activities.An antivirus scanner complements the standard traffic inspection features when the firewall is licensed for the UTM (unified threat management) feature.


Built-in Load Balancing and High AvailabilityStoneGate provides innovative built-in clustering and load-balancing features that provide several benefits over traditional solutions. Clustering and load-balancing are not supported for SOHO Firewalls.Traditionally, in order to achieve high availability on the firewall itself, additional hardware switches, software clustering products, or special load balancing devices have been added and maintained. This often results in the transfer of a single point of failure to another network component—typically the network link.In StoneGate, however, the clustering of the firewall engines is integrated in the product, thus introducing true built-in high availability and load balancing. The firewall engines dynamically load-balance individual connections between the cluster nodes, transparently transferring connections to available nodes in case a node becomes overloaded or experiences a failure.A firewall cluster can have the maximum of 16 nodes. With load balancing, the processing of network traffic is automatically balanced between the cluster nodes. This way, the performance of the StoneGate system can be upgraded by simply adding new nodes to the cluster when necessary. Individual nodes can also be taken offline during business hours for maintenance purposes; connections that were handled by that particular engine will be transparently redistributed to other online nodes.

Integration with StoneGate IPSThe interoperation between the StoneGate Firewall/VPN and StoneGate IPS products makes the combination of these two a very powerful network security solution. The common StoneGate Management Center (SMC) with the secured inter-system communications ensure efficient integration of the system components.System administration is also improved with a unified user interface for managing the entire network security environment and the related enterprise-wide security logs, alerts, and so on.IP address blacklisting is a shared feature for StoneGate Firewall/VPNs and StoneGate IPS that allows blocking harmful traffic not just at the component that detects it, but also on other StoneGate engines on the connection path. Blacklisting is not supported for SOHO Firewalls.

Multi-Link TechnologyStoneGate single-node and clustered firewall installations come standard with Multi-Link, which ensures high availability for network connections. Multi-Link technology is not supported for SOHO Firewalls.Multi-Link allows configuring redundant network connections without the more complex traditional solutions that require redundant external routers and switches, the use of complex routing protocols, such as Border Gateway Protocol (BGP) and Hot Standby Routing Protocol (HSRP), and peering arrangements between the ISPs.


Any IP-based link with a dedicated IP address range can be used as part of a Multi-Link configuration. You can also define standby links that are used only when primary links fail. The illustration that follows shows a basic Multi-Link setup with a single firewall that has two active and one standby network links to the Internet.

Illustration 4.3 StoneGate Multi-Link Technology

Most often, multiple network links are used to ensure continuity of Internet access, but Multi-Link can be used for any other network as well. The traffic is dynamically balanced across the different connections based on a performance measurement or based on the links’ relative bandwidths. The traffic automatically fails over to other links when the firewall detects that one of the links fails. The firewall uses network address translation (NAT) to direct the traffic through the different links to make the source IP address valid for the link used.StoneGate Multi-Link technology provides highly available network connections for the following scenarios:• Outbound connections: load balanced routing ensures that outbound traffic always

picks the best link towards its destination. For more information, see Load Balancing, on page 265.

• Inbound connections: the Server Pool feature allows you to ensure continuity of services your company offers to external users. For more information, see Multi-Link for Server Pools, on page 273.

• VPN connections: the Multi-Link tunnel selection for VPN traffic is done independently from other types of traffic. Also standby links can be selected independently for a VPN. For more information, see Multi-Link VPN, on page 379.

QoS and Bandwidth ManagementQuality of Service (QoS) rules are interface-specific rules on a firewall that help you ensure that important network services are given priority over less important traffic. Quality of Service and bandwidth management features are not supported for SOHO Firewalls.QoS rules help you in three ways:• You can set up a minimum bandwidth for traffic that must always be allowed

through quickly.• You can set up a maximum bandwidth for traffic that must never take more than a

certain share of the available bandwidth.


• You can set a Priority value for the traffic. Higher priority traffic is sent forward to its destination before lower priority traffic whenever the firewall needs to make such a choice.

You can set any combination from one to all of the options for any one type of traffic.You can also create QoS rules that read or write the priorities in DiffServ Code Point (DSCP) type of service (ToS) field, so that StoneGate is aware of the priorities set by other network equipment and other equipment is aware of the priorities set in StoneGate. You can also create rules that both read and write the ToS fields, which allows you to use StoneGate to “translate” between two QoS implementation that assign the priority values differently from each other.For more information, see Bandwidth Management and Traffic Prioritization, on page 281.

Reporting ToolsStoneGate provides extensive reporting tools for generating statistical reports based on logs, alerts, and operating statistics. A variety of ready-made report designs are available for use and you can create new reports to fit your needs.

Illustration 4.4 Finished Example Reports

Reports can be displayed on the screen or exported as PDF files for printing and distribution. For more information, see Chapter 29, Reports.


Unified StoneGate Management CenterYou can configure and monitor the StoneGate Firewall/VPN and the StoneGate IPS through the same Management Center and the same graphical user interface. Additionally, logs and alerts from StoneGate Firewall/VPN, IPS, and SSL VPN components can be viewed and handled easily and efficiently with the same tools.The common user interface provides an integrated security platform for configuration and other administrative tasks. For delegating the tasks, the StoneGate Management Center provides role-based administrator accounts with different authorization levels. Tasks can thus be easily delegated as seen suitable in a given network environment.In large-scale and international environments, the manageability of the system becomes crucial. With StoneGate’s flexible architecture, different components within the same system can be physically distributed. Several administrators can simultaneously manage the system, while conflicts in editing the configurations are automatically tracked and prevented.

Virtual Private Networks (VPNs)StoneGate provides fast, secure, and reliable VPN connections with the added benefits of the clustering and Multi-Link technologies that provide load balancing and failover between ISPs and VPN gateways.You can create VPN connections also with SOHO Firewalls. However, clustering and Multi-Link are not supported for SOHO Firewalls.StoneGate supports both gateway-to-gateway and client-to-gateway connections. VPN clients can access multiple VPN sites through a central VPN hub gateway.VPN scalability is supported by StoneGate, giving administrators the ability to control how many tunnels are created and used, thus avoiding wasting resources on supporting unnecessary or unused tunnels. For more information on VPNs, see Overview to VPNs, on page 353.



CHAPTER 5 StoneGate Firewall/VPN Deployment

This chapter provides general guidelines for the StoneGate Firewall/VPN system deployment. It also illustrates a typical deployment with an example scenario.


Deployment Overview, on page 54 Firewall Deployment, on page 55 Management Center Deployment, on page 59

53

Deployment OverviewThe StoneGate Firewall/VPN system consists of firewall engines and the StoneGate Management Center. The Management Center consists of the Management Server, one or more Log Servers, and one or more Management Clients. You can also have one or several secondary Management Servers. The system components are listed in Table 5.1.

Illustration 5.1 shows the general principle for positioning the different StoneGate components.

TABLE 5.1 System Components


StoneGate Firewall/VPN

Picks up network traffic, inspects it against the firewall policy, and routes only connections specifically allowed in the policy to the correct next-hop gateway according to configured parameters.

UTM Firewall

The StoneGate UTM solution combines a firewall, virus scanner, deep packet inspection for selected protocols, and basic URL filtering. The UTM Firewall is configured and managed in exactly the same way as other StoneGate Firewall/VPN engines.

SOHO Firewall

SOHO Firewalls only allow outgoing connections from local trusted networks (employees) through VPN tunnels to other sites and from local untrusted (guest-access) networks to the Internet without inspecting the traffic. The SOHO firewalls are configured differently from other StoneGate firewalls.

Management Server

Stores the configuration data and manages the StoneGate system.

Log ServerStores the received log data and alerts the administrators when critical events occur.

Management Client

Provides a graphical user interface for managing and monitoring the system.

54 Chapter 5: StoneGate Firewall/VPN Deployment

Illustration 5.1 Positioning StoneGate Components

Firewall DeploymentThe StoneGate Firewall/VPN engines can be installed as follows:• As a Firewall/VPN cluster that consists of 2 to 16 engine machines installed as

cluster nodes.• As a single-node Firewall/VPN.SOHO Firewalls are always single-node installations and cannot be clustered.The firewalls have an integrated, hardened Linux operating system that simplifies everyday use significantly, because a hardened version of the operating system is installed and upgraded together with the StoneGate engine software, without any separate action from the administrators. The network interface card and hardware requirements can be found on Stonesoft’s website at http://www.stonesoft.com/en/products_and_solutions/products/fw/Certified_Servers/.

Positioning FirewallsThe firewall is a perimeter defence, so naturally all traffic between the Internet and your internal networks must be routed through the firewall to achieve a secure system. DMZ (demilitarized zone) networks, which typically contain web servers or other servers providing services to the general public or other ‘outsiders,’ are a third category of networks that needs to be considered separately.

Internal NetworksInternal networks are often mixed environments with servers and end user computers. The diverse, high-volume traffic in these networks is due to a large number of different applications and hosts communicating within, in, and out of the network. Firewalls




control the inbound and outbound traffic on the network perimeter, restricting traffic between the different internal networks, but traffic within each network is often not secured.

DMZ NetworkDMZ networks are often quite unified environments consisting mainly of servers. There are usually no end user computers in the DMZ. The traffic in these networks can be high in volume, but often uniform with only specific services available. Firewalls

TABLE 5.2 Internal Network Considerations for Firewalls

Concept Description Implications on Firewalls

Main purpose

Network services and connectivity for the authorized end users. Possibly also back-end servers that serve other networks and user groups.

Internal networks have confidential data and can be quite permissive for the traffic within the network. Firewalls control the traffic in and out of the network and allow you to enforce authentication as a condition for access.

Hosts

Mixed environment consisting of servers, laptops, desktops, networked devices such as printers, etc.

Network communications of the servers and the end user computers differ in characteristics.

UsersFor authorized personnel. Only a controlled access in and out of the network through a firewall.

The users are known and usually authenticated providing a more controlled environment than the publicly available networks (where the users are not necessarily known or authenticated).

Traffic type

Diverse traffic with large number of different applications and hosts communicating within and in/out of the network.

The firewall policy must be balanced between users’ demands for a wide range of different services and keeping the internal networks safe. Deep packet inspection, virus scanning, and external content inspection servers help in sanitizing permitted communications.

Network security

A “trusted network” where the users and the traffic are considered to be authorized. Inbound and outbound traffic is controlled by a firewall although the traffic within the network can often be unsecured.

The firewalls provide perimeter security controlling the traffic in and out of the network. StoneGate IPS provides another layer of security for inspecting and filtering the traffic within the network and by further analyzing the traffic going through the firewall.


control the inbound and outbound traffic on the network perimeter, and the traffic may be encrypted to provide extranet access.The DMZs usually allow connections coming in from the public network and there may also be communications between the internal networks and the DMZ, making the DMZ a potential target for intrusion attempts.

External NetworkExternal networks provide the infrastructure to connect the “trusted” internal networks to the “untrusted” public networks and “trusted” remote networks. Only a limited number of hosts are located in this network, including firewalls and possibly some

TABLE 5.3 DMZ Considerations for Firewalls


Main purpose

Mainly services for authorized and public use, such as public Web servers.

DMZ networks are often much more strict with the network communications than the internal networks.

Hosts

Often a uniform environment consisting mainly of servers. There are usually no end user computers.

The DMZs often have only servers that serve clients connecting from other networks. Access rules can be very specific and restrictive on the communicating hosts and protocols.

Users

Services can be provided to authorized and public use, but local access is usually restricted only to the administrative staff. Only a controlled access in and out of the network through a firewall.

The public servers are not as well protected as the internal networks, because the public servers are available to other networks and users that are not necessarily known or authenticated. This needs to be taken into account when designing policies.

Traffic type

Rather uniform traffic with only specific applications and servers communicating within and in/out of the network.

The rather uniform traffic can be further controlled by configuring inspection rules in the firewall policy for supported protocols.

Network security

A network between the trusted and untrusted security zones allowing access for authorized and public use.Inbound and outbound traffic is controlled by a firewall, and the traffic may be encrypted (also within the network).

The firewalls provide perimeter security controlling the traffic in and out of the network. StoneGate IPS provides another layer of security for inspecting the traffic within the network and by further analyzing the traffic going through the firewall. This is especially important for the security of the publicly available hosts.


secured hosts that must be directly accessible from the public network. Traffic volume in these networks is often limited by the Internet bandwidth and there is only limited filtering between the external networks and the public Internet.

TABLE 5.4 External Network Considerations for Firewalls


Main purpose

Connectivity between the protected and public networks.

External networks are often rather open to connections from the public network. The firewall is the primary tool in selecting the traffic you want to permit from traffic that you do not want to enter your internal or DMZ networks.Much of the legitimate traffic is often encrypted in VPNs and typically the firewall also translates the addresses from private addresses used in internal and DMZ networks to a few public IP addresses.

Hosts

Often only hosts that must be directly accessible from the public network, such as a firewall. Usually, there are no end user computers in this network, and the servers are often located in a DMZ behind the firewall.

Networking devices such as routers and firewalls are important components in the external network. These systems are usually highly secured.

Users

This is often a pass-through network for the traffic between the public networks and the firewall(s) protecting the internal networks. Local access to the network and the hosts is usually restricted to the administrative staff only.

Connections can originate almost from any user in the internal or public networks. Thus, the users are not necessarily known or authenticated. This needs to be taken into account when designing policies.

Traffic type

Traffic going in and out through the firewall may be encrypted (e.g., in VPNs). Interfering connection attempts and attacks can reach this network as there is only limited filtering between the external and the public networks.

Deep packet inspection can be used to find harmful patterns in the communications.


StoneGate Management ConnectionsTo ensure security for the StoneGate IPS system communications, all the connections between the system components are encrypted and authenticated using the Secure Sockets Layer/Transport Layer Security (SSL/TLS) protocol. SSL/TLS provides digital certificates for authentication and encrypted connections for confidentiality. A separate network can also be used to isolate the system component communications from other network traffic. The internal Certificate Authority (CA) on the Management Server handles the signing of the system component certificates that are used for authenticating the system components during communications.The system communications are illustrated in StoneGate Architecture, on page 39. The Management Center communications require only minimal bandwidth (less than 1 Kbit/s on the average).In addition to alerting and logging the traffic, the traffic itself can be recorded on specific events detected by the firewall (inspection rules). The recorded traffic is stored in files and transferred from the firewalls to the Log Server. The traffic volume depends on the frequency and the size of the recordings.

Management Center DeploymentThe StoneGate Management Center (SMC) consists of the Management Server, Log Servers, and Management Clients. Firewalls are managed through the Management Server, so the Management Client does not ever connect directly to the firewalls. Communications between the StoneGate system components are described in StoneGate Architecture, on page 39.It is possible to run the Management Server and the Log Server on the same machine for small environments. You can also have one or several secondary Management Servers. Several Log Servers can be added as needed. For larger environments, the components can be distributed, especially when there are geographically different locations. The Management Clients can be installed where needed. The Management Clients take connections to the Management Server for configuring and monitoring the

Network security

The network is rather open to the public network traffic with only limited filtering, thus requiring the hosts and services to be security-hardened in this network. Confidential traffic passing through this network is usually encrypted by using VPNs or other secured connections.

The external network is less secure than the DMZs and internal networks, as it is located outside of the corporate security perimeter. The firewall controls which traffic is allowed access into your networks, but it is beyond the firewall’s control what and how much traffic arrives from the public networks.

TABLE 5.4 External Network Considerations for Firewalls (Continued)



system, as well as to Log Servers for browsing the log entries. The SMC hardware requirements can be found on Stonesoft’s website at http://www.stonesoft.com/en/products_and_solutions/products/fw/Certified_Servers/.The general Management Center deployment steps can be described as follows:1. Position the Management Server at a central location where it can access all the

other components and so that the Management Clients can connect to it. If you have secondary Management Server(s), it is best to position them at another location for security reasons.

2. Position Log Servers centrally and/or locally based on the log data volume requirements.

3. Position Management Clients freely where they are needed. The SMC deployment considerations are described in further detail below.

Positioning the Management ServerThe Management Server is the central point of administration as it stores the configuration data and manages all components in the StoneGate system, including StoneGate IPS. It is usually positioned on a central site at the corporate headquarters or data center, from where it can reach all the firewalls and Log Servers. The Management Server does not need to be located close to the administrators, as the entire system is managed through the Management Clients that connect to the Management Server and Log Servers over the network using an encrypted connection.The purpose of having one or more secondary Management Servers is to guarantee that your SMC configuration is not lost and you can still manage the StoneGate system even if the primary Management Server fails for some reason. If you have secondary Management Server(s), it is best not to position them in the same location with the primary Management Server.We recommend that the same Management Server is used for the StoneGate IPS and StoneGate Firewall/VPN solutions. This unified approach simplifies managing wide, physically distributed network environments and allows closer integration, for example, sending blacklist requests from the IPS components to the firewalls. Also, the configuration information and log data can then be shared and used efficiently together. A single Management Server can manage a very large number of components efficiently.

Positioning Log ServersLog Servers store the log data and possible traffic recordings received from any engine components, including firewalls, IPS sensors and analyzers, and StoneGate SSL VPN appliances. As the data transfers to the Log Server can be substantial in volume, the primary concern for the Log Server deployment is the amount of data received by the server. Based on the log data sources and the traffic volume, Log Servers can be located on a central site as well as locally on the remote sites. A centralized Log Server can be sufficient for a number of small remote sites, whereas a




large remote office with high volume network traffic may require its own Log Server for efficient use. Log Servers also handle alerts and alert escalation to inform the administrators on critical events. The alerts can be handled locally on each Log Server, or alternatively the alerts can be forwarded to a different Log Server. For example, all the alerts from the different sites can be forwarded to a central Log Server at the corporate headquarters for alert escalation.

Positioning Management ClientsThe Management Client provides a graphical user interface for managing and monitoring the entire system. Management Clients can be used at any location where they can reach the Management Server for system administration and the Log Servers for log and alert browsing.The Management Clients can be installed by running the installer program locally or through the Web browser via Java Web Start. The main difference between the installations is that locally installed clients are also upgraded locally and individually, whereas the Web Start installation is updated centrally when the Management Server is upgraded and the individual Management Client installations are then automatically upgraded without user intervention.



Setting Up StoneGate

CHAPTER 6 Management Client Basics

The Management Client is the single graphical tool that is used for setting up, managing, and monitoring all features in the StoneGate system.


Introduction, on page 66 General Tools, on page 66 System Status View, on page 70 Overview, on page 73 Status Icons and Colors, on page 74 Configuration View, on page 78 Logs View, on page 79 Policy Editing View, on page 82

65

IntroductionThe Management Client is the tool for connecting to the Management Server for configuring, controlling, and monitoring your StoneGate system. Both StoneGate Firewall/VPN and StoneGate IPS elements are managed through the same Management Client.There are five main types of views in the Management Client, the System Status view (the first view that opens by default), the Configuration view, the Logs view, the Policy Editing view, and the Overview.In all views, you can:• Arrange the different panes within each view by grabbing them by their top edge and

dragging and dropping them to a different position.• Select the displayed panes and reset their positions through the View menu.

General Tools

Main ToolbarThe following buttons are present on the toolbar in all windows.

Illustration 6.1 General Toolbar Buttons

Additional view-specific buttons may show up on the toolbar depending on the view.

Back and forward buttons. Click and hold to see history.

Shortcuts to policies.

Switch to Logs view.

Switch to System Status view.

Switch to Configurationview.

Shortcuts to Overviews.

66 Chapter 6: Management Client Basics

Status BarThe status bar at the bottom of the StoneGate windows displays system messages.

Illustration 6.2 Status Bar

Element SearchThe Management Client has a general search for quickly finding elements.

Illustration 6.3 The Search Panel

Informational messages regarding the operation of the Management Client.

Location selector (for connecting to Log Servers when NAT is used).

Notification of one or more active alerts in the system. Right-click for options.

Information on who is logged in on this Management Client.

Search term.

Options to restrict the search.

Search Results.

General Tools 67

BookmarksYou can bookmark any view through the Bookmark menu to later be able to quickly open any of your preferred views. Bookmark actions are in the Bookmark menu.

Illustration 6.4 Example Bookmark Menu

Bookmarks and bookmark groups in the Shared Bookmarks group are shown to all administrators. Other bookmarks and bookmark groups are private to their creator.Bookmark Menu is dynamic, that is, the menu changes according to the bookmarks and bookmark groups that have been defined.You can also add bookmark folders and separate bookmarks to the toolbar.

Create new bookmarks. Lists bookmarks for viewing and organizing.Bookmark a view that

opens each time you log in. Shared Bookmarks

group is shown for all administrators.


Online HelpThe step-by-step documentation for configuring StoneGate (the contents of the Administrator’s Guide) is available directly in the Management Client in a dedicated help window. All dialogs and some of the task-specific views open the Online Help directly in the section that explains how that particular dialog or view is used.

Illustration 6.5 Management Client Online Help Window

Online Help provides the how-to instructions for all aspects of using and configuring the product features, excluding the installation steps. The search tools include:• A table of Contents.• A Search through all text in the Online Help (except the Index terms).• An Index of selected keywords that includes some alternative terms that do not

appear in the text, but may be more familiar to you than those used in StoneGate.• A Glossary that explains what StoneGate-specific terms mean.

Note – The Online Help search does not support wildcards (like *) or other special characters neither in their special meaning nor as search terms.

Tools for searching; showing the table of contents.

The Prev and Next links in the top and bottom bars allow you to leaf through the topics like pages in a book.

General Tools 69

System Status ViewThe System Status view is where you control and monitor the installed StoneGate Firewall/VPN and IPS system components. The status information is sent from each firewall and IPS engine to a Log Server, where it is stored. The Management Server relays the information for you to view it in the System Status view.

Illustration 6.6 System Status View

System SummaryThe System Summary shows at a glance whether elements are online or offline, and whether there are any errors, warnings, or alerts.

Illustration 6.7 System Summary

Tree of those elements that can be monitored. Element status is shown with colors.

Summary of the system’s status.

Details of the selected element (Not visible in the Monitored Elements view, if no element has been selected).

Active Alerts shows how many alerts there are that administrators have not yet acknowledged receiving yet.

Status by element types.The numbers work as links to more detailed information in the Info Panel or, for Alerts, in the Logs view.


Status TreeThe Status tree displays the firewall and IPS engines, SOHO firewall engines, Management Center servers, VPNs, and SSL VPNs. Also those Diagram and Group elements that contain any of the monitored elements are monitored in this tree.

Illustration 6.8 Status Tree

The elements can be controlled (for example, rebooted) and configured using the right-click menu on the Status tree. Selecting an element displays details about its status in the Info Panel (see below). You can also view the status of elements in a graphical format (see Graphical Monitoring, on page 72).

Info PanelThe Info Panel provides information on the status of the element you have selected on the Status tree.

Illustration 6.9 Element Status Information

In addition to showing the status of an element, the Info Panel also allows you to view more detailed status information on the Firewall or IPS engine you have selected in the Status tree (including the status of the engine’s interfaces and the appliance used as the engine).

System Status View 71

Illustration 6.10 Engine Status Information

The number of tabs in the element status information panel and engine status information panel depends on the selected element/engine. The information is not displayed by default in the Info Panel. You must refresh the information manually to be able to view it.The interface and appliance status information is only available for Firewall and IPS engines version 4.3 or higher, but it may not be available for all appliance models.

Graphical MonitoringThere is an alternative way to monitor your networks. When you select a Firewall, IPS engine, or Server element on the Status tree, a diagram showing the element’s connectivity status is automatically displayed in the System Summary view.You can also create diagrams (IP Diagrams or Connectivity Diagrams) in the Diagram Editor. The status of the components is automatically shown directly in the diagrams (see Illustration 6.11).

Illustration 6.11 Graphical Monitoring


OverviewAn Overview is a user-definable collection of system statistics views that enables the administrator to monitor all high-level system information of StoneGate at a glance.StoneGate has several ready-made Overview templates that you can use ‘out of the box’, and you can also modify any existing Overview template for your own needs.Overviews consist of one or more Sections that can contain a wide variety of system information, such as, element state information, tables consisting of traffic and counter data, reports, and different types of charts (pie/curve/bar).

Illustration 6.12 Example Overview

Sections consist of the following section groups:• Statistics sections

• Progress sections (curve or bar chart)• Top Rate sections (bar or pie chart)• Period Total sections (table)

• System Summary sections• Bookmark folder sectionsYou can freely adjust your Overview, select how many sections you want to add to your Overview and decide what will be the content of each section.

Toolbar.

Grid.

Section.

Overview 73

Status Icons and ColorsThe status symbols visualize the system status as presented in the tables below. Similar icons are shown also in the System Summary. The status icons are always accompanied by textual explanations in the Info panel and as tooltips when you hover the pointer over the elements.The cluster status icons give an overview to the status of all nodes. Status display for Groups and Diagrams follow the same logic.

TABLE 6.1 Cluster Status Icons

Icon Cluster Status Description

Green icon, all OK All nodes have a normal status (online or standby).

Yellow icon, warningSome of the nodes have an abnormal status or have been commanded offline by administrator command, but are still sending status updates normally.

Red icon, alertAll of the nodes have an abnormal status, there is one or more nodes that have not sent expected status updates, or all nodes have been commanded offline.

Grey icon, unknown status

No policy has been installed on any of the nodes in the cluster.

White icon, not monitored

Administrator has set the cluster not to be monitored.


The Node status icons show more detailed information on individual engines. The Status display for SMC Servers follows the same logic, although only online, timeout, alert, and unknown states are possible for the servers.

TABLE 6.2 Node Status Icons

Icon Node Status Description

Green icon, node or server online

The node or server is online and processing traffic.

Green icon with slot, locked online

The node is locked online to prevent automatic status transitions. The node will not change state unless commanded by an administrator.

Cyan icon, standby mode

The node is in standby mode. A standby node goes online when the cluster has no other online node.

Blue icon, node offline

The node is offline and does not process traffic.

Blue icon with slot, locked offline

The node is locked offline to prevent automatic status transitions. The node will not change state unless commanded by an administrator.

Grey icon, timeout or unknown status

The management system does not know the status of the node.

White framed icon, not monitored

The node is not monitored.


The color of the NetLink icons shows the status of the NetLinks in the Multi-Link configuration.

The VPN status icons alert you to problems in VPNs.

TABLE 6.3 NetLink Status Icons

Color Status Description

Green OK The NetLink is up.

Grey Unknown status The status of the NetLink is unknown.

White Not monitored The NetLink is not monitored.

TABLE 6.4 VPN Status Icons

Icon Cluster Status Description

Green icon, tunnels up

All tunnels have a normal status (online or standby).

Yellow icon, warningSome error has been detected, at least for some traffic, but the tunnels are usable in principle, and some other traffic may be getting through.

Red icon, error Some or all tunnels are down.

Blue icon, idleThe tunnels are valid, but not up because there has not been traffic going through them in a while.

Gray icon, not configured

The VPN has no valid tunnels, because the VPN configuration is not complete or does not allow any valid tunnels.


The Connectivity tab in the Info view shows the current status of the selected element’s connectivity with other elements in the StoneGate system. The table below explains the meaning of the different colors in the Status column. See the tooltip for the status color for more details.

TABLE 6.5 Connectivity Status

Color Status Explanation

Green OKThe connection is active (there have been communications within the last 2 minutes) and no problems have been reported.

Red ErrorThe Management Server has received a report that connection attempts have failed.

Cyan IdleConnection between components is still open, but no traffic passes between them.

Yellow Warning

There are problems with heartbeat or state synchronization between nodes in a firewall cluster. Only one of the interfaces used for heartbeat or state synchronization is functioning properly. This does not affect how the cluster functions.

Blue Closed The connection was closed by one of the components.

GreyTimeout, Unknown

The Management Server does not know the status of the connection. The connection may or may not be working.


Configuration ViewThe Configuration view is where you can view, modify, and add any configuration information in the system. You can also see the status information for those elements that you are viewing and command the StoneGate system components.

Illustration 6.13 Configuration View

Full tree of all elements and objects in the system.

Tree or list of selected type of elements; showing firewall policy tree.

Information on selected element; switched to show modification history for the selected policy.


Logs ViewThe Logs view allows you to view either current entries as they arrive to the Log Server or browse historical data stored in log files, including alert and audit entries (depending on administrator rights).

Illustration 6.14 Logs View

The log entry table shows information contained in the log entries in columns that you can add and remove and organize in your preferred order.

Logs toolbar. Query panel.

Fields panel.Timeline for browsing.

Log entry table.

Field preview.

Logs View 79

Illustration 6.15 Logs Toolbar

The Logs view, by default, shows logs stored on all servers and sorts the logs according to their timestamp. You can browse backward and forward within the selected time range or even beyond it either using the keyboard, or the Timeline. There are also two other main modes:• In the Current Logs mode, the view automatically updates to show the most recently

received log entries until you select an entry or deactivate the Current Logs mode.• In Sorting mode, (Options→Sorting) you can sort the logs within the query

according to any of the columns in the table.The time range and other criteria for filtering the log display are set in the Query panel.

Current Logs mode off.

Acknowledge one alert (stops alert escalation).

Current Logs mode on.

Go to the last log record. Zoom (in/out).

Refresh statistics.

Show the details of a Log entry.

Acknowledge all alerts (stops alert escalation).

Statistics view.

Tools button.


Illustration 6.16 Query Panel

The Statistics view allows you to generate basic reports of the log data currently displayed in the Logs view.

Illustration 6.17 Reports in Logs View

Drag and drop log fields from the log entry table or the Fields panel or enter the information by hand for quick log filter creation. You can also add saved log filters here.

Select types of logs to be viewed.

Show logs from a subset of engines or servers that send and store the data.

Focuses the view to the beginning/end of the time range.

Time range.

Apply filters the logs according to your selections.

You can change to a different statistical report within the view. Use the Query panel to change filtering criteria.

Logs View 81

Policy Editing ViewYou can open policies in two modes. Any number of administrators can simultaneously check the rules in the Preview mode. When you choose to open the policy in the Edit mode, the policy is locked, and other administrators cannot edit it at the same time. When you navigate out of a policy you have opened for editing, the lock is released and you are asked if you want to save the policy if there are unsaved changes.

Illustration 6.18 Policy Editing View for Firewall Policy

The policy view has three tabs for the different types of rules you can add to the policy: Access Rules, Inspection Rules, and NAT rules. The rule table columns are different depending on the tab.

Illustration 6.19 Policy Toolbar

Policy-specific tools are placed under the Tools icon in the Policy Toolbar.

Rule table.

Policy toolbar.

Save the policy and install it on engine.

Save changes. Policy-specific tools.


Illustration 6.20 Policy-specific Tools Menu

Find and highlight the rules that match the criteria you define.

Show Inherited rules passed down from higher-level template(s).

Toggle between element names and IP addresses.

Compare the policy you have modified to the engine’s current policy.

Validate the policy you have created.

Policy Editing View 83


CHAPTER 7 Administrator Accounts

Administrator accounts define administrator rights within the Management Client.


Overview to Administrator Accounts, on page 86 Configuration of Administrator Accounts, on page 87 Using Administrator Accounts, on page 92 Examples of Administrator Accounts, on page 92

85

Overview to Administrator AccountsYou can define administrator rights in fine detail for each administrator according to the administrator’s duties. You can first select the basic rights for the administrator and then select the elements to which these rights apply. You can also grant administrators access to whole groups of elements instead of granting access only to individual elements. Selecting specific administrator rights and limiting administrators’ access to certain elements makes the administration of StoneGate more efficient and prevents administrators from making unauthorized changes.StoneGate keeps track of all the elements to make sure that administrators do not overstep the rights defined in the administrator accounts. For example, an administrator can modify an element only if the administrator is allowed to modify all the configurations where the element is used. StoneGate also prevents administrators from deleting elements that are still in use in some other configuration. To make it easier to find and edit all places where an element is used, administrators can search for references to any element using the search feature.As many administrators can have access to the same elements, it is important that administrators do not undo the work of other administrators by editing and deleting elements without due consideration. Administrators who are allowed to edit elements can lock the elements and add a comment to an element as a message to other administrators. If other administrators want to edit the element, they must first unlock it.

86 Chapter 7: Administrator Accounts

Configuration of Administrator AccountsTwo types of elements represent administrator accounts is StoneGate: Administrator elements and Monitoring User elements. With Administrator elements you can define administrators’ rights in great detail. Monitoring User elements represent administrator accounts for users who are allowed to view logs and policy snapshots in the optional Monitoring Client.Illustration 7.1 shows the elements used with Administrator elements.

Illustration 7.1 Elements in Administrator Accounts

Administrator Roles are used with Administrator elements to define the actions that the administrator is allowed to take. Each administrator can have one or several Administrator Roles. You can either use predefined Administrator Roles or create new ones. You must also select one or more elements to which the rights defined in the Administrator Role apply. You can either select Firewall, SOHO Firewall, IPS engine, Firewall Policy, and IPS Policy elements or a whole group of elements by using Access Control Lists, which are lists of different types of elements. You can either use predefined Access Control Lists or create new ones. If an administrator is allowed to view logs, you can also set administrator-specific filters for displaying the logs.Because the rights of Monitoring Client users are automatically restricted to viewing logs and policy snapshots in the Monitoring Client, Administrator Roles are not used with Monitoring User elements. All other elements used with Administrator elements (Access Control Lists, Filters, and selected engines and policies) can also be used with Monitoring User elements.


Default ElementsThere are several predefined elements that you can use for managing administrator accounts: a predefined Superuser account with unlimited permissions as well as predefined Administrator Roles and Access Control Lists. The predefined administrator account elements are stored in the Administrators, Administrator Roles, and Access Control Lists branches of the Access Rights tree.

Predefined Account with Unrestricted PermissionsA Superuser account with unrestricted permissions is created during StoneGate installation. The user name and the password for the account are defined in the installation wizard. With this account, you can create the necessary number of new administrator accounts and grant other administrators permission to create and manage administrator accounts. You cannot delete this account.

Predefined Administrator RolesThere are three predefined Administrator Roles: Owner, Operator, and Editor. You cannot modify them.

Predefined Access Control ListsAll elements automatically belong to one or several predefined Access Control Lists, which you cannot modify.

TABLE 7.1 Predefined Administrator Roles

Administrator Role Description

OwnerOwners are administrators who can edit and delete a limited set of elements that they or other administrators have created.

OperatorOperators are administrators who can view the contents of a limited set of elements that other administrators have created. They can also browse logs and alerts from elements granted to them.

EditorEditors are responsible for managing a limited set of elements, which they can create, modify, and delete. They can also browse logs and alerts from elements granted to them.

TABLE 7.2 Predefined Access Control Lists

Access Control List Description

ALL Administrators All Administrator accounts.

ALL Monitoring Users All Monitoring Client user accounts.


Configuration WorkflowThe following sections provide an overview of the configuration tasks related to Administrator and Monitoring User accounts. Detailed step-by-step instructions can be found in the Management Client’s online help and the Administrator’s Guide PDF in the section called Administrator Access.

Task 1: Create a New Administrator RoleAdministrator Roles define which actions administrators are allowed to take. They are used with Administrator elements.For security reasons, it is important that you select only the permissions that are necessary for performing the tasks for which the Administrator Role is created. For example, the right to manage administrators must be limited to only the administrators who are responsible for administrator accounts.You can either use the Predefined Administrator Roles or create new ones.

Task 2: Create a New Access Control ListAccess Control Lists are lists of elements. You can use them in Administrator elements to select to which elements the rights of a specific Administrator Role apply. You can also use them in Monitoring User elements to specify the elements from which the Monitoring Client user is allowed to view logs and the policies from which the Monitoring Client user is allowed to view snapshots.

ALL StoneGate Elements All elements in StoneGate.

ALL Firewall Policies

The elements mentioned in the name of the Access Control List.

ALL Firewalls

ALL Incident Cases

ALL IPS Policies

ALL Sensors and Analyzers

ALL SOHO Firewalls

ALL SSL VPN Gateways

ALL Simple ElementsAll elements except Firewalls, SOHO Firewalls, IPS engines, Firewall Policies, IPS Policies, Incident Cases, and SSL VPN Gateways.

TABLE 7.2 Predefined Access Control Lists (Continued)

Access Control List Description


An Access Control List can contain Firewall, SOHO Firewall, IPS engine, Firewall Policy, and IPS Policy elements.Access Control Lists are used to limit administrators’ access to elements. When a new element is created, it is automatically included in predefined Access Control Lists according to element type. For example, a new Firewall element is automatically included both in the All StoneGate Elements and All Firewalls Access Control Lists.You can also use the Access Control Lists that you have created in the properties of Firewall, SOHO Firewall, IPS engine, Firewall Policy, and IPS Policy elements.

Task 3: Configure Administrator Password PolicyThe Administrator password policy defines the settings for password strength, password expiration, and failed logins. You can optionally configure the administrator password policy in <installation directory>/data/SGConfiguration.txt on the Management Server. The following settings can be configured:

TABLE 7.3 Administrator Password Policy Settings

Parameter Name Description

FAILED_AUTH_ATTEMPT_MAXThe maximum number of failed login attempts before the administrator account is locked.

TIME_LOGIN_LOCKED

The duration (in minutes) for which the administrator account is locked when the maximum number of failed login attempts has been reached. You must define a value for FAILED_AUTH_ATTEMPT_MAX to use this.

OBSOLETE_PASSWORD_QUEUE_LENGTHPrevents the reuse of the defined number of previous passwords.

PASSWORD_BOTH_LETTER_AND_NUM_REQUIRED

Defines whether administrator passwords must contain both letters and numbers. When the value is true, both letters and numbers are required.

PASSWORD_CHARACTER_NUMBER_MINIMUM

The minimum number of characters administrator passwords must contain.

PASSWORD_EXPIRATIONThe number of days after which the administrator password expires and must be changed.


Task 4: Create a New Administrator Element or Monitoring User ElementWe recommend that every administrator have a personal administrator account. Using shared accounts makes auditing difficult and may prevent timely discovery if there is a security breach.An administrator account defines a user name for the administrator and the authentication method: internal authentication with a password or RADIUS authentication (see RADIUS Authentication, on page 92).When you use internal authentication, the strength of the administrator passwords is checked according to the administrator password policy defined in Task 3: Configure Administrator Password Policy, on page 90. Administrator passwords expire at the intervals you set in the administrator password policy. You can configure the password for a particular administrator account to never expire in the Properties for that administrator account. You can optionally configure the administrator account to expire on a certain date.Administrator passwords must be carefully selected and frequently renewed. We recommend that passwords be at least eight characters long and contain combinations of alphabetical, numerical, and special characters. Avoid using any words found in a dictionary, parts of your or your relatives’ names, birthdays, home addresses, or similar.When you create administrator accounts with Administrator elements, the administrators’ rights are defined with administrator permissions. There are two permission levels, which reflect the basic access levels that the administrators may need to have.The Unrestricted Permissions option gives the administrator the right to manage all elements without restriction. This includes, for example, the right to manage administrator accounts and define which elements other administrators can access.The Restricted Permissions option allows you to define an administrator’s rights in great detail. You must select at least one Administrator Role for the administrator. You can use either a predefined Administrator Role or one that you have created. You must also select one or more elements for each Administrator Role. These are the elements to which the Administrator Role’s rights apply. You can select Access Control Lists or individual Firewalls, SOHO Firewalls, SSL VPN Gateways, IPS engines, Firewall Policies, or IPS Policies as the elements for Administrator Roles. All other elements are included in the ALL Simple Elements Access Control List.When you define the rights of a Monitoring Client user in a Monitoring User element, you must select the elements from which the administrator is allowed to view data (log data or policy snapshots). You can select either Access Control Lists or individual Firewalls, SOHO Firewalls, IPS engines, Firewall Policies, or IPS Policies. An administrator whose account is defined with a Monitoring User element is not allowed to log in using the Management Client.


You can select administrator-specific log filters in the administrator account to define which logs are displayed to the administrator. You can either use predefined filters or create new filters (see Filters, on page 297 for more information). The log filter selection is available only if the administrator is allowed to view log data.

Using Administrator AccountsYou can customize administrator accounts by defining log colors for administrators. You have also the option of using RADIUS authentication as the method for identifying administrators.

Customizing Log Color SettingsDifferent types of logs are displayed with a different background color when you browse log entries in the Management Client or the optional Monitoring Client. The background colors for log entries are set with log filters. The log colors are the same for all administrators by default. If you have the right to manage administrator accounts, you can customize the default log colors used for all new administrator accounts. You can also define administrator-specific log colors that will be used for displaying logs and alerts to the administrator. Administrator-specific log colors make it easier to draw the administrator’s attention to particular logs.

RADIUS AuthenticationYou can use an external RADIUS server for authenticating administrators’ Management Client or Monitoring Client login. The supported authentication protocols are EAP-MD5, PAP, CHAP, MSCHAP, and MSCHAP2. The RADIUS authentication method for administrator accounts is selected in the Management Server element’s properties. The communications are configured in a RADIUS Authentication Server element. The communications are secured using a shared secret.You can use RADIUS authentication, for example, with Microsoft Active Directory Servers and RSA SecurID. If you use an Active Directory Server element for user authentication, you must create a separate RADIUS Authentication Server element for authenticating the administrators.RADIUS authentication is selected individually for each Administrator element and Monitoring User element. The administrator’s user name must be the same on the Management Server and in the user database that the RADIUS server uses. Note that you cannot set external authentication servers to query the administrator account information from the Management Server’s internal database.

Examples of Administrator AccountsThe examples in this section illustrate common uses for administrator accounts in StoneGate and the general steps on how the scenarios are configured.


Creating Accounts with Predefined Administrator RolesIn Company X, all administrators are responsible for monitoring the traffic that passes through StoneGate. However, the responsibility for creating and modifying elements is reserved for the more experienced administrators.The company’s administrators must create new accounts for both types of administrators. Because the predefined Operator and Editor Administrator Roles are suitable for the company’s needs, the administrators decide to use the predefined Editor and Operator roles in the new administrator accounts. To create each account, the administrators:1. Create an Administrator element.2. Select Restricted Permissions as the level of administrator permissions.3. Select the Administrator Roles:

• Operator role for an administrator who needs access to logs and alerts.• Editor role for an administrator who has to have all the rights that the Operators

have but who also needs to be able to create and delete elements and edit element properties.

4. Select the elements to which the rights granted by the Administrator Role apply. • The default elements for the Operator and Editor roles are ALL Simple

Elements, so ALL Simple Elements is already selected for the roles. The administrators only need to add ALL Firewalls, ALL Sensors and Analyzers, ALL Firewall Policies, and ALL IPS Policies as elements for the Operator and Editor roles.

Creating Accounts with a New Access Control ListCompany Y has established a new branch office. The company’s administrators decide to let the administrator at the branch office have the responsibility of managing the branch office engines and their policies. Because of this, the branch office administrator needs access to the branch office Firewalls and IPS engines and the logs and alerts from them. The administrators find the predefined Editor role suitable for the new administrator. As the predefined Access Control Lists are not suitable for the new administrator, the administrators create a new Access Control List that includes the engines and security policies used in the branch office. The administrators:1. Create a new Access Control List and select the branch office Firewalls, IPS

engines, Firewall Policies, and IPS Policies to the list.2. Create a new Administrator element.3. Set the administrator permissions by selecting Restricted Permissions as the

permission level, predefined Editor role as the Administrator Role, and the new Access Control List as the element for the role.

Examples of Administrator Accounts 93


CHAPTER 8 Network Elements and Services

Network elements represent physical devices (IP addresses) in your network. Services represent protocols and ports. The main use for both types of elements is building rules in your firewall policies.


Introduction to Network Elements and Services, on page 96 Network Element Types, on page 96 Services, on page 101

95

Introduction to Network Elements and Services

Network elements represent network devices (identified by their IP addresses). The same elements are used in policies, log filters, and in any other place where you must specify IP addresses. Network elements also include special elements, such as Expressions, which allow defining any set of IP addresses with one element.Services represent ports and protocols. For example, when you use the default Service element for HTTP in the Access rules of your firewall policy, the rule matches TCP traffic on port 80 and the firewall makes sure that the matching communications proceed according to the standards of TCP.Network elements and services are managed in the StoneGate Configuration view, accessible through the Configuration menu.

Network Element TypesMost network elements can be defined by simply giving them a unique, descriptive name and an IP address in their properties. It is a good idea to add also descriptive comments to help identify the elements or their purpose.It is possible to define secondary IP addresses for Host, Router, DNS Server, and CIS (Content Inspection Server) elements. A secondary IP address is used only to identify an element as a source or destination of traffic. The secondary IP addresses are not used for other applications of the network elements. For example, only the primary address of a Router element is used for routing purposes when the element is used in the Routing view.

Address Range ElementsAddress Range refers to a range of IP addresses that can be used for some common purpose, but which is typically smaller than a network segment. You only need to define the first and last address in the range.

Alias ElementsAliases are special, generic elements that can represent any other network element. They are context dependent: unlike other elements, an Alias does not have a fixed value. Its value depends on the firewall on which the policy containing the Alias element is installed. The value of the Alias is defined for each firewall (in the Alias element’s or Firewall element’s properties).You can create your own Aliases, but there are also several pre-defined aliases in the system that are useful in the configuration. For a listing, see Predefined Aliases, on page 423.

96 Chapter 8: Network Elements and Services

Expression ElementsExpression is a special element that allows network elements to be combined with logical operators. Expressions allow you to create a single element to represent complex sets of network resources. For example, expressions make it very simple to define an element that represents a whole network except for one address or a few addresses scattered throughout the address space. The expression operators are used as described in Table 8.1.

Parenthesis are always evaluated first, then negations, intersections and finally

unions. With the expression A (B C) D, the formula between parenthesis

is solved first, say X = B C. Then, the negation against X is solved before solving the intersection between set A and the negation of set X.

Firewall ElementsFirewalls are a special class of element for storing the configuration information about the StoneGate firewall engines. The most important information contained in the Firewall elements is the interface configuration. The Firewall elements also allow you to monitor and command your physical firewalls. Firewall elements are often not valid for use in configuration tasks as representations of IP addresses, since they typically have multiple interfaces and therefore multiple IP addresses in different networks. In those cases where it can be used, the firewall elements represent their Primary Control IP address.

SOHO Firewall ElementThe SOHO Firewall elements represent SOHO firewall appliances.

Single Firewall ElementThe Single Firewall elements represent non-clustered firewalls.

TABLE 8.1 Network Element Expressions

Expression Description

A BThe union of sets A and B. Unites two sets and forms a new set that includes every element of set A and set B.

A BThe intersection of sets A and B. Creates a new set that includes every element shared in common between sets A and B.

AThe negation of set A. Creates a new set that includes every possible element except the ones in set A.


Firewall Cluster ElementThe Firewall Cluster elements represent two to sixteen StoneGate engines that are clustered together to share the workload and/or provide high availability for network access.

Group ElementsGroup is an element that combines other network elements together into a single object for convenience and clarity.For example, you could create a Group called “Web server” that includes three Web servers and use the Group in several Access rules that allow access to and from the Web servers. The Group approach is especially convenient for making changes. For example, if you were later to add two more Web servers, you could just add them in the Group. Each Access rule where the Group is used would automatically include the two new servers without any need for you to change each rule individually.

Host ElementsThe Host element can be used to represent any single IP address. Typically, it represents a single PC or a server, or the translated address of any component in the NAT rules when NAT (Network Address Translation) is used.

IPS ElementsThe IPS network elements are the IPS engines defined in your system. For more information, see the IPS Reference Guide and the Online Help system of the Management Client.

SSL VPN ElementsThe SSL VPN elements are the SSL VPN gateways defined in your system. For more information, see the SSL VPN Administrator’s Guide.

Network ElementsThe Network element enables an administrator to define an IP address range by specifying the network address and the subnet mask. The Network element has an option to include the broadcast addresses (0.0.0.0 and 255.255.255.255) to the element’s address space.The Any Network element equals to network 0.0.0.0 that matches all IP addresses. Any Network can be used to represent networks that are not specifically defined. StoneGate also automatically generates network elements based on the interface configuration of firewall elements.


Router ElementsThe Router elements are used in the Routing view and inside NetLink elements for defining a next-hop gateway. For more information about routing, see Chapter 12, Routing and Antispoofing.

Server ElementsThere are several specific server types available in StoneGate. Each of them performs particular roles in assisting StoneGate firewalls with controlling and managing network traffic. There is no special element for servers in your network that take no part in StoneGate’s operation. The IP address of such servers (like Web servers, FTP servers etc.) are defined using the other elements (such as Host elements) when needed, for example, in Access rules.

Management Server ElementThe Management Server element represents the StoneGate Management Server(s). Only one Management Server is active at a time, but you can additionally have several backup Management Servers, which are all represented by their own element. The Management Server elements can be automatically created in the Management Center during installation.

Log Server ElementsThe Log Server element represents a StoneGate Log Server. Your system must have one Log Server element for each physical Log Server. The Log Server element can be automatically created in the Management Center when you certify the Log Server during or after its installation.

Authentication Server ElementsAuthentication Server is used for defining external servers that provide authentication services to StoneGate. There are separate elements for the two supported protocols, RADIUS and TACACS+. Either of these two standards can be used for authenticating users connecting to resources through the firewall (either through a VPN or unencrypted). A RADIUS server can be used for authenticating StoneGate administrators’ Management Client logins.

Active Directory Server ElementsThe Active Directory Server element includes settings needed when you want to use a Microsoft Active Directory server to authenticate users and/or store user information for user authentication in StoneGate. The Active Directory Server element includes both the IAS (RADIUS authentication) and LDAP (user directory) settings for Microsoft Active Directory servers.


LDAP Server ElementsThe LDAP Server element is used for external LDAP directory servers that maintain a user directory for StoneGate. StoneGate has a built-in database for storing user information, but you can use this element to specify an external LDAP directory to be used instead.

Content Inspection Server (CIS) elementsContent Inspection Servers (CIS) define servers that provide additional inspection services for StoneGate, such as virus scanning or URL filtering. This element defines the servers to which packets are forwarded for content inspection and also the protocols to be inspected.

DNS Server ElementsThe DNS Server element is used to define DNS servers for inbound traffic management when Dynamic DNS updates are used. These servers must support DDNS updates, however, inbound traffic management can be handled also without DDNS. If you are not using DDNS, there is no need to define this element.

DHCP Server ElementThe DHCP Server element defines DHCP servers that distribute dynamic IP addresses and/or virtual IP addresses (optionally used by VPN clients).

Monitoring Server ElementThe Monitoring Server element represents the StoneGate Monitoring Server, a gateway for the StoneGate Monitoring Client. The Monitoring Server element can be automatically created in the Management Center when you certify the Monitoring Server during or after its installation.

Traffic Handler ElementsTraffic Handlers are a special set of elements used on StoneGate firewalls for inbound and outbound traffic management (discussed in Server Pool Configuration, on page 271 and Routing and Antispoofing, on page 141). With NetLinks, Outbound Multi-Links, and Server Pools you can take advantage of the advanced Multi-Link and traffic management features of StoneGate.

NetLinkThe network connectivity provider is represented by the NetLink element. Typically, this would be an Internet Service Provider (ISP), however, any other IP-based means of communication can be represented with NetLinks: leased lines, cable modems, xDSL links, or even two alternative routes within your internal network that lead to the same destination.


NetLinks are similar to routers, but NetLinks have additional properties, such as a list of IP addresses to probe in order to verify the operation of an ISP connection. Each NetLink needs to be associated with a gateway element (router or firewall).

Multi-LinkAn Outbound Multi-Link element collects together NetLinks for exclusive use with outbound traffic management. Given type of outbound traffic defined in the policy will be load balanced between the NetLink elements included in the specified Multi-Link. For correct routing, NAT is necessary, and the Outbound Multi-Link element also defines the external IP addresses that are used for translating the source addresses in connections through the different NetLinks.

Server PoolDefines a group of application servers, such as Web servers that are used for server load balancing for inbound traffic management. This element also defines the DNS information for inbound traffic management.

ServicesThe Service elements are used in Access rules to match the rule to a certain port, to define the connections that are handled using Protocol Agents (see Chapter 17, Protocol Agents), and to define the Protocol that is used for matching the traffic to the correct Situations in Inspection rules. The Services are organized according to service families, such as TCP and UDP. There are also Service Groups that combine similar single Services together.

TABLE 8.2 Services

Service Description

Services that use Protocol Agents with default value.

Service Group; no Protocol Agents attached.

Service Group; with Protocol Agent(s).

ICMP: Identifies the message by the ICMP Type and Code fields.

IP-proto: Identifies the protocol by the IP header Protocol field.

Services 101

The services are further divided into the following two classes:• System service is a system generated service description defining one service (e.g.,

TCP destination port, IP protocol, etc.).• Custom service is a user-defined service description (e.g., a non-standard TCP port

used by an in-house software).There are pre-defined system Service elements for official (IANA-reserved) and well-known protocols and services (such as DNS, FTP, HTTP etc.). You can also create your own custom Service elements to specify any port that is not pre-defined, or copy one of the pre-defined services to change the port to a non-standard one or change any of the other options that the Services have.

SUN-RPC: Identifies the Sun remote procedure call (RPC) service by the program identifier.

TCP: Identifies the service by the TCP header Source Port and/or Destination Port fields.

UDP: Identifies the service by the UDP header Source Port and/or Destination Port fields.

TABLE 8.2 Services (Continued)

Service Description


CHAPTER 9 SOHO Firewall Configuration

A SOHO (Small Office/Home Office) Firewall is a firewall primarily meant for small businesses and home offices. It offers a different set of features than Single Firewalls and Firewall Clusters.


Overview to SOHO Firewall Configuration, on page 104 Configuration of SOHO Firewalls, on page 104 Using a SOHO Firewall, on page 107 Example of a SOHO Firewall Deployment, on page 109

103

Overview to SOHO Firewall ConfigurationThe SOHO Firewalls are primarily intended to provide small remote site or home office users access to the main company network through a wired or wireless connection. SOHO Firewalls can also allow remote site and home office users as well as visiting users access to the Internet through a wired or wireless connection.SOHO Firewalls are StoneGate appliances which have WLAN (Wireless Local Area Network) features and an integrated ADSL (Asymmetric Digital Subscriber Line) modem. Only outbound connections are allowed from SOHO Firewalls to the Internet. Connections to and from the main company network must be made through a VPN (Virtual Private Network).SOHO Firewalls do not support many of the features Single Firewalls and Firewall Clusters support. Only general features such as monitoring, logging, and reporting are supported in addition to the features explained in this chapter.

Configuration of SOHO FirewallsSOHO Firewalls are configured and managed centrally through the Management Server. A SOHO Firewall element represents the SOHO Firewall’s configuration on the Management Server. The elements used for configuring SOHO Firewalls are shown in Illustration 9.1.

Illustration 9.1 Elements in SOHO Firewall Configuration

The main point of configuration is the SOHO Firewall element. When ADSL or PPPoE is required, a suitable ISP element is referenced for the settings suitable for a particular provider. The SOHO Gateway Group element collects together the SOHO Gateways, so that the often identical configurations can be represented in a simple and clear way in a VPN.The configuration of SOHO Firewalls is based on a classification of the network interfaces into different security zones. There are no separate policies to set up. This chapter describes the configuration of network interfaces for a SOHO Firewall, the only configuration needed to get the SOHO Firewall itself up and running.

104 Chapter 9: SOHO Firewall Configuration

You can define the following types of interfaces:• External is the SOHO Firewall’s connection to the Internet. This is either an ADSL

line or an Ethernet connection. Incoming connections are only allowed through this interface if they are transferred over the VPN configured between the SOHO firewall and the main site.

• Corporate is the SOHO Firewall’s protected, internal network. Connections are allowed freely between all Corporate interfaces and to and from the VPN. Also direct connections to the Internet are allowed by default. However, it is possible to configure that only Internet connections to the main company network over a VPN are allowed. Connections to/from Guest interfaces are not allowed. You can also define a wireless Corporate interface.

• Guest is meant for visitor access. Connections are not allowed from the Guest interface to the VPN nor to the Corporate interface(s). Only direct connections to the Internet are allowed. You can also define a wireless Guest interface.

The SOHO Firewall has an integrated DHCP server that can be used to assign addresses to clients in the Corporate and Guest networks. The IP addresses the DHCP server distributes are configured separately for each type of interface.

Default ElementsThere are ISP elements in the system for a large number of Internet service providers from around the world. In most cases, you should be able to find a suitable element for your ADSL or PPPoE configurations from these default elements. If your ISP decides to change the settings required, you will have to duplicate the default element or create a completely new element to be able to make the necessary changes.

Configuration WorkflowThe following sections provide an overview of the configuration tasks related to configuring and customizing SOHO Firewalls. Detailed step-by-step instructions can be found in the online help of the Management Client and the Administrator’s Guide PDF, in the section called Elements.

Task 1: Create SOHO Firewall Element(s)A SOHO Firewall element represents the configuration information related to a SOHO Firewall engine. You must define a new SOHO Firewall element to introduce the new SOHO Firewall to the Management Center.Instead of creating several SOHO Firewalls one by one, you can also create several SOHO Firewalls simultaneously using the SOHO Firewall Configuration Wizard. Depending on the options needed, the Configuration Wizard may be sufficient alone or some settings may need to be added at the level of the individual SOHO Firewall elements once the wizard is complete.

Configuration of SOHO Firewalls 105

Task 2: Select the Interface TypesYou must define at least two interfaces for a SOHO Firewall: an External interface for Internet connections and a Corporate interface that allows connections to the corporate network over a VPN and optionally also direct connections to the Internet. You can either select one of the Ethernet interfaces 1-4 or the ADSL interface as the External interface. Only one interface can be set as External. Several interfaces can be set as Corporate as necessary.In addition to the External and Corporate interfaces, you can optionally define one or more Guest interfaces to provide Internet access for visitors (or family members of your employees who have SOHO firewalls for their home offices).

Task 3: Define the Interface SettingsThe interface settings are always identical within one interface type, even though there can be several Corporate or Guest interfaces.The settings for the External interface include either setting the IP address, or adding a Service Provider. If your Service Provider requires a username and password, the information can be entered in the configuration or locally by the person installing the appliance on site.The interface settings for the Corporate and Guest interfaces are similar to each other. The SOHO Firewall always has a static IP address on these interfaces. You can optionally activate the internal DHCP server on these interfaces and define the address space used for this. You can also activate wireless access and set security settings per interface type. Both the DHCP and the wireless can be used simultaneously on the Corporate and the Guest interface, also with differing settings. In addition, you can select in the Corporate interface settings if direct connections to the Internet are allowed from the Corporate interface.

Task 4: Define General Wireless Channel SettingsThe wireless settings related to the wireless radio transmissions apply to both Corporate and Guest wireless connections. These include, for example, the channel used for the wireless communications and the mode of the wireless network (802.11b/g). The 802.11g-mode provides faster maximum transmission speeds than the 802.11b mode.Mixed mode can be used if all connecting clients are not compatible with the 802.11g mode. Mixed mode allows both types of clients to join, and allows 802.11g clients to connect at a higher data rate than the 802.11b mode, although the maximum speed for 802.11g clients is not quite as high as it is in the 802.11g mode.

Task 5: Configure the Main Site FirewallMake sure that your Firewall Policies allow connections from the SOHO Firewall to the Management Server and to the Log Server. You must also allow VPN traffic between the SOHO Firewall and the VPN gateway, including any connections the SOHO Firewall users make to the Internet. The Internet connectivity offered through the main site


firewall must also be reflected in the VPN routing (the Any Network element must be included in the main firewall’s VPN Site).If you define RADIUS authentication for wireless users, make sure that connections from the SOHO Firewall to the RADIUS server are also allowed in the Firewall Policy. The services needed for the connections between the different system components are listed in StoneGate-Specific Ports, on page 401.

Task 7: Install the SOHO Firewall ApplianceDuring the engine installation, the interface definitions created in the Management Client are transferred to the SOHO Firewall engine. The interface definitions are transferred by importing the initial configuration to the engine through the SOHO Firewall web interface. In most cases, this is the only configuration required. However, if the username and password information is required, but is not included in the configuration, the administrator installing the appliance must enter the username and password manually through the SOHO Firewall web interface.Once the initial configuration has been transferred to the engine, the engine makes the initial contact to the Management Server and receives a certificate for management communications. This establishes a trust relationship between the engine and the Management Server. Any subsequent configuration changes are done in the Management Client and installed remotely without any need to manually transfer the configuration file again.

Using a SOHO FirewallThe main points of the SOHO Firewall configuration are explained in the preceding sections of this chapter. This section give more information about configuring wireless connections with the SOHO Firewall.

Configuring Wireless ConnectionsYou can configure the SOHO Firewall to allow wireless connections for corporate and visiting users. You can define separate settings for both user groups and select different security modes for the wireless connections. You can also define a RADIUS server and require that the wireless users must authenticate themselves. Using RADIUS authentication requires a separate RADIUS server.

Caution – Be careful when you define the security mode for wireless traffic. Enabling wireless connections without requiring encryption may endanger your network security. Always use encryption on the Corporate interface.

Caution – WEP encryption has known weaknesses. If you must use WEP, we recommended that you change the encryption key frequently.

Using a SOHO Firewall 107

Table Table 9.1 explains the available security modes for wireless use..

TABLE 9.1 Security Modes and Methods for Wireless Use

Security Mode Mode Description

Disabled None

Wireless traffic is not encrypted.Use this security mode with caution. This security mode allows access to anyone within range.Never use this mode for the Corporate interface.

WEP

WEP 40

Wireless traffic is encrypted with a 40-bit WEP (Wired Equivalent Privacy/Wireless Encryption Protocol) key. WEP has known weaknesses. We recommend you use WPA instead whenever possible. If you must use WEP, we recommend that you use the stronger encryption instead.

WEP 104

Wireless traffic is encrypted with a 104-bit WEP key. WEP has known weaknesses. We recommend you use WPA instead whenever possible. If you must use WEP, this is the recommended option.

WPA-PSK

WPA (with TKIP encryption)

Wireless traffic is encrypted with TKIP (Temporal Key Integrity Protocol) encryption. This security mode is normally used in small networks.

WPA2 (with AES encryption

Wireless traffic is encrypted with AES (Advanced Encryption Standard) encryption. This security mode is normally used in small networks.

WPA and WPA2Wireless traffic is encrypted with TKIP or AES. This security mode is normally used in small networks.

WPA Enterprise

WPA (with TKIP encryption)

An external RADIUS server is used to authenticate the users. Wireless traffic is encrypted with TKIP. This security mode is normally used in larger networks to transfer sensitive data.

WPA2 (with AES encryption

An external RADIUS server is used to authenticate the users. Wireless traffic is encrypted with AES. This security mode is normally used in larger networks to transfer sensitive data.

WPA and WPA2

An external RADIUS server is used to authenticate the users. Wireless traffic is encrypted with TKIP or AES. This security mode is normally used in larger networks to transfer sensitive data.


Example of a SOHO Firewall DeploymentThe example in this section illustrates a common deployment scenario for SOHO Firewalls and a general overview to the steps on how the scenario is configured.

Setting up Several SOHO FirewallsOur example company is a construction company that has one head office and different work sites in different towns and cities. The head office has a StoneGate firewall cluster. The offices at the work sites use various equipment, some picked up from computer stores and some provided by their Internet service providers with the ADSL lines. The company has a contract with one ISP for the Internet connectivity at all the remote sites.Differences in the equipment make the current setup difficult to maintain and monitor, so the company decides to unify their work site equipment and take advantage of the central management offered by the StoneGate SOHO Firewalls.The network setup the company plans to have is shown in Illustration 9.2.

Illustration 9.2 Network Setup

The remote offices have wireless and wired networks that are meant for employees to connect to the network services at the main site and the local services offered at the work sites, such as network printers. Outside contractors and other visiting users sometimes need access to the Internet to access the company’s extranet and for general access.

Example of a SOHO Firewall Deployment 109

To set up their new SOHO appliances, the administrators:1. Create the SOHO Firewall elements using the multiple SOHO Firewall

Configuration Wizard.• The External interface receives its IP address dynamically and the ISP does not

require a password for the ADSL access, so all SOHO Firewall elements can be created at the same time and require no additional configuration once generated.

• A single Guest interface is used in this case and the other Ethernet interfaces are used as Corporate interfaces.

• WPA personal is used to secure the wireless Guest access and WPA Enterprise to provide RADIUS-authenticated access through the Corporate wireless interface. The RADIUS server is located at the main office.

2. Configure a new VPN in the Management Client for access between the SOHO Firewalls and the main office firewall.

3. Add access rules for the management and VPN connections from the SOHO Firewalls into the policy of the main office firewall.

4. Save the configuration for the SOHO firewalls. The remote site employees plug the appliances in at the new and current work sites and import the initial configuration through the web-based interface.

5. When the work site changes, the appliances can be plugged off at the old site and plugged in at the new site without any configuration, since the ISP is the same.


CHAPTER 10 Single Firewall Configuration

A Single Firewall is a firewall that has only one firewall engine (instead of a cluster of two or more engines).


Overview to Single Firewall Configuration, on page 112 Configuration of Single Firewalls, on page 112 Using a Single Firewall, on page 115 Example of a Single Firewall Deployment, on page 117

111

Overview to Single Firewall ConfigurationA single Firewall can be deployed at sites where the performance benefits and high availability provided by a clustered firewall are not essential. High availability of network connections is still available, since single Firewalls fully support Multi-Link. Single firewalls additionally support two features unavailable on firewall clusters: firstly, single firewalls can have dynamic IP addresses on their interfaces and secondly, they can be configured as a DHCP server for their network. The Single Firewall engine can be a standard server with an Intel-compatible processor or a StoneGate appliance. A StoneGate UTM appliance adds anti-virus scanning to the standard Firewall/VPN feature set.This chapter concentrates on network interface configuration, which is the only part of the basic firewall configuration that has major differences between a single Firewall and a clustered installation. The section Using a Single Firewall, on page 115 addresses other configuration tasks that you may do in the Firewall elements’ properties. Other features, including routing and antispoofing, are explained together for both types of installations in separate feature-specific chapters.Note that SOHO firewalls are very different from other firewall installations. For information on configuring a SOHO Firewall, see SOHO Firewall Configuration, on page 103.

Configuration of Single FirewallsStoneGate firewalls are configured and managed centrally through the Management Server. The Single Firewall element represents the firewall’s configuration on the Management Server. The main configuration options in the Single Firewall element are the settings related to network interfaces. This chapter concentrates on those settings.

Dynamic Firewall Interface AddressesStoneGate single firewalls support the use of DHCP and PPPoE to assign dynamic IP addresses on a Firewall’s network interfaces. Typically, a dynamic IP address is used in smaller sites with xDSL connections that have no static IP address available for the Firewall.Instead of an IP address, each dynamic interface is identified by a DHCP Index, an arbitrary number of your choice that is used to distinguish different dynamic interfaces from one another.When a firewall has a fixed IP address, the Management Server can contact the firewall whenever there is need. But when the firewall has a dynamic IP address, the Management Server does not have a fixed IP address to contact, so the firewall contacts the Management Server instead. The frequency of these contacts can be adjusted as necessary. If the contact is lost (for example, the Internet connection goes down), the Management Server queues the commands you have made to the firewall and executes them when contact is re-established.

112 Chapter 10: Single Firewall Configuration

Dynamic IP addressing also affects the VPN configuration in much the same way as management communications: but here, note that the other end-point must use a static IP address. The Firewall with the dynamic address always has to open the VPN tunnel. After the VPN tunnel is established, connections can be made in both directions as usual. Dynamically changing IP addresses also make direct VPN client connections impractical, but the VPN client connections can be forwarded through a gateway-to-gateway VPN from some gateway that has a static IP address (VPN hub configuration).

Configuration WorkflowThe following sections provide an overview to the configuration tasks related to configuring and customizing Single Firewalls. Detailed step-by-step instructions can be found in the online help of the Management Client and the Administrator’s Guide PDF, in the section called Elements.

Task 1: Create a Single Firewall ElementTo introduce a new single firewall to the Management Center, you must define a Single Firewall element that stores the configuration information related to the firewall engine.

Task 2: Define Physical InterfacesPhysical Interface definitions represent the actual network interface cards on the engines.To route traffic through the firewall, you must define at least two physical interfaces.The network interface numbering in the configuration is independent from the operating system level numbering of the physical interfaces on the engine. By default, the two numbering schemes are mapped one to one, but you can change the mapping freely using command line tools on the engine.

Task 3: Define VLAN InterfacesA Virtual Local Area Network (VLAN) is a logical grouping of hosts and network devices that allows creating several separated networks on a single physical link. To allow this separation, StoneGate supports VLAN tagging as defined in the IEEE 802.1q standard. One network interface can support up to 4094 VLANs.If you want to define VLAN interfaces on the engine’s network interfaces, add the VLAN interfaces for the physical interfaces before configuring the IP addresses for those interfaces. The defined VLAN interfaces are displayed, for example, as “5.202” for network interface 5 with VLAN 202. You must also configure the router with the VLAN properties.

Configuration of Single Firewalls 113

Task 4: Define IP AddressesYou can define several IP addresses for the same physical interface. You can also define VRRP (virtual router redundancy protocol) settings for each IP address to have the firewall utilize an existing redundant router configuration.

Task 5: Install the Firewall EngineDuring the engine installation, you map the physical interfaces on the engine to the interface IDs you define in the Management Client. You can also configure the engine automatically using a configuration saved on a USB memory stick. If you use the automatic engine configuration, the interface IDs shown in the Management Client are automatically mapped to physical interfaces in sequential order. For example, Management Client interface ID 0 is mapped to eth0, Interface ID 1 is mapped to eth1, and so on. The first physical interface (eth0) is always used as the Management interface. For this reason, Interface ID 0 must be defined as the Management interface in the Management Client if automatic USB configuration is planned.During the installation, a basic initial configuration is activated and an initial contact between the Management Server and the engine is initiated. During the initial contact, the engine authenticates itself to the Management Server with a one-time password. When this initial contact succeeds, the engine receives a certificate from the Management Center for authenticating all subsequent communications—a trust relationship between the engine and the Management Server is established. The one-time password expires at that time, since it is unnecessary from that point onwards.

Task 6: Install a Firewall PolicyAfter the firewall engine establishes contact with the Management Server, only the primary control interface with the Management Server is configured. You must install a Firewall Policy using the Management Client to transfer the complete configuration to the firewall with information on all interfaces, routing, policies, and other settings. After this is done, the firewall is ready to start processing traffic.


Using a Single FirewallThe main points of Single Firewall configuration are explained in the preceding sections of this chapter, but this section illustrates some concepts further and explains some additional optional features:• Using Multi-Link, on page 115• Running Automatic Tests, on page 116• Sending SNMP Traps, on page 117

Using Multi-LinkMulti-Link technology uses multiple network connections to provide both high availability and load balancing between multiple network links (NetLinks). For more information and details about Multi-Link, see Multi-Link Configuration, on page 263.Illustration 10.1 shows how a Single Firewall’s network interfaces are used for Multi-Link.

Illustration 10.1

In this example, interface 1 is used as the network interface for Internet traffic that is routed through ISP A. Interface 2 is used as the network interface for Internet traffic that is routed through ISP B. It is also possible to configure Multi-Link by defining two or more IP addresses for a single physical interface - the router behind the interface then forwards the traffic to the different ISPs. However, this is not recommended, as it creates an additional single point of failure at the intermediate router, and the associated cabling and network cards.

Internal DHCP ServerSingle firewalls contain an internal DHCP server that can be used to assign IP addresses to hosts in the protected network. This is meant for branch office type installations where it may be more practical to assign the IP addresses using the firewall rather than relay the DHCP requests from a separately maintained local DHCP server or from some other site’s DHCP server through a VPN.

Using a Single Firewall 115

Running Automatic TestsThe firewalls have a test system, which runs on the engines. Note that some tests are already configured by default. You can configure the firewall to run additional or different tests. The tests can check different aspects of the firewall’s current operating state and take action depending on the success or failure of the test. The action can include sending an alert or an SNMP trap, or changing the operating state of the firewall. Each test can be run on the whole firewall or one or more interfaces. The available types of tests are listed in the table below.

All entries that you have configured with the tester are displayed in the Test Entries table. The selected states and actions are indicated on that table with letters as summarized in table below.

TABLE 10.1 Pre-defined Tests

Test Explanation

External

Runs a custom script you create and store on the engine. You can freely decide the content of the script, but the script must return an exit code of 0 (zero) if it succeeds. Any non-zero return value is considered a failure.

File System SpaceChecks whether the available free hard disk space on the specified partition is above the specified minimum amount (in kilobytes).

Firewall PolicyChecks if a new policy is activated on the engine. It is mainly intended for sending SNMP notifications.

Free Swap SpaceChecks whether the free hard disk swap space is above the specified minimum value (in kilobytes).

Interface Up Checks whether a network port is enabled or disabled.

Link Status Tests whether a network port reports the link as up or down.

MultipingSends out a series of ping requests to determine whether there is connectivity through a network link.

TABLE 10.2 Test Entry Display of Selected Actions and States

Types Table display Description

States to test

N Online

O Offline

S Standby


Sending SNMP TrapsThe firewall can send SNMP traps on events such as test failures and changes in its operating state. An SNMP Agent element is a reusable container for the settings according to which the firewalls send SNMP trap messages to compatible external software. A single SNMP Agent can be created once and used on multiple firewalls by selecting the correct SNMP Agent in the firewall properties.StoneGate’s SNMP agent supports SNMPv1 (RFC1157), SNMPv2c (RFCs 1901 and 3416), and SNMPv3 (RFC 3414).

Example of a Single Firewall DeploymentThe example in this section illustrates common deployment scenarios for a Single Firewall and general overviews to the steps on how each scenario is configured.

Setting up a Single FirewallOur example company has just opened a new branch office. The administrator at the branch office is setting up a Single Firewall in the branch office network. The Branch Office Firewall has two interfaces with the internal and external routers:• The Internal Router is connected to Interface ID 0.• The ISP Router is connected to the Interface ID 1.Illustration 10.2 shows the network at the Branch Office.

Action on failure

A Alert

O+A Offline + Alert

FO+A Force Offline + Alert

A+S Alert + SNMP

O+A+S Offline + Alert + SNMP

FO+A+S Force Offline + Alert + SNMP

TABLE 10.2 Test Entry Display of Selected Actions and States (Continued)



Illustration 10.2 Branch Office Network

The administrator has already installed the StoneGate Management Center, and is ready to install and configure the Single Firewall. The administrator does the following:1. Creates a Single Firewall element (Branch Office Firewall) and defines the

Branch Office Log Server as its Log Server.2. Creates an interface for the Internal Router and gives it the following properties:

• Interface ID: 0.• IP Address: 172.16.2.1.• Primary Control IP Address.

3. Creates an interface for the ISP Router and gives it the following properties:• Interface ID: 1.• IP Address: 212.20.2.254.

4. Saves the initial configuration of the Branch Office Firewall on a USB stick.5. Installs the firewall engine in the server room.6. Inserts the USB stick in the firewall, turns it on, and waits until the Management

Client shows that contact is established between the engine and the Management Server.

7. Checks the routing configuration and adds the first few rules for allowing traffic through the firewall.

8. Installs a Firewall Policy using the Management Client to transfer the first working configuration to the Firewall.

Adding a New Interface to an Existing ConfigurationIn the previous example, the administrators initially configured the firewall at their company’s new branch office with just two interfaces. Now they decide that they need an additional physically separated DMZ network for access to/from that office’s mail server to properly control both internal and external traffic with this publicly exposed server. The administrator:1. Creates an interface for the DMZ and gives it the following properties:

• Interface ID: 2.• IP Address: 192.168.2.1.

2. Creates new rules in the firewall’s policy to allow traffic to/from the DMZ and NAT rules to translate between the private and public IP address of the mail server.


3. Connects the new DMZ router to the firewall.4. Installs a Firewall Policy using the Management Client to transfer the new

working configuration to the Firewall.



CHAPTER 11 Firewall Cluster Configuration

A Firewall Cluster is a group of firewall nodes that work as a single logical entity to share the load of traffic processing and provide redundancy, ensuring the availability of network services to the users.


Overview to Firewall Cluster Configuration, on page 122 Configuration of Firewall Clusters, on page 123 Using a Firewall Cluster, on page 129 Examples of Firewall Cluster Deployment, on page 137

121

Overview to Firewall Cluster ConfigurationA single firewall can be a single point of failure. This creates a severe threat to the availability of business critical applications of an organization and complicates the maintenance of the equipment. These problems can be significantly alleviated by clustering firewall nodes. A StoneGate Firewall cluster consists of 2 to 16 nodes that function as a single entity. Clustering is a standard feature that you can activate on any StoneGate Firewall/VPN installation if you have two or more licensed engines.The clustered firewall engines can run on a standard server with an Intel-compatible processor or on a StoneGate appliance. StoneGate UTM adds anti-virus scanning to the standard Firewall/VPN cluster feature set (only standby operation is supported, see Standby Operation, on page 124 and Virus Scanning, on page 237).This chapter concentrates on configuration of network interfaces and clustering, which are the only parts of the basic configuration where there are major differences between a single firewall and a clustered installation. The section Using a Firewall Cluster, on page 129 addresses other configuration tasks that you may do in the Firewall elements’ properties. Other features, including routing and antispoofing, are explained together for both types of installations in separate feature-specific chapters.

Benefits of ClusteringThe StoneGate Firewall/VPN solution uses built-in clustering technology, for which no additional software or hardware is needed to cluster several nodes. If a node itself or the surrounding network equipment malfunction, the other nodes in the cluster take over the traffic processing, minimizing any disruptions to the traffic flow. Similarly, maintenance is easier with a cluster, because individual nodes can be taken offline and even exchanged for new hardware without causing service outages.In addition to eliminating the single point of failure, Firewall clusters balance the load of traffic processing between the firewall nodes. You can also flexibly add nodes to scale up the Firewall, improving the throughput and performance.

Communication Between the NodesThe nodes exchange information constantly so that the state tables that list open connections (known as state sync) and the operating state of the other nodes (known as heartbeat) are exchanged. This exchange of information ensures that all nodes have the same information on the connections and that if a firewall node becomes unavailable, the other nodes of the cluster immediately notice this. The exchange of information between clustered StoneGate nodes is synchronized through selected interfaces via a heartbeat network using multicast transmissions. The heartbeat messages are authenticated, and can also be encrypted if necessary (enabled by default).The heartbeat interfaces exchange data that is crucial for the correct functioning of the cluster. A dedicated network is recommended for these time-critical communications. If both primary and backup synchronization communications

122 Chapter 11: Firewall Cluster Configuration

between clustered nodes are lost for a set period of time, each online node will try to handle any active connection it sees.

Caution – We recommend you never to run the heartbeat on a network that handles other traffic. If you do, turn on encryption to keep this confidential data hidden. Also, other traffic may interfere with these time-critical communications and severely disrupt the operation of the cluster. Therefore, we recommend you to always use dedicated physical networks for the heartbeat. Take special care to ensure that heartbeat interfaces operate correctly and reliably.

HardwareThe clustered firewall nodes all have a nearly identical software configuration, but the hardware the nodes run on does not need to be identical. Different types of equipment can be used as long as all nodes have enough network interfaces for your configuration (additional network interfaces do not matter; those are left unused).If equipment with different performance characteristics are clustered together, the load-balancing technology automatically distributes the load so that lower performance nodes handle less traffic than the higher performance nodes. However, when a node goes offline, the remaining node(s) must be able to handle all traffic on their own to ensure high availability. For this reason, it is usually best to cluster nodes with similar performance.

Configuration of Firewall ClustersStoneGate firewalls are configured and managed centrally through the Management Server. The Firewall Cluster element represents the firewall cluster’s configuration on the Management Server. The main configuration options in the Firewall Cluster element include the settings related to network interfaces and clustering. This chapter concentrates on those settings.In a clustered Firewall configuration, the recommended way to cluster the nodes is load-balanced clustering, where traffic is balanced between the nodes dynamically. Load-balanced clustering provides both fault tolerance and performance benefits. However, you also have the option to use standby clustering, where only one node is processing traffic at a time, and other nodes are used as backups in case the active node stops processing traffic for any reason. The drawback with standby mode is that there is no performance gain in clustering the firewalls. However, the standby mode is the recommended mode of operation when the deep packet inspection or antivirus scanning are active on the cluster to ensure reliable operation.

Load BalancingIf load-balanced clustering is used, the traffic arriving at the Firewall cluster is balanced across the nodes according to settings of the cluster’s load balancing filter.


This filtering process distributes packets between the firewall nodes and keeps track of packet distribution. The Firewall determines the packet ownership of the nodes by comparing the incoming packet with node-specific values based on the packet headers. The load-balancing filter is pre-configured for optimal performance and is not meant to be adjusted independently by the system administrators.The Firewall cluster keeps track of which node is handling each ongoing connection. As a result, all packets that are part of a given connection can be handled by the same node. Some protocols use multiple connections, which are sometimes handled by different nodes, but this usually does not affect the processing of the traffic.

Standby OperationIf standby clustering is used, only one cluster node can be active at any one time. Other node(s) in the cluster are waiting on standby, ready to take over when the currently active node goes offline. Nodes that should not take over automatically can be set offline as usual.

Network InterfacesTo work as replacements for each other, cluster members must have near-identical network interface configurations. In fact, a single physical interface definition in the Management Client always represents one network interface on each node of the cluster. The table below explains the two types of interface configurations you can add to a physical interface definition. You can add several of each type to a single physical interface to define several IP addresses for it.

TABLE 11.1 Firewall Cluster Interface Types

Interface type Description

Cluster Virtual Interface (CVI)

CVIs handle the traffic directed to the Firewall cluster for inspection. A CVI is a logical interface shared by all nodes in a cluster. CVIs give the cluster a single identity on the network, reducing the complexity of routing and network design. Each CVI has a single IP address shared by all nodes in the cluster. How this shared IP address is used depends on the clustering technique selected.

Node Dedicated Interface (NDI)

NDIs handle all communication for which the end-point is the node itself, including node-to-node, Management Server to node, and node-initiated connections. In most cases, you must define one NDI for each physical interface. Multiple NDIs are not commonly needed for the same physical interface, but can be added. Each node in the cluster has its own dedicated IP address for each NDI.


Illustration 11.1 Cluster Interfaces

Illustration 11.1 shows how CVIs and NDIs are used on a Firewall cluster. In this example, the Node Dedicated Interface ID 0 on each node is used for heartbeat traffic in a dedicated network between the cluster nodes. There is no CVI on Interface 0, since it handles only node-to-node traffic. Interface ID 1 is used as the CVI for Internet traffic (for example, Web browsing), and is also an NDI for traffic the nodes send toward the Internet (for example, automatic tests the firewall uses to check connectivity). Interface ID 2 is used as the CVI for protected network traffic and as the NDI for management connections to and from the Firewall nodes.

Clustering ModesThere are several modes for how traffic can be directed to the cluster:• Packet Dispatch• Unicast MAC• Multicast MAC• Multicast MAC with IGMPThe Packet Dispatch mode is the recommended clustering mode, as it requires no additional switch or router configuration. If you need more information on the other clustering modes, see Appendix K, Multicasting. It is also possible to set different cluster modes for different CVIs if they are defined for different physical interfaces.In Packet Dispatch mode, one node per physical interface is selected as a dispatcher that handles the distribution of traffic between the different nodes for all CVIs on that physical interface. When the dispatcher node receives the packets, it assigns them to one of the nodes (including itself), and the assigned node then handles the actual resource-intensive traffic processing. The dispatcher attempts to balance the nodes’


loads evenly, but assigns all packets belonging to the same connection to the same node. The node acting as the packet dispatcher can be (and often is) different for CVIs on different physical interfaces. Illustration 11.2 shows an example of how packet dispatch handles a connection.

Illustration 11.2 Packet Dispatch CVI Mode

The dispatcher node for CVI 1 receives a new connection (1) and then dispatches the connection to one of the other firewall nodes for processing (2). One node is responsible for handling each connection, and the dispatcher node for the CVI 2 forwards the replies within the open connection to the same node (3) based on the information on open connections shared between the nodes. The node responsible for the connection handles all resource-consuming tasks: determines if the connection is allowed to continue, translates addresses as necessary, and logs the connection.The dispatcher node controls the CVI’s IP address and MAC address. The other nodes use their own physical interface’s MAC address for the same CVI. When the dispatcher node goes offline, one of the other nodes becomes the dispatcher node. The new dispatcher node changes its interface’s MAC address to the address defined for the Packet Dispatch CVI.

Note – Because of the limitation of only one unicast MAC address per physical interface, all the NDIs defined on the same physical interface as a Packet Dispatch CVI use the same unicast MAC address as the CVI is using on each node.

1.

3. 2.


The network switch has to update its address table without significant delay when the packet dispatcher MAC address is moved to another firewall node. This is a standard network addressing operation where the switch learns that the MAC address is located behind a different switch port. Then, the switch forwards traffic destined to the CVI address to this new packet dispatcher.

Configuration WorkflowThe following sections provide an overview of the configuration tasks related to configuring and customizing Firewall Clusters. Detailed step-by-step instructions can be found in the online help of the Management Client and the Administrator’s Guide PDF, in the section called Elements.

Task 1: Create a Firewall Cluster ElementTo introduce a new firewall cluster to the Management Center, you must define a Firewall Cluster element that stores the configuration information related to the firewall engines. Alternative to creating a new Firewall Cluster element, you can also promote an existing Single Firewall element to a Firewall Cluster element if you are adding new nodes to an existing single-node firewall.

Task 2: Create Physical InterfacesPhysical interfaces represent the actual network interface cards on the engines. In a cluster, each physical interface definition represents a network interface on all nodes of the cluster.To route traffic through the firewall, you must define at least two different physical interfaces. When you define a CVI for a physical interface, the CVI inherits the MAC address defined at this level. Because of the limitation of only one unicast MAC address per physical interface, all the Packet Dispatch CVIs defined on the same physical interface use the same MAC address. The CVIs on different physical interfaces cannot have duplicate MAC addresses.The network interface numbering in the configuration is independent from the numbering of the physical interfaces. By default, the two numbering schemes are mapped one to one, but you can change the mapping freely using command line tools on the engine. This mapping can be done differently from node to node as long as you take care that the same interface on each node is correctly cabled to the same network.

Task 2: Define VLAN InterfacesA Virtual Local Area Network (VLAN) is a logical grouping of hosts and network devices that allows creating several separated networks on a single physical link. To allow this separation, StoneGate supports VLAN tagging as defined in the IEEE 802.1q standard. One network interface can support up to 4094 VLANs.If you want to define VLAN interfaces on the engine’s network interfaces, add the VLAN interfaces for the physical interfaces before moving on with any detailed configuration.


When you create a VLAN interface, the CVI mode and MAC address are defined commonly for all virtual interfaces configured for the same Physical interface definition. The defined VLAN interfaces are displayed, for example, as “5.202” for network interface 5 with VLAN 202. You must also configure the router at the other end of the link with matching VLAN settings.

Task 3: Configure InterfacesYou can define two types of interfaces: CVIs and NDIs. Both CVIs and NDIs are basically IP address definitions, but the two different types are required due to the special requirements of clustering. You can define as many CVIs and NDIs per physical interface as you need.• CVIs are used for traffic directed to the Firewall Cluster for inspection and have one

IP address shared by all nodes. They allow the surrounding network to see the cluster as a single entity.

• NDIs handle all traffic for which the end-point of the communication is a node itself and have a dedicated IP address for each node. They allow the communications to reach a particular node.

You must specify an IP address and MAC address for each CVI. The MAC/IP address pair of the CVI remains the same all the time as only the location of the MAC address changes to the current dispatcher node (packet dispatch). This makes the external network equipment forward traffic to the correct node for dispatching. The NDIs are used for node-to-node communications as well as for traffic between each individual node and the Management Server and Log Server, as well as communications with external components (such as authentication servers, or hosts that are probed in automatic network connectivity tests).When you define NDIs, you must define both node-specific properties (such as the node’s IP address) and properties that are shared by all the nodes in the cluster. All nodes must have the same netmask value for the IP address of their respective NDIs. The node-specific IP addresses are used whenever the nodes need to be contacted individually. For example, the Management Server communicates with the nodes using these addresses on the defined control interfaces.To ensure correct operation in all cases, we recommend you define an NDI IP address for all nodes on each physical interface. If there is a shortage of IP addresses, it is possible to leave some physical interface without an NDI. If a physical interface does not have an NDI IP address for a node, the node uses an IP address from one of the other NDIs (the one designated for this purpose) when initiating communications through that interface. Gratuitous ARP requests used for updating the MAC address/IP address relationship in the Packet Dispatch mode may be affected by this configuration. The ‘borrowed’ IP address can be used without issues with routers that strictly follow the ARP standard as long as the IP address used is valid from the routing point of view. However, some routers may not reply the firewall’s gratuitous ARP requests in this case, and static ARP entries may be required in the firewall’s configuration to allow communications.


Task 4: Install the Firewall EnginesEngines in a clustered configuration are installed in the same way as engines of a single firewall. The engines do not receive any clustering settings until the first time you install a policy on them and the working configuration is received from the Management Server.During the engine installation, you map the physical interfaces to the physical interface definitions created in the Management Client. You can also install the engine automatically using a configuration saved on a USB memory stick. If you use the automatic engine configuration, Management Client physical interface definitions are automatically mapped to the actual physical interfaces in sequential order. For example, interface 0 is mapped to eth0, interface 1 is mapped to eth1, and so on. In this case, the first physical interface (eth0) is always used as the Management interface. For this reason, interface 0 must be defined as the Management interface in the Management Client when the automatic configuration is used.During the installation, a basic initial configuration is activated and an initial contact between the Management Server and each engine is initiated. During the initial contact, each engine authenticates itself to the Management Server with its own single-use password. When this initial contact succeeds, the engine receives a certificate from the Management Center for authenticating all subsequent communications—a trust relationship between that engine and the Management Server is established.

Task 5: Install a Firewall PolicyAfter the firewall engines have made initial contact with the Management Server, only the primary control interface with the Management Server is configured. You must install a Firewall Policy using the Management Client to transfer the complete interface configuration to the firewall.All nodes must have the same version of the operating configuration. For this reason, a policy installation requires that all cluster nodes defined in the Management Client are installed and reachable. Nodes that are temporarily unreachable (under maintenance) can be disabled from the configuration to install a policy on the rest of the firewall engines.

Using a Firewall ClusterThe main points of Firewall Cluster configuration are explained in the preceding sections of this chapter, but this section illustrates some concepts further and explains some additional optional features:• Using Multi-Link, on page 130• Using VLANs, on page 131• Running Automatic Tests, on page 132• Sending SNMP Traps, on page 133• Advanced Configuration of Clustering, on page 134


Using Multi-LinkMulti-Link technology uses multiple network connections to provide both high availability and load balancing between multiple network links (NetLinks). Multi-Link is available as standard on all installations and it is not dependent on clustering. For more information and details about Multi-Link, see Multi-Link Configuration, on page 263.Illustration 11.3 shows how Multi-Link works with the CVIs of a Firewall Cluster.

Illustration 11.3 Cluster Interfaces for Multi-Link

In this example, interface 1 is used as the CVI for Internet traffic that is routed through Internet service provider (ISP) A. Interface 2 is used as the CVI for Internet traffic that is routed through ISP B. Both nodes have one physical interface for each CVI, so that both nodes are physically connected to both routers leading to the Internet.It is also possible to configure Multi-Link by connecting two CVIs to a single router, which in turn connects to both ISPs. However, this configuration is not recommended, as it creates a single point of failure.


Using VLANs

Illustration 11.4 Using VLANs

Illustration 11.4 presents the use of VLANs. The firewall nodes have three CVIs with five connected networks. In this case, Interface 1 is configured with two VLAN interfaces: interface 1.100 and 1.101 for the VLANs 100 and 101, and Interface 2 with the VLAN interfaces 2.200 and 2.300 for the VLANs 200 and 300, respectively.VLANs can separate traffic based on function, but additionally, they make it easier to deploy geographically distributed Firewall clusters, as fewer physical interfaces and less cabling is needed.


Illustration 11.5 VLANs with a Geographically Distributed Cluster

Illustration 11.5 shows a geographically distributed cluster, where Node A is located in one building while Node B is located in another one. In addition to the heartbeat, both nodes have an interface towards VLAN 1 and another interface towards VLAN 2 and VLAN 3. Both nodes are connected to the VLANs through a switch. The VLAN capable switches share a trunk link, which is duplicated in this example.

Running Automatic TestsThe firewalls have a test system, which runs on the engines. You can configure the firewall to run different tests depending on its current operating state and take action depending on the success or failure of the test. The action can include sending an alert or an SNMP trap, or changing the operating state of the firewall. Each test can be run either on the whole cluster or one or more individual nodes and on one or more interfaces. The available types of tests are listed in the table below.

TABLE 11.2 Pre-defined Tests

Test Explanation

External

Runs a custom script you create and store on the engine. You can freely decide the content of the script, but the script must return an exit code of 0 (zero) if it succeeds. Any non-zero return value is considered a failure.

VLAN 1Trunk links

1 and 2

Trunk links 3 and 4

Node A Node B

VLAN 2VLAN 3

To the Router To the Router

NIC 0 NIC 0

NIC 1 NIC 1

Interface 1.2

Interface 0.1 Interface 0.1

Interface 1.2

NIC 2 NIC 2

Trunk link

VLAN 1

VLAN 2

Heartbeat link

VLAN 3Interface 1.3 Interface 1.3


All entries that you have configured with the tester are displayed in the Test Entries table. The selected states and actions are indicated on that table with letters as summarized in table below.

Sending SNMP TrapsThe firewall can send SNMP traps on events such as test failures and changes in its operating state. The SNMP Agent element is a reusable container for the settings

File System SpaceChecks whether the available free hard disk space on the specified partition is above the specified minimum amount (in kilobytes).

Firewall PolicyChecks if a new policy is activated on the engine. It is mainly intended for sending SNMP notifications.

Free Swap SpaceChecks whether the free hard disk swap space is above the specified minimum value (in kilobytes).

Interface Up Checks whether a network port is enabled or disabled.

Link Status Tests whether a network port reports the link as up or down.

MultipingSends out a series of ping requests to determine whether there is connectivity through a network link.

TABLE 11.3 Test Entry Display of Selected Actions and States


States to test

N Online

O Offline

S Standby

Action on failure

A Alert

O+A Offline + Alert

FO+A Force Offline + Alert

A+S Alert + SNMP

O+A+S Offline + Alert + SNMP

FO+A+S Force Offline + Alert + SNMP

TABLE 11.2 Pre-defined Tests (Continued)

Test Explanation


according to which the firewalls send SNMP trap messages to compatible external software. A single SNMP Agent can be created once and used on multiple firewalls by selecting the correct SNMP Agent in the firewall properties.StoneGate’s SNMP agent supports SNMPv1 (RFC1157), SNMPv2c (RFCs 1901 and 3416), and SNMPv3 (RFC 3414).

Advanced Configuration of ClusteringThis section illustrates the following advanced concepts for working with Firewall Clusters:• Tuning Node Synchronization, on page 134.• Security Level for State Synchronization, on page 135.• About Manual Load Balancing, on page 136

Caution – Do not modify the firewall’s Advanced Settings without due consideration. An invalid configuration of the parameters may lead to system instability or malfunction.

Tuning Node SynchronizationState synchronization is essential for the following features:• Dynamic load balancing.• Transparent switchover of nodes in case of failure or maintenance.• Handling of related connections when a service (e.g., FTP) opens multiple

connections.Both on-demand and timed synchronization are supported, but only timed synchronization is configurable.

Regular, timer-launched synchronization events are needed to synchronize state data and to avoid cutting connections in case of node failure. Timed synchronization messages are initiated by a configurable timer. For performance reasons, timed synchronization events are divided into full and incremental sync messages (see Table 11.4 for details).

TABLE 11.4 Sync Messages

Type Explanation

Full Sync MessagesContain all connection data about the traffic handled by a node at the time when the message was sent. When new data is received, it replaces the existing data.


By default, a combination of full and incremental sync messages is exchanged between nodes. This way, frequent updates on incremental changes and recurrent reports on existing connections are combined. It is also possible to send full sync messages only, but in this case, only information on existing connections is exchanged and none on intermediary changes.You can modify the default values set for both full sync interval and incremental sync interval. Note, however, that setting the interval values requires careful consideration.• Full sync interval is longer than the incremental one, typically some seconds (5000

ms by default).• Incremental sync interval is generally some tens of milliseconds (50 ms by default).The shorter the full sync interval is, the more burdened the heartbeat network and nodes are with node communications. Longer sync intervals do not require as many resources, but the shared connection data becomes less accurate. The combination of full and incremental sync gives best results with the appropriate tuning of sync intervals.

Security Level for State SynchronizationBecause synchronization controls the inter-node traffic within a heartbeat network, you must ensure the security of the heartbeat and synchronization data. Without authentication and encryption, it is possible to both sniff synchronization data and send fraudulent messages to open connections. Three different levels of security are available for primary and backup control interfaces:• None: no authentication or encryption is performed on synchronization traffic. At

this level, the heartbeat network must be absolutely secure and isolated from other networks. This setting may improve performance slightly over the default setting.

• Sign: all synchronization messages are signed with a digital signature and confidential messages are encrypted. This level of security prevents forging of synchronization traffic. It is the default security level.

• Encrypt and sign: all messages are both signed and encrypted (except specific Inform sync and Reference count sync messages which are never signed or encrypted). This level of security engages resources of the Firewall to process encryption/decryption operations against sniffing attempts.

Incremental Sync Messages

Contain only data on connections that were created or changed since the last full or incremental sync message. Incremental sync needs less bandwidth and processing time. Since the incremental changes are sent only once, the system may lose connections if the data is lost. While able to produce accurate data with frequent updates, incremental sync requires full sync to provide reliable synchronization data.

TABLE 11.4 Sync Messages (Continued)

Type Explanation


Note – Independent of the security level, all critical information such as passwords and encryption keys are protected. Even when None is used, they are never sent in plaintext.

About Manual Load BalancingModifying the load balancing parameters of the Firewall cluster is not recommended unless you fully understand the load balancing function and there is a specific need for modifications. Any user-defined load balancing parameters are combined with the automatically created filtering entries. Without careful consideration, this can cause conflicts in filtering decisions. For more information on the settings available, see the Administrator's Guide PDF or the Online Help of the Management Client.


Examples of Firewall Cluster DeploymentThe examples in this section illustrate the configuration of a cluster in StoneGate with general steps on how each scenario is configured.

Setting up a Firewall ClusterThe administrators at the headquarters of Company A want to set up a Firewall Cluster. The cluster consists of two cluster nodes: Node1 and Node2. The HQ Cluster Firewall has a dedicated heartbeat network, is connected to two internal networks, and uses Multi-Link to ISP A and ISP B for its connection to the Internet.Illustration 11.6 shows Company A’s headquarters network.

Illustration 11.6 Headquarters Network

The administrators:1. Create a Firewall Cluster element (HQ Cluster) and define HQ Log as its Log

Server.2. Define the physical interfaces 0-4.3. Define the CVIs and NDIs for the physical interfaces. Except for the IP

addresses, the node-specific properties for Node1 and Node2 are the same. See Table 11.5.


4. Save the initial configuration of the engines in the Management Client.5. Map the interface identifiers in the configuration to the physical interfaces on

each engine’s command line and establish contact between each engine and the Management Server.

6. Install a Firewall Policy on the Firewall Cluster in the Management Client to transfer the working configuration to the firewall engines. The nodes exchange authentication information and begin to work as a cluster.

TABLE 11.5 Cluster Interfaces

Interface Type IP Address Comment

0 NDI for Node1 10.42.1.1 Heartbeat

0 NDI for Node2 10.42.1.2 Heartbeat

1 CVI 129.40.1.254 ISP B

1 NDI for Node1 129.40.1.21 ISP B

1 NDI for Node2 129.40.1.22 ISP B

2 CVI 212.20.1.254 ISP A

2 NDI for Node1 212.20.1.21 ISP A

2 NDI for Node2 212.20.1.22 ISP A

3 CVI 192.168.10.1 Management Network

3 NDI for Node1 192.168.10.21 Management Network

3 NDI for Node2 192.168.10.22 Management Network

4 CVI 172.16.1.1 Intranet

4 NDI for Node1 172.16.1.21 Intranet

4 NDI for Node2 172.16.1.22 Intranet


Adding a Node to a Firewall ClusterCompany A’s Firewall currently consists of two nodes. However, the load on the Firewall is exceptionally high, so the administrator has decided to add another node to ensure continuity of network services even when one of the nodes is offline. The administrator does the following:1. Adds a new node in the Firewall Cluster element’s properties.2. Defines the node-specific IP addresses for the NDI interfaces of the new node.

• The cluster-level interface configuration does not need adjustments, since it is shared by all nodes.

3. Installs the new engine and performs the initial configuration.4. Refreshes the security policy of the Firewall Cluster.



CHAPTER 12 Routing and Antispoofing

Routing is the process of defining through which network interface StoneGate forwards traffic from a source address to a destination address. Antispoofing is the process of defining which addresses are considered valid source addresses for the network(s) connected to each interface.


Overview to Routing and Antispoofing, on page 142 Configuration of Routing and Antispoofing, on page 142 Using Routing and Antispoofing, on page 147 Examples of Routing, on page 148

141

Overview to Routing and AntispoofingIn addition to examining packets, a firewall has to determine how to route packets so that they can get from their source to their destination.For the most part, StoneGate automates routing and antispoofing configuration. Much of the configuration is generated automatically based on the IP addresses that you enter for network interfaces.IP address spoofing is an attack where the source IP address in a packet is modified to gain unauthorized access or to cause a denial-of-service (DoS). Such attacks can be prevented with antispoofing rules. StoneGate automatically configures antispoofing rules to match your routing configuration and always enforces antispoofing on all interfaces.

Configuration of Routing and AntispoofingThe routing configuration is different on SOHO firewalls and the standard single or clustered firewalls. Consult the correct sections below depending on the types of firewalls in your system.

Routing on Single and Clustered FirewallsThe Routing and Antispoofing information is displayed and configured graphically in interface-based trees in the Routing view and Antispoofing view. When you create a Firewall element and define the interfaces and the IP addresses for each interface, the Routing view automatically displays each Interface and a Network element for each network that is directly connected to the firewall. The Network is created based on the IP address(es) you define for each interface. Any networks that are not directly connected to the firewall must be manually added to the routing tree along with the next-hop router(s) that can route the traffic onwards to those Networks. Similarly, you must also add a default route for packets whose destination IP address is not included anywhere else in the routing tree.The antispoofing configuration is generated automatically based on the routing tree, and antispoofing is always enforced on all interfaces. You can change the antispoofing configuration, but in most environments, there is no need to do so. Changes are only necessary to allow some IP address from a second interface in addition to the definition automatically generated based on routing.New Networks are automatically added to routing when you change the firewall’s interface properties. However, none of the Networks are automatically removed, so you must check your Routing view for obsolete entries and clear them manually. This is to prevent the system from removing currently unused route definitions that you may want to reuse or keep for easy rollback to previous definitions. All additions and deletions in the routing view are automatically reflected in antispoofing view. Manual definitions in the Antispoofing view are preserved regardless of routing changes.The routing information is stored on the Management Server. The information is transferred to the firewalls when the firewall policies are installed or refreshed.

142 Chapter 12: Routing and Antispoofing

Routing on SOHO FirewallsThe routing information of SOHO Firewalls is automatically generated based on the interfaces defined for the SOHO Firewall elements. To change the routing information, you must edit the interface definitions in the SOHO Firewall properties. None of the configuration options explained in other sections of this chapter are available for SOHO Firewalls. SOHO Firewalls do not support antispoofing.The routing on SOHO Firewalls is based on a classification of interfaces as Internal, External, and Guest interfaces. To configure the interfaces of a SOHO Firewall, you must define an External interface that allows connections to the Internet and at least one Corporate interface that allows connections to the corporate network. You can also define one or more Guest interfaces for visitors who need access to the Internet. Note that Multi-Link routing is not supported on SOHO Firewalls, so you can only have one external interface at a time on a SOHO Firewall.You can view the graphical routing tree of SOHO Firewalls just like on any other firewall, but the routing information is always automatically added and removed based on the interface definitions and it is not possible to manually edit the Routing view of SOHO firewalls.

Reading the Routing and Antispoofing TreesThe routing of both Firewall and SOHO Firewall elements is displayed in the Routing view. However, the routing for SOHO firewalls is always generated completely automatically based on the interface definitions. None of the configuration options explained in this chapter are available for SOHO firewalls.The routing and antispoofing views are graphical representations of the firewall’s routing table and antispoofing rules. When the firewall reads these definitions, it picks the most specific definition it finds. For each packet, the firewall selects the most specific route and antispoofing definition it finds.In routing, the firewall first checks if there is a route defined for the specific destination IP address of the packet (a Host element), then checks routes to the defined networks (a Network element), and finally uses the default route (the Any Network element) if none of the other routes match the packet’s destination address. If there are overlapping definitions, the more specific one is considered first. For example, if interface 1 has a Host element for 192.168.0.202 and Interface 2 has a Network element for 192.168.0.0/24, a packet to 192.168.0.202 is routed through Interface 1, and the Interface 2 definition is not considered for those packets at all.


Illustration 12.1 Example: The More Specific Destination is Considered First in Routing

In Antispoofing, the most specific route is considered first, just like in Routing. For example, in an Antispoofing tree automatically generated based on the routing example above, antispoofing will discard any traffic with the address 192.168.0.202 if it originates from Interface 2, because it has the less specific definition for that address (the Network 192.168.0.0/24).

Illustration 12.2 Only The Most Specific Destination is Considered Valid in Antispoofing

To allow the traffic to originate from both interfaces, you would also have to add the Host element for 192.168.0.202 under the second interface, so that the definitions are equally specific (both interfaces contain a Host element) and therefore both definitions are valid at the same time.

Illustration 12.3 Both Interfaces are Considered Valid

Interface 1 is always used for a destination of 192.168.0.202 because it has a Host element with the most specific address under it.

Packets from Example Host (192.168.0.202) are only considered valid if they originate from Interface 1, because it has the most specific route to the host’s address.

Both are Interface1 and Interface2 considered valid routes to Example Host (192.168.0.202) because the Host element is included under both interfaces.


Multi-Link Routing for Single and Clustered FirewallsStoneGate’s patented Multi-Link technology uses multiple network links (NetLinks) to balance the load of outbound traffic and ensure high availability of Internet connectivity. With each new outbound connection, StoneGate selects the fastest route for the connection from the available NetLinks. You can use Multi-Link with both single firewalls and firewall clusters. You cannot use Multi-Link to route VPN traffic between a single or clustered Firewall and a SOHO Firewall. For more information about Multi-Link for outbound connections, see Multi-Link Configuration, on page 263.A NetLink element is associated with a gateway (router or firewall) element and the corresponding network address space.

Illustration 12.4 NetLinks in Routing View

In Illustration 12.4, a Multi-Link configuration is used to define a default route to the Internet (to “Any network”) through the ISP A and ISP B NetLinks. Separate network interfaces on the Firewall element can be used for each NetLink, which is recommended for the Multi-Link configuration. It is also possible to configure multiple NetLinks for a single network interface. However, this is not recommended, as configuring multiple networks on the same interface introduces a single point of failure.For each NetLink, a range of IP addresses is defined for source IP NAT. These addresses are used for NATing the source IP address of an outbound connection that goes through the NetLink. A NAT rule in the firewall policy defines the Outbound Multi-Link element that is used for Multi-Link outbound connections.

Default ElementsNetworks that correspond to the IP addresses of each interface are automatically added to the routing configuration and also to the antispoofing rules of Firewall elements.


The system includes a default network element called Any network, which is needed to define the default route. The system also includes a Host element for Bootp/DHCP clients in the Antispoofing view for Firewall elements.

Configuration WorkflowThe following sections provide an overview of the configuration tasks related to the routing and antispoofing of Firewall elements in StoneGate. The routing of SOHO Firewall elements is automatically generated based on the interface definitions. You cannot configure antispoofing for SOHO Firewalls.Detailed step-by-step instructions for configuring the elements and policies can be found in the online help of the Management Client and the Administrator’s Guide PDF, in the section called Routing.

Task 1: Add Router or NetLinkA Router or a NetLink element represents a next-hop gateway that forwards packets to network(s) that are not directly connected to the Firewall element(s). If a single interface is enough for routing traffic to a network, you can use a single Router. If you want to route traffic to a network through two or more interfaces, you must use NetLinks. See Multi-Link Configuration, on page 263 for more information about NetLinks and Multi-Link.

Task 2: Add Network(s)A Network element represents the IP addresses (a network or a subnetwork) to which the Router or the NetLink forwards the traffic.Routes to directly connected networks are automatically defined. You must manually define routes to networks that are not directly connected.

Task 3: Modify Antispoofing RulesStoneGate automatically determines antispoofing rules for the Firewall elements shown in the Routing view, so there is usually no need to change the antispoofing rules. However, if you define policy routing to route packets from specific IP addresses through a specific gateway, you may have to modify the antispoofing rules manually. See Policy Routing, on page 147 for more information.The Antispoofing view defines the source addresses of traffic that are considered valid (not spoofed) for each interface of a Firewall element. If an interface receives a packet with a source address that is not a valid address for the network(s) connected to that interface, the packet is discarded. This is the case, for example, when an external interface receives a packet with an internal source.You can manually add, disable, or modify the entries in the Antispoofing view. The manually modified entries are denoted with a special icon to make them stand out from the system-generated entries.


Task 4: Refresh Firewall PolicyChanges to the routing or antispoofing configuration are only transferred to the firewall engine when you refresh the firewall policy. The Management Server automatically includes all the necessary configuration information (including routing).

Using Routing and AntispoofingIn addition to simple routing or Multi-Link routing, you can use policy routing and static IP Multicast routing with Firewall elements. With StoneGate’s Quality of Service (QoS) features you can also manage the bandwidth and priorities allocated to different types of traffic (see Bandwidth Management and Traffic Prioritization, on page 281). However, none of these features are available on SOHO Firewalls.

Policy RoutingWith policy routing you can route traffic through a selected gateway. These policy routing entries override other routing configuration defined in the Routing view.A policy routing entry includes a source IP address, a destination IP address, netmasks for the source and destination addresses and the IP address of the selected gateway.Antispoofing configuration may need to be changed accordingly when using manual policy routing entries.

Static IP Multicast RoutingIP multicasting is the transmission of an IP datagram to all hosts in a multicast host group, which is identified by a single destination IP address. This way the data needs only to be sent once to the multicast IP address, instead of sending it to all the hosts individually. See Appendix K, Multicasting for more information on multicasting.StoneGate implements static IP multicast routing, making it possible to relay multicast traffic through a Firewall element in a controlled way. Because the multicast configuration is static (it does not rely on IGMP messaging), it has to be explicitly defined by an administrator. Because of the static nature of the configuration, static IP multicast routing is suitable for enduring configurations, such as mutually agreed multicast traffic between organizations. Multicast traffic is handled in the Firewall element as any other traffic according to the configured firewall policy.

Modifying AntispoofingIn rare cases you may need to modify the default antispoofing definitions to make exceptions to the antispoofing rules (for example, if you have defined policy routing manually). You can also disable Antispoofing for an interface, if necessary.The firewall interprets the antispoofing tree by picking the most specific entry defined in the view. If some IP address must be allowed access through two or more different

Using Routing and Antispoofing 147

interfaces, the definition for each interface must be at the same level of detail for the IP address in question.For example, if Interface A contains a Host element for 192.168.10.101 and Interface B contains a Network element for 192.168.10.0/24, connections from 192.168.10.101 are considered spoofed if they enter through Interface B. If this is not desired, the Host element must also be added under Interface B (in addition to the Network element already included).

Examples of RoutingThe examples in this section illustrate some common uses for routing Firewall elements in StoneGate and general steps on how each scenario is configured. The routing of SOHO Firewalls is automatically generated based on the interface definitions (see SOHO Firewall Configuration, on page 103).

Routing Traffic with Two InterfacesCompany A needs to route traffic to the Internet as well as to the internal Network B, which is not directly connected to the company’s Branch Office Firewall. The company’s administrators decide to create a separate route to the internal Network B and a default route for traffic to the Internet. The administrators:1. Open the Routing view for the Branch Office Firewall.2. Add a Router and Network B under Interface 0.3. Add a Router and the default element “Any network” under Interface 1.4. Refresh the firewall policy on the Branch Office Firewall.

Routing Internet Traffic with Multi-LinkCompany B wants to ensure high availability of Internet connections through the company’s firewall. The company’s administrators decide to use Multi-Link routing with two NetLinks to balance Internet connections. They:1. Create two NetLinks.2. Combine the NetLinks into an Outbound Multi-Link element to balance the

connections.3. Add one of the NetLinks under Interface 1 and the other NetLink under Interface

2 in the Routing view.4. Add the default route “Any network” under the NetLinks.5. Add a NAT rule to the firewall policy to balance the connections between the

NetLinks.6. Refresh the firewall policy.


Routing Traffic to Networks That Use Same Address SpaceCompany C’s network is connected to two partners: Network A and Network B. The Network A and the Network B partners use the same address space in their internal networks.

Illustration 12.5 Policy Routing in Company C

There are two hosts in Company C’s network. Host 1 works only with the Network A partner and Host 2 only with the Network B partner. The administrators at Company C decide to use policy routing to route the traffic between Company C’s network and the two partner sites. The administrators:1. Create policy routing entries for Host 1 and Host 2 on the Firewall HQ Cluster as

shown in Illustration 12.6.

Illustration 12.6 Policy Routing Entries for Host 1 and Host 2

2. Modify the antispoofing rules so that they take into account the routing defined with the policy routing entries.

3. Refresh the firewall policy on the Firewall HQ Cluster.

Examples of Routing 149


Access Control Policies

CHAPTER 13 Firewall Policies

Firewall policy elements are containers for the lists of rules that determine how the firewall examines traffic. The policy elements include Template Policies, Policies, and Sub-Policies.


Overview to Firewall Policies, on page 154 Configuration of Policy Elements, on page 156 Using Policy Elements, on page 162 Examples of Policy Element Use, on page 163

153

Overview to Firewall PoliciesThe policy elements store rules according to which the firewall examines the traffic. This chapter introduces you to how these elements are used by the firewall and explains how to build a purposeful and efficient policy hierarchy using the different policy elements. The basics of building the actual traffic handling rules that are contained in the policy elements are discussed in separate chapters (see Access Rules, on page 165, Inspection Rules, on page 183, and Network Address Translation (NAT) Rules, on page 193).SOHO Firewalls do not have firewall policies. They allow traffic based on their interface definitions. If you use SOHO Firewalls, you must modify your firewall policies to permit, for example, the communications between the SOHO Firewalls and the StoneGate components. See SOHO Firewall Configuration, on page 103 for more information.

Policy HierarchyThe policy structure in StoneGate is a hierarchical structure based on templates, which allows you to:• Reuse rules without duplicating them.• Assign and enforce editing rights of different parts of a single policy to different

administrators.• Reduce the resource consumption of the firewall.• Make policies easier to read.The template and policy hierarchy is flattened when the Firewall Policy is transferred to the firewall, so the policy will look the same to the firewall regardless of how it is organized on the Management Server (as long as the rules themselves are in the same order). You can also create sections of conditional rules that you can insert into the other policy elements. The firewall may skip the processing of a conditional block of rules based on whether or not certain common matching criteria is found in the packet being examined.If your environment is very simple and you do not see a need for the benefits outlined above, you have the option of creating a very simple policy hierarchy, starting from a single Firewall Policy built on the Default template provided (a single policy may be used even if you have more than one firewall).

How StoneGate Examines the PacketsThe StoneGate firewall passes through only traffic that is specifically allowed in the firewall’s policy. All other traffic is discarded. All connections are handled in exactly the same way in this respect, even connections that the firewall itself opens.If the firewall is a cluster, the load balancing filter first determines which engine in the cluster will actually process a packet. Then the processing of the packet begins on the selected node.The firewall matches a new connection to the rules in the firewall’s policy rule by rule. The header on each packet arriving on an interface is examined for the source and

154 Chapter 13: Firewall Policies

destination IP address, and protocol-related information, such as the port. Also the authentication status of the user attempting a connection and the current date and time may be included as parameters in the examination process.The packet handling process is shown in Illustration 13.1.

Illustration 13.1 Connection/Packet Handling in a StoneGate Firewall

The illustration above shows how the policies are used:

1.

2.

3.

4.

5.

6.

7.

Overview to Firewall Policies 155

1. The firewall checks that the traffic is coming in through the correct interface as defined in the Routing and Antispoofing trees.

2. The firewall checks the current connection tracking information to see if the packet is part of an established connection (for example, a reply packet to a request that has been allowed).

3. If the packet is not part of an existing connection, the packet is compared with the Access rules in the installed Firewall Policy. The processing continues until the packet matches a rule that tells the firewall to allow or stop the packet.• If there is no rule match anywhere else in the policy, the packet is discarded

when the firewall reaches the end of the Firewall Policy.4. If the packet is allowed as an existing connection or in an Access rule, the

firewall checks that the packet is valid for the state of the connection. If not, the packet is dropped.• For example, a TCP connection must always begin with a SYN packet (as

defined in the protocol standards), so the firewall checks that the first packet of a new connection is a valid SYN packet.

5. The firewall applies inspection rules to HTTP and SIP connections that are selected for deep packet inspection in the Access rules.• Inspection applies to all packets in a connection, so the Inspection rules are

applied even if the packet is a part of an existing connection.• The inspection rules are used to look for harmful patterns hiding in the

legitimate-looking connections (i.e., payload of packets that are a part of allowed connections).

6. Network Address Translation (NAT) rules are applied. The source and destination addresses are translated according to the first matching NAT rule (or not done at all, if a NAT rule so defines). If none of the NAT rules match, the packet continues with the original addresses.

7. A routing decision is made (using the translated address), and the packet is let through the firewall according to its priority and any bandwidth limits or guarantees that may be in place.

Configuration of Policy ElementsThe firewall policy elements are stored in the Firewall Configuration→Firewall Policies branch of the All Elements tree. There are three kinds of firewall policies:• Firewall Template Policies are policies that are used as a basis for firewall Policies

or other Template Policies. The Template Policies may contain any number of rules, which are then copied into lower-level policy elements. Such inherited rules have equal weight as any rule added directly into the lower-level policy elements, but the inherited rules cannot be edited from within the lower-level policy.

• Firewall Policies are always based on a Template Policy. The Firewall Policies are the only policy elements that can be installed on firewalls.

• Firewall Sub-Policies are simply sections of rules that you can insert into Firewall Policies and Template Policies. They can be thought of as conditional rules,


because you can define matching criteria that determines whether the Sub-Policy applies to a connection or not. Like rules inherited from templates, rules inserted from Sub-Policies are not editable in the policy element that uses them.

The hierarchy of how rules are inherited between different policy elements is shown in Illustration 13.2.

Illustration 13.2 Rule Inheritance

In the illustration, Template Policy A is the basis for Template B, so Template B contains all rules defined in Template A. Template B adds new rules, as well as rules from a Sub-Policy. Our example Firewall Policy inherits all rules from Template B, so the Firewall Policy includes all the rules from Template A, Template B, and the Sub-Policy, as well as any rules the administrators add to the Firewall Policy directly. The only rules that can be edited from within the Firewall Policy are the rules that are added to it directly. All other rules must be changed in the Template Policy or Sub-Policy where they were originally defined.A hierarchy such as the one outlined above is useful to• Reduce the need for creating the same or similar rule in several policies. For

example, any rule added to Template Policy A is also added to any policy created based on that template. The next time inheriting Firewall Policies are installed on firewalls, the new rule is used on all those firewalls without anyone directly modifying each individual Firewall Policy.

• Restrict the editing rights of administrators. For example, administrators who are granted rights to only the inheriting Firewall Policy cannot edit the rules defined in the higher-level templates. Their actions have no effect on rules that are placed above the row where the upper-level template allows them to insert new rules. In the hierarchy shown in the illustration above, the insert point(s) for the Firewall Policy are defined in Template B, which in turn can be edited only in the place where there is an insert point in Template A.

• Reduce the likelihood of mistakes affecting important communications. Templates can be reserved for defining only the rules for essential communications, so that most daily editing is done in the lower-level Firewall Policy. If the template is properly designed, the rules in the template cannot be overridden by any rules in


the lower-level policy, even if such rules are accidentally added. Good organization also makes policies easier to read, further reducing the risk of errors.

• Improve processing performance. With the help of sub-policies, whole blocks of rules may be skipped during processing when a connection does not match the rule that directs the traffic processing to the Sub-Policy. This reduces the processor load, which may lead to higher or faster throughput if the processor load is constantly very high.

Default ElementsThe system has several ready-made policies. The most important one is the Default Template Policy, which includes Access rules that allow traffic between the StoneGate components, such as connections from the Management Server to the firewalls. (These default rules are explained in Configuration of Access Rules, on page 167.)As with all system elements, none of the default policies can be modified. However, you can make copies of the default policies if you need to create a modified version.The following policy elements are available by default:• The Default Template Policy is always in the system and contains the pre-defined

Access rules necessary for the firewall to communicate with the Management Center. All other Template Policies or Policies must be based on the Default template or a customized copy of it.

• The Default Inspection Rules Template Policy contains the pre-defined Inspection rules. It is introduced into the system when you import and activate a recent dynamic update package (for example, during the installation).

• The DHCP Relay Sub-Policy contains rules that allow the firewall to relay DHCP requests from a host in one internal network to a DHCP server in a different network, as well as DHCP requests from VPN Clients to an internal DHCP server.

Configuration WorkflowThe following sections provide an overview of the configuration tasks related to configuring and customizing Firewall Policies. Detailed step-by-step instructions for configuring the elements and policies can be found in the online help of the Management Client and the Administrator’s Guide PDF in the section called Policies.

Task 1: Create a Template PolicyFirewall Template Policies are used as a basis for other Firewall Policies and Template Policies. Every Firewall Policy and Template Policy is based on a template. You can also base several policies on the same template. At the highest level of the policy hierarchy, there is always either the Default template or a customized copy you have created from it. It is not mandatory to create any custom templates if you feel that it is not necessary in your environment.When editing the policies, the main difference between Template Policies and Firewall Policies are the special rows called Insert Points. Insert points are shown in both Template Policies and Firewall Policies, but you can add them only to Template


Policies. The Insert Points added to templates mark the place where new rules can be added in the lower-level Template Policies and Firewall Policies. When creating a Template Policy, you must add an insert point separately for the Access Rules, Inspection Rules, and NAT rules.

Illustration 13.3 Insert Point in a Template and the Inheriting (Template) Policy

Illustration 13.3 shows what the same insert point looks like in a Template Policy and in the inheriting policy elements. The color of the insert point indicates whether the insert point has been added in the current Template Policy for inheritance to lower levels (orange) or whether it has been inherited from the higher-level template (green). Only the orange insert points are inherited to lower-level policy elements, so you must add at least one new insert point at each template level to make the lower-level policies editable. When you add the first new rule to the green insert point, the rule replaces the insert point. Any number of rules can then be added directly above and below that first rule.Rules defined in the Template Policy itself are not editable in lower-level policies that use the template. Such inherited rules are shown only on your request and they have a grey background. Note that only the actual rules are inherited from a higher-level template into the lower-level policies and templates; editing rights must be defined individually for each policy element if you use such controls.Together with the editing restrictions, insert points help ensure that important rules are not made void by configuration mistakes or modified by administrators who are not authorized to do so. Because the firewall reads rules in order from top down, any rules above the insert point in the higher-level template cannot be cancelled by anything a lower-level policy adds into the insert point.

Task 2: Create a PolicyThe Firewall Policy is the only policy element that you can transfer to a firewall, so the Firewall Policy is the element that gathers together all the rules from the different policy elements. The Firewall Policy is always based on a Template Policy, either the Default template or a Template Policy you have created.

Task 3: Create a Sub-PolicyFirewall Sub-Policies are sections of Access rules that you can insert into firewall Policies, Template Policies, and even other Sub-Policies to make the firewall process


traffic faster, and to organize the rules. The Sub-Policies are not based on any template. NAT rules and Inspection rules cannot be inserted into Sub-Policies.The Sub-Policies may make reading the policies and assigning administrator editing rights easier. You can give some administrators the rights to edit only certain Sub-Policies without giving editing rights to the Firewall Policy.A Sub-Policy is inserted into some other policy element by adding a Jump rule. The Jump rule directs connections that match the Jump rule for matching against the rules in the Sub-Policy.

Illustration 13.4 A Sub-Policy in Use

The illustration above shows the same Jump rule in a policy in the collapsed and the expanded state. The rules of the Sub-Policy are shown on a grey background, because they can be edited only within the Sub-Policy itself, not in the Firewall Policy that uses the rules.You can also create a Sub-Policy automatically in a policy by selecting the rules for the Sub-Policy and then an action for creating the Sub-Policy. In that case, the system automatically adds a Jump rule into the policy.You could use a Sub-Policy, for example, for examining traffic destined to a group of servers located in one particular network. The Jump rule could then use the destination network as a criteria for directing connections for matching against the Sub-Policy. Any connection that was destined to some other network would not get matched against any of the rules in the Sub-Policy. This makes the matching process faster, because the firewall can skip a whole Sub-Policy by comparing a connection to just one simple rule for any non-matching connection. If the Sub-Policy rules were inserted directly into the main Firewall Policy, the firewall would have to compare all connections to all those rules individually (since that is the only way to find out if the connection matches the rules or not). Naturally, the performance benefit gained depends on the number and complexity of the rules that can be placed in a Sub-Policy and how heavily stressed the firewall is to begin with.

A Jump rule inserts the Sub-Policy, which is shown as an expandable section.


Task 4: Add RulesPolicy elements are merely containers for the actual traffic handling rules. When you have decided on a policy hierarchy, you can populate the policy elements with the actual rules for handling the traffic (see Access Rules, on page 165, Inspection Rules, on page 183, and Network Address Translation (NAT) Rules, on page 193).Each rule in a policy has an individual rule tag that consists of two parts (for example, @180.2). The first part of the tag is permanent and belongs to only that rule in the policy. The permanent part of the tag is followed after a period by the second part that changes as the rule is modified.

Task 5: Validate the PolicyThe number of rules in a Firewall Policy may grow quite large over time. It may become quite difficult, for example, to spot duplicate rules in a policy. To make policy management easier and to make sure that the policy does not contain misconfigured rules, you can optionally validate the policy either before installing or refreshing the policy or when you install or refresh the policy on an engine. You can select different criteria for validating the policy. You can, for example, check the policy for duplicate and empty rules or check if there are rules that cannot match traffic. If there are rules that match the selected validation criteria in the policy, the Management Client displays a list of the rules and the issues it found in them.

Task 6: Install the PolicyAfter creating or modifying a Firewall Policy, you must transfer the changes to the firewall using the Management Client in a Policy installation (transfers the policy you select) or Policy Refresh (transfers the most recent version of the policy that the firewall already uses). You can install the same Firewall Policy simultaneously on several firewall systems under your administration.When you install a modified or a completely new Firewall Policy, any existing connections that are not allowed by the new Firewall Policy are dropped. The existing connections allowed by the new Firewall Policy are not affected; they continue uninterrupted (including related connections and authenticated connections).Policy installation transfers more information than just the Firewall Policy. Whenever you update the firewall configuration or the properties of an element used in the configuration, you must reload the Firewall Policy to the firewall engine to make the changes effective. This includes, for example, changes in the routing configuration, the VPN configuration, and the Firewall element itself, even if the changes are not directly related to the rules in the Firewall Policy.

Tip: You can get a list of engines that have a configuration that is not up to date compared to the configuration stored on the Management Server with the Policy Refresh Check option.

If the installation of a Firewall Policy fails for some reason, the system automatically rolls back to the previously installed configuration. By default, a rollback also occurs if StoneGate detects that the new Firewall Policy or related configuration (such as routing configuration) does not allow the Management Server to connect to the firewall


engines. This safety feature prevents an administrator from inadvertently installing a configuration that would cause the critical management connections to fail.

Using Policy ElementsThe main points of using policy elements are explained in the preceding sections of this chapter, but this section illustrates two additional concepts that are useful when working with policies.

Connectionless Packet InspectionCertain kinds of connections do not require keeping track of the connection state (e.g., SNMP traps). Some applications may also communicate in a non-standard way that prevents them from passing the firewall when connection tracking is used. For those connections, connection tracking can be disabled in the Access rule. This allows StoneGate to function as a simple packet filter for those connections, but it also prevents you from using some features that require the connection information, such as NAT, from being applied to the connections.If done carelessly, turning connection tracking off reduces the benefits you gain from your firewall and may even weaken security. You may have other options: in some cases using the correct Protocol Agent helps.When connection tracking is off, each packet that you want to allow must match an Access rule allowing the packet. This means that even if two-way communications are always opened one way, both directions of communication must be explicitly allowed in Access rules. Reply packets are not recognized, so they are not automatically allowed through like they are when connection tracking is on.

Continue RulesThe Continue action for a rule sets default options (such as logging options, connection timeouts, etc.) for the traffic matching process. Options set in Continue rules are used for subsequent rules that match the same criteria as the Continue rule, unless the rules are specifically set to override the options. Templates are particularly convenient for setting options with a Continue rule, because all policies and templates that use the template inherit the option settings you have specified. Continue rules are explained in detail in Configuring Default Settings for Several Rules, on page 176.

Policy SnapshotsA Policy Snapshot is a stored record of a policy configuration. A policy snapshot is stored in an engine’s upload history whenever a policy is installed or refreshed on the engine. The Policy Snapshots allow you to the check the Firewall Policies and other configuration information that were uploaded and when they were uploaded. You can also compare any two policy snapshots and see the differences between them highlighted.


Examples of Policy Element UseThe examples in this section illustrate some common uses for the different policy elements in StoneGate and general steps on how each scenario is configured.

Protecting Essential CommunicationsCompany A has a firewall system administered by multiple administrators of various degrees of familiarity with networking, firewalls, and StoneGate. The administrators are often overworked and must make very quick changes to respond to the needs of the company and attend to any problems detected.The administrators recognize that in this situation, it is possible that someone may accidentally alter the Firewall Policy in such a way that important services are cut off. They decide to separate the rules allowing the most important business communications from rules that deal with non-essential traffic to minimize this risk. The administrators:1. Create a new Template Policy under the Default template.2. Cut and paste the rules allowing essential communications from their current

Firewall Policy into the new Template Policy.• In this case, all administrators are allowed to edit the new template as well.

3. Add an insert point below the copied rules in the Template Policy.• Having the insert point below the essential rules prevents the rules added to

the inheriting Firewall Policy from affecting the essential communications.4. Reparent their current Firewall Policy to use the new template, moving it down a

step in the policy hierarchy.5. After validating the policy and making sure that the rules are correct, refresh the

current Firewall Policy.• Since most daily editing is done in the Firewall Policy, there is less risk of

someone accidentally changing the essential rules in the Template Policy, because the rules are not editable in the Firewall Policy.

Improving Readibility and PerformanceCompany B has two separate DMZs, one for the extranet and one for other Web services. The number of services offered is quite large. The company also has a large number of partners and customers that have varying access rights to the different services. The administrators realize that a large number of the rules in their policies are related to the DMZ connections. The rest of the rules govern access to and from the company’s internal networks. Many of the rules have been entered over time by inserting them at the beginning of the rule table, so rules governing access to the different networks are mixed and finding all the rules that govern access to a particular network takes time.The administrators decide that they want to make their Firewall Policy more readable and at the same time optimize the way the firewall handles traffic, so they:1. Create two new Sub-Policies: one for each DMZ.

Examples of Policy Element Use 163

2. Cut-and-paste the rules from the current Firewall Policy into the correct Sub-Policies.

3. Add Jump rules into the Firewall Policy to direct the examination of traffic to/from the different networks into the correct Sub-Policy.

4. Refresh the Firewall Policy.

Restricting Administrator Editing RightsCompany C is implementing a distributed network with multiple sites: one central office where most of the StoneGate administrators work, and a number of branch offices in different countries. The branch offices mostly have IT staff with only limited networking experience, but who are still responsible for the day-to-day maintenance of the network infrastructure at their site. They must be able to, for example, add and remove Access rules for testing purposes without always contacting the main StoneGate administrators.In compliance with the company’s practices, the StoneGate administrators decide to limit the privileges of the branch office IT staff so that they are not able to edit the policies of the firewalls at any of the other sites. The administrators:1. Create a new Template Policy based on the Default template.2. Add rules using Alias elements to the template to cover the essential services

that each of these sites has, such as the VPN connections to the central site.• Using a common template for all the branch offices also eliminates the need to

make the same changes in several policies, easing the workload.3. Create a new Firewall Policy based on the new template for each of the branch

office sites.• Although a single Firewall Policy for all sites could work, in this case the

administrators decide against it, since separate policies are needed for the separation of editing rights. The policies are based on the same template, so rules can still be shared without duplicating them manually.

4. Grant each Firewall Policy to the correct Firewall element.• After this, only the correct policy can be installed on each firewall. No other

policy is accepted.5. Create new accounts with restricted rights for the branch office administrators

and grant the correct Firewall element and Firewall Policy to each administrator.• The branch office administrators are now restricted to editing one Firewall Policy

and can install it on the correct firewall.• The branch office administrators are not allowed to edit the template the policy

is based on, nor can they install any other policies on any other firewalls.Administrator rights are explained in more detail in Administrator Accounts, on page 85.


CHAPTER 14 Access Rules

Access rules are lists of matching criteria and actions that define how the firewall treats different types of network traffic. They are your main configuration tool for defining which traffic is stopped and which traffic is allowed.


Overview to Access Rules, on page 166 Configuration of Access Rules, on page 167 Using Access Rules, on page 175 Examples of Access Rules, on page 178

165

Overview to Access RulesThe Access rules are traffic handling rules in which you define the details of how you want the traffic to be examined and which action you want to take when matching details are found. The Access rules are stored in policy elements, which are discussed in Firewall Policies, on page 153. Access rules are not configurable on SOHO Firewalls; the rules are automatically deduced from the interface types, see SOHO Firewall Configuration, on page 103.The traffic matching is based on the information contained in the packets:• Source and destination IP addresses.• Protocol-specific information, such as the port information for protocols that use

ports, or the options set in Protocol Agents.Additional matching criteria that is not based on information in the packets includes:• The VPN where the traffic is coming from (on an engine where that VPN terminates).

This allows creating rules that apply to VPN traffic only, or rules that apply to all traffic except VPN traffic.

• The day of the week and the time of day (allowing you to enforce rules only during certain times, such as working hours).

The Access rules in policies provide several different ways to react when some traffic is found to match a rule. You can:• Specifically allow the traffic.• Specifically stop the traffic.• Allow the traffic on the condition that the user has passed authentication.• Allow the traffic on the condition that a VPN is established.Regardless of which of the above actions is taken, a matching rule can also create a log or alert entry.Additionally, Access rules select which allowed traffic is subjected to further inspection against the Inspection rules.In addition to traffic allowed by the Access rules, StoneGate automatically allows the following types of traffic with specific configurations:• DHCP requests and replies for an interface for which a DHCP server is enabled.• DHCP requests and replies for an interface which has a dynamic IP address.• State synchronization between cluster nodes.As these are automatically allowed, you do not need to add Access rules for these types of traffic to the firewall policy.

166 Chapter 14: Access Rules

Configuration of Access RulesAccess rules are configured on the Access Rules tab inside Firewall Policy, Template Policy, and Sub-Policy elements.

Illustration 14.1 Newly Inserted Access Rule - Main Cells

Illustration 14.1 above displays an Access rule that has just been inserted into the policy. The matching cells are set to NONE and the action is set to Discard, to prevent the rule from having any effect on traffic in case a new rule is added to the policy accidentally. It is not necessary to modify all cells in each rule, but the mandatory cells for traffic matching (Source, Destination, and Protocol) must be set to some value other than NONE for the rule to be valid. The Source VPN cell is also matched against traffic in the inspection process, but it is not mandatory to change it. The other editable cells specify further conditions and options for handling connections that match the cells that are used for traffic matching.Before starting to build policies, make sure you understand the network element types available and how you can use them efficiently to define the resources that you want to protect and control. The illustration below shows the types of elements that you can use in Access Rules.

Illustration 14.2 Elements in Access Rules

The table below explains briefly what each Access rule cell does and which elements you can use in the rules. More information on each cell is included in the task flow

Mandatory cells for matching traffic

Logging is configured in the Options cell

Firewall applies Action when it finds a match


later in this chapter. The cells are presented in the default order, but you can drag and drop them to your preferred order in your own Management Client.

TABLE 14.1 Access Rule Cells

Cell Explanation

ID

(Not editable.) Automatically assigned ID number that indicates the order of the rules in the policy. The rules are matched against traffic in the order of the ID numbers. For example, the rule 14.3 is the third rule added in this policy to the insert point that is the fourteenth rule in the upper-level template.

Source Elements containing the IP addresses that the rule matches. Both the Source and the Destination defined must match the source and destination of a packet for the packet to match the rule. The Source and Destination cells accept any elements in the Network Elements branch of the All Elements tree.

Destination

Service

The Services, at their simplest, match a certain port, but they often also reference a Protocol Agent for more advanced, application-layer inspection and traffic handling. The Service cell accepts Service and Service Group elements.

Action Command for the firewall to carry out when a connection matches the rule.

UsersThe end users that the rule applies to when the rule requires authentication. This cell accepts both User and User Group elements. If this cell is left to N/A, User information is not considered for this rule.

Authentication

Defines whether the rule requires end-users to authenticate and the authentication methods (Authentication Services) that are valid for this rule. If this cell is left set to None, authentication is not required for this rule.

QoS Class

The QoS Class that the firewall assigns to connections that match this rule. Used in traffic prioritization and bandwidth management. The priority has effect only if you set up QoS Policies, see Bandwidth Management and Traffic Prioritization, on page 281.

Options

The options for logging, connection tracking (i.e., whether matching traffic is handled as a connection or as individual packets), deep packet inspection, and blacklisting. If this cell is left set to Undefined, the behavior is as explained in Task 4: Select Rule Options, on page 173.

TimeThe time period when the rule is applied. If this cell is left empty, the rule applies at all times.

Comment Your optional free-form comment for this rule.


Considerations for Designing Access RulesOne of the crucial issues in designing any of the policies is the order of the rules. The most important thing to keep in mind when editing the Template Policies, Policies, and Sub-Policies is that the rules are read from top down. The actions Allow, Refuse, and Discard and the action Use VPN with the option Enforce stop the processing from continuing down the rule table for any connection that matches the rule. Therefore, rules with any of these actions must be placed so that the more limited the rule is in scope, the higher up in the rule table it is. For example, this means that an Access rule that allows connections to the IP address 192.168.10.200 must be put above an Access rule that stops all connections to the network 192.168.10.0/24.See Example of Rule Order, on page 178 for a more detailed example and Guidelines for Building Network Security, on page 497 for a thorough presentation on policy design.

Default ElementsThere is a template called Default that contains the basic Access rules that allow communications between the StoneGate firewall on which the policy is installed and other system components.You must use the Default template as the basis for defining your own templates and policies, as it is not possible to create a new template at the highest level of the policy hierarchy. No changes can be made directly to the Default template, but you can create your own copy of it if you have a specific need to modify those rules.

Note – If you decide to use a copy of the Default template, you may have to adjust your rules manually when the system is upgraded to account for changes in system communications. Upgrades can change only the Default template, not the copies.

Tag

(Not editable.) Automatically assigned unique identifier for the rule. Works as a link between the log entries and the rule that has generated the log entries. The rule tag consists of two parts (for example, @180.2). The first part of the tag is permanent and belongs to only that rule. The permanent part of the tag is followed after a period by the second part that changes whenever the rule is changed.

Source VPNMakes the rule match traffic based on whether it is coming from a specific VPN. If this cell is left empty, the rule matches both VPN and non-VPN traffic.

TABLE 14.1 Access Rule Cells (Continued)

Cell Explanation


Illustration 14.3 Default Template Access Rules

The illustration above shows the Access rules included in the Default template. The insert point, where rules can be added in the inheriting Policy and Template Policy elements, is shown as an orange row near the end of the Access rules table.The rules above the insert point detail the various kinds of system communications. Most of the IP addresses are defined using Aliases to make the rules applicable on any system where they are installed. These Aliases are default elements in the system and they are listed in the appendix Predefined Aliases, on page 423. The Service cell is the best starting point for understanding in greater detail what these rules do. See appendix StoneGate-Specific Ports, on page 401 for a listing of the system communications and the Service elements that correspond to them.There are two rules below the insert point. The rule directly below the insert point has the action Refuse for the Ident protocol traffic, which means that this traffic is stopped with an ICMP error message sent to the Ident request sender. This rule exists to prevent Ident requests from being silently dropped (as the next rule specifies for all other traffic), because silently dropping Ident requests causes delays in communications. The last rule before the end of the policy is a rule that discards all traffic and creates a log entry that is stored. This rule’s purpose is to ensure that this


connection dropping is logged, since the firewall silently drops the connection without creating a log entry if the matching process reaches the end of the policy.

Configuration WorkflowThe following sections provide an overview of the configuration tasks related to configuring and customizing Access Rules. Detailed step-by-step instructions for configuring the rules can be found in the online help of the Management Client and the Administrator’s Guide PDF, in the section called Policies.

Task 1: Define the Source and DestinationThe source and destination IP addresses specified in a rule are compared to the IP addresses in each packet’s header. Based on these and other criteria, the rule is applied to matching packets. By default, these cells are set to NONE, and you must change the value in both cells to make the rule valid.The Source and Destination cells accept many kinds of elements. Any of the elements in the Network Elements category of the All Elements tree can be used to represent IP addresses in the Source and Destination cells. Groups, Aliases, Address Ranges, and Expressions are especially useful for defining IP addresses in complex scenarios. You can set these cells to ANY to make the rule match all possible source or destination IP addresses. Also, you can add more than one element in each cell to make the rule match several IP addresses.

Task 2: Define the ServiceThe Service cell defines which protocol(s) the rule you design applies to. By default, the Service is set to NONE, and you must change the value to make the rule valid.The Service cell accepts only Service and Service Group elements. There are ready-made Services in the system that cover most needs, but you may also use your own customized versions, for example, to define a non-standard port. The Services available for rule design are categorized according to protocols. You can add more than one element in this cell to make the rule match several Services.Certain Services are associated with Protocols of the Protocol Agent type, which define more advanced inspection and handling for the connections. Additionally, the Protocol element identifies the protocol for the traffic for inspection against the Inspection rules (only some protocols are supported for this purpose on the firewall). For more information on Protocols, Protocol Agents, and the network protocols that require their use, see Protocol Agents, on page 207.You can set the Service to ANY to make the rule match traffic using any protocol. A previous Continue rule (such as the one in the Default template) may define a Protocol Agent for certain types of traffic that is allowed by rules with ANY as the Service (see Configuring Default Settings for Several Rules, on page 176).


Note – The firewall cannot handle some types of traffic correctly if the traffic is allowed without the correct Protocol Agent when connection tracking is on (stateful inspection). Also, if there is no previous Continue rule matching the same connection that would define a Protocol Agent, a rule allowing ANY Service does not apply a Protocol Agent to the traffic.

For more information on Services, see Network Elements and Services, on page 95.

Task 3: Select the ActionThe Action cell defines what happens when a packet matches the rule. The available actions are explained in Table 14.2.

TABLE 14.2 Action field options

Action Explanation

Allow The connection is let through the firewall.

Continue

Stores the contents of the Options and QoS Class cells and the Protocol (if defined in the Service used) in memory and continues the inspection process. Used for setting options for subsequent rules as explained in Configuring Default Settings for Several Rules, on page 176.

Discard The connection is silently dropped.

RefuseThe connection is dropped and an ICMP error message is sent in response to notify the packet’s sender.

JumpMatching is continued in the specified sub-policy until a match is found. If there is no matching rule in the sub-policy, the process is resumed in the main policy.


Task 4: Select Rule OptionsEach Access rule has three types of options: logging options, connection tracking options, and blacklisting options.By default, the Logging options are set to Undefined, which means that the rule uses logging options that have been set in the previous Continue rule above. If there is no previous Continue rule, a Stored-type log entry is created. If this is what you want, you can leave the setting as Undefined. Logging for the closing of the connection can be turned on or off, or on with accounting information (e.g., bytes sent). You must collect accounting information if you want to create reports that are based on traffic volumes. Logging is discussed in greater detail in Log Management, on page 309Connection tracking means that the firewall keeps a record of all currently open connections (stateful inspection). With connection tracking, the firewall can verify that the connection proceeds according to the protocol standards. Connection tracking is required for modifying the addresses using NAT. By default, connection tracking is on, but some connections may need to be handled without connections tracking to pass them through the firewall, and you may need to disable it. This makes StoneGate function as a packet filter for those specific connections.

Use VPN

EnforceThe connection is allowed if the specified VPN is used. Otherwise the connection is discarded.

Apply The connection is allowed if the specified VPN is used. Otherwise, the rule is considered as non-matching and the matching process continues to the next rule.

Forward

The connection is forwarded to the specified gateway-to-gateway VPN from the VPN defined in the rule’s Source VPN field or the connection is forwarded from the internal network to the client-to-gateway VPN.

The Selected VPNSpecifies a gateway-to-gateway or a client-to-gateway VPN for Enforce, Apply, or Forward.

Any Mobile User VPN

Specifies all the client-to-gateway VPNs involving the Firewall on which the current policy is installed for Enforce, Apply, or Forward.

Apply BlacklistChecks the packet against the blacklist according to the options set for this rule. If the packet matches a blacklist entry, the connection is discarded.

TABLE 14.2 Action field options (Continued)

Action Explanation


Note – Before disabling connection tracking, always check if there is a Protocol Agent for the protocol in question. The Protocol Agents can pass such troublesome connections with connection tracking on, which is always a more secure option.

The Deep Inspection option determines whether matching connections are inspected also against the Inspection rules. Any rule that has the Deep Inspection option selected must also have a Service that uses a Protocol that is supported for deep inspection on the firewall (for deep inspection of other protocols, use StoneGate IPS).In the options, you can also set the Idle Timeout for connections if connection tracking is on. The timeout is meant for clearing the firewall’s records of old connections that the communicating hosts leave hanging. The timeout concerns only idle connections, so connections are not cut because of timeouts while the hosts are still communicating. The timeout defined for an Access rule overrides the default idle timeout value that is set for the protocol in question in the Firewall element’s properties.

Caution – Setting excessively long timeouts for many connections can consume resources to a point where the firewall performance and stability start to suffer.

The Blacklisting options are used in rules that have Apply Blacklist as the action. The options allow you to choose which entries on the blacklist apply to connections that match the rule based on the component that added the blacklist entry on the blacklist. A restriction based on blacklist sender may be necessary, for example, if the same IP address exists in two different networks. The default setting is to take all blacklist entries into account regardless of the component that created the entry.

Task 5: Add User AuthenticationThe firewall can enforce user authentication. A client-to-gateway VPN always requires some form of authentication, but you can also add the authentication requirement to any non-VPN rules if you wish.The authentication is configured in the Users and Authentication cells. The Users cell accepts User and User Group elements and defines the end-users who are allowed to make connections allowed by the rule. You define the authentication method used in this particular rule in the Authentication cell, as each user and user group can have several authentication methods configured.If the authentication fails, the connection is discarded, unless the rule specifies the Use VPN action with the Apply option (in which case the matching process continues with the next rule). If the authentication succeeds, the connection is allowed through. Note that the firewall does not use the Users or the Authentication cells for matching traffic to the rule: if the Source, Destination, Protocol, and the optional Source VPN in the rule match a connection made by some user that is not included in the rule, the connection is always dropped unless the rule’s action is set to Apply VPN.


For more information, see Chapter 18, User Authentication.

Task 6: Restrict the Time When the Rule Is EnforcedOptionally, you can set a specific time period when a rule is applied using the Time cell. The validity of the rule can be set by month, day of the week, and time of day. For example, you might have certain rules that allow access only during business hours on weekdays. If you leave the Time cell empty, the rule is always valid.

Note – The times are entered in Coordinated Universal Time (UTC), and you must adjust the times you enter to make them correspond to the firewall’s local time zone. Also consider that UTC time does not adjust to daylight saving time (summer time).

Task 7: Restrict the Rule Match Based on Source VPNOptionally, you can match the rule based on whether the traffic is coming from a VPN. You can define that the rule matches only non-VPN traffic, or only traffic from a certain VPN.You can use the Source VPN cell with the Forward action to transfer traffic from a client-to-gateway VPN to the gateway-to-gateway VPN defined in the Action cell. This VPN hub functionality is currently supported only between a client-to-gateway VPN and a gateway-to-gateway (VPN hub cannot be used to forward traffic from one gateway -to-gateway VPN to another). For more information, see Overview to VPNs, on page 353.

Using Access Rules

Adding Comments to RulesAccess and Inspection rule tables can grow large, so comments are a good way to ensure that the rules are easy to read. You can add comments to each rule (in the Comment cell) or you can add dedicated comment rules in between other rules. Comment rules are displayed on a colored background, so they are particularly good for visually separating sections of rules within a single policy.

Allowing System CommunicationsThe necessary communications between the firewall and other StoneGate components are allowed in the Default Template Policy. However, the Default template does not allow other StoneGate components to communicate through the firewall to some third StoneGate component.For example, in a configuration where you have a firewall and a Log Server at a remote site that are managed by a Management Server behind a firewall at a central site, you must create rules in the Firewall Policy at the central site to allow:• Management and monitoring connections to/from the remote firewall.


• Monitoring and log browsing connections from the central site to the remote Log Server.

• Any remote-site Management Client connections to the Management Server at the central site.

If NAT is used for the connections, Access rules alone are not enough. You must also create Location elements and add Contact Addresses for the elements to define which translated addresses are necessary for making contact (see NAT and System Communications, on page 201).There are predefined Service elements in the system for all system communications. You can use these to create your Access rules (see Services, on page 101).

Configuring Default Settings for Several RulesYou may want to set default values for some settings in rules to avoid defining the same settings for several rules individually. The Continue action is used to set such default values.When a connection matches a rule with Continue as the action, some of the rule’s settings are written in memory but the matching continues until another rule that matches is found. This matching rule uses the defaults set in the Continue rule unless the rule specifically overrides the defaults with different settings. This way, you do not have to define the settings for each rule separately. You can use Continue rules to set default settings for a general type of traffic and define settings for individual rules only when specifically required. There are also default values that are used for rules that are set to use the values of a Continue rule, but there is no previous matching Continue rule.The options that can be set using Continue rules in Access rules include:• The Connection tracking option (default is on).• The connection time-out (overrides the global default set for the protocol in the

Firewall element’s properties).• The logging options (default is Stored).• The Protocol inside the Service (used to apply a Protocol Agent to rules with ANY as

their Service, see Using Continue Rules with Protocol Agents, on page 177).• The QoS Class (default is a priority of 8, but no specific QoS Class assigned).Continue rules are defined the same way as other rules. However, you must keep in mind that when any of the options listed above is set in the Continue rule, many or even all rules below may be affected. The Continue rule options are used by the rules below, provided that the Source, Destination, Service, and the optional Source VPN definition match the same connection as the Continue rule. Continue rules are inherited from Template Policies into lower-level templates and policies like any other rules.Continue rules behave in the same way as any other rules. A Continue rule can be overridden by some subsequent Continue rule that has an identical scope (Source, Destination, etc.), or partially overridden by a Continue rule that partially overlaps with the previous Continue rule. When you define Continue rules with different matching


criteria, you can have several Continue rules one after another without them interfering with each other in any way at all.Sub-Policies may require special attention with Continue rules: the Sub-Policies may have different options when you insert them into different policies if the Sub-Policy rules do not override the options set by preceding Continue rules. Also, when a Sub-Policy contains a Continue rule, the options are then used for further matching in the higher-level policy (if the processing returns to the higher-level policy).

Using Continue Rules to Set Logging OptionsOne common use for the Continue action is to set the default log level for all subsequent rules. Instead of setting the logging option for all rules individually, you can set a Continue rule in a template or in a policy to set the default log level. Any subsequent matching rules can have their log level as Undefined, yet they trigger logging as defined in the Continue rule.

Illustration 14.4 Setting the Default Log Level

In Illustration 14.4, the default log level is set to Transient for any source, destination or service. All subsequent rules in this policy and any sub-policies log Transient by default. In this way, the administrator can collect information to display in the Logs view for all rules. Individual rules can still override this option with specific log levels, such as Essential or Stored.There is also a default logging setting that is used if logging for a rule is set as Undefined and there is no prior Continue rule that would determine its logging mode: an Access rule will generate a Stored log entry in that case.

Using Continue Rules with Protocol AgentsThe default Protocol Agent can be set using the Continue action. This way, the correct Protocol Agent is also used for traffic that is allowed by rules that are set to match any Service (this may be even be mandatory, for example, if you want to allow certain protocols that allocate ports dynamically). The Default template includes one Continue rule that defines that Protocol Agents are used for the Service Group Default Services with Agents.

Illustration 14.5 Default Template Protocol Agent Rule

If you want to set a Protocol Agent for more types of protocols or override the Default rule shown in Illustration 14.5 for some or all connections, place one or more


Continue rules at the top or some other suitable place in your own template or policy. The Source and Destination can be some specific addresses if you want to limit the scope of your Continue rules.For more information on using Protocol Agents in rules, see Protocol Agents, on page 207.

Using Aliases in Access RulesAliases are one of the most useful tools for reducing the complexity of a policy. With Aliases, you can avoid creating multiple, near-duplicate rule sets when you have several firewalls. The Alias element is used like any other network element. However, the IP addresses that the Alias represents depends on the Firewall where the rules are installed. The IP address to firewall mapping is defined in the Alias element.For example, in a company that has offices in several different locations, each office can have its own Web server. The Web server rules could be put in a single Sub-Policy, but each location’s Web server has a different IP address. Normal rules would require allowing access to all IP addresses on all firewalls, which is not only unnecessary, but can also be considered a security risk. Using aliases, the company can create a single set of rules that are still valid when applied to multiple firewalls, but which do not allow access to IP addresses that are not in use on a particular firewall.In this way, aliases simplify policies without reducing security.

Validating RulesYou can validate the rules in the policy before installing or refreshing the policy on the engines. You can select different criteria for the policy validation. If there are rules that match the selected validation criteria, the Management Client displays a list of the rules and the issues it found in them.

Examples of Access RulesThe examples in this section illustrate some common uses for Access rules in StoneGate and general steps on how each scenario is configured.

Example of Rule OrderCompany A has an office network, a DMZ for WWW servers, and a second DMZ for an FTP server. At this point, the administrators only need to add rules for the DMZ traffic.


Illustration 14.6 Company A’s Communications of Special Interest

The WWW servers must be accessible to anyone from both internal and external networks. HTTP traffic will be inspected against the Inspection rules, excluding the Administrator’s own PCs (on the right in the illustration), since they often test the servers for vulnerabilities. The FTP server is accessible to all users in the general office network, but only to certain external users (on the left in the illustration) that authenticate using an external authentication server.The administrators:1. Create Host elements for the WWW servers, the FTP server, and the

administrators’ PCs.2. Create a Group element that contains the WWW server host elements.3. Create a Group element that contains the administrator PCs’ host elements.4. Configure an external authentication server for use with StoneGate.5. Create User and User Group elements for the allowed external FTP users.6. Add Access rules with the Allow action for access to the DMZs:

TABLE 14.3 Access Rules for the DMZ

Source Destination Service Users Authentication Options

“Administrator PCs” Group

“WWW Servers” Group

“HTTP” ServiceDeep Inspection: Off

ANY“WWW Servers” Group

“HTTP” ServiceDeep Inspection: On

Network element for Office Network

“FTP Server” Host

“ftp (file transfer [control])” Service

Deep Inspection: Off


• As seen in the rule table, there are two rules for traffic to both the WWW servers and the FTP server.

• The rules are arranged so that the more specific rules are above the more general rules. For example, the rule allowing administrators to connect to the WWW servers without checking against the Inspection rules is above the more general rule that allows any connection to the servers as subject to the Inspection rules.

• If the first two rules were in the opposite order, the rule specific to administrators would never match, as the rule with the source as ANY would be applied first, the connection would be allowed according to that general rule, and the firewall would stop checking the rule table.

Example of Continue RulesCompany B has decided to implement QoS Policies. The administrators want to set the QoS Class for traffic using a classification of high, medium, and low for all traffic depending on the sender. High priority is assigned to a small number of hosts in different networks, medium priority to one internal network, and low priority to all other hosts. The administrators want to follow how much traffic is allowed using the highest priority, so they also want to make sure that this traffic is logged with the accounting option turned on. They decide that the lower priorities of traffic need not be permanently logged at this point, so the administrators:1. Configure the QoS features.2. Create elements for all high-priority hosts.3. Add the following Access rules to the top of their policy:

ANY“FTP Server” Host

“ftp (file transfer [control])” Service

“External Users” User Group

Require authentication with the external authentication service selected

Deep Inspection: Off

TABLE 14.3 Access Rules for the DMZ (Continued)

Source Destination Service Users Authentication Options

TABLE 14.4 Continue Rules for Logging and QoS Class

Source Destination Service Action Options QoS Class

Important Hosts

ANY ANY ContinueStored with accounting

High priority


• After adding these rules, individual rules can override the settings as needed, but most of the existing rules governing access from internal networks to the Internet now use the QoS Class and Logging options as set in these rules.

4. Transfer the policy to the firewall.

Network element for Important Network

ANY ANY Continue TransientMedium priority

All other Hosts ANY ANY Continue Transient Low priority

TABLE 14.4 Continue Rules for Logging and QoS Class (Continued)

Source Destination Service Action Options QoS Class



CHAPTER 15 Inspection Rules

Inspection Rules are lists of matching criteria and actions. They define how the firewall looks for malicious patterns in traffic allowed through the Access rules and what happens when a certain type of pattern is found.


Overview to Inspection Rules, on page 184 Configuration of Inspection Rules, on page 184 Using Inspection Rules, on page 191 Example of Inspection Rules, on page 191

183

Overview to Inspection RulesInspection rules are an additional layer of defense that can be used for inspecting traffic that has already been allowed through in the Access rules. The Inspection rules look inside the packets after the Access rules have allowed them, and throughout the connection to see if the data being transferred contains a malicious pattern. The Inspection rules are stored in policy elements, which are discussed in Firewall Policies, on page 153.There are two general cases where Inspection rules help:• You can stop attempts to exploit known vulnerabilities in one of your systems at the

firewall. Malicious programs and people use vulnerabilities to gain access to restricted information, gain control over your computing resources, bring down your services, or simply destroy whatever data they can.

• You can also detect other patterns in traffic, such as the use of certain programs or even attempts to access a particular file. The traffic may be something you may want to stop, or something you just want to have logged.

The Inspection rules allow the firewall to inspect HTTP or SIP traffic just like an IPS sensor. However, unlike the sensors, the firewall does not send any of the detected events to IPS analyzers for event correlation.The Inspection rules work by comparing traffic to patterns of known security threats. Patterns are supplied by Stonesoft in dynamic update packages, but you can define your own traffic patterns as well. You can restrict the scope of each Inspection rule by defining additional matching criteria, such as IP addresses.Using the inspection capabilities on the firewall requires that enough hardware resources are available to support the feature, as the inspection process is memory-intensive. Inspection Rules are not supported on SOHO firewalls.The Inspection rules provide several different ways to react when some traffic is found to match a rule. You can:• Specifically allow the traffic without further inspection (for example, to eliminate a

false positive).• Specifically stop the traffic.• Reset the connection.Regardless of which of the above actions is taken, you can also create:• A log entry with or without recording an excerpt of the detected traffic.• An alert with or without recording an excerpt of the detected traffic.

Configuration of Inspection RulesThe firewall inspects traffic based on Situation elements, which contain the information about known vulnerabilities and attacks. The same Situation elements can be used in the inspection rules of both firewalls and sensors. However, only HTTP and SIP situations can be used in the Firewall Policy, as these are the two protocols the firewall supports for deep packet inspection. By matching traffic to Situations, the firewall can detect certain characteristics in the content of the packets within an

184 Chapter 15: Inspection Rules

already allowed connection, such as commands that match a known exploit against a certain type of operating system or application.Inspection rules are configured on the Inspection Rules tab inside Firewall Policy and Template Policy elements. Sub-Policies cannot contain Inspection rules.

Illustration 15.1 Newly Inserted Inspection Rule - Main Cells

Illustration 15.1 shows an Inspection rule that has just been inserted into the policy. The Situation and Severity are set to ANY to match all Situations included in the system. However, the Source and Destination cells are set to NONE, so this rule never matches until those are changed to ANY or some more specific value. The main matching criteria are the Situation and the Severity. The role of the Source, Destination, and Protocol cells is to limit the scope of the rule to some specific traffic when necessary, for example, when you want to take different action based on which host is the sender or receiver of the traffic identified as malicious.Before you start to build your own Inspection rules, you must understand the element types available and how you can use them efficiently to define the traffic that is potentially unwanted. Particularly the Situation elements are central in configuring your Inspection rules, see Situations, on page 249. The illustration below shows the types of elements you can use in Inspection rules.

Illustration 15.2 Elements in Inspection Rules

Situation cell defines which traffic patterns the rule matches.

Severity can make the rule match only a subset of the selected Situations.

Firewall applies Action when it finds a match.


The table below explains briefly what each Inspection rule cell does (more information is included in the task flow further in this chapter). The columns are presented here in the default order, but you can drag and drop them to your preferred order in your own Management Client.

TABLE 15.1 Inspection Rule Cells

Cell Explanation

ID

(Not editable.) Automatically assigned ID number that indicates the order of the rules in the policy. The rules are matched against traffic in the order of the ID numbers. For example, the rule 1.3 is the third rule added in this policy to the insert point that is the first inspection rule in the upper-level template.

Situation

Contains the elements that define the patterns of harmful traffic the rule detects. In addition to individual Situation elements, this cell may contain Tag elements, which are shown as branches in the Situations tree and allow adding the whole branch of Situations at once to a rule. Currently, HTTP and SIP inspection is supported on firewalls. Situations that inspect other protocols are for use with StoneGate IPS.

SeverityLimits the scope of the rule to those matching Situations that have a severity value within a range you define. This allows you to create different responses for otherwise identical traffic based on the Severity.

Source Elements containing the IP addresses that the rule matches when encountered as a Source and Destination in the packets. The Source and Destination cells accept any elements in the Network Elements branch of the All Elements tree.

Destination

Protocol

Protocols that the rule matches. The protocol is set in the Access rules by inserting a Service with a Protocol Agent in the rule that allows the traffic. Currently, HTTP and SIP inspection is supported on firewalls. Protocol elements for other protocols are for use with StoneGate IPS.

Action Command for the firewall to carry out when a connection matches the rule.

Options Options for logging and connection resetting and termination.

TimeThe time period when the rule is applied. If this cell is left empty, the rule applies at all times.

Comment Your free-form comment for this rule.


Considerations for Designing Inspection RulesThe basic design principle of Inspection rules is the same as in Access rules, meaning that the rules are read from top down, and more specific rules must be placed above more general rules that match the same traffic. But in Inspection rules, matching is mainly done based on information included in the Situation elements. Because each Situation matches only a particular pattern in traffic, the rules match the same traffic only when they match the same Situation, even if they have identical Source, Destination, and Protocol definitions.The Inspection rule design is mainly a process of selecting which Situations are applied to which traffic and which reaction is triggered when a match is found. The actual matching criteria is included in the Situation elements. This also means that the behavior of the inspection rules can change without anyone editing the policy itself. Just creating a new Situation in the system may include it in the policy, if there are rules with “ANY” as the defined Situation or rules that include a Tag attached to the Situation.

Default ElementsThe Inspection rules have their own template called Default Inspection Rules, which is introduced in your system when you import and activate a dynamic update package. The Default Inspection Rules template is placed below the main Default template in the policy hierarchy, but you must manually reparent any existing policies if you want them to use the Default Inspection rules. It is not mandatory to use the default template for inspection rules: the Default template (the one that contains the Access rules) has an insert point for Inspection rules on its otherwise empty Inspection rules tab.The rules in the Default Inspection Rules template may change when you activate new update packages in your system. The illustration below shows the most recent rules at the time of writing this guide.

Tag

(Not editable.) Automatically assigned unique identification for the rule. Works as a link between the log entries and the rule that has generated the log entries. The rule tag consists of two parts (for example, @180.2). The first part of the tag is permanent and belongs to only that rule. The permanent part of the tag is followed after a period by the second part that changes whenever the rule is changed.

TABLE 15.1 Inspection Rule Cells (Continued)

Cell Explanation


Illustration 15.3 Default Inspection Rules Template

In Illustration 15.3, you can see the insert point and two rules below that. The Inspection rules may look very simple, but they actually include a multitude of Situations: the Situation cell in both rules includes tags, which means that all Situations that are marked with those tags are included in the rules. This also means that when new Situations are added to the system with one of the Tags in the rules, the firewall will automatically start looking for the patterns the new Situation contains without any direct modifications to the rules.The Firewall reads the Inspection rules from top down. In the illustration, just below the insert point, Rule 1.2 defines that a connection that matches Situations marked with the Tag Attacks or the Tag Successful Attacks is Terminated. Rule 1.3 below creates a log entry, if less serious Situations are encountered, but Permits the connections.The insert point is above the two default rules. This supports a workflow where you use the default template as a basis for your own policies and then add rules that override the default behavior for some Situations to adapt the Inspection Rules to your particular environment. You can use the insert point to add the rules that take no action at all for certain Situations that you know are not relevant in your environment.

Configuration WorkflowThe following sections provide an overview to the configuration tasks related to configuring and customizing Inspection Rules. Detailed step-by-step instructions for configuring the rules can be found in the online help of the Management Client and the Administrator’s Guide PDF, in the section called Policies.

Note – You must import and activate a recent dynamic update to create Inspection Rules. See the online help for information on updating your system with dynamic updates and instructions for enabling automatic update download and activation.

Task 1: Add SituationsThe Situation field is used for matching traffic to known patterns of exploits, so the Situation field includes the information that makes the inspection possible. In addition to individual Situation elements, this cell may contain Tag elements, which are shown as branches in the Situations tree and allow adding the whole branch of Situations at


once to a rule. Currently, only the HTTP and SIP Situations can be used in Firewall Policies. Incompatible Situations are ignored if you add them to the Firewall Policy.You may also set the Situation cell to ANY, which makes the cell match any Situation defined in the system. This makes for one notable difference between the Access rules and Inspection rules: Inspection rules do not match all traffic even if all matching cells are set to ANY, because the rule still matches only traffic patterns that are defined in the Situation elements included in the system.You can create your policies without creating any custom Situation elements: you can decide which of the pre-defined Situations are applied to which traffic and which kind of responses are triggered when a match is found. If you use the Default Inspection Rules template, the Situations you will add to the policy are most likely those that you consider to be false positives in your environment.However, if you want to detect some pattern in traffic that is not defined in the pre-defined Situations (for example, a particular internal file server in your network being accessed) or if you want to create a modified version of some existing Situation, you must create a new Situation element. This is explained in Configuration of Situations, on page 250.

Task 2: Limit the Situations by SeveritySituation elements always have a severity value, which is a number from 1 (least severe) to 10 (most severe). The Severity cell allows you to limit the scope of the rule to those matching Situations that have a severity value within a certain range. Restricting the scope using Severity is most useful when you use Tags in the Situations cell.For example, defining the Severity allows you to create different responses for otherwise identical rules that include many different Situations (like Situations that include all known vulnerabilities related to a certain operating system): you could decide to issue an Alert for matches to more severe Situations and only create a normal log or no log at all for less severe ones.

Task 3: Define the Source and DestinationThe Source and Destination cells are used for limiting the scope of inspection to certain traffic. This is done in the same way as in Access rules, but with a different purpose. Inspection rules allow all connections to pass by default, unless specifically terminated by a rule. Therefore, the Source and Destination are used only to restrict the scope of the Inspection rules or to except traffic between certain hosts from further inspection.

Task 4: Define the ProtocolThe Protocol cell corresponds to the Service cell in Access rules. When the traffic is directed from Access rules, it is defined as belonging to a specific protocol (SIP or HTTP), so all traffic that arrives in Inspection rules has a specific protocol defined. If necessary, you can refer to this protocol to limit a rule’s scope. This is useful, if you


have Situations with mixed protocols included in a rule (for example, when the Situations are defined with Tag elements). Individual Situations match only either HTTP or SIP traffic in any case.

Task 5: Select the ActionInspection rules have three actions:• Permit stops the inspection process for matching connections. All further

inspection rules have no effect on the matching connections. The Permit action is perhaps most often used to eliminate false positives. You can also use it to configure rules that create an alert or a log entry, but do not stop matching traffic.

• Continue rule’s options (defined in the Options cell) are stored in memory while the matching process continues. The options can be overridden partially or completely by a later, matching rule. See Setting Default Options for Several Inspection Rules, on page 191.

• Terminate stops the matching connection according to options set for the rule.

Task 6: Set the Options for the RuleEach rule has three types of options: for logging, for the Terminate action, and for connection resets.By default, the logging options are set to Undefined, which means (like in Access rules) that the rule uses logging options that are set in the previous matching Continue rule above. But in Inspection rules, the default option is that no log entry is generated if there is no previous Continue rule. The only difference between the logging options compared to Access rules is the addition of the option to record excerpts of the actual packet payload in connections that match the rule.

Note – Storing or viewing the packets’ payload may be illegal in some jurisdictions due to laws related to the privacy of communications.

Logging is discussed in greater detail in Log Management, on page 309.The connection termination options allow you to select whether you want the Terminate action to actually terminate the connection, or whether it will just log that termination could have occurred. The purpose of this option is to allow testing of a new rule without having to worry that a mistake could cut the wrong connections, while still providing a distinctive entry in the Logs view (different from any other log entries, including actual terminations of connections).A second option allows you to select whether the connection termination additionally sends a reset that appears to both communicating hosts as though the other host reset the connection. An additional option for connection resetting defines whether an ICMP error message is sent when the communications use some other protocol in cases where a connection reset would be sent if the rule had matched a TCP connection (by default, no ICMP error message is sent).


Task 7: Restrict the Time When the Rule is EnforcedOptionally, you can set a specific time period when a rule is applied using the Time cell. The validity of the rule can be set by month, day of the week, and time of day. For example, you might have certain rules that allow access only during business hours on weekdays. If you leave the Time cell empty, the rule is always valid.

Note – The times are entered in Coordinated Universal Time (UTC), and you must adjust the times you enter to make them correspond to the firewall’s local time zone. Also consider that UTC time does not adjust to daylight saving time (summer time).

Using Inspection Rules

Adding Comments to Inspection RulesInspection rules can have comments so that you can ensure your rules are easy to read. You can add comments to each rule (in the Comment cell) or you can add dedicated comment rules in between other rules.

Setting Default Options for Several Inspection RulesYou may want to set default settings for some rules to avoid defining the same settings for several rules individually. The Continue action is used to set such default options. In Inspection rules, only the contents of the Options cell can be set using Continue rules.The Continue rules in Inspection rules work in the same general way as those in Access rules, see Configuring Default Settings for Several Rules, on page 176.

Validating RulesYou can validate the rules in the policy before installing or refreshing the policy on the engines. You can select different criteria for the policy validation. If there are rules that match the selected validation criteria, the Management Client displays a list of the rules and the issues it found in them.

Example of Inspection RulesThe example in this section illustrates a common modification to the default Inspection rules in StoneGate and general steps on how the scenario is configured.

Eliminating a False PositiveThe StoneGate administrators in this example have just started using Inspection rules, installing a policy that includes only the rules defined in the Default Inspection Rules template. When they install the Firewall Policy, they soon start receiving alerts.

Using Inspection Rules 191

After some investigation, the administrators realize that the alert is caused by a custom-built application, which communicates in a way that happens to match the pattern of how a certain exploit would be carried out by an attacker. The custom-built application is only used by a specific server and a few clients in the internal network, so they quickly modify the Inspection rules to exclude those particular hosts for the Situation in question. The administrators:1. Create Host elements to represent the server and the clients.2. Create a Group element that includes the client’s Host elements.

• The administrators name the Group so that it is immediately clear from the name that the Group contains those hosts that must contact the server running their custom-built application. This makes the new rule easier to read than if they included the hosts directly in the rule.

3. Add the following rule in the Inspection rules in their policy:

• If the Situation matches traffic between any other hosts than those included in the Group, the IP address does not match those defined in the new rule, so the processing will continue to the next rule, which terminates the traffic and triggers an alert.

• The logging would not have to be set to None, because it is the default option, but the administrators want to do so anyway to make sure any rules they add in the future cannot accidentally set logging on for this rule.

4. Install the new policy on the Firewalls.

TABLE 15.2 Rule for Eliminating a False Positive

Situation Source Destination Action Options

The Situation element that is mentioned in the alerts in the Logs view.

The Group defining the clients.

The Host for the internal server.

Permit Logging: None


CHAPTER 16 Network Address Translation (NAT) Rules

Network address translation (NAT) means changing the IP address and/or port information in packets. Most often, NAT is used to allow internal hosts to communicate via networks where their actual address is not routable and to conceal the internal network structure from outsiders.


Overview to NAT, on page 194 Configuration of NAT, on page 197 Using NAT and NAT Rules, on page 200 Examples of NAT, on page 204

193

Overview to NATNetwork address translation (NAT) changes the source or destination IP address or port for packets traversing the firewall. It is most often used to hide internal networks behind a single or just a few routable IP addresses on the external network. NAT is also often used to translate an external, routable destination address into the private internal address of a server. For destination NAT, it is also possible to perform port translation (sometimes referred to as PAT) when the protocol in question uses ports. Port translation can be used to redirect a standard service, such as HTTP (port 80/TCP), to a non-standard port (for example, port 8080/TCP). The NAT rules are stored in policy elements, which are discussed in Firewall Policies, on page 153.SOHO firewalls always perform dynamic NAT to their own IP address for direct Internet connections. The NAT rules for SOHO Firewalls are not configurable.There are five possible methods for network address translation in StoneGate:• Static source translation, which translates each single IP address to some other

single IP address (one-to-one relationship).• Dynamic source translation, which translates several IP addresses to a single IP

address or a small pool of IP addresses (many-to-one/many-to-some relationship) differentiated by port.

• Static destination translation, which translates each single IP address to some other single IP address (one-to-one relationship).

• Destination port translation, which translates a port to a different one (one-to-one relationship).

• Both source translation and destination translation for the same connection.These methods are explained in more detail in the next sections.Dynamic destination translation is done automatically as part of the Server Pool feature, see Server Pool Configuration, on page 271.Additionally, when NAT is performed, return address translation is needed to allow reply packets to reach the correct sender or to show the source address that the destination host expects. However, return address translation does not normally need configuration as it is done automatically with the help of connection tracking.

Note – If you have Access rules that turn off connection tracking for some traffic, you cannot use address translation with those connections.

Static Source TranslationIn static source translation (one-to-one source translation), the source IP address of a certain host is always translated using the same specific IP address. Often, the original source address is the actual assigned IP address for a device on an internal network or DMZ. The translation is then done to a public IP address belonging to the public IP address range assigned by the Internet service provider.

194 Chapter 16: Network Address Translation (NAT) Rules

Illustration 16.1 Static Source Translation

In Illustration 16.1, the packet starts out with the source (SRC) and destination (DST) addresses (1). The firewall replaces the source address of the packets with a new source address (2). Connection tracking information is used to automatically translate any reply packets: as the server responds, the destination address in the server’s response (3) is replaced with the original address (4), ensuring that the responses find their way back to the host.You can also define static translation using whole networks. There is still a fixed one-to-one relationship between each original and translated IP address, so the original and translated networks must be of the same size. The addresses map to their counterparts in the other network, for example, if you translate the network 192.168.10.0/24 to 212.20.1.0/24, the host 192.168.10.201 is always translated to 212.20.1.201.

Dynamic Source TranslationDynamic source translation allows translating a large number of original IP addresses to a much smaller pool of translated addresses, even a single IP address.Dynamic source translation, sometimes referred to as hide NAT, is often used to mask the internal networks of a company behind one or a few public, routable IP addresses provided by an ISP.

Illustration 16.2 Dynamic Source Translation

Translated packet

192.168.100.101

Source packet

Static source NAT

Translated packet Reply packet

Internalnetwork

Publicserver

SRC: 192.168.1.101DST: 129.40.1.100

129.40.1.100

SRC: 212.20.1.50DST: 129.40.1.100

SRC: 129.40.1.100DST: 212.20.1.50

SRC: 129.40.1.100DST: 192.168.1.101

192.168.1.101Translation backinto source IP

4 3

21

Translated packet

192.168.100.101

Source packet

Dynamic source NAT

Translated packet Reply packet

Internalnetwork

Publicserver

SRC: 192.168.1.101: 9057DST: 129.40.1.100: 80

129.40.1.100

SRC: 212.20.1.50: 9345DST: 129.40.1.100 : 80

SRC: 129.40.1.100 : 80DST: 212.20.1.50: 9345

SRC: 129.40.1.100 : 80DST: 192.168.1.101: 9057


4 3

21

Overview to NAT 195

Illustration 16.2 shows the process for dynamic source translation. Since dynamic source translation involves multiple hosts using the same IP address (in a many-to-one or many-to-some relationship), the firewall needs some additional information to differentiate the connections when the reply packets arrive. For this, the firewall uses the source port: as each different host makes connections (1), it is assigned a unique port (one of the unreserved high ports) to track its connections (2). Based on the port used in the reply packets (3), the destination is translated to the original source address and port (4).

Static Destination TranslationMost typically destination translation is needed when you have servers behind NAT to translate new incoming connections from the server’s public IP address to the private one. You can use static destination translation for both IP addresses and ports.

Illustration 16.3 Destination Translation

In the example in Illustration 16.3, a host on the Internet connects to a server on the internal network. The host connects to the external, public IP address (1). StoneGate then translates the destination address to the private IP address of the server on the internal network (2). The server sends its response back (3), and StoneGate automatically translates the source address back to the external IP address (4).You can also define static translation for whole same-size networks at once. This works in the same way as in static source translation.

Destination Port TranslationDestination translation can also be used to translate ports. For example, Web traffic to the corporate Web servers on a DMZ would typically come in on port 80. However, an administrator may wish to run the Web service on a non-standard port for security or network management reasons. The original destination port can be translated using static destination port translation with or without destination address translation.

Source packet

192.168.100.101

Translated packet

Static destination NAT

Reply packet Translated packet

Internalnetwork

Externalnetwork

SRC: 129.40.1.200DST: 192.168.1.101

129.40.1.200

SRC: 129.40.1.200DST: 212.20.1.100

SRC: 212.20.1.100DST: 129.40.1.200

SRC: 192.168.1.101DST: 129.40.1.200


43

2 1


Configuration of NATAddress translation is configured as part of the Firewall Policy using NAT rules. NAT rules are configured on the NAT Rules tab inside Firewall Policy and Template Policy elements. Sub-Policies cannot contain NAT rules.

Note – NAT rules are applied only after a packet matches an Access rule and is allowed by the firewall. For return NAT or dynamic NAT to be possible, the Access rule must have connection tracking enabled (default).

Illustration 16.4 Newly Inserted NAT Rule

Illustration 16.4 shows a NAT rule that has just been inserted into a policy. The Source, Destination, and Service cells are set to NONE and they must be changed to something else for the rule to match any traffic. The Used on cell is also used for traffic matching: you can add specific Firewall elements in this cell to make the rule valid only on those firewalls, or you can leave it to the default ANY to make the rule valid on all firewalls where the policy is installed.The illustration below shows the types of elements you can use in NAT rules.

Illustration 16.5 Elements in NAT Rules

The table below explains briefly what each NAT rule cell does (more information is included in the task flow further in this chapter). The columns are presented here in

Source, Destination, and Service are used to match the rule to traffic.

Used on makes the rule match on particular firewalls.

NAT cell defines how the translation is done.


the default order, but you can drag and drop them to your preferred order in your own Management Client.

Considerations for Designing NAT RulesThe basic design principle of NAT rules is the same as in Access rules: the rules are read from the top down, and more specific rules must be placed above more general rules that match the same traffic. The traffic is matched based on the Source,

TABLE 16.1 NAT Rule Columns

Cell Explanation

ID

(Not editable.) Automatically assigned ID number that indicates the order of the rules in the policy. The rules are matched against traffic in the order of the ID numbers. For example, rule 4.3 is the third rule added in this Firewall Policy element to the insert point that is the fourth NAT rule in the upper-level Template Policy element.

Source Elements containing the IP addresses that the rule matches. Both the Source and the Destination defined must match the source and destination of a packet for the packet to match the rule. The Source and Destination cells accept any elements in the Network Elements branch of the All Elements tree.

Destination

ServiceAllows limiting the rule’s scope to a specific protocol (similar to Access rules). The Service cell accepts only Service elements.

NAT

The actual network address translation that is applied to connections that match the rule. You can also set outbound load balancing parameters in this cell (see Outbound Load Balancing NAT, on page 203). If you leave this cell empty, address translation is not applied to matching connections, that is, the rule specifies that NAT is not to be applied to matching connections (to make an exception to the other NAT rules below).

Used onThe firewalls on which the NAT rule is applied. Used for creating NAT rules when a shared policy is used on several different firewalls. The Used on cell accepts only Firewall and Firewall Cluster elements.

Comment Your free-form comment for this rule.

Tag

(Not editable.) Automatically assigned unique identification for the rule. Works as a link between the log entries and the rule that has generated the log entries. The rule tag consists of two parts (for example, @180.2). The first part of the tag is permanent and belongs to only that rule. The permanent part of the tag is followed after a period by the second part that changes whenever the rule is changed.


Destination, Service, and Used on cells. When the first matching rule is found, the NAT defined for the rule is applied and the rest of the NAT rules are ignored. All NAT operations for the same connection must be defined in the same NAT rule (for example, if you want to apply both source and destination translation to a connection).

Note – NAT is applied after an Access rule has allowed the connection but before a routing decision is made. Make sure the Access rules allow the connection with the original (before NAT) addresses, and that the translated (after NAT) addresses are included under the correct interface in the Routing view, if necessary.

Default ElementsThe Default template contains NAT rules that exclude from address translation the communications between the firewall and the Management Server that controls it and the communications from the firewall to the Log Server where the firewall sends its log data. You must not use NAT rules to translate the addresses in these system communications, but define Locations and Contact Addresses instead, see NAT and System Communications, on page 201.

Configuration WorkflowThe following sections provide an overview of the configuration tasks related to configuring and customizing NAT Rules. Detailed step-by-step instructions for configuring the rules can be found in the online help of the Management Client and the Administrator’s Guide PDF, in the section called Policies.

Task 1: Define Source, Destination, and ServiceSource, Destination, and Service are the main matching criteria that determine whether a NAT rule is applied to a connection or not. These are defined in the same way as in Access rules.

Task 2: Define Address TranslationIf a connection matches the rule, the address translation defined in the NAT cell is applied. You can leave the NAT cell empty, if you do not want to apply NAT to any connections that match the rule. Otherwise, this cell allows you to define that the source address, the destination address, or both addresses are translated.Static translation implies a one-to-one relationship. Therefore, in static source and destination translation, the translated address space must be as large as the original address space.Dynamic source translation allows a many-to-one relationship, so that several hosts can use the same IP address. In dynamic translation, a port is reserved for each host that is communicating, so as many hosts can communicate simultaneously using a single IP address as there are ports in the port range you define. However, if the ports run out, translation cannot be done and some of the communications fail. If this


happens, you may need to divide your dynamic translation rule and use an extra IP address for the translation. Naturally, dynamic translation can only be applied to communications that use ports (TCP and UDP based protocols).

Task 3: Define the Firewall(s) that Apply the RuleThe Used on cell in the rule can be used to limit the scope of NAT rules based on the firewall where the rule is installed. This way, you can install the same policy on different firewalls and create NAT rules that take into account the different addressing in the different networks. If you leave the cell empty, the rule is applied on any firewall where the policy is installed.

Task 4: Check Other ConfigurationsTranslated IP addresses are used in routing, in VPN site definitions, and system communications. After adding or modifying NAT rules, you must consider how these areas of communications are affected and what changes are needed. If you are using Multi-Link, Outbound Multi-Links have their own NAT configurations that must not overlap with the NAT rules you define.Particularly, check the following:• Access rules and Inspection rules use the addresses that are seen in the packets

as they arrive on the firewall (as they are before the NAT is done).• Routing decisions are made after NAT, so the routing decision is made using the

translated address. Make sure the translated address is included in the Routing view under the correct interface unless the packets are forwarded to the default gateway.

• If you translate addresses of communications going through VPN tunnels, the translated addresses must be included in the VPN site definitions.

Note – By default, NAT is disabled with connections traversing a VPN (NAT rules are completely ignored for VPN traffic). If you want the NAT rules to apply to connections traversing a VPN, enable NAT in the properties of the VPN element.

Using NAT and NAT RulesThe general configuration of NAT is explained above, but there are certain areas that require special consideration as explained in the sections below:• NAT and System Communications, on page 201• Outbound Load Balancing NAT, on page 203• Proxy ARP and NAT, on page 203• Protocol Agents and NAT, on page 204


NAT and System CommunicationsIf NAT is needed between StoneGate components, you must define Contact Addresses for the communications, so that the StoneGate components use the correct (NATed) address for contact when needed.Contact Addresses are used in a NAT environment for communications of StoneGate components with each other and with some external components that function as a part of the system (such as a RADIUS server used for authenticating Administrators). Contact Addresses may be needed also for site-to-site and mobile-user VPNs.The Default template includes NAT rules which define that NAT is not done for communications between the firewall where the policy is installed and the Management Server and Log Server that the firewall uses. If these connections require NAT, the configuration must be done as explained here. Other system communications traversing the firewall can be translated as any other connections (but Location and Contact Address definitions are usually still needed for those components so that they know the correct addresses to use with each other), see Example of a Situation Where a Contact Address is Needed below.Contact Addresses are defined for Locations, which is an element that represents all devices that are routable behind a particular interface of a NAT device. The components that need Contact Addresses are placed in the Locations according to the Contact Address they use.

Example of a Situation Where a Contact Address is NeededA branch office site, Branch Office 1, has a Log Server that the Monitoring Server needs to contact from the Headquarters site. This (encrypted) StoneGate-internal traffic is routed through the Internet like any other traffic.

Illustration 16.6 Contact Address example

The Branch Office 1 firewall hides all IP addresses in its internal network by NATing the connections. This means, for example, that if there is a Monitoring Server at the Headquarters site, the Monitoring Server cannot use the real, internal address of the


Log Server as defined in the Log Server element, because that address cannot be routed through the Internet.On the other hand, the Branch Office 1 firewall needs to contact the Log Server as well, but using the untranslated address, so the Log Server cannot be defined using just the external, translated address either (that would also prevent licensing the server). A Contact Address needs to be defined so that both the translated and untranslated addresses can be used.In the scenario above, the Headquarters and the Branch Office 2 firewall do not NAT the communications between StoneGate components, so the Administrator has left the Locations for those components undefined, leaving them in the Default Location.Management Clients at the Headquarters and Branch Office 2 sites can contact the Log Server at the Branch Office 1 site without changing the Location setting. They are outside the Branch Office 1 site, so they automatically use the defined (default) Contact Address.However, for a Management Client at the Branch Office 1 site to be able to view logs from the Branch Office 1 Log Server, the Administrator must set the Management Client’s Location to Branch Office 1, so that the contact is made to an internal address without using NAT.

Contact Addresses and LocationsThe Contact Address represents the translated address of a component. Contact Addresses are defined for each Location element. The Location is a way to group components together, in effect telling them that there is no NAT device between them. The contents of a Location are shown in Illustration 16.7

Illustration 16.7 Location for NATed Communications

The system components on each side of a NAT device are grouped into two separate Location elements (if necessary, more Location elements can be used). The Contact Address is defined in each element’s properties for the other Location. When contacting some other component in their own Location, the components always use the untranslated address. When contacting some component outside their own


Location, the contacting component checks if the other component has a Contact Address defined for the contacting element’s Location, and if found, it uses the Contact Address. If there is no Contact Address defined, the connection is attempted using the untranslated address.For example, when a Management Server contacts a firewall node through NAT, the Management Server uses the translated Contact Address instead of the firewall node’s real Control IP address. The NAT device in between translates the NAT address to the firewall’s real IP address as usual.We recommend dividing elements into different Locations based on NAT and the communications the components have, and not just based on actual physical sites. For example, if there is one central site and several remote sites, and the system communications take place only from each remote site to the central site (not between the remote sites), only two Locations are needed no matter how many of the firewalls use a translated address.

Note – If NAT is performed between a Log Server and a Management Client, you may need to select the correct Location for the Management Client as well.

Outbound Load Balancing NATIn addition to source and destination translation, another main use for NAT is outbound load balancing. It is used in a Multi-Link configuration where StoneGate balances outbound traffic between two or more network connections. To be able to direct traffic to the faster connection, the firewall translates outgoing connections to an address from a pool assigned to each available NetLink. In this case, the IP address(es) used for the NAT are defined in the properties of the Outbound Multi-Link element. Outbound traffic management using NAT with Multi-Link Technology is covered in detail in Multi-Link Configuration, on page 263 and Multi-Link Routing for Single and Clustered Firewalls, on page 145.

Proxy ARP and NATProxy ARP (Address Resolution Protocol) is a specification that allows a device to respond to ARP requests on behalf of some other device on the network. When network address translation is used on a firewall, the firewall is typically configured to use proxy ARP so that it can accept packets for the translated addresses. The firewall uses proxy ARP instead of requiring the administrator to assign all of the translation addresses to the firewall’s network interface.In StoneGate, proxy ARP is handled automatically. Proxy ARP is enabled by default in the NAT cell in NAT rules for each translation type, although you have the option to uncheck it, if necessary. Automatic proxy ARP requires that the firewall is configured with an explicit route to the host in question (host/network added in the Routing view).


Protocol Agents and NATProtocol Agents help with problems related to certain complex protocols and NAT. In some protocols, like FTP, IP address information is included in the data payload of the packets, which do not normally include information for routing. Protocol Agents can examine the data payload of packets arriving to the firewall and also modify it. For example, when the source address is included in a packet’s data, the firewall can translate the original source address and also the address embedded in the data. Protocol Agents are discussed in more detail in Protocol Agents, on page 207.

Validating NAT RulesYou can validate the rules in the policy before installing or refreshing the policy on the engines. You can select different criteria for the policy validation. If there are rules that match the selected validation criteria, the Management Client displays a list of the rules and the issues it found in them.

Examples of NATThe examples in this section illustrate some common uses for NAT rules in StoneGate and the general steps on how each scenario is configured.

Dynamic Source Address Translation ExampleCompany A uses private IP addresses that are not routable on the Internet in their internal network. The administrators need to translate the internal IP addresses to IP addresses that are routable on the Internet to make it possible to use external services. The administrators:1. Create an Address Range element “External Addresses” for two consecutive IP

addresses from the pool of addresses that they have been assigned by their Internet service provider.

2. Add a new NAT rule to their Firewall Policy:

• The administrators use the whole range of high ports (1024-65535) for translating the addresses in this case.

• Return address translation is done automatically, so a single rule suffices to cover all (client) hosts that only open connections themselves, and do not need to accept new connections coming from external networks.

TABLE 16.2 Dynamic Translation Rule for Opening Connections to the Internet

Source Destination Service NAT

“$ Local Protected Sites” Alias element

“NOT $ Local Protected Sites” Expression element

ANYSource: Dynamic to External Addresses 1024-65535


3. Refresh the FIrewall Policy. All internal addresses are now hidden behind two IP addresses and a range of ports.

Static Address Translation ExampleIn the first example, Company A set up the firewall to translates the IP addresses of all communications between the internal and the external network dynamically. However, the company also has a mail server, which must be able to accept connections from external networks. For this, it must have a fixed translated IP address. The administrators:1. Create the Host element “Mail Server” to represent the mail server’s private IP

address.2. Create the Host element “Mail Server NAT” to represent the mail server’s public

IP address.3. Add two new NAT rules above the general dynamic translation rule.

• In this case, new connections may be opened both from the mail server and from external hosts, so two rules are necessary.

4. Change the newly added NAT rules as follows:

• The first rule is for connections that the mail server opens to external hosts.• The second rule is for connections that external hosts open to the mail server.• Return address translation is done automatically, so if the connection would

always be opened from one end, a single rule would suffice.5. Refresh the Firewall Policy.

NAT with Hosts in the Same NetworkCompany B has two servers running in the same DMZ network. The servers keep contact with each other to exchange some information. The administrators want to route the traffic through the firewall so that it is logged for reporting purposes instead of letting the servers communicate with each other directly.

TABLE 16.3 Static Translation Rules for Opening Connections Both Ways


“Mail Server” Host element


“SMTP” Service element

Source: Static from Mail Server to Mail Server NAT


“Mail Server NAT” Host element

“SMTP” Service element

Destination: Static from Mail Server NAT to Mail Server

Examples of NAT 205

Illustration 16.8 Company B’s Network Setup

The administrators first intend to just configure the servers to use the external (NAT) address of the other server as a destination and configure the related static destination NAT rule. However, they soon realize that the receiver would see the real source address in the communications and the replies would be sent directly, bypassing the firewall for the reply communications. This would obviously prevent the connections. A static source NAT is required in addition to the static destination NAT.

The administrators:1. Create Host elements to represent the private addresses of the two servers.2. Create Host elements to represent the public addresses of the two servers.3. Add two new NAT rules before any other NAT rule that would match these

connections:

• When the servers are configured to contact each other using the public IP addresses, the communications are routed through the firewall.

• The Firewall translates the destination to the other server’s private IP address and the private IP address of the source to the public IP address to “hide” the private source address from the receiving host. This way, the replies are sent to the public IP address and routed correctly through the firewall.

TABLE 16.4 Static Translation Rules for Opening Connections Both Ways


“Server A Private” Host element

“Server B Public” Host element

ANY

Source: Static from Server A Private to Server A PublicDestination: Static from Server B Public to Server B private.

“Server B Private” Host element

“Server A Public” Host element

ANY

Source: Static from Server B Private to Server B PublicDestination: Static from Server A Public to Server A private.


CHAPTER 17 Protocol Agents

Protocol Agents are special modules for some protocols and services that require advanced processing. The Protocol Agents can enforce policies on the application layer.


Overview to Protocol Agents, on page 208 Configuration of Protocol Agents, on page 209 Using Protocol Agents, on page 211 Examples of Protocol Agent Use, on page 221

207

Overview to Protocol AgentsProtocol Agents are software modules for advanced processing protocols that require special handling on the firewall due to their complexity, address information hidden in the data payload, etc. They can be used to extend the firewall’s Access rules with proxy-like application layer features. Protocol Agents are represented in the Management Client as Protocol elements that have Protocol Agent as their type. Protocol elements also associate the traffic with a certain protocol for inspection against the Inspection rules.Protocol Agents can:• Validate application-level protocol use (e.g. FTP command syntax).• Modify application data when required (e.g. NAT in H.323 data payload).• Open related connections when required (e.g. FTP data connections).• Redirect FTP, HTTP, and SMTP connections to content inspection servers.• Proxy HTTP connections.Some types of traffic always require the use of the correct Protocol Agent to pass the firewall when handled using stateful inspection.

Connection HandlingWhen related new connections are opened based on information exchanged in an initial connection, Protocol Agents may be needed. Protocol Agents are provided to handle the following protocols:• FTP with the related active and passive data connections.• H.323 conferencing protocol communications.• Microsoft RPC for Microsoft Exchange and Outlook communications.• NetBIOS for the Windows NetBIOS datagram services.• Oracle TNS protocol communications.• Remote Shell protocol communications.• SunRPC portmapper communications.• TFTP file transfers.File Transfer Protocol (FTP) is a good example of a protocol that uses two related connections: a control connection and a separately established data connection. If the control connection is allowed without the Protocol Agent, the firewall does not recognize that the data connection is part of an existing connection and handles it like a new connection (which usually leads to failed data transfer).

208 Chapter 17: Protocol Agents

Protocol ValidationProtocol Agents can be used to validate communications against standards of specific protocols. How this exactly works depends on the protocol in question. A few examples:• The FTP Protocol Agent can be set to strictly limit the allowed commands within the

control connection to standard commands as listed in the FTP standards. If other commands are sent in the control connection, the connection is dropped.

• The Oracle Protocol Agent can control the size of the Oracle TNS packets, or the location of the Listener service with respect to the database services.

• The SSH Protocol Agent can ensure that the SSH handshake is performed at the beginning of an SSH connection.

NAT in Application DataProtocol Agents can be used to assist with network address translation in the application data.For example, the H.323 conferencing protocol includes the source and destination address information in the data payload of the packets (as opposed to ‘normal’ traffic where all IP address information relevant to the communications is in the spaces reserved for this in the packet headers). The H.323 Protocol Agent can examine the data payload and modify the addresses according to the network address translation as needed. Therefore, when the source address is included in the protocol data, the source address is also translated in the data payload. The receiving machine will then respond to the proper address.

Configuration of Protocol AgentsThe Protocol Agents are represented in the Management Client by Protocol elements. Protocol elements that have an associated Protocol Agent have “Protocol Agent” as their type. Other Protocol elements are of the type “Protocol Tag”. The Protocol Agent elements represent software modules on the firewall engines that you activate by using a corresponding Protocol element in your configuration.

Illustration 17.1 Using Protocol Agents

As seen in Illustration 17.1, Protocols are not included directly in firewall policies. They are used inside custom Service elements that you create and which can then be used in Access rules. Whenever traffic matches a rule that contains a Service element with an associated Protocol Agent, the Protocol Agent is automatically activated.

Configuration of Protocol Agents 209

All Protocol Agents in the system are default elements, and you cannot change them or add any new ones. There are also default Service elements in the system for most supported protocols that you can use to activate the Protocol Agents. However, some Protocol Agents have parameters and options you can set by creating customized Services as explained below.

Configuration WorkflowThe following sections provide an overview of the configuration tasks related to configuring and customizing Protocol Agents. Detailed step-by-step instructions for configuring the elements and policies can be found in the online help or the Administrator’s Guide PDF, in the section called Elements.

Task 1: Create a Custom Service with a Protocol AgentThere are default Service elements in the system that refer to Protocol Agents that you can use as such in your Access rules. However, the default Services do not allow you to change the default parameters of Protocol Agents that have configurable parameters. If you want to modify the way a Protocol Agent behaves, you must create a new custom Service of your own and attach the correct Protocol Agent to that Service. Also, there are no default Services for redirecting connections to content inspection servers, since this operation requires settings related to each particular environment (see Content Inspection, on page 241).The Service element contains the identifying information, such as a port number, that determines which traffic the Service matches. This alone ensures, in most cases, that the Protocol Agent is not applied to the wrong type of traffic.

Task 2: Set Parameters for the Protocol AgentIf you create your own custom Service that uses a Protocol Agent that has configurable parameters, you can give parameters for the Protocol Agent in the properties of the Service. The Protocol Agents and the parameters you can set are listed in Using Protocol Agents, on page 211.

Task 3: Insert the Service in Access RulesWhether you create a custom Service or use one of the pre-defined Services that have a Protocol Agent attached to them, you must define the traffic the Protocol Agent handles in the Access rules in your Firewall Policies.A Protocol Agent can be set either on a rule-by-rule basis, or you can create a rule with Continue as the rule’s Action. When there is a Continue rule, rules further down in the rule table that match the same traffic (same source and destination) use the Protocol Agent defined in the Continue rule. With Protocol Agents, the Continue rule affects only rules where the Service cell is set to ANY. Any more specific Service definition overrides the Continue rule, as all Service elements either specify some particular Protocol Agent or that no Protocol Agent is used. Some protocols may require a Protocol Agent if Connection Tracking is on for the rule. Those protocols may not be


passed by a rule that have “ANY” as their service unless a Protocol Agent is configured using a previous matching Continue rule. The Default template contains a Continue rule that sets a Protocol Agent to be used with Services in the Service Group called Default Services with Agents.Since Protocol Agents validate the traffic against the specifics of a particular protocol, you must ensure that the Service with a Protocol Agent is not applied to traffic that does not use that protocol. Also, Protocol Agents are designed for particular types of uses, so they may not always be appropriate even if the protocol matches. See below for details of what each Protocol Agent does.

Using Protocol AgentsThere are Protocol Agents for many different protocols, and the purpose of each Protocol Agent depends on the particular demands the protocol in question places on the firewall. This section describes the available Protocol Agents and lists the configurable parameters that they add to Services that use them. When the description below states “There are no configurable parameters for this Protocol Agent”, the Protocol Agent does not have any options, but may still have a control for turning the Protocol Agent on/off in the Service. This control is meant for StoneGate IPS, which may require the Protocol element without the Protocol Agent features in some situations.

FTP AgentOne of the most common ways to transfer files across networks is using FTP. An FTP session starts with a control connection (by default, TCP port 21), and the communications continue using a dynamically allocated port. The Protocol Agent keeps track of the actual ports used so that ports can be opened only as needed for specific connections. This way, the whole range of possible dynamic ports does not need to be allowed in the policy.The FTP Protocol Agent inspects protocol validity. There are two selectable levels of inspection: loose (default) and strict.• In the loose mode, the Protocol Agent tries to identify information for opening the

data connection. The loose mode is needed with some non-standard FTP applications.

• With the strict mode, the protocol integrity can be enforced: all connections with commands that do not comply with the RFC 959 FTP standard are dropped.

The FTP Protocol Agent can modify payload data, if necessary. This may be required to handle NAT correctly.The FTP Protocol Agent can also redirect traffic to an external content inspection server or to any proxy-type solution. For more information on how content inspection servers are used, see Content Inspection, on page 241.The FTP Protocol Agent is platform-independent.


Table 17.1 lists the parameters that the FTP Protocol Agent adds to Service elements that use it:

H.323 AgentH.323 defines a set of protocols as well as the components and procedures for real-time multimedia communication. H.323 consists of a series of different types of standards related to video and audio services, real-time transport, control channels, security, etc.

TABLE 17.1 FTP Protocol Agent Parameters

Parameter Description

Allow active modeAllows active mode FTP connections, where the server opens a data connection to the client.Options: Yes (default)/No

Allow passive modeAllows passive mode FTP connections, where the client opens a data connection to the server. Options: Yes (default)/No

Allow Related ConnectionsAllows control connections to be opened with the data connection.Options: True (default)/False

Control data inspection mode

Indicates which FTP commands are allowed in control connection and how strictly the FTP control data is inspected to validate a connection.Options: Loose (default)/Strict

Highest allowed source port for Active data connection

Limits the range of allowed source ports of data connection on the server side if the FTP server does not follow standard port numbering. If the server uses a standard port, both the lowest and highest port number must be 0. Valid range: 1 - 2,147,483,647 or 0 for both (default 0)

Lowest allowed source port for Active data connection

Limits the range of allowed source ports of data connection on the server if the FTP server does not follow standard port numbering. Value 0 means that the server always uses the port number immediately preceding the destination port.Valid range: 1 - 2,147,483,647 or 0 for both (default 0)

Redirect connections to CISSelects the content inspection server (CIS) to which the connections are redirected. “None” disables redirection (default).


H.323 may open several related connections, which places demands on access control and NAT. The H.323 Protocol Agent’s task is to keep track of the related connections that are opened within the same session. Particularly, if you want the firewall to apply NAT to H.323 connections, you must ensure that the connections use this Protocol Agent.The H.323 Protocol Agent attaches to the Call Signalling Channel (Q.931/H.225.0) connection and allows the related Control Channel (H.245) connection to open. It attaches also to the H.245 connection and allows further related connections (RTP and RTCP) to open, based on the port negotiations on the parent connection.When NAT is applied to the Q.931 connection, the Protocol Agent performs the same NAT to the related H.245 connection and modifies the payload data of the parent connection. The same NAT operation is performed also on the opened RTP and RTCP connections.Table 17.2 lists the parameter that the H.323 Protocol Agent adds to Service elements that use it.

HTTP AgentsThere are three Hypertext Transfer Protocol (HTTP) Protocol Agents:• The HTTP agent can be used for redirecting traffic to an external content inspection

server and to log the URLs from HTTP requests. This agent has parameters you can set in the Service properties.

• The HTTP Proxy agent can be used for redirecting traffic to any proxy-type of software so that the client application does not need to be configured to use a proxy. This agent has no parameters.

• The HTTPS agent can be used for identifying encrypted HTTPS traffic for inspection in the Inspection rules. This agent has no parameters.

The URL logging feature in the HTTP Protocol Agent can be used to log the URLs from HTTP requests.

TABLE 17.2 H.323 Protocol Agent Parameters


Special logical channel supportAllows special H.323 clients to open an audio and video channel through the firewall without a NAT operation.


Table 17.3 lists the parameters that the HTTP Protocol Agent adds to Service elements that use it.

ICMP AgentThe Internet Control Message Protocol (ICMP) is used by the operating systems of networked computers to send error messages. There are no configurable parameters for this Protocol Agent.

MSRPC AgentThe Microsoft Remote Procedure Call (MSRPC) Protocol Agent is meant for communications between Microsoft Outlook clients and a Microsoft Exchange server. Other applications are not supported.The supported end-point mapper (EPM) connection method between the Outlook client and the Exchange server is TCP. By default, the Microsoft RPC/EPM service is available at port 135/TCP and the communications continue using a dynamically allocated port. This protocol agent keeps track of the actual ports used, so that the range of dynamic ports does not need to be allowed in the policy. Microsoft has implemented the RPC service mapping using Endpoint Mapper (EPM) protocol transferred over an RPC. The client sends an inquiry to the EPM service to locate other services. The response sent by the EPM service contains availability information on the requested service on various levels (IP address, protocol, and port information). The MSRPC Protocol Agent monitors the responses and allows related connections based on this information. This Protocol Agent can also be used to NAT related connections and modify the payload data of the control connection accordingly.

TABLE 17.3 HTTP Protocol Agent Parameters


Logging of Accessed URLsDefines whether the URL address used in the communications is logged or not.

Redirect Connections to CISSelects the Content Inspection Server (CIS) to which the connections are redirected. “None” disables redirection (default).


Table 17.4 lists the parameters that the MSRPC Protocol Agent adds to Service elements that use it.

NetBIOS AgentThis Protocol Agent is used to allow Windows NetBIOS Datagram Service connections through the firewall, if required.There are no configurable parameters for this Protocol Agent.

Oracle AgentThis Protocol Agent handles Oracle Transparent Network Substrate (TNS) protocol-based SQL*Net, Net7, and Net8 connections. It is meant for cases where TCP port 1521 is used only for negotiating the port number for Oracle database connections, and the port number for the actual connection is assigned dynamically.This Protocol Agent is needed only if the database is located on a different computer than the Oracle listener. The Oracle Protocol Agent does not modify payload data because the database service connections could go through a different route than the listener connection. You can create custom Oracle agents with different settings when required.

TABLE 17.4 MRPC Protocol Agent Parameters


Allow MS Exchange Remote administration service

Required to enable the remote administration of the Microsoft Exchange server. The Protocol Agent allows the use of the Exchange System Attendant service.

Allow MS Exchange user services

Required to enable the normal use of the Microsoft Outlook client. The Protocol Agent allows the use of Exchange Database service, Directory service, Information Store service, MTA service, and Store service.

Allow Related Connections Allows the response sent by the EPM service.

Allow Unsupported MS RPC Message Types

Allows RPC message types that are not supported by the Protocol Agent to bypass the control connection. No additional related connections are allowed based on these messages.


Table 17.5 lists the parameters that the Oracle Protocol Agent adds to Service elements that use it.

Remote Shell (RSH) AgentRemote Shell (RSH) is a widely used remote management protocol. This Protocol Agent manages Remote Shell connections and RExec connections. RExec is a remote protocol with which it is possible to run commands in another computer.Table 17.6 lists the parameters that the Remote Shell (RSH) Protocol Agent adds to Service elements that use it:

TABLE 17.5 Oracle Protocol Agent Parameters


Allow Related ConnectionsAllows/disallows database connections based on information in the listener connection.Options: True (default)/False

Max. length allowed for one TNS packet

Limits the amount of TCP payload data that each Oracle TNS packet can carry. Valid range is 1 - 2,147,483,647. The default value is 4096.

Netmask for allowed server addresses

Limits Oracle database service addresses allowed to pass the firewall. The value 255.255.255.255 allows to open the database connection only to the address in which the Oracle Listener service was located. The value 0.0.0.0 allows database connections to all addresses. The default is 255.255.255.255.

Set checksum to zero for modified TNS packets

With this setting, the Protocol Agent can reset the header and packet checksum to zero when the Protocol Agent has to modify the packet data. Options: Yes (default)/No.

TABLE 17.6 Remote Shell (RSH) Protocol Agent Parameters


Allow Related ConnectionsAllows standard error (stderr) stream as a response to an RSH command.Options: True (default)/False


Services in Firewall AgentThis Protocol Agent is intended for system services running on the firewalls. It is only intended for the system’s internal use. There are no configurable parameters for this Protocol Agent.

SIP AgentThe Session Initiation Protocol (SIP) agent can be used to handle multimedia connections that use SIP as their transfer protocol (such as voice over IP). Using the agent allows SIP to be used across a firewall that uses NAT. SIP uses TCP or UDP port 5060 to initiate the connection, after which the traffic is allocated a dynamically assigned port. The Protocol Agent keeps track of the actual ports used, so that the whole range of dynamic ports does not need to be allowed in the firewall policy.The SIP agent can be configured to force the client and/or server address used within the SIP transport layer to be used also for the media stream carried over SIP (by default, this is enforced for both the client and the server).Table 17.7 lists the parameters that the SIP Protocol Agent adds to Service elements that use it.

TABLE 17.7 SIP Protocol Agent Parameters


Allow Related ConnectionsAllows the SIP media connections based on the signalling connection.Options: True (default)/False

Enforce client side media

Allows checking that the media stream used over SIP uses the same address as the SIP traffic on the host that is the ‘client’ in SIP communications.Options: Yes (default)/No

Enforce server side media

Allows checking that the media stream used over SIP uses the same address as the SIP traffic on the host that is the ‘server’ in SIP communications.Options: Yes (default)/No


SMTP AgentThe Simple Mail Transfer Protocol (SMTP) Protocol Agent redirects connections to an external content inspection server. Table 17.8 lists the parameter that the SMTP Protocol Agent adds to Service elements that use it.

SSH AgentSecure Shell (SSH) is an encrypted remote use protocol. This Protocol Agent validates the communications to make sure the protocol used really is SSH. The SSH Agent validates SSHv1 only. You can create custom SSH agents with different settings, if required.Table 17.9 lists the parameters that the SSH Protocol Agent adds to Service elements that use it.

TABLE 17.8 SMTP Protocol Agent Parameters


Redirect Connections to CISThe Content Inspection Server (CIS) to which the connections are redirected. “None” disables redirection (default).

TABLE 17.9 SSH Protocol Agent Parameters


Bytes allowed from client before Server ID

Limits how much data the client can send to the server before the server sends its own identification string. Value range: 0 - 2,147,483,647 bytes (default 0)

Bytes allowed from server before Client ID

Limits how much data the server can send to the client before the client sends its own identification string.Value range: 0 - 2,147,483,647 bytes (default 0)

Bytes allowed from server before Server ID

Limits how much data the server can send to the client before the server sends its own identification string.

Value range: 0 - 2,147,483,647 bytes (default 0)

Make Protocol ValidationValidates the communications to make sure the protocol used really is SSH.


SunRPC AgentThe Sun Remote Procedure Call (RPC) Protocol Agent only assists the firewall in Portmapper connections. It makes the handling of RPC program numbers used in the Access rules faster. Only Portmapper connections going through the firewall are assigned this Protocol Agent. This Protocol Agent is not intended for other communications.The Portmapper Protocol Agent collects information about RPC services by interpreting the GET PORT and DUMP PORTS requests and their respective answers. All information it collects is stored in the Portmapper cache.When the packet filter needs to evaluate RPC matches, it consults the Portmapper cache to check if the destination of the packet has the appropriate service defined in the rule. If the cache does not have the requested information available, the packet under evaluation is not let through and a query is sent to the destination host for RPC information. The reply information is stored in cache.There are no configurable parameters for this Protocol Agent.

TCP Proxy AgentThe TCP Protocol Agent is a proxy agent used for TCP connections that need to be closed after a certain amount of idle time. Certain TCP based applications do not properly handle the closing of connections, and leave them open for a long period of time, unnecessarily consuming resources. For such situations, the TCP proxy agent can be used to actively close the connections after a certain idle time. In addition, the TCP Proxy Agent may abort a connection if the closing of the connection does not complete in a specified period of time.This handling of idle connections is different from other connection handling, because without the Protocol Agent, idle connections are removed from the firewall’s records without sending any notices to the communicating parties (according to the general TCP timeout set in the Firewall properties, or an overriding timeout set in the rule that allowed the connection).


Table 17.10 lists the parameters that the TCP Proxy Protocol Agent adds to Service elements that use it.

TFTP AgentThe Trivial File Transfer Protocol (TFTP) Agent performs data transfer from a server to a client using dynamically selected ports. There are no specific limits to the port range in the TFTP protocol (RFC 1350). Apart from Access rules, the TFTP Protocol Agent is also useful in NAT operations.A TFTP Agent is attached to a UDP connection established between the client and the server. The client opens the control connection from a dynamically selected source port to the fixed destination port 69/UDP on the server. A separate UDP data connection is established between the client and the server after the client has sent a “read” or “write” command to the server. The server opens a data connection from a dynamic source port to the client’s destination port, which is the same as the one used as the source port in the control connection.

TABLE 17.10 TCP Proxy Protocol Agent Parameters


Abort on close

Defines whether the abort operation in the TCP protocol is executed when a connection is not closed completely in time. When the abort operation is used, the TCP Proxy agent sends TCP Reset packets to those endpoints that have not responded to the close operation, thus aborting the TCP connection. The value zero indicates that aborting is disabled. A positive value indicates the number of seconds to wait for the close operation to finish before aborting.

Idle timeout

Defines the idle time-out in seconds. After the idle time-out the connections are closed. The default value is 1500 seconds (25 minutes). The value zero means no time-out.

Use Proxy Defines whether the TCP proxy is used.


Table 17.11 lists the parameters that the TFTP Protocol Agent adds to Service elements that use it.

Examples of Protocol Agent UseThe examples in this section illustrate some common uses for Protocol Agents in StoneGate and the general steps on how each scenario is configured.

Preventing Active Mode FTPCompany A has an FTP server that allows access from the Internet. According to company policy, the firewall must restrict users to passive mode FTP connections.The administrators:1. Create a new Service element for passive FTP.2. Attach the FTP Protocol Agent to the Service.3. Change the active mode FTP setting to No in the Service properties.4. Create an Access rule that allows users to connect to the FTP server using their

custom-made Service element.

Logging URLs Accessed by Internal UsersCompany B decides to keep track of which web pages the employees visit. In addition to logging the connections, the administrators want to also log URLs. The access is currently controlled by a simple rule that allows all outbound connections from the internal networks to the Internet regardless of the service, so the administrators decide to add the HTTP Protocol Agent in a Continue rule.

TABLE 17.11 TFTP Protocol Agent Parameters


Allow ‘read’ requestsControls whether file transfer from server to client is allowed. Options: Yes (default)/No.

Allow Related ConnectionsAllows replies to TFTP requests. Options: True (default)/False.

Allow ‘write’ requestsControls whether file transfer from client to server is allowed. Options: Yes (default)/No.

Log file names and pathsControls whether names of transferred files and their paths are written to log. Options: Yes/No (default).

Examples of Protocol Agent Use 221

The administrators:1. Add the Continue rule above the existing Access rule like this:

• Using the “NOT Local Protected Sites” expression requires that the Alias “Local Protected Sites” has been configured with a translation value for the firewall in question.

2. Refresh the firewall’s policy.

TABLE 17.12 Example Rules for Company B

Source Destination Service Action

Internal NetworksExpression “NOT Local Protected Sites”.

“HTTP (with URL Logging)” default Service.

Continue

Internal NetworksExpression “NOT Local Protected Sites”.

ANY Allow


CHAPTER 18 User Authentication

User authentication in the context of StoneGate means requiring the users of services in your network to authenticate themselves (for example, by providing a username and password) before they are given access to some resources.


Overview to User Authentication, on page 224 Configuration of User Authentication, on page 226 Using Authentication, on page 232 Examples of User Authentication, on page 233

223

Overview to User AuthenticationAuthentication means requiring users to prove their identity before giving access to a network resource. Authentication is mandatory with client-to-gateway VPNs, but you can require authentication for non-VPN connections as well. The Access rules in the Firewall Policies define which connections require authentication and which do not.By default, authentication is not required for users who access resources through SOHO Firewalls. The right to use the resources depends on the interface definitions in the SOHO Firewall properties. The hosts belonging to the network defined for the Corporate interface are allowed access to the corporate network and the Internet, whereas the hosts belonging to the network defined for the Guest interface are only allowed access to the Internet. However, if wireless connections are allowed with the SOHO Firewall, you can define RADIUS authentication for the corporate and guest users in the SOHO Firewall properties (see SOHO Firewall Configuration, on page 103). To make authentication possible, the information regarding the users must be defined and stored. You can store this information in StoneGate’s internal user database, or you can store it on an external server. StoneGate can connect to an external LDAP server (such as Microsoft Active Directory) so that you can use the user information for creating rules. Authentication is done based on the user information, but is always a separate operation and is not necessarily done on the same server that stores the user information. Also, different users can be stored in different databases and use different authentication methods.

224 Chapter 18: User Authentication

The following table explains the possible configurations for user authentication:

StoneGate can be configured to use external authentication services such as RSA Authentication Manager (formerly known as ACE/Server) or Microsoft Active Directory servers.If you prefer, you can use the same server for storing and authenticating the users, for example, when you use StoneGate’s internal services or a Microsoft Active Directory server for both tasks. Still, when an external server is used, the user information is queried first using LDAP (if StoneGate is defined to query the user information), and then the authentication is done in a second operation.The users can authenticate by connecting to the StoneGate firewall via Telnet, or by using the Authentication Client (a separately installable part of the StoneGate VPN Client). With the Authentication Client, the authentication dialog can be configured to pop up automatically when needed. Otherwise, the users must manually launch the authentication before they can use protected services.

TABLE 18.1 Combinations of Internal and External User Databases and Authentication Servers

Authentication Server

Internal External

Use

r D

atab

ase

Internal

User and User group information is maintained using the Management Client and can be used for creating rules. Authentication can be done with password, IPsec certificate, or pre-shared key.

This alone is not a valid configuration. To make the configuration work, a second, external user database is required because the external authentication server has no access to the internal database. The same user information is maintained separately in StoneGate and the external user database. User and User Group information can be used for creating rules. Any authentication method supported by the external authentication server can be used.

External

StoneGate is defined as an LDAP client for the external server. User and User Group information is shown in the Management Client, and can be used for creating rules. Authentication can be done with password, IPsec certificate, or pre-shared key.

It is optional to introduce the user information to StoneGate. To do this, define StoneGate as an LDAP client as in the table cell on the left, or manually maintain the information in two databases as in the table cell above.If you do not make the user information available to StoneGate, each authentication rule includes all users. There can be several rules, but any user that can authenticate in one rule can authenticate also when any of the other rules is triggered.Any authentication method supported by the external authentication server can be used.

Overview to User Authentication 225

Configuration of User AuthenticationIn StoneGate, user information is stored in an internal or an external LDAP (Lightweight Directory Access Protocol) database. The standard LDAP user management model consists of three different levels: domains, user groups, and users. Each of the three levels are represented in StoneGate as elements.Authentication services define the authentication method used by particular users and user groups. StoneGate supports the following authentication services:• User passwords.• IPsec certificates (for use with VPN clients).• Pre-shared keys (for use with some third-party VPN clients).• Authentication provided by servers that support the TACACS+ protocol.• Authentication provided by servers that support the RADIUS protocol.Both internal and external LDAP servers can be used for simple password authentication (in addition to storing the user information). If you use an external authentication server, multiple authentication methods are available, such as one-time passwords and token cards.Illustration 18.1 shows how user authentication elements are configured.

Illustration 18.1 Configuring User Authentication

External authentication servers are configured as Authentication Server elements in the system. They are then used for defining Authentication Services. The Authentication Service defines the allowed authentication methods for Access rules and for the Users and User Groups. The Authentication Service is needed in the Access rules to define which service is used for which rule when the Users and User Groups have several allowed Authentication Services. The User and User Group elements can both be used in Access rules, allowing you to define the access rights flexibly.

User DatabasesStoneGate provides an integrated LDAP database for storing user information and for authenticating the users with password authentication. The internal LDAP directory is the simplest choice when there is no specific need to have an external LDAP server.


When StoneGate’s internal LDAP database is used, the user and group information is stored on the Management Server. Each firewall node stores a replica of the user database, and any changes to the main database are replicated immediately to the firewalls. This way, the firewalls can access their local directories instead of constantly communicating user information over the network.Alternatively, an external LDAP directory can used. In this case, the StoneGate uses its integrated LDAP client to query the external LDAP directory. The Users and User Groups are shown in StoneGate as elements, which can be inserted into Access rules. The External LDAP directory is not replicated into the internal directory on the Management Server nor into the local directory of the firewalls. Instead, the external LDAP is queried directly by the Management Server when you view the User elements and by the firewalls when a user attempts to authenticate.Regardless of whether you use the internal or an external LDAP database, the user and user group information can be viewed through the Management Client. The information shown depends on your set up, but the tree will always look similar to the tree for the internal LDAP database in the illustration below.

Illustration 18.2 Domains, User Groups, and Users in the Element Tree

As with other element branches, the individual User elements are not shown in the tree view, but are displayed in the other panel when you select a User Group.Using an external LDAP server may require that the StoneGate specific classes and attributes are added to the external LDAP directory. See Schema Updates for External LDAP Servers, on page 457.

Note – It is not possible to give external components (such as authentication servers) access to the internal LDAP database.

You can also leave StoneGate out of user management, so that It is up to the external authentication server to check the supplied information and report back to StoneGate whether authentication succeeds or fails. In this configuration, it is not possible to add different Access rules for different users and user groups, as StoneGate has no access to this information.

Branch for user-related elements (under the Firewall Configuration branch).

Domain (default domain for internal LDAP database).

User Group (default group for VPN users).

DC of the User Group.


Authentication ServicesStoneGate uses the RADIUS or TACACS+ back-end protocols to communicate with external authentication servers. Many third party authentication products support these protocols, so you can choose among many different authentication methods.Illustration 18.3 shows how the firewall authenticates a user using an external authentication server. The process is the same even if the LDAP database and authentication service are provided by the same physical server, and when the users are stored in the internal LDAP database.

Illustration 18.3 Using External LDAP and Authentication Server

1. The user sends an authentication request to the firewall.2. The firewall contacts an external LDAP server or looks the user up in its local

version of the internal user database to check the user’s authentication method. If no authentication services are specified for an individual user, the user is authenticated using the authentication services specified for the group to which the user belongs.

3. If the authentication services defined for the user or group are allowed in the Access rule, the engine connects to the authentication server.

4. If the authentication succeeds, the current or upcoming connection or the client IP address is given access, according to what is defined in the Access rule. If the authentication fails, the connections that match the rule are dropped.

Default ElementsThere are default elements in the system that help you start using the internal user authentication tools. The internal LDAP server’s domain is pre-defined as InternalDomain and contains the pre-defined User Group Mobile VPN Users.

External LDAP server

Name : “Auth. : RADIUS

User

Name : “toto”

UserUser

Firewall

Authentication requestUser = “toto”Password = ********

Authentication server (RADIUS)

User = “toto”Password = ********

Authentication result

User

Authentication andauthorization result

1

2 3

4


There are also four pre-defined Authentication Services:• IAS Authentication is for use with an external Active Directory server.• IPsec Certificate is for VPN client authentication.• Pre-Shared Key Method is for use with some third-party VPN clients.• User Password is for simple password authentication against the internal LDAP

database.If you want to use the internal LDAP database for storing user information, you must add the User Group and User elements in the pre-defined domain. If you want to use the internal tools for authentication, you must use one of the pre-defined Authentication Services that are configured for internal authentication.

Configuration WorkflowThe following sections provide an overview of the configuration tasks related to configuring and customizing User Authentication in StoneGate. Detailed step-by-step instructions for configuring the elements and policies can be found in the online help of the Management Client and the Administrator’s Guide PDF, in the section called Policies.The configuration of RADIUS authentication for wireless users in SOHO Firewalls is explained in SOHO Firewall Configuration, on page 103.

Task 1: Create an External Authentication Server ElementIf you want to use an external authentication server instead of using one of the authentication methods supported internally in StoneGate, you must create an Authentication Server element. There are separate Authentication Server elements for RADIUS and TACACS+ compatible authentication servers. The server element is used for defining the information that StoneGate needs to contact the authentication server, such as the IP address and shared secret.If you use a Microsoft Active Directory server to store and authenticate users, you can define an Active Directory Server element instead of separate LDAP and Authentication Server elements.In addition to the StoneGate element configuration, you must naturally configure the authentication server to allow the firewalls to use the authentication services.

Task 2: Create an External LDAP Server ElementIf you want to use an external LDAP server, you must define the parameters for contacting the server and the LDAP object classes in the form of an LDAP Server element, unless you are using an Active Directory server and define both the authentication and user directory parameters in the combined Active Directory server element.


Task 3: Create an Authentication Service ElementIf you are using an external authentication server, you must define a new Authentication Service to represent it in user properties and Access rules. The Authentication Service also allows you to group more than one Authentication Server of the same type together to create an Authentication Service where an alternative server is used if the first contacted server does not respond. If alternative servers are listed, all servers must contain information on all authenticating users, since if a server responds that a user is unknown, the connection is dropped.The Authentication Services for all forms of internal Authentication are already pre-defined in the system. There is also a pre-defined Authentication Service for IAS that is for use with an Active Directory server.

Task 4: Add a DomainWhen using the internal user database user management, the only domain under which users and groups can be managed is StoneGate’s InternalDomain. This internal StoneGate domain is generated automatically by the system.If you are using an external LDAP directory for user management, you must create a new domain. After the domain is associated with the external LDAP server, the users and user groups can be viewed and edited through the Management Client.One domain can be selected as the Default domain, which allows users belonging to that domain to authenticate without specifying the domain information. Users in other domains must specify their domain whenever they authenticate themselves.

Task 5: Add Users and User GroupsTo implement user authentication, you must define user accounts either in the internal database or on an external server. It is not necessary to integrate an external database with StoneGate, if you are using an external authentication server and it is not necessary to define different access rights to different users. In that case, you can create a special User element with the name *external* (in the internal user database) to represent any user that authenticates using the external authentication service.Users are created as members of a User Group. This saves time and effort as you avoid having to specify all user parameters separately for each individual User. A User that is a member of a User Group can inherit, for example, the Authentication Service and account expiration time from the User Group. Each User Group must belong to a Domain.We recommend that user accounts be used by a single person. You can create Users to any User Groups under either the internal StoneGate domain or any external LDAP domain. Each User can belong to several User Groups. User-specific properties can override properties defined at the User Group level.You can import and export Users and User Groups to/from the internal user database through an LDIF file to transfer the information to/from an external LDAP database.


Task 6: Add Authentication to Access RulesAny of the Access rules in a firewall policy can be configured to require the user to authenticate before allowing connections. With client-to-gateway VPNs, some form of authentication is always mandatory.The authentication parameters are defined in the Users and Authentication cells.

Illustration 18.4 Authentication Field in the Access Rules

After authenticating the user, the rule can authorize access from the client IP address for a defined duration, or the specific connection that required authentication.

Note – If only authentication is used in the Allow rule, the traffic is only authenticated but not encrypted. Use Mobile VPN instead to encrypt the traffic in addition to the authentication.

The user can authenticate by launching a separate authentication connection using Telnet from the client to the firewall (for example, by running a script you prepare), or the firewall can prompt a connecting VPN client for user authentication. The Firewall initiated authentication can be used only with the Authentication Client, a component in the StoneGate VPN Client. If the full VPN Client is not needed, the Authentication Client can be installed stand-alone without the VPN features.

Caution – The username and password are transported as cleartext. If you require authentication from users connecting through the Internet or some other insecure network, we recommend setting up an external authentication service that uses disposable passwords. Certificate-based (hybrid) authentication is a more secure alternative that is used on StoneGate VPN Clients (since it is difficult for unauthorized parties to procure a valid certificate).

After authenticating the user, the firewall can authorize access from the client IP address for a defined duration, or the specific connection that required authentication.With authorization for Client IP, the IP address of the remote system is granted access through the firewall for a specific period of time. This allows any number of connections from the client during this period. The disadvantage of the client IP authorization is that all connections are authorized from the source IP address. If the client is a multi-user system, the user must be only authorized for the given connection. Client IP authorization must be used with client-to-gateway VPNs and it can be used with Telnet-based authentication. With authorization for the Connection, access is given to one connection through the firewall from a successfully authenticated client. The user has to authenticate again


for the next connection. Current connection authorization can be used with Telnet based authentication but it cannot be used with mobile-user VPNs.

Using AuthenticationStoneGate supports many third-party authentication services. You can integrate your third-party authentication products with StoneGate through the RADIUS and TACACS+ protocols.With simple password authentication, you can use the internal or an external LDAP server to store the user and password information. Alternatively, you can use any external RADIUS or TACACS+ compatible server as authentication service for any user. One-time passwords require using either RADIUS or TACACS+ for authentication. The RADIUS or TACACS+ authentication service is selected based on the user information in the internal or external LDAP directory as usual.

RADIUS AuthenticationRemote Authentication Dial-in User Service (RADIUS) is a protocol for carrying authentication, authorization, and configuration information. RADIUS is a widely supported standard. For example, Microsoft Active Directory server and RSA Authentication Manager (formerly known as ACE/Server) support the protocol and can be used for user authentication in StoneGate.RADIUS uses UDP as its transport protocol. The exchanges between the client and the RADIUS server are authenticated through the use of a shared secret, which is never sent over the network. User passwords transferred between the client and the RADIUS server are encrypted using the MD5 message digest algorithm. The rest of the RADIUS communications are in cleartext.When a connection that requires authentication is attempted, the firewall requests the user information from an LDAP server. If the user attributes specify that RADIUS is used to authenticate the user, StoneGate requests authentication from the defined RADIUS server. StoneGate then allows or denies access based upon the response it gets from the RADIUS server. It is possible to define more than one authentication server for high availability. If for some reason the primary RADIUS server becomes unreachable, the next server in the authentication service list is contacted after a timeout or specified number of retries. Authentication servers can be located on any network, but you must make sure the firewall that has the authentication rule in its policy can connect to the server.The same RADIUS servers can also be used to authenticate the administrators’ login to StoneGate (see RADIUS Authentication, on page 92) or to authenticate wireless users in SOHO Firewalls (see SOHO Firewall Configuration, on page 103).


TACACS+ AuthenticationTACACS+ is a protocol used for similar purposes as RADIUS. In general, TACACS+ provides a more secure method of user authentication than RADIUS. This is mainly because TACACS+ uses TCP as the transport protocol instead of UDP. Consequently, transport is more reliable and less sensitive to disruption at the network layer communications. TACACS+ also separates authentication, authorization, and accounting services, whereas RADIUS provides a user profile defining all the user-specific parameters with the authentication. This separation of services allows TACACS+ to use other forms of authentication, such as Kerberos, together with its own authorization.TACACS+ uses a pre-shared key to authenticate exchanges. TACACS+ encrypts all traffic between the authentication server and the device requesting authentication. User information, such as IDs and passwords, are secured with the MD5 message digest algorithm.

Examples of User AuthenticationThe examples in this section illustrate some common uses for User Authentication in StoneGate and general steps on how each scenario is configured.

Using the Internal Database for Authenticating UsersCompany A have a general office network and a separate network for servers that contain HR information, such as employee records and payroll information. The servers restrict the users who have access, but for auditing reasons, the administrators want to make anyone accessing the network to authenticate. The administrators:1. Create a User Group “HR users” in the InternalDomain and assign the User

Password authentication service as the authentication method.2. Create User elements for each person with access rights with the User

Password authentication method selected.3. Add an Access rule with authentication defined as shown below.

TABLE 18.2 Example Access Rule for Internal LDAP Authentication

Source Destination Users Authentication

Network element for general office network

Network element for HR network

“HR Users” user group.

Require authentication with “User Password” Authentication Service.


Using StoneGate with a Microsoft Active Directory ServerCompany B has an existing Microsoft Active Directory server that stores user information. They decide it makes sense to use this existing information for user authentication in StoneGate.The administrators:1. Define an Active Directory Server element.2. Enter the StoneGate-specific classes and attributes into the Active Directory

server’s configuration to be able to fully manage the user accounts through the Management Client.

3. Define StoneGate as an LDAP client for the Active Directory server.4. Define StoneGate as an authentication client for the Active Directory server.5. Add Access rules with authentication defined as shown below.

Note – Even though the user information and authentication is done by the Active Directory server, the user must still authenticate separately to access protected resources, even if the username and password are the same that are used for Windows logon.

Using SecurID Authentication with StoneGate VPN ClientsCompany C is about to introduce remote StoneGate VPN Client access to their network. The administrators want to enhance the security of their authentication solution, as authentication is currently done using an external LDAP server and Telnet clients within the internal network. They decide to add the use of one-time passwords with SecurID cards with their existing RSA Authentication Manger server that already shares the user information in the company’s LDAP server.

TABLE 18.3 Example Access Rule for IAS Authentication

Source Destination Users Authentication

Some Host or Network elements


Some User or User Group elements.

Require authentication with “IAS Authentication” Authentication Service.


Illustration 18.5 Company C’s Authentication Scheme

The administrators:1. Create an Agent Host record for StoneGate in the RSA Authentication Manager

server.2. Create a VPN configuration in StoneGate with the default Hybrid Authentication

selected as the authentication method for connecting clients.• Hybrid authentication, available for StoneGate VPN Clients, requires that the

VPN Client has a valid certificate (validated by the firewall) in addition to the user providing the correct Username/Password combination (validated by the RSA Authentication Manager server).

3. Create an Authentication Server element with RADIUS selected as the authentication method.

4. Create a custom Authentication Service element for the server, naming it “SecurID”.

5. Add the “SecurID” Authentication Service in the correct User and User Group elements (stored on the existing external LDAP server).

6. Add VPN Access rules with authentication defined as shown below.

TABLE 18.4 Example Access Rule for SecurID Authentication

Source Destination Users Authentication Action



Some User or User Group elements.

Require authentication with “SecurID” Authentication Service.

“Use VPN” with the “Enforce VPN” option.



CHAPTER 19 Virus Scanning

A virus scanner, part of the StoneGate UTM solution, compares parts of the network traffic against a virus signature database to look for viruses. If a virus is found infected traffic is stopped or infected content is stripped out.


Overview to Virus Scanning, on page 238 Configuration of Virus Scanning, on page 238 Using Virus Scanning, on page 239

237

Overview to Virus ScanningA virus scanner is available as a part of the StoneGate UTM solution. Virus scanning is a resource-intensive activity and is practical mainly in branch-office-type settings, where there is a need to keep the physical setup as simple as possible with the minimum amount of equipment on-site.The virus scanner can inspect HTTP, IMAP, POP3, and SMTP protocol traffic. If the virus scanner detects infected files, it strips them out. If an e-mail attachment is filtered out, a message is added to the e-mail notifying the recipient. The internal virus scanner does not inspect traffic sent through VPNs.Virus scanning is alternatively available (on all firewall/VPN engines) when you set up an external virus scanner and integrate it with StoneGate by configuring the external server as a content inspection server (CIS), see Content Inspection, on page 241 for more information.

Configuration of Virus ScanningSetting up virus scanning is simple: you activate the virus scanning in the Firewall element properties and then you use the Access Rules to select the traffic that you want scanned.

Configuration WorkflowThe following sections provide an overview of the configuration tasks related to configuring and customizing virus scanning. Detailed step-by-step instructions for configuring the elements and policies can be found in the online help or the Administrator’s Guide PDF, in the section called Policies.

Task 1: Activate the Anti-Virus Feature for a FirewallTo activate virus scanning, you must have the StoneGate UTM solution. The anti-virus settings in the Firewall element properties allow you to add mirrors for downloading virus signatures and change the settings for logging the viruses found in network traffic.

Task 2: Select Traffic for Inspection with Access RulesTo inspect traffic for viruses, you must activate the virus scanning for the traffic you want inspected. Virus scanning is available for traffic that uses the HTTP, IMAP, POP3, or SMTP protocols. You activate anti-virus scanning in the rule options separately for each Access rule. Activating the anti-virus scanning always also activates the deep packet inspection for the same traffic (the traffic is also checked against the Inspection rules). This setting must always be selected for each rule individually (Continue rules cannot be used to set this option for other rules).

238 Chapter 19: Virus Scanning

Using Virus Scanning

Integrated Scanning vs. a Content Inspection ServerIn branch-office-type environments where there may be no skilled administrators, a centrally managed virus scanning solution on the same hardware with the firewall makes maintenance easier than having separate equipment. The virus scanning is needed when there is direct Internet connectivity at the site (instead of having only VPN connectivity to a central site where the traffic can be scanned centrally).Virus scanning directly on the firewall is not practical in high-traffic environments. The amount of data gathered for virus scanning is large, since files must be inspected as a whole to prevent any part of the infected content from passing through. Storing and scanning files significantly increases the demand for resources as the volume of traffic grows. In high-traffic environments, a separate content inspection server (CIS) integrated with the firewall is a more economical and flexible solution (see Content Inspection, on page 241) than a UTM device.

Limitations of Virus Scanning on ClustersFirewall/VPN clusters that are correctly licensed can be used for virus scanning. However, there are some restrictions that apply. Load-balanced (active-active) clustering is not supported: the data collected for anti-virus scanning is not synchronized between the nodes and standby clustering must be used to ensure that all parts of inspected traffic pass through the same node, since load-balanced clustering may in some cases result in even the same connection being split between the nodes. Standby clustering should be sufficient for the intended use as a UTM solution for low-traffic remote offices while still providing continued network access if a node is taken offline. Since the data being inspected is not synchronized between the nodes, connections that are undergoing virus scanning at the time of a fail-over are dropped when the fail-over occurs and must be reopened by the applications.

Using Virus Scanning 239

240 Chapter 19: Virus Scanning

CHAPTER 20 Content Inspection

Content inspection means analyzing the content of e-mail messages, the web pages your users access, and other such traffic to check and strip out viruses or to filter traffic, for example, by comparing access requests to lists of forbidden URLs.


Overview to Content Inspection, on page 242 Configuration of Content Inspection, on page 243 Using Content Inspection, on page 245 Example of Content Inspection, on page 247

241

Overview to Content InspectionContent inspection includes a wide range of different ways to check traffic - many of which you can utilize in a simpler way by integrating an external content inspection server solution with your firewall. The integration involves setting up your firewall to redirect traffic to an external content inspection server of your choice. The main benefit in using the firewall to redirect traffic to a separate content inspection server is that the redirection works transparently: the communicating hosts need no additional proxy configuration when the redirection is done for them at the firewall.Content inspection servers are most typically used for virus scanning and content filtering, but the available applications are not limited to those. Using an external content inspection server allows you to expand the capabilities of the firewall with virtually any type of content screening to perform tasks, for example, stripping certain types of attachments out of e-mail messages without blocking the message itself. This type of anti-virus checking is available directly on the firewall as well (as part of the StoneGate UTM solution), but an external content inspection server is a better option in medium to high throughput environments (see Integrated Scanning vs. a Content Inspection Server, on page 239 for some guidelines). SOHO Firewalls cannot forward traffic to a content inspection server.

Illustration 20.1 content inspection server Redirection

Illustration 20.1 shows how a client’s connection to a server is redirected from the firewall to the content inspection server. Connections arriving at the firewall are checked against the firewall’s policy. Access rules determine which connections are redirected to the defined content inspection server for inspection. The content inspection server then handles the traffic according to its policies. Finally, the content inspection server opens a connection through the firewall and onwards to the original destination. Replies are received with the content inspection server’s IP address, so those are also redirected to the content inspection server for screening.The content inspection server is used as a transparent proxy, so the client and server are not aware of the redirection and they require no additional configuration. The firewall uses NAT (network address translation) to forward the connections to the external content inspection server.

242 Chapter 20: Content Inspection

Configuration of Content InspectionFTP, SMTP, and HTTP traffic can be redirected to content inspection servers for inspection. This is done with the help of Protocol Agents.

Illustration 20.2 Elements for content inspection server Redirection

Illustration 20.2 shows how content inspection server redirection is configured. A custom Service element and a content inspection server (CIS) element are needed. A Service redirects connections for content inspection when one of the existing default Protocol elements of the type Protocol Agent (redirection is available for FTP, HTTP, or SMTP) is attached to the Service. The Service element contains a parameter that defines which content inspection server inspects the connection. The Service can be inserted to any number of Access rules in the Firewall Policy to select traffic to be redirected to the content inspection server. There can be several different Services for content inspection server redirection, if you have several content inspection servers.The Protocol Agent redirection allows using the content inspection server as a transparent proxy, thus requiring no additional configuration on the client machines. The redirection is fully transparent to both the client and the server. The Protocol Agent translates the destination address automatically to the content inspection server’s address to redirect the traffic. The content inspection server then functions as a proxy by establishing the forward connection to the actual destination address.In addition to translating the real destination address to the content inspection server address for redirection, the source address is also translated for handling the content inspection server redirection on the firewall. The translated source address can be any address that is routed back from the content inspection server to the firewall (so that replies are correctly handled). Further address translation can be applied to the connection from the content inspection server to the communications destination.

Configuration of Content Inspection 243

Default ElementsA Protocol of the type Protocol Agent is needed for content inspection server redirection. All Protocol Agents are always default elements. There are three Protocol Agents that can redirect connections to a content inspection server:• FTP for file transfer protocol file transfers.• HTTP for hypertext transport protocol connections used in Web browsing.• SMTP for simple mail transfer protocol for e-mail.Additionally, the default Services for the three supported protocols can be used when allowing connections that the content inspection server opens for the redirected traffic.

Configuration WorkflowThe following sections provide an overview to the configuration tasks related to configuring and customizing content inspection. Detailed step-by-step instructions for configuring the elements and policies can be found in the online help or the Administrator’s Guide PDF, in the section called Policies.

Task 1: Create a CIS Server ElementThe CIS Server element defines the content inspection server’s IP address and the services and ports that the content inspection server handles.

Task 2: Create a Custom Service for Content Inspection Server RedirectionA custom Service element is always needed for content inspection server redirection. When you attach a Protocol that supports content inspection server redirection, you can activate the feature by attaching the correct CIS Server element to the Service.The (mandatory) source address translation for the redirected connections is defined in the Service - these addresses are what the content inspection server sees as the connection originator. Any additional address translation for the traffic must be configured for the connections from the content inspection server when the proxy connections are opened through the firewall.

Note – There must not be any NAT rule that would match the same traffic that is being redirected to the content inspection server.

Task 3: Define Access Rules for RedirectionConnections are redirected through Access rules that match the connections that you want redirected to a particular content inspection server. To activate redirection for a rule, you attach your custom Service element for content inspection server redirection. The redirection rule must always have connection tracking on (which it is by default for all new rules), since connection tracking is required for the mandatory address


translation. Otherwise, these rules have the same matching possibilities and options as any other Access rules. Both incoming and outgoing connections can be redirected.Two Access rules may be needed for content inspection server redirection:• One rule for the original connection from the client.• A second rule for the new connection that proxy-type content inspection servers

open to the actual destination.

Task 4: Configure NAT Rules for Content Inspection Server RedirectionNAT rules must usually be adjusted for content inspection server redirection. The Protocol Agent handles the translation of addresses when forwarding the traffic from the firewall to the content inspection server and there must not be overlapping address translation defined for these connections in the NAT rules. A matching rule with an empty NAT cell may be needed to ensure other NAT rules do not match to these connections.Any NAT you want applied to proxy connections opened by the content inspection server must be done using normal NAT rules.

Note – Ensure that no destination NAT is done for the traffic that is to be redirected to a content inspection server. If necessary, create a matching NAT rule with no NAT (empty NAT field in the rule). Otherwise, the traffic is not redirected to the content inspection server.

Using Content InspectionThe main benefit in redirecting traffic to a separate content inspection server is that it works transparently: the communicating hosts need no additional proxy configuration when CIS redirection is used. However, the redirection uses NAT, which may sometimes cause problems if you want the CIS to treat traffic differently based on IP address. In such cases, it may be necessary to configure the CIS server traditionally on the clients instead of using StoneGate’s redirection feature.To illustrate how the connections are handled, the following table shows an example of what are the source and destination IP addresses used in redirected connections at different stages. This example may be useful when planning the Access rules. The client’s translated IP address in the redirection must be different from the public translated IP address normally used for the client’s Internet connections. There are two different connections: one connection between the client and the content

Using Content Inspection 245

inspection server, and a second connection between the content inspection server and the server that is the target of the client’s connection.

This scenario requires two Access rules (one for each connection) and one NAT rule (for the connection between the content inspection server and the target server). To see how these types of communications are reflected in firewall Access and NAT rules, see Example of Content Inspection, on page 247.Alternatively, anti-virus features are available directly on the firewall for low-traffic environments as part of the StoneGate UTM solution (separately licensed feature), see Virus Scanning, on page 237 for more information. Also, limited URL filtering is available as part of the deep packet inspection features (hardware permitting).

TABLE 20.1 Addresses Used in Content Inspection Server Redirection

Communication Source IP Address Destination IP Address

Client to firewall Client’s private IP address Target server’s public IP address

Firewall to CIS Client’s translated IP address Target server’s public IP address

CIS to firewallContent inspection server’s private IP address

Target server’s public IP address

Firewall to serverContent inspection server’s public IP address

Target server’s public IP address

Server to firewall Target server’s public IP addressContent inspection server’s public IP address

Firewall to CIS Target server’s public IP addressContent inspection server’s private IP address

CIS to firewall Target server’s public IP address Client’s translated IP address

Firewall to client Target server’s public IP address Clients private IP address


Example of Content InspectionThe example in this section illustrates a common use for content inspection in StoneGate and general steps on how the scenario is configured.

Inspecting Internal User’s Web Browsing and File TransfersThe example company has decided to screen out non-work-related connections using an external content inspection server that can screen the HTTP and FTP connections that the company’s employees open to the Internet. The content inspection server acts as a proxy for these connections. The administrators have already installed the content inspection server and configured it to process HTTP and FTP traffic according to the company’s policy. To configure the redirection in StoneGate, the administrators:1. Create an element for their content inspection server.2. Create a custom Service element for both HTTP and FTP that refer to the

Protocol Agents for those protocols.3. Add the content inspection server to the Protocol Agent parameters in the

Service properties.4. Create the Access rules for redirecting connections to the content inspection

server and the connections that the proxy server then opens to the Internet or any other destination.

Illustration 20.3 Example Access Rules for content inspection server Redirection

• Illustration 20.3 shows rules for redirecting outgoing HTTP and FTP traffic through a content inspection server. Connections opened from the corporate LAN are redirected to the content inspection server in rule 15.1 and 15.3. The content inspection server then connects to the actual destination, which is allowed in the rules 15.2 and 15.4.

• The FTP Service without redirection in rule 15.4 also uses a Protocol Agent, as this is required for the FTP connections to be correctly handled by the firewall. However, this is the default element that is not configured for content inspection server redirection.

5. Create the NAT rules for ensuring that NAT rules do not match to connections that are being redirected to the content inspection server and rules for translating the connections opened by the content inspection server for load-balancing the connections across the company’s Multi-Link network connections.

Example of Content Inspection 247

Illustration 20.4 Example NAT Rules for content inspection server Redirection

• The rules 4.1 and 4.3 ensure that there is no address translation for the traffic that is redirected to the content inspection server (NAT cell is empty, which means no NAT is done for matching connections).

• The rules 4.2 and 4.4 are used to NAT the forward connections from the content inspection server to the actual destination, in this case, dynamic source NAT for load balancing the traffic across available ISP links (using the Outbound Multi-Link element, which in our example company has been given the name “Internet NetLinks”).


CHAPTER 21 Situations

Situation elements collect together the information that identifies and describes detected events in the traffic (or in the operation of the system). Situations contain the context information, that is, a pattern that the system is to look for in the inspected traffic.


Overview to Situations, on page 250 Configuration of Situations, on page 250 Using Situations, on page 253 Examples of Custom Situations, on page 254

249

Overview to SituationsSituations are elements that provide a way to define the patterns in traffic and events in your system that you want to detect with the firewall’s Inspection rules. This is done by selecting a Context for the Situation, which contains the information on the traffic to be matched, and options you can set for the matching process. Situations also provide a description that is shown in the logs, and link to relevant external information (CVE/BID/MS/TA) in the form of a Vulnerability element attached to the Situation.The Inspection rules in Firewall define how the Situations are matched to traffic and what kind of action the system takes when a match to a particular Situation is found.

Note – The Firewall Inspection rules can currently inspect only HTTP, IMAP, POP3, SIP, and SMTP traffic.

Situations have their own grouping system called Tags. The main difference between a Tag and a regular Group element is that Tags are shown as branches in the Situations tree. The Tag elements can be used in policies to represent all Situations that are associated with that Tag. For example, using the Tag “Windows” in a rule means that the rule matches to all Situations in the system that concern Windows systems.

Configuration of SituationsThe Situation elements are shown in their own Situations branch in the All Elements tree. The Tag and Context elements are not shown as static lists, but as sub-branches of the By Tag and By Context branches under Situations. Vulnerabilities are located under IPS Configuration. The illustration below shows how Situations and the related elements are used together.

Illustration 21.1 A Situation and the Associated Elements

250 Chapter 21: Situations

As you can see in the illustration above, the Situation element uses different elements in the system to form a representation of the traffic that you want to detect in your Inspection rules. The purpose of these elements is as follows:• The Tag elements help you to create simpler policies with less effort. For example,

the Inspection rules in the System Template Policy have been defined using the Situation Type Tags (Attacks, Successful Attacks, etc.), so that only five Tag elements inserted in the policy represent the available Situations (marked with those Tags).

• The Context element allows you to define what you want your custom Situation to detect. The Context binds the Situation to a certain type of traffic and gives you a set of options or a field for entering a regular expression.

• The Vulnerability element associates your custom Situation with a commonly known vulnerability. It allows you to attach a description of the Vulnerability and a reference to a public vulnerability database (which are shown in the Logs view if a match is found).

The Context is the only mandatory element in a Situation. However, it will help you in the long run if you consistently associate all relevant Tags to each and every Situation you create. The vulnerability description is not mandatory, but is helpful to have it for those Situation elements that detect some publicly known issue.

Situation ContextsContext elements are protocol-specific, so they define what the Situation element matches. They provide a framework for defining the parameters of each Situation. The parameters are entered as a regular expression or through a set of fields and options that you can adjust, depending on the Context element selected.The sections below explain the types of Context elements available and how they can be configured.

Note – The details related to the Contexts in your system may be different from what is described here, because the Contexts may have been updated through dynamic update packages after this guide was published. Read the release notes of each update package you import to see which elements are affected.

Protocol-Specific ContextsThe protocol-specific contexts are used to detect a particular characteristic in the network traffic.For Contexts that have particular values to be filled in (instead of a regular expression), the parameters you define in these contexts often actually determine what is considered normal, so that anything above/below/outside/not matching these values is considered a match for the Situation. So in other words, you may define what the Situation does not match.

Configuration of Situations 251

The properties of each Context (shown as branches under the Situations→By Context tree) provide assistance on filling in the parameters for these types of contexts. Effective modifications to the protocol-specific contexts require that you are familiar with the protocols in question and how the traffic in your network uses those protocols.

System ContextsThe System Contexts are used for errors and other system events. They are internal to StoneGate, and they cannot be modified in any way.

Default ElementsThere are many pre-defined Contexts, Situations, Tags, and Vulnerabilities available, which are imported and updated from dynamic update packages. This also means that the set of elements available in your system changes in some part whenever you update your system with new definitions. Both Situation and Context elements each have a comment and a longer description that you can view in the Management Client (in the Info panel or in the Properties dialog for the element) to see what each element is meant for.The Release Notes of each dynamic update package lists the new elements that the update introduces to your system. If your Management Server can connect to the Stonesoft web site, you can view the release notes directly through the Management Client by looking up the updates in the Administration branch of the resource tree.

Configuration WorkflowThe following sections provide an overview to the configuration tasks related to configuring Situations. Detailed step-by-step instructions for configuring Situations can be found in the online help of the Management Client and the Administrator’s Guide PDF, in the section called Elements.

Task 1: Create a Custom Situation ElementYou can create new Situation elements in addition to the predefined ones. A Custom Situation element collects together the related elements and settings and sets the severity value for the Situation, which can be used for matching in Inspection rules and Alert Policies. The severity value can be set between 1 (least severe) to 10 (most severe).

Task 2: Add a Context for the SituationAdding a Context to a Situation allows you to define what kinds of patterns you want to look for in the traffic. For example, you can specify that you want to look for a certain character sequence in an HTTP stream from the client to the server. With the firewall system, you can use contexts for the application-level protocols HTTP, SIP, SMTP, and POP3.


When you select a Context you get a set of options or a field for entering a regular expression as parameters for the context. The parameters define the pattern you want to look for in the traffic. The syntax for StoneGate regular expressions is explained in Regular Expression Syntax, on page 427.Other types of context parameters are not listed in this guide. They concentrate on some aspect of a particular kind of network traffic, and using them requires that you have basic knowledge of the underlying network protocols. For more information on what a particular context is used for, see the Properties dialog of the Context element in question.

Task 3: Associate Tags with the SituationTag elements are simple labels, shown as branches in the Situations tree. They help you organize the tree and create simpler Inspection rules with less work. You can drag and drop the Tags into the Situations cell in the Inspection rules, which allows you to match the rule to all Situations that contain the Tag.

Note – If a Tag you add to a Situation is in use in some Firewall Policy, the new Situation is automatically included in the policy when you save the Situation, and the firewall starts matching traffic to the Situation when you refresh the policy.

Task 4: Associate the Situation with a VulnerabilityVulnerabilities provide a short description of the event that has matched, and a reference to external vulnerability information (CVE/BID/MS/TA). This information is also shown in the Logs view.Vulnerability information is included in dynamic update packages, so all Situations provided by Stonesoft that are related to a known vulnerability are linked to a Vulnerability element. When you create your own Situations, you can associate them with an existing Vulnerability or first create your own custom Vulnerability element.

Using SituationsSituations are used for defining what you want to detect with the Inspection rules. Situations are generally used for detecting harmful, unwanted, or otherwise interesting patterns in traffic. The Situations supplied by Stonesoft in dynamic update packages concentrate on known vulnerabilities and exploits. Custom Situations you define will most likely detect less sinister patterns, such as a certain URL or file being accessed.Although the general workflow requires ensuring that a Situation you want to use is included in the Firewall policy, you may often not actually insert the Situation into the rule, but use a Tag element instead. If you assign a Tag that is used in a Firewall policy to a Situation, the Situation is included in the Firewall policy without any further action, and is used by the firewall engines after the next policy installation.

Using Situations 253

Examples of Custom SituationsThe examples in this section illustrate a common use for Situations in StoneGate and the general steps on how the scenario is configured.

Detecting the Use of Forbidden SoftwareCompany A has a firewall that inspects all outgoing Web traffic against the Inspection rules. The use of instant messaging clients across the Internet is forbidden in the company, and their Inspection rules are set to detect and log Situations with the Instant Messaging Tag.Now the administrators find out that some of the internal users have started chatting using a new little-known instant messaging client that does not have a default Situation yet. The communications seem to be standard HTTP directly from client to client, so the traffic is hard to distinguish from other Web traffic. However, the administrators find one distinctive characteristic in the software: when launched, the software in question always connects to a particular address to check for updates using HTTP. The administrators:1. Create a new custom Situation element with the name “Software X”.2. Add the HTTP Request URI context to the Situation and type in a regular

expression that contains the address they want the Situation to find using the StoneGate regular expression syntax (see Regular Expression Syntax, on page 427).

3. Add the default system Tag Instant Messaging to the Situation.4. Refresh the firewall’s policy.5. Open the Logs view and filter the view using the “Software X” Situation as the

filtering criteria.6. See which computers use the forbidden software and take action to remove the

software from the computers shown in the logs.In this case, the firewall could not be configured to stop the actual instant messaging connections automatically, since the unwanted traffic did not have a unique enough pattern to distinguish it reliably from other traffic. Still, the firewall could be used to detect the use of the forbidden software and the problem could be solved.


CHAPTER 22 Blacklisting

Blacklisting is a way to temporarily block unwanted network traffic either manually or with blacklist requests from a Sensor, Analyzer, or Management Server. Blacklisted connections are blocked for the duration of blacklist entries, after which the connections are again allowed.


Overview to Blacklisting, on page 256 Configuration of Blacklisting, on page 257 Using Blacklisting, on page 258 Examples of Blacklisting, on page 259

255

Overview to Blacklist ingBlacklisting makes it possible to block unwanted network traffic for a specified time. Sensors, Analyzers, and Management Servers can send blacklist requests to Firewalls or inline sensors with the Transparent Access Control (TAC) feature. Analyzers can add IP addresses to the blacklist based on detected events. You can also blacklist IP addresses manually. Blacklisting is not supported on SOHO Firewalls.Access rules in the firewall’s or sensor’s policy define which connections are matched to the blacklist. If an Access rule checks a connection against the blacklist and the IP addresses and ports in one of the blacklist entries match, the connection is discarded. Each blacklist entry exists only for a defined time period after which the entry is cleared and matching traffic is again allowed.

Note – Use blacklisting with consideration. An attacker may use spoofed IP addresses. This may cause a self-inflicted denial-of-service on legitimate traffic.

Risks of BlacklistingBlacklisting can have unintended consequences that could disrupt business-critical traffic. Use blacklisting with careful consideration. The following two categories represent the typical risks associated with blacklisting:

These risks can be minimized with good planning. The threats must be identified and evaluated carefully, and the active responses must be defined only with good reasons.

WhitelistingWhitelisting means defining a list of IP addresses that must never be blacklisted. There is no separate “whitelisting” feature in StoneGate, but you can still whitelist connections by following general Access rule design principles. If an Access rule in the firewall’s policy allows a connection, an Access rule that refers to the blacklist further down in the policy cannot blacklist the connection.

TABLE 22.1 Risks of Blacklisting

Risk Explanation

Blacklisting legitimate connections (false positive)

If the defined pattern for detecting malicious traffic is inaccurate, legitimate traffic may sometimes be blacklisted. This causes service downtime for hosts that are incorrectly identified as malicious.

Causing self-inflicted denial of service (DoS)

When an attacker uses spoofed IP addresses, a different (legitimate) IP address may be blacklisted instead of the attacker’s IP address. This may cause a self-inflicted denial-of-service on legitimate traffic.

256 Chapter 22: Blacklisting

Configuration of Blackl ist ingBlacklisting is executed as defined in the Access rules of the IPS or Firewall Policy, and automatic blacklisting requests are sent as defined in the Inspection rules of the IPS policy.

Illustration 22.1 Blacklisting Configuration

In Illustration 22.1, sensors, analyzers, and Management Servers send blacklist requests. When sensors send blacklisting requests, analyzers relay the request to the component that enforces the blacklisting. When an inline sensor is both the sender and the executor of a blacklisting request, the request is sent through the analyzer back to the inline sensor. Manual blacklisting commands from the administrators are sent through the Management Server.Firewalls or inline sensors can execute blacklist requests generated automatically by sensors and analyzers that are managed by the same Management Server execute the blacklist request. The duration of the blocking is defined when the blacklist entry is created based on the value configured in the IPS Inspection rule that generates the blacklist entry (firewalls do not automatically create blacklist entries). There is one blacklist per Firewall or inline sensor. When traffic matches a blacklisting access rule, the current blacklist entries on the firewall or inline sensor are checked. The traffic is discarded if any of the current blacklist entries matches the traffic. If the traffic does not match the blacklisting access rule or its related blacklist entries, the next access rule in the policy is checked as usual.

Configuration WorkflowThe following sections provide an overview of the configuration tasks related to configuring and customizing blacklisting. Detailed step-by-step instructions for configuring the elements and policies can be found in the online help of the Management Client and the Administrator’s Guide PDF, in the section called Policies.

Configuration of Blacklisting 257

Task 1: Define Blacklisting in Access RulesBlacklisting is applied in the Firewall or IPS policy with access rules that contain the Apply Blacklist action. By default, all Sensors, Analyzers, and Management Servers are allowed to send blacklist requests. You can also restrict the allowed blacklisters to certain elements in the access rule’s options.Blacklisting applies only at the position of the blacklisting access rule(s) in the policy. Traffic that has already been allowed or discarded before the blacklisting rules is not affected by blacklisting. Only traffic that matches the blacklisting access rules is blacklisted.No further configuration is needed for manual blacklisting. Tasks 2 and 3 explain the other steps needed for configuring blacklisting with StoneGate IPS.

Task 2: Define Analyzer-to-Firewall or Analyzer-to-Sensor ConnectionsThe Analyzer or Management Server connects to the StoneGate Firewall or Inline Sensor to send the blacklist requests. The Firewall or IPS policy’s Default template contains a rule that allows the blacklisting connections to the Firewall or Sensor. If your policy is not based on the Default template, or if you have deleted the rules that allow the Analyzer and the Management Server to send blacklist requests to the Firewall or Sensor, you may need to add Access rules that allow the blacklisting connections.

Task 3: Define Inspection Rules in the IPS PolicyWhen IPS is used, blacklist scope options in IPS Inspection rules trigger blacklisting for the detected events. Blacklisting scope options can be defined for any type of IPS Inspection rules, including correlation rules. Blacklisting is defined using the detected event’s IP source and destination addresses, and optionally the TCP or UDP ports. If the event does not contain this information, a blacklist entry cannot be created.The source and destination addresses to be blacklisted can be determined from the IP addresses of the detected event. Netmasks can also be used to blacklist not just the detected event’s IP address but also its network.

Using Blacklist ingBlacklisting is needed whenever the Firewall is unable to determine whether traffic is harmful and relies on a separate IPS to tell the difference. An inline Sensor combines these functions, and in many cases is able to block attack attempts alone without the need to use blacklisting. However, blacklisting is useful in the following cases:• The traffic latency requirements are too strict for an Inline Sensor. A non-inline

Sensor analyzes the traffic off-line and therefore does not cause any delays to legitimate traffic.

• The offending connection is not the only one that the administrators want to block. If the IPS detects that a business-critical application server has been compromised,


the desired reaction may be to shut down the whole network until the intruder has been cleared out. This may require blacklist requests to several Firewalls.

• A Firewall is already in a suitable place, and therefore adding the non-inline Sensor is easier than implementing an inline Sensor.

Manual BlacklistingYou can blacklist traffic manually through the Management Client. This requires that the Firewall policy has an access rule which applies blacklisting and allows Firewall(s) to accept blacklist requests from the Management Server. There are three ways to create new blacklist entries manually. You can blacklist a connection found in the log data, define a new blacklist entry for a Firewall element, or create new blacklist entries in the Blacklist view.

Monitoring BlacklistingThe currently active blacklisting entries on the Firewall can be monitored in the Blacklist view. Blacklist monitoring does not show you which connections are actually dropped. Blacklist monitoring only shows you the addresses that are currently on the blacklist. The access rule(s) that apply blacklisting in the Firewall policy determine which of these connections are dropped (if any). The Logs view can show which connections are actually dropped, depending on the logging options you have set. The blacklist can be sorted and filtered in the same way as logs. Blacklist entries can be removed and added manually.

Examples of Blacklist ingThe examples in this section illustrate some common uses for blacklisting in StoneGate and the general steps on how each scenario is configured.

Blacklisting Traffic from a Specific IP Address ManuallyCompany A is using StoneGate Firewalls. The company starts getting a large amount of spam from IP address X. The company’s administrators decide to blacklist all traffic originating from that IP address for two hours. To do this, the administrators:1. Create a new Access rule in the Firewall policy. The Access rule applies

blacklisting and allows the Management Server to send blacklist requests to the Firewall(s).

2. Refresh the Firewall policy.3. Open the Logs view.4. Select one of the entries which originate from IP address X. 5. Create a new blacklist entry which sets two hours as the Duration of the

blacklist entry and defines the Firewall(s) that will receive the blacklist request.

Examples of Blacklisting 259

Automatic Blacklisting with IPSCompany B is using a Firewall and IPS managed by the same Management Server. The IPS has recently detected a large number of attempted attacks against several of the company’s servers. The attempted attacks have come from multiple IP addresses. It is difficult to predict which server will be the target of a particular attack. The administrators want to automatically block traffic between the IP address that is the source of the attacks and the target server for one day whenever an attempted attack is detected.There is already a default Situation for attempted attacks that defines the source IP address of matching traffic as the Attacker and the destination IP address as the Victim. To configure the automatic blacklisting for traffic from the attacker to the company’s servers, the administrators:1. Create a new Access rule in the Firewall policy. The rule applies blacklisting and

allows any component to send blacklist requests to the Firewall(s).2. Refresh the Firewall policy.3. Create an Inspection rule in the IPS policy that sends a blacklist request to the

Firewall when traffic matches the Situation for attempted attacks.4. Define the following Blacklist Scope properties in the options of the inspection

rule:• Block traffic between endpoints• Duration: 1 day• Endpoint 1 Address: Attacker• Endpoint 2 Address: Victim• Blacklist Executor: Firewall

5. Refresh the IPS policy.


Traffic Management

CHAPTER 23 Multi-Link Configuration

Multi-Link allows you to distribute outbound traffic between multiple network connections to provide high availability and load balancing for outbound traffic.


Overview to Multi-Link Configuration, on page 264 Configuration of Multi-Link, on page 264 Using Multi-Link, on page 268 Examples of Multi-Link, on page 268

263

Overview to Multi-Link ConfigurationA single connection to the Internet is a single point of failure: if the connection becomes unavailable, all outbound traffic is blocked. To prevent this, StoneGate’s patented Multi-Link technology distributes outbound traffic between multiple network connections. Multi-Link ensures that Internet connectivity remains available even when one or more network connections fail. The firewall can also balance the load of outbound traffic between the network connections to use the available Internet connections more efficiently.This chapter describes the use of Multi-Link for outbound connections. For inbound connections, load balancing is provided by Server Pool elements. For information about using Server Pools and Multi-Link for inbound connections, see Server Pool Configuration, on page 271. For more information about using Multi-Link with VPN, see Multi-Link VPN, on page 379.

Configuration of Multi-LinkYou can use Multi-Link on both single and clustered firewalls.The network connections for Multi-Link are represented by NetLink elements in the Management Center. In most cases, a NetLink element is used to represent an ISP connection. However, NetLinks can also represent a leased line, xDSL, or any other type of network connection mediated by your firewall.There are two types of NetLinks: static and dynamic NetLinks. Dynamic NetLinks are used only with single firewalls, as dynamic IP addresses are not supported for clustered firewalls in StoneGate.

Illustration 23.1 Configuration of Multi-Link

Illustration 23.1 shows how StoneGate elements are used to configure Multi-Link. Each NetLink contains a Router element that represents the router for that network connection, and a Network element that represents the set of public IP addresses allocated by the provider of the network connection. NetLinks are added to the Routing

264 Chapter 23: Multi-Link Configuration

view under the interface IDs that represent the physical interfaces towards the routers for the Internet connections. Multiple NetLinks are combined into an Outbound Multi-Link element. Outbound Multi-Link elements are the central element used to configure load balancing for outbound traffic. Outbound Multi-Link elements must be used in NAT rules in the Firewall policy to implement outbound load balancing.

Load BalancingLoad balancing can be based on two methods: Round Trip Time and Ratio.When the Round Trip Time method is used, NetLink performance is measured for each new TCP connection by sending the initial request (SYN) to the destination through all the available NetLinks. When the destination host sends the reply (SYN-ACK), the NetLink that receives the reply first is used to complete the TCP connection establishment. The firewall cancels the slower connection attempts by sending a TCP Reset (RST) to the destination through the other NetLinks. This way, the fastest route is automatically selected for each connection based on the Round Trip Time measurement. Information about the performance of each NetLink is cached, so no new measurement is made if a new connection is opened to the same destination within a short time period.When the Ratio method is used, traffic is distributed between all of the available NetLinks according to the relative capacity of the links. The bandwidths of the other NetLinks are automatically compared to the bandwidth of the NetLink with the most bandwidth to produce a ratio for distributing the traffic. When the volume of traffic is low, the ratio of actual traffic distribution is approximate. When the volume of traffic is high, the ratio of traffic handled by each NetLink is closer to the ratio calculated from the link capacity.

Standby NetLinks for High AvailabilityStandby NetLinks allow you to define a NetLink as a backup that is only activated when all primary NetLinks are unavailable. This minimizes the use of NetLinks that are more expensive or otherwise less preferable, while still ensuring high availability of Internet connectivity. To test which NetLinks are available, the status of the NetLinks is monitored as described in NetLink Monitoring below. As soon as one or more primary NetLinks become active again, the standby NetLinks are deactivated. Previously established connections continue to be handled by the deactivated NetLink, but new connections are no longer sent to the standby NetLink. You can define multiple active NetLinks and multiple standby NetLinks. When load balancing is used with standby NetLinks, traffic is only distributed between the NetLinks that are currently active. Standby NetLinks are not activated to balance the load.


Using standby NetLinks on the same interface as other NetLinks affects the interface speed you enter in the configuration of QoS for firewall interfaces (see Task 4: Define QoS for Firewall Interfaces, on page 286).

NetLink MonitoringTo monitor the status of the NetLinks, the firewall sends ICMP Echo Requests (ping) through each NetLink. If no response is received before the end of the timeout interval you define, the NetLink is considered unavailable.Probing Settings must be configured if you want to use standby NetLinks or if you want to see the status of the NetLinks in the System Status view. Make sure the Probe IP Addresses you select produce a reliable measurement of the link performance. For example, probing the IP address of the ISP router would not indicate that the link is down in a situation where the outage is in the ISP network at some point behind the router.

Configuration WorkflowThe following sections provide an overview of the configuration tasks related to Multi-Link in StoneGate. Detailed step-by-step instructions for configuring the elements and policies can be found in the online help of the Management Client and the Administrator’s Guide PDF, in the section called Routing.

Task 1: Create NetLink ElementsTo introduce a new Internet connection, you must define a NetLink element that represents the Internet connection in the Management Center. The NetLink element contains the details of the Internet router and the related networks, the Probing Settings for testing the availability of the NetLinks, and the Input and Output speed of the Internet connection. A NetLink can be either static or dynamic. Dynamic NetLinks are supported only for single firewalls. You can use the same NetLink with several firewalls. If you want to use NetLinks with a firewall that has several dynamic interfaces, you must create a separate Dynamic NetLink element for each dynamic interface.The Probing Settings must be configured if you want to use standby NetLinks. You must configure Probing Settings for the primary (active) NetLinks. ICMP Echo requests are sent at the intervals you specify in the Probing Settings. Optionally, standby NetLinks can also be probed.

Caution – If Probing Settings are not configured for the primary NetLinks, the standby NetLinks are never activated.

The Input Speed and Output Speed must be defined if you want to use ratio-based load balancing. The values represent the maximum input and output capacities of the


Internet connection. Input Speed and Output Speed are used to calculate the ratio of the bandwidths of the NetLinks.

Task 2: Configure Routing for NetLinksThe NetLinks must be added under the appropriate interfaces in the Routing tree to support Multi-Link. See Routing and Antispoofing, on page 141 for more information.

Task 3: Combine NetLinks into Outbound Multi-Link ElementsTo group the NetLinks together as a single entity, you must create an Outbound Multi-Link element that includes the NetLinks. When you create the Multi-Link element, you define which NetLinks are included, the load balancing method for determining which link is selected for each new outbound connection, and whether each NetLink in the Multi-Link element is an Active or Standby NetLink.You can create multiple Outbound Multi-Link elements, and each NetLink can belong to more than one Outbound Multi-Link element at the same time.You can optionally assign a QoS class to each NetLink in the Multi-Link element. Assigning a QoS class to a NetLink specifies that traffic with the selected QoS class is routed through the selected NetLink. The same QoS class can be assigned to more than one NetLink in the same Multi-Link element. When no QoS class is assigned to a particular NetLink, traffic is routed through that NetLink according to the load balancing method you select.

Task 4: Create Access Rules to Apply QoS ClassOptionally, if you want to use QoS class to specify which traffic uses which NetLink, you must assign the QoS class to the traffic in an Access rule or with the QoS policies based on the DSCP codes in the traffic. For more information, see Bandwidth Management and Traffic Prioritization, on page 281.

Task 4: Create NAT Rules for Outbound TrafficMulti-Link for outbound connections is implemented with NAT rules in the firewall policy. You define which traffic uses the Outbound Multi-Link element. It is not necessary for all traffic to be balanced through the Outbound Multi-Link element. When a NAT rule that balances outbound connections matches the traffic, only the traffic that matches the rule is balanced through the Outbound Multi-Link element specified in the rule. Other traffic does not use the Outbound Multi-Link element. See Multi-Link Routing for Single and Clustered Firewalls, on page 145 for more information about NAT rules for outbound traffic.Some protocols cannot use dynamic NAT based on IP/port translation. To achieve high availability and load balancing for connections that use these protocols, you can use static NAT with a Multi-Link element in an outbound load balancing NAT rule. When static NAT is used, the size of the source network must be the same as the size of the Multi-Link network.


Using Multi-LinkMulti-Link is mainly used for high availability to ensure that business-critical traffic gets through even when one or more Internet connections fail. Standby NetLinks act as backup Internet connections that are only activated if all the primary NetLinks fail. Using standby NetLinks provides high availability of Internet connectivity, but is less expensive than having multiple NetLinks active at the same time. Using Multi-Link for load balancing can also help reduce costs. Traffic can be balanced between two slower, less expensive, Internet connections instead of one faster connection.

Using Multiple Outbound Multi-Link elementsYou can create multiple Outbound Multi-Link elements, and each NetLink can belong to more than one Outbound Multi-Link element at the same time. This can be useful, for example, when you want a certain type of traffic to be balanced only between some of the NetLinks, and another type of traffic to be balanced between all of the NetLinks.

Examples of Multi-LinkThe examples in this section illustrate some common uses for Multi-Link in StoneGate and general steps on how each scenario is configured.

Preparing for ISP BreakdownCompany A wants to make sure their Internet connection remains available even when one ISP connection fails. The company has subscribed to one Internet connection each from ISP A and ISP B. The administrators decide to use Multi-Link to ensure high availability of Internet connectivity.The administrators do the following:1. Create NetLink elements to represent connections to ISP A and ISP B.2. Place the ISP A and ISP B NetLinks under the correct interfaces in the Routing

view.3. Create an Outbound Multi-Link element and add the ISP A and ISP B NetLinks to

it.4. Define the following NAT rule in the Firewall Policy so that traffic from the

internal network (Internal Network element) to destinations that are not internal (Not Internal expression) is handled by the Outbound Multi-Link element (My Multi-Link):

TABLE 23.1 Example NAT Rule


Internal Network Not Internal ANY Dynamic load balancing: My Multi-Link


Save and install the policy to transfer the changes to the engine.

Excluding a NetLink from Handling a QoS Class of TrafficCompany B has three Internet connections: ADSL A, ISDN B, and Satellite C, which is a satellite link. Because of the long latency in satellite connections, the administrators do not want any VoIP traffic to be routed through Satellite C. They decide to use QoS classes so that VoIP traffic is only routed through ADSL A and ISDN B. To do this, the administrators:1. Create NetLink elements to represent connections to ADSL A, ISDN B, and

Satellite C.2. Place the ADSL A, ISDN B, and Satellite C NetLinks under the correct interfaces

in the Routing view.3. Define a QoS class and assign it to VoIP traffic.4. Create a Multi-Link element and add the ADSL A, ISDN B, and Satellite C

NetLinks to it.5. Select the QoS class for the ADSL A NetLink and the ISDN B NetLink in the

Outbound Multi-Link element properties. No QoS class is assigned to Satellite C.

6. Define the following NAT rule for outbound load balancing in the Firewall Policy:

7. Save and install the policy to transfer the changes to the engine.

Balancing Traffic According to Link CapacityCompany B has three ISP connections that have different bandwidths:• ISP A 20 Mbit/s• ISP B 10 Mbit/s• ISP C 4 Mbit/sThe administrators want the traffic to be divided between the NetLinks according to the ratio of their relative bandwidths. This means that ISP A handles twice as much traffic as ISP B and 5 times as much traffic as ISP C. The administrators have already created and configured NetLink elements to represent each ISP connection, so now they:1. Combine the NetLinks for each ISP connection into a Multi-Link element and

select the Ratio load balancing method.

TABLE 23.2 NAT Rule for Outbound Load Balancing


ANY ANY ANY Dynamic load balancing: Multi-Link Element

Examples of Multi-Link 269

2. Define the following NAT rule for outbound load balancing in the Firewall Policy:

3. Save and install the policy to transfer the changes to the engine.

Balancing Traffic between Internet ConnectionsThe administrator at Company B determines that a 1 megabyte Internet connection is needed to handle the volume of traffic their network receives. However, Company B is a small company on a tight budget, and the cost of a single 1 megabyte connection is too high. The administrator decides to subscribe to one 512 kbps connection each from ISP A and ISP B, and use Multi-Link to balance the load of traffic between the two connections to reduce costs.The administrator:1. Creates NetLink elements to represent connections to ISP A and ISP B.2. Places the ISP A and ISP B NetLinks under the correct interfaces in the Routing

view.3. Creates an Outbound Multi-Link element and adds the ISP A and ISP B NetLinks

to it.4. Defines the following NAT rule in the Firewall Policy so that traffic from the

internal network (Internal Network element) to destinations that are not internal (Not Internal expression) is balanced by the Outbound Multi-Link element (My Multi-Link):

5. Saves and installs the policy to transfer the changes to the engine.

TABLE 23.3 NAT Rule for Outbound Load Balancing


ANY ANY ANY Dynamic load balancing: Multi-Link Element

TABLE 23.4 Load Balancing NAT Rule


Internal Network Not Internal ANY Dynamic load balancing: My Multi-Link


CHAPTER 24 Server Pool Configuration

A Server Pool balances the load of incoming connections between a group of servers that function as a single entity. Additionally, Server Pools can be used to utilize dynamic DNS updates to disable access to a single server or a group of servers through non-working Multi-Link Internet connections.


Overview to Server Pool Configuration, on page 272 Configuration of Server Pools, on page 272 Using Server Pools, on page 275 Examples of Server Pools, on page 278

271

Overview to Server Pool ConfigurationThe Server Pool is a built-in load balancer in the firewall that can be used for distributing incoming traffic between a group of servers to balance the load efficiently and to ensure that services remain available even when a server in the pool fails. The Server Pool has a single external IP address that the clients can connect to and StoneGate then uses NAT to distribute the incoming traffic to the different servers.The server load is distributed to the Server Pool members based on each server’s availability. Monitoring agents installed on each server can be used to monitor server availability and load balancing. Alternatively, the server availability can be checked with simple ICMP Echo Requests (ping) sent from the firewall engines to each server periodically. Whereas the ping test only checks the server’s connectivity, Monitoring Agents provide additional information about the server’s load and functioning.If the ping test or the Monitoring Agent reports a server failure, the server is taken out of the Server Pool and the connections are distributed to the remaining servers. When a server is taken out of the Server Pool, traffic from existing connections can still sent to the server (since in typical use scenarios the other servers would not be able to handle them in any case) without sending new connections to the failed member. With Monitoring Agents, the server can be completely excluded from handling traffic.When a previously unavailable server comes back online, existing connections are not redistributed, but some of the new connections that are opened are again directed to the server that rejoins the pool.Additionally, Multi-Link can be used with Server Pools to provide the connecting clients access to the Server Pool through multiple Internet connections, increasing Server Pool availability.

Configuration of Server PoolsIllustration 24.1 Server Pool Configuration

Host elements represent your servers in the Management Center. One or more Host elements are added as Server Pool members to a Server Pool element. The Server Pool element must be used in an Access rule in the Firewall Policy for incoming traffic to be routed to the pool members. There can be several Server Pools for different services. The Access rules define which traffic is directed to which pool.

272 Chapter 24: Server Pool Configuration

Multi-Link for Server PoolsIf you have configured Multi-Link, it can be used to improve Server Pool availability. You can also use Multi-Link with just one server in the Server Pool to take advantage of dynamic DNS updates (as explained below).

Illustration 24.2 Multi-Link Configuration for a Server Pool

As an addition to the basic configuration, also the NetLinks and (optionally) the external DNS Server are specified for the Server Pool.When dynamic DNS updates are not used, Multi-Link is based on assigning an IP address for the Server Pool in each NetLink. The Server Pool’s DNS entry on the external DNS server must be configured with an IP address for each NetLink so that clients can access the servers through the different NetLinks. When the connecting client requests the IP address for the Server Pool’s DNS name, the DNS server sends the Server Pool’s DNS entry with the IP addresses on the different NetLinks. The client connects to one of these addresses and StoneGate then allocates the connection to one of the Server Pool members. If the first Server Pool IP address is unreachable, the client can connect to the Server Pool’s next IP address on a different NetLink (depending on the client application).When dynamic DNS updates are used, the firewall updates the DNS entries automatically based on the availability of the NetLinks. When a NetLink becomes unavailable, the Server Pool’s IP address for that link is automatically removed from the DNS entry on the external DNS server. When the NetLink becomes available, the IP address is again automatically added to the DNS entry (for more information, see Dynamic DNS (DDNS) Updates, on page 275).

Configuration of Server Pools 273

Default ElementsYou can use Server Pools to balance the load between servers without using Multi-Link for inbound traffic management. To do this, you use the special “Not specified” default NetLink element.

Configuration WorkflowThe following sections provide an overview of the configuration tasks related to inbound traffic management. Detailed step-by-step instructions can be found in the online help of the Management Client and the Administrator’s Guide PDF, in the section called Routing.

Task 1: Define HostsFirst, you must introduce each server in the Server Pool into the system as Host elements so that the firewall has the IP addresses for sending the traffic. When you define a Host element, you enter the IP address that the firewall uses to contact the server, in other words, the internal (un-NATed) address of the server.

Task 2: Combine Hosts into a Server Pool ElementTo allow the servers to function as a single entity, you must create a Server Pool element that includes the Host elements. If you have only one server and you want to have the inbound traffic balanced between your NetLinks, you can define a Server Pool with just one Host. This allows dynamic DNS update Information to be used to prevent contacting clients from attempting to use a NetLink that is out of service.If there are several servers in the Server Pool, the granularity of the traffic allocation between the different servers can be adjusted as follows:• Source Network directs traffic coming from the same C-class network to the same

server. This is a good choice when connections come from many different networks. The Not Defined setting has the same effect.

• Host directs traffic coming from the same IP address to the same server. This is a good choice if a large portion of connections come from different hosts in the same C-class network.

• Connection makes a new traffic management decision for each new connection. This may be necessary if a large portion of connections use just one IP address.

Note – Using the Host setting (if the host’s IP address apparent to StoneGate can change) or the Connection setting (in all cases) means that connections from the same source may be directed to different servers. Depending on the services offered, this may deteriorate service quality.

Task 3: Configure the External DNS ServerWhen using static DNS entries, you must ensure that the IP address(es) for your server pool are properly entered into your DNS server’s records. The Server Pool has


one IP address per NetLink (Internet connection) in a Multi-Link configuration and a single IP address in a single-link configuration.If you decide to use dynamic DNS updates, configure the DNS server accepts the DDNS updates from the firewall.

Task 4: Create an Inbound Load Balancing RuleServer Pool load balancing is applied to the firewall configuration by adding the Server Pool element in an Access rule in the firewall policy (see Access Rules, on page 165 for more information about firewall Access rules). When this rule matches some traffic, the Server Pool uses NAT to change the destination IP address to the IP address of the server that the firewall selects for the connection. Reverse NAT (for the replies the server sends back to the client) is handled automatically.

Note – Server Pool NAT is handled automatically when the Server Pool is defined in an Access Rule. No separate NAT rule is required. Make sure the connections handled by the Server Pool do not match any NAT rule.

Task 5: Set up Server Pool Monitoring AgentsOptionally, Server Pool Monitoring Agents can be installed to the servers to monitor availability and load of the Server Pool members. The Monitoring Agent has various in-built tests and it can additionally run external scripts or programs on the server to check that the server is functioning properly.

Using Server Pools

Dynamic DNS (DDNS) UpdatesOptionally, StoneGate can automatically update dynamic DNS (DDNS) entries for the Server Pool according to the available NetLinks. The firewall engine removes the Server Pool IP addresses for NetLinks that are not available from the DNS entry, and adds the IP addresses back when the NetLink becomes available again. When the connecting client requests the Server Pool’s IP address from the DNS server, the client receives a list of IP addresses that only contains IP addresses that work.

Caution – DDNS can be a security risk because there is no access control. If you must use dynamic DNS updates, do so only after very careful research, planning, and testing.

To improve the security of dynamic DNS updates:• Always place the DNS server(s) behind the firewall (in a DMZ) for protection from IP

spoofing.• Use BIND or an equivalent DNS server that allows you to define which hosts are

allowed to send dynamic updates.


• Always consider using static DNS entries instead, as DDNS is not necessarily needed with inbound load balancing. Obviously, in that case the DNS entries are not removed automatically from the DNS server if an ISP fails, but these problems can sometimes be solved otherwise: for example, some Web browsers can automatically try other IP addresses if one address does not respond.

Using Server Pool Monitoring AgentsServer Pool Monitoring Agents provide advanced features for monitoring the server load and status. While the ping monitoring relies on checking the server availability with periodic ICMP Echo Requests sent to the servers, Monitoring Agents run on each server to check the status and load. The Monitoring Agents can also run system checks on the servers and send log messages to the StoneGate Management Center.

Illustration 24.3 Firewall Queries Server Pool Monitoring Agents on Each Server

A Monitoring Agent runs as a service (port 7777/UDP by default) on the Server Pool member. The firewall queries the Monitoring Agent on each Server Pool member to check the status and load of the server.

Illustration 24.4 Server Pool Monitoring Agents Provide Status Information


The Monitoring Agent on each Server Pool member provides information about the server load and statu to the firewall.

Illustration 24.5 Firewall Balances Connections Between Server Pool Members

The firewall balances the incoming connections between the Server Pool members according to the status and load information it receives from the Monitoring Agents.

Illustration 24.6 Server Pool Monitoring Agents: Test Failure

The Server Pool Monitoring Agent also has a tester that is configured to run predefined tests or user-defined programs. Automatic action can be configured based on the results of the test. When a test fails, an alert is sent to the StoneGate engines. Optionally, the agent can also take the server out of the Server Pool by changing its status from “OK” to “Excluded”. When a server is excluded from the Server Pool, all established and new connections are directed to other available servers in the pool and the excluded server does not process any connections.Server Pool Monitoring Agents are available for Windows, and Linux platforms. For more information, see Server Pool Monitoring Agents, on page 465.


Examples of Server PoolsThe examples in this section illustrate some common uses for Server Pools in StoneGate and general steps on how each scenario is configured.

Load Balancing for Web ServersA company has three Web servers to handle the large volume of traffic its website receives. The administrators have already created Host elements to represent their Web servers and created NAT rules to assign an external address to each Web server. Now the administrators want to distribute the load of the traffic between the servers. The administrators also want to monitor the status and the load of the servers, and receive an alert whenever one of the Web servers in the Server Pool fails. The administrators decide to set up a Server Pool and install Monitoring Agents on the Web servers. To do this, they:1. Remove the existing NAT rules that translate the IP address of each server so

that the Server Pool can do automatic NAT without conflicts.2. Create a Server Pool element and add the Host elements to it. Because they are

not balancing incoming connections to the WebPool between multiple Internet connections, the administrators select the Not Specified NetLink.

3. Install a Server Pool Monitoring Agent on each server in the Server Pool and configure the Monitoring Agents to measure the load average on the server. They also set up a test that checks each server’s connectivity every 60 seconds and sends an alert if the test fails.

4. Enable the Server Pool Monitoring Agents in the Server Pool element.5. Add the following Access rule to the Firewall policy to allow HTTP connections

from addresses that are not internal (Not Internal expression) to the Server Pool:

6. Save and install the Firewall policy to transfer the changes to the firewall engines.

TABLE 24.1 Server Pool Access Rule

Source Destination Service Action

Not InternalThe Server Pool element

HTTP Allow


Setting up Multi-Link and Dynamic DNS UpdatesThe administrators at our example company already configured a Server Pool (see previous example) but now they want to ensure that Web services remain available even when an Internet connection fails, and they want the Server Pool’s NetLink addresses to be automatically updated on the DNS server based on the availability of the Internet connections.The administrators have already configured Multi-Link routing with the necessary NetLink elements to represent each of their Internet connections. A DNS server has also already been set up in the network. The administrators decide to add the NetLinks to the Server Pool and set up Dynamic DNS (DDNS) updates.The administrators do the following:1. Configure the DNS server to accept DDNS updates from the firewall.2. Edit the NetLinks to add probe IP addresses for testing the NetLinks’ status.3. Edit the Server Pool properties and replace the default Not Specified NetLink

with the NetLinks that represent their Internet connections.4. Define an External DNS Server element to represent the DDNS-capable server in

the Management Center.5. Enable dynamic DNS updates and configure the dynamic DNS settings in the

Server Pool properties.6. Save and install the Firewall policy to transfer the changes to the firewall

engines.

Examples of Server Pools 279


CHAPTER 25 Bandwidth Management and Traffic Prioritization

Bandwidth management means creating policies that determine how the available network link bandwidth is divided between different types of connections to ensure important traffic is not delayed by less important traffic when the network is congested.Traffic prioritization is used either independently or in addition to bandwidth management to ensure quick delivery of time-critical communications, such as streaming audio or video.


Overview to Bandwidth Management and Traffic Prioritization, on page 282 Configuration of Limits, Guarantees and Priorities for Traffic, on page 283 Using Bandwidth Management and Prioritization, on page 287 Examples of Bandwidth Management and Prioritization, on page 291

281

Overview to Bandwidth Management and Traffic Priorit ization

This chapter explains the two Quality of Service (QoS) features available in StoneGate: bandwidth management and traffic prioritization. Both features are configured using the same tools, but you are free to choose whether you want to use both features together or just either of them individually (for any given type of traffic). Bandwidth management and traffic prioritization are not supported on SOHO Firewalls.

Bandwidth ManagementIn practice, bandwidth management simply means giving a guaranteed portion of the bandwidth to important traffic and on the other hand setting limits to how much of the total available bandwidth each type of traffic (important or not) is allowed to consume at any given time. You are free to choose whether to set a limit, a guarantee or both for any given type of traffic.Bandwidth management features can be used to ensure quality of time-critical communications (even under normal network load), to prepare for malfunctions, and to restrict the total bandwidth needed.

Note – Bandwidth management applies to outbound traffic only. Still, the firewall can indirectly control incoming traffic in a limited way (see Managing Bandwidth of Incoming Traffic, on page 290, for more information).

Traffic PrioritizationEven under normal traffic conditions, temporary traffic peaks sometimes occur. With many communications, slight delays caused by queuing traffic are not noticeable to the user of the service. However, some connections, such as streaming audio or video, are extremely time-critical, and even relatively minor delays cause noticeable reduction in service quality.Normally, when packets are queued, they are sent onwards in the same order in which the packets were received. To change this behavior, you can assign priority values to the traffic. This way, you can assign time-critical connections a high priority, allowing for the fastest possible delivery; high-priority packets are placed before any lower-priority packets in the queue.StoneGate has its own internal prioritization scheme, but StoneGate can also read and write DiffServ Code Point (DSCP) markers (type of service (ToS) fields). This allows you to integrate StoneGate with other network equipment that is implementing QoS management in your own or your ISP’s network.

282 Chapter 25: Bandwidth Management and Traffic Prioritization

Effects of Bandwidth Management and PrioritizationBandwidth management and traffic prioritization will improve the quality of service for important traffic, but this may happen at the expense of the traffic that you define as less important.Usually the traffic management process allows all connections to proceed, although some traffic may occasionally slow down when the bandwidth limits are reached. If there is prolonged congestion in the network, lower priority traffic will eventually start to time out. If you set priorities without setting any bandwidth limits or guarantees, high-priority traffic may even use all available bandwidth, blocking all lower-priority traffic.In most situations, the guaranteed bandwidths given to important connections allow traffic to proceed, if defined correctly. However, even traffic with bandwidth guarantees suffer if the network links are not able to maintain their defined throughputs or if the volume of high-importance traffic continuously exceeds the throughput. Make sure that your bandwidth management policy is granular enough to account for situations where a part of the bandwidth is lost (such as due to an ISP failure in a Multi-Link environment), and follow up on the total bandwidth use so that you can increase the throughput before problems appear.

Caution – Inappropriate bandwidth limits and guarantees only disturb traffic. Make sure the guarantees and limits you set are appropriate for the volume of each type of traffic.

Configuration of Limits, Guarantees and Priorit ies for Traffic

Bandwidth management and traffic prioritization in StoneGate are configured in QoS Policies, which contain rules for the bandwidth guarantees, limits, and priorities you want to set for each type of traffic. The QoS policies do not contain any traffic profile: to define which QoS rule affects which type of traffic, a QoS Class element is inserted as a link in the correct QoS rule and again in one or more Access rules that allow traffic through the firewall.


Illustration 25.1 Traffic Handling in a QoS-Enabled Configuration

QoS rules are applied when traffic is exiting the firewall. In Illustration 25.1, traffic arrives at Interface 1, and is headed to the network behind Interface 2. When the traffic is inspected against the firewall policy, the traffic matches a firewall access rule that includes a QoS Class. Using the QoS class as a matching criterion, the firewall checks the QoS Policy that the administrator has defined for Interface 2. If the QoS policy contains a rule with the same QoS Class defined, the QoS rule is applied to the connection and the packets are entered in the queue according to the QoS rules.

Default ElementsThere are three default QoS Classes in the system: High Priority, Normal Priority, and Low Priority. These are used in the supplied sample QoS Policy, Prioritize.The Prioritize QoS Policy contains simple rules that prioritize traffic using the three default QoS Classes. High Priority traffic is assigned the highest possible priority value of 1, the Normal Priority value is 8, and Low Priority is assigned the lowest possible value of 16. The default Prioritize policy does not provide any bandwidth guarantees or limits.

Caution – If you set priorities without setting any bandwidth limits or guarantees, high-priority traffic may use all available bandwidth, blocking all lower-priority traffic.

If the default Prioritize policy is sufficient for you, you can use the default QoS Classes and the Prioritize policy as they are. Just add the QoS Classes to some or all access rules that allow traffic in the firewall’s policy (see Task 3: Assign QoS Classes to Traffic, on page 286) and configure the (Internet) interface(s) to use the Prioritize QoS Policy and define the interface speed (see Task 4: Define QoS for Firewall Interfaces, on page 286).If you want to define guarantees or limits, or if you want to have more control over the priorities, you must create your own policy and elements as explained below.


Configuration WorkflowThe following sections provide an overview of the configuration tasks related to configuring and customizing bandwidth management and traffic prioritization. Detailed step-by-step instructions for configuring the elements and policies can be found in the online help of the Management Client and the Administrator’s Guide PDF, in the section called Policies.

Task 1: Define QoS ClassesQoS Classes are links between your QoS rules and certain types of traffic that is allowed in your firewall policy. As the QoS policy must not have overlapping rules, you must create one QoS class for each rule you plan to add in the QoS Policy. However, several firewall Access rules can have the same QoS class set, so several Access rules can point to the same QoS rule. You can create as many QoS Classes as necessary.

Task 2: Define QoS PoliciesQoS Policies are stored as elements under the Firewall Configuration branch of the tree in the Configuration view. The fact that QoS rules are separate from firewall policies allows you to create different QoS Policies for different interfaces of the same firewall.QoS Policies contain the rules for managing the available bandwidth. The fields in QoS rules are explained in the table below.

TABLE 25.1 QoS Policy Fields

Field Explanation

QoS Class

A drop-down list of the defined QoS Classes for selecting the correct QoS class for the rule. The QoS Class matches this QoS rule to traffic when you insert the same QoS class in one or more Access rules in the firewall’s policy.

DSCP Match

The DSCP code of the traffic that you want this rule to match (the QoS Class of this rule is given to matching traffic). This field is only applied on the source interface. DSCP Match allows you to:a) enforce traffic classifications set by other devicesb) convert traffic classifications to a different classification scheme if you set the DSCP Mark field in a policy assigned to the destination interface.

Guarantee

Sets the minimum bandwidth given to this type of traffic under any conditions in kilobits per second or as a percentage of the available bandwidth. If you set bandwidth guarantees that total more than the total bandwidth you define for the interface, all bandwidth guarantees are scaled down maintaining their relative proportions compared to each other.


Connections that have no matching QoS rule are handled with priority 8 (middle of the scale) without any bandwidth guarantees or limits, and any DSCP markers in the traffic are preserved, but have no effect on how StoneGate handles the traffic.

Task 3: Assign QoS Classes to TrafficThere are two ways to assign a QoS Class to traffic:• Firewall Access rules contain a QoS Class field that is set to Not Classified by

default. Insert a QoS Class to a cell in a rule that allows traffic or in a Continue rule to set the same QoS Class to several rules.

• A QoS Policy rule with a filled-in DSCP Read cell assigns the QoS Class of the rule to incoming traffic. A QoS Class assigned this way is overridden by any matching Access rule that has a QoS Class defined.

Task 4: Define QoS for Firewall InterfacesStoneGate has no automatic mechanism for finding out how much bandwidth each interface has. You must define the interface speeds and the QoS policies you want to use in the Firewall element’s properties for each interface whose bandwidth you want to manage. The speed setting is always mandatory if a QoS Policy is selected for the interface, even if you do not plan to set limits or guarantees.

LimitSets the maximum bandwidth that this type of traffic is allowed to consume at any one time as kilobits per second or as a percentage of the available bandwidth.

Priority

Assigns this type of traffic a number that is used to determine the order in which the firewall sends queued packets onwards or get dropped if the queue fills up. Priority is a number between 1 (highest priority) and 16 (lowest priority).

Comment A short free-form comment for your reference.

DSCP Mark

Defines the DSCP code (ToS field) that is given for traffic matching to the QoS rule. This field is only applied on the destination interface. DSCP Mark allows you to:a) communicate the priority of this traffic to other devices that support QoSb) convert traffic classifications to a different classification scheme if you set the DSCP Match field in the policy assigned to the source interface on the firewall.c) Clear the DSCP classification set by other devices by entering 0 as the value (shown in the policy as 0x00).

TABLE 25.1 QoS Policy Fields (Continued)

Field Explanation


Note – When the interface throughput is defined, StoneGate always scales the traffic to this throughput, so take special care that you set the value correctly.

If you are using Multi-Link with more than one NetLink behind the same firewall interface, set the link speed to the total bandwidth of all the NetLinks behind that interface. See Multi-Link Configuration, on page 263 for more information about Multi-Link.

Using Bandwidth Management and Priorit ization

Bandwidth management and traffic prioritization are generally used for the following purposes:• To ensure the quality of service for time-critical communications during occasional

traffic peaks. This may be necessary to ensure the quality of time-critical communications even if there is generally ample bandwidth available.

• To prepare for severe congestion caused by the loss of network links when there are technical problems. In a Multi-Link environment, you can have several network links. Ideally, the throughput of these links is large enough that each link can alone handle the traffic. However, if this is not a viable option, it may become necessary to choose which connections are given priority if network connections are lost.

Additionally, bandwidth limits are sometimes used to restrict non-essential services to reduce the total bandwidth needed:• If it is not possible to increase throughput of the network links or add new links,

important services, such as VPN connections to branch offices and clients’ connections to the company extranet can be given priority at the expense of employees’ Web surfing (for example, either generally for all HTTP connections or based on the Web servers’ IP address).

Implementation OptionsYou can prioritize traffic using the default QoS Classes and the default Prioritize policy if they provide enough granularity for you. Otherwise, you can create your own QoS Policies and QoS Classes. To configure bandwidth management, you must always create a custom QoS Policy, as you cannot overwrite the settings in the default policy.In addition to the configuration changes described above in Configuration of Limits, Guarantees and Priorities for Traffic, new firewall Access rules may need to be added to provide a higher degree of granularity, because each firewall rule can have only one QoS Class associated with it.As an alternative to access rules, priorities can be set based on DSCP codes present in the traffic, see Communicating Priorities with DSCP Codes, on page 289.


Designing QoS PoliciesEach QoS Class can appear in only one (active) rule in each QoS policy. This makes QoS Policy design simpler than access policy design, as the order of the rules is not significant. The classification of the traffic is made using Access rules, so the QoS rules’ task is to determine which limit, guarantee, or priority traffic marked with a certain QoS Class receives.All cells in the QoS rules are optional, except for the QoS Class, but at least one of the cells must be filled in a rule for the rule to have any effect on the traffic. None of the cells exclude any of the other cells, so you are free to select which cells you want to use for any given QoS Class.When you save the QoS policy, the system checks if there are contradictions within each rule, such as a rule that sets a limit that is lower than the guarantee for the same rule. When you install the policy on the firewall, the QoS Policies defined for the firewall’s interfaces are checked again, but this time comparing the policies to the throughput values you have set for the interfaces. At this point, the values may be automatically scaled down if the sum of all guarantees in a QoS Policy exceed the interface’s throughput. The values are never scaled up, though, so it is not necessary to define the use of all available bandwidth in your QoS policy. The bandwidth outside the guarantees as well as any bandwidth within the guarantees that is not used for actual traffic at any given time is used to handle the traffic that has no specific QoS rule on the normal first-come-first-served-basis using the medium priority of 8.

Note – If your guarantees are equal to the total throughput of an interface, any traffic without a guarantee will be completely blocked if all guarantees are fully used.

The values for the limits and guarantees can be entered either in kilobits or as percentages of the total interface throughput. Technically, nothing prevents you from using both ways of entering values even in the same rule. However, from the design point of view, it is best to choose one way of entering the values and follow it consistently throughout each QoS Policy. Using mixed methods of entering the values makes it more difficult for the administrators to read the policy and may prevent the system from checking for contradictions when you save the QoS policy, as the interface throughput(s) are not known at this point. If checks cannot be performed when the QoS Policy is saved, the checks are made at firewall policy installation, in which case mistakes in the QoS policy may prevent you from refreshing the firewall policy.

Assigning QoS Classes to TrafficYou have full control as to which traffic is assigned which QoS Class. Any Access rule can have its own QoS Class or the same QoS Class as one or more of the other Access rules. This way, you can assign a specific QoS Class to any traffic that you can define in a single Access rule.


If you want to prioritize traffic according to DSCP markers set by other network devices, or if you want to change such DSCP markers when the traffic goes through StoneGate, the QoS Classes are assigned and overwritten according to the QoS Policies of the source and destination interfaces, and the traffic must not match an Access rule that contains a QoS Class. See the section below for more details.

Communicating Priorities with DSCP CodesYou and your ISP may have routers that also make decisions on handling the packets based on the priority of the traffic. DSCP markers (DiffServ type of service fields) in the traffic are commonly used to indicate how network equipment prioritizes the traffic. You can communicate traffic priorities between StoneGate and other network equipment using DSCP to ensure the best possible quality of service for important traffic.The DSCP markers are always read and assigned a QoS Class according to the QoS Policy of the interface through which the traffic enters the firewall, and the DSCP markers in the packets are always changed or written according to the QoS Policy of the interface through which the traffic leaves the firewall.StoneGate internally uses priority values between 1 (highest priority) and 16 (lowest priority). These priority values, set in your QoS Policies, are the only values that StoneGate can follow. If you want StoneGate to prioritize traffic based on DSCP markers, you must use the QoS Policies to map the DSCP priority values to the desired StoneGate priorities.If you have a service level agreement (SLA) with your ISP that includes the prioritization of traffic, the priorities must usually follow priorities in the way defined by the ISP. If the priority levels are different in different networks, for example if you have Multi-Link Internet connections from two different ISPs that use different priorities for the same traffic, it may be necessary to set different priority values according to which link the traffic uses. You can do this by using a different QoS Policy for the different interfaces.Two QoS Policies can also be used together to “translate” between two different DSCP schemes as shown in Illustration 25.2.

Illustration 25.2 Translating Between Two DSCP Schemes


In the illustration above, the packets arrive at Interface 1. The firewall reads the existing DSCP value and compares it to the QoS Policy A assigned to Interface 1. The policy has a DSCP Match rule for the DSCP marker with an associated QoS Class called “Important”, which is then assigned to this traffic.

Note – This traffic must not match to any firewall access rule with a QoS Class definition, because the QoS Class in the access rule overrides the QoS Class that is assigned based on the DSCP marker.

When the packets are sent out through Interface 2, StoneGate checks the QoS Policy B assigned to this interface. In this QoS Policy, there is a rule that states that traffic with the QoS Class “Important” will be marked with a DSCP marker specified in the rule, and StoneGate now overwrites the original DSCP marker the packets had before reaching the firewall.

Managing Bandwidth of Incoming TrafficBandwidth management and prioritization usually help manage the quality of service for traffic going through Internet links, which are often the choke point in a corporate network due to the costs associated with increasing the bandwidth.Outbound traffic can be controlled easily and accurately with QoS policies, since the firewall has full control of what traffic it forwards. Controlling incoming traffic is more difficult, since by the time the firewall sees the traffic, the packets have already travelled through the congested links and taken their share of the limited bandwidth. Still, you may be able to limit some types of incoming traffic by controlling how your firewall passes the connections onwards. In this case, only limits have affect. To set guarantees and priorities to traffic, you must consider other solutions, such as to arrange with your ISP(s) that they implement traffic management before the traffic is passed to your Internet links.To limit the bandwidth incoming traffic consumes, you can apply the QoS Policy on the firewall interfaces that the traffic uses to exit the firewall into the internal network. When traffic is checked against the Firewall Policy, allowed traffic can be assigned a QoS class. At the interfaces towards the internal network, the QoS Policy is applied, and incoming traffic is thus restricted according to the limits set in the QoS Policy (Illustration 25.3).

Illustration 25.3 Applying QoS to Incoming Traffic


Limiting the bandwidth of incoming traffic is made possible because most applications scale down their transmissions when they notice that the transmissions do not get through as quickly as the applications send them. If the remote application does not scale down its bandwidth use, any limits you set have no effect. The only option in that case is to either increase the bandwidth or control the traffic before it enters the congested link (by your ISP).

Examples of Bandwidth Management and Priorit ization

The examples in this section illustrate some common uses for the bandwidth management features in StoneGate and general steps on how each scenario is configured.

Ensuring Quality of Important CommunicationsIn this example, Company A has two offices, one in Italy and one in France. The company has decided to replace most conventional phone lines with VoIP telephony to cut down on cost.

Illustration 25.4 Company A Networks

The illustration above shows the two offices and the traffic between them. Telephone and e-mail connections are both a very important tool for the employees, who use these services to communicate with team members at the other office. Additionally, employees at the Italian office must be able to use Web-based tools at the French site. The administrators determine the priorities as follows:• The VoIP streaming audio is not only important, but also a time-critical service, so it

must have the highest priority.• Even though business e-mail is important, it makes no real difference if the e-mails

are delivered immediately as they are sent, so this traffic can be assigned a lower priority.

• The Web-based services are not time-critical, but delays and time-outs may be annoying to the workers, so the company decides to give these a lower priority than VoIP, but a higher priority than e-mail.

The internal networks are so fast that there is no need to implement any QoS Policies for those interfaces, so only the interfaces towards the Internet need a QoS Policy. The Administrators decide that the same QoS policy can be used at both sites, and that


the default elements and the default Prioritize policy are suitable for use without customization. So now they:1. Add the QoS Class “High Priority” to access rules permitting VoIP traffic.2. Add the QoS Class “Low Priority” to access rules permitting e-mail traffic.3. Define the QoS Policy Prioritize to be used on the Internet interfaces at both the

Italian and the French firewall, along with the interface speeds.4. Refresh the policies of both firewalls.The administrators did not define a specific QoS Class for the medium-priority traffic because all traffic that is not specifically classified is assigned a medium priority.

Preparing for ISP BreakdownCompany B decides to use Multi-Link to ensure high availability of network connections for important business communications. The company, an engineering subcontractor, is mainly concerned about two types of connections:• A VPN connection they have for accessing the internal tools and resources of an

important client when doing work for them.• HTTPS connections to the extranet server that the company’s clients use to check

the status of projects.The company is on a tight budget, and the cost of having enough bandwidth in both links to handle all traffic even during peak hours is deemed too high. Therefore, they decide that only the two most important types of traffic must get through if one ISP link goes down during peak hours. The company determines that 500 kbps is enough to handle those connections, so they decide to subscribe to two different ISPs for one 512 kbps link from each. None of the communications are especially time-critical, so the company decides not to prioritize the traffic. Then the StoneGate administrators:1. Create a new QoS Policy and two new QoS Classes, called VPN and Extranet.2. Create the QoS rules for the important connections filling in the following cells:

3. Add the QoS Class “VPN” to the VPN rule for outbound traffic in the Firewall’s Access rules.

4. Add the QoS Class “Extranet” to the rule allowing the outbound connections from the company extranet.

5. Define the throughput speeds and the new custom QoS Policy to be used for both ISP interfaces on the firewall.

6. Refresh the policy of the firewall.

TABLE 25.2 QoS Policy for Company B

QoS Class Guarantee

VPN 400

Extranet 100


Limiting the Total Bandwidth RequiredCompany C has experienced a radical increase in the amount of network traffic. It seems that many employees have started to use bandwidth-intensive services, downloading large files and listening to Internet radio in high-quality mode while they work. The situation is getting to the point where business communications are starting to slow down. The management would rather prohibit connections that are not directly work-related than use company resources on increase the bandwidth.However, the StoneGate administrators suggest a different approach: limiting the portion of the bandwidth that the non-essential traffic can use so at least some of the employees can still listen to Internet radio while the business communications are guaranteed the bandwidth they need. To assure the quick delivery of time-critical business communications, they also decide to prioritize the traffic using the three default QoS classes. The administrators:1. Create a new custom QoS Policy with the following rules:

• Normal Priority traffic gets the largest guaranteed portion of the bandwidth because it has the largest volume.

• High Priority and Normal Priority traffic can each use up to 90% of the bandwidth. Low Priority traffic cannot consume more than 50% of the available bandwidth even if there is more bandwidth available. So, in this configuration, there must be traffic in at least two of the classes for the bandwidth to be utilized up to 100%.

• Even Low Priority traffic is given a guarantee of 5% of the bandwidth to avoid total loss of service, which would cause even more complaints from users than slowed-down service will.

2. Place a Continue rule at the top of the firewall Access rules that includes the Normal Priority QoS Class. This way, all traffic that is not specifically classified as High Priority or Low Priority is classified as Normal Priority.

3. Place the High Priority QoS Class into Access rules that permit important traffic, creating new, more detailed rules as necessary, and the Low Priority QoS Class to low-importance traffic in the same way.

4. Define the throughput speed and the new custom QoS Policy to be used for the Internet interface on the firewall.

5. Refresh the policy of the firewall.

TABLE 25.3 QoS Policy for Company C

QoS Class Priority Guarantee Limit

High Priority 1 35% 90%

Normal Priority 8 55% 90%

Low Priority 16 5% 50%



Logs, Alerts, And Reports

CHAPTER 26 Filters

Filters are descriptions of log fields and their values combined together with operations for the purpose of sorting log data. Filters can be used, for example, to select which logs are displayed in the Logs view or which logs will be archived or exported.


Overview to Filters, on page 298 Configuration of Filters, on page 298 Using Filters, on page 305 Examples of Filters, on page 306

297

Overview to Fi ltersNetwork traffic can generate a large amount of log data. It is important that administrators can choose just the necessary data for use. Filters serve as a tool for selecting the desired data from among all the log data. There are two kinds of Filters: permanent and temporary ones. You can use permanent and temporary Filters to select which logs are displayed in the Logs view. You can also use permanent Filters when you, for example, archive logs, or create reports from log data.

Configuration of Fi ltersYou can use predefined StoneGate Filters or create new Filters. Filters are mainly configured in the Filters branch in the Configuration view.

Illustration 26.1 Filter Properties

You can edit Filters in the Filter Properties dialog, which contains two panels. The right panel displays the Filter and the left panel lists the fields, operations, and resources that are used in the Filter.A Filter consists of one or more fields, operations, and field values. A field represents a field in log data. An operation defines how fields and their values in log data are compared to each other. In addition to permanent Filters, you can also create temporary Filters in the Logs view (see Temporary Filters and Browsing Logs Interactively, on page 306).

298 Chapter 26: Filters

You can create new Filter Types and give your Filters a type tag. Filters are displayed according to Filter Type in the Filters branch and the dialogs for selecting Filters. This makes it easier to find the correct Filter among all the available Filters.

Matching Log Data with FiltersStoneGate matches log data with Filters by comparing the fields in the log data with the fields in the Filters using the operations defined in the Filters. A simple Filter could consist of a single field and a single operation. It could be used, for example, for filtering logs from a certain IP address. A more complex Filter could contain several fields and operations.

Illustration 26.2 Matching Events with a Filter

Illustration 26.2 shows an example of the way a log event is matched with a Filter, when the Filter contains several fields and operations.First, the innermost operations are performed for the log data. To match the upper AND operation, the IP destination address must be in the 172.16.1.0/24 network, and the destination port must be 80. To match the lower AND operation, the IP destination must be in the 172.16.2.0/24 network, and the destination port must be 80.Second, the outermost operation is performed for the log data. To match the outermost OR operation in the example, at least one of the innermost AND operations must match.For example, an event indicating a connection to a server at 172.16.1.200 port 80 would match this example Filter. An event with a connection to a server at 172.16.1.200 port 21 would not match it.

Default ElementsPredefined StoneGate Filters are available in the Filters branch in the Configuration view. You cannot modify predefined Filters. They are imported and updated from dynamic update packages, so the selection and names of predefined filters may change when you update StoneGate. The predefined Filters are grouped according to type in the By Filter Type folder.


There are five kinds of predefined Filters, which are explained in the table below.

Configuration WorkflowThe following sections provide an overview of the configuration tasks related to Filters. Detailed step-by-step instructions can be found in the Management Client’s online help and the Administrator’s Guide PDF in the section called Elements.

Task 1: Create a New FilterIn addition to using predefined Filters, you can create both permanent and temporary Filters. You can also save a temporary Filter as a permanent one. For information on creating temporary Filters, see Temporary Filters and Browsing Logs Interactively, on page 306.

Task 2: Select FieldsWhen log data is filtered, the fields in the log data are compared to the field(s) in the Filter. The fields in the Filter allow you to select only the data that interests you among all the available log data.A Filter can have one or several fields. The number of fields depends on what kind of log data you are interested in. The more fields you have in the Filter, the more specific the selection of log data becomes. For example, if you are interested in traffic from a certain source IP address, you can use the “IP source” field in the Filter and get a selection of log data that matches the source IP address of your choice. To limit the selection of log data even further, you could define what kind of traffic (for example, HTTP or FTP) interests you.

TABLE 26.1 Predefined Filters

Predefined Filters Explanation

Action Filters Filters that match different actions (for example, Allow or Discard).

Alert FiltersFilters that match different alerts (for example, Active Alert or Not Alert).

Protocol Filters Filters that match different protocols (for example, FTP or IP)

Situation FiltersFilters that match different situations (for example, Aggressive Port Scan).

General FiltersOther Filters that match other criteria in network traffic (for example, Match All or Match None).


Task 3: Select OperationsOperations define how field values in log data are compared to the field values defined in the Filter. You can have one or several operations in a Filter.There are three operation types to choose from: • Calculation operations are used for basic calculations, such as summing field

values. See Table 26.2 for details.• Comparison operations are used for comparing fields with field values: between,

defined, equal to, greater or less than, and so on. See Table 26.3 for details.• Logical operations are used for the AND, OR, NOT types of logical operations. See

Table 26.4 for details.You can use different operation types in the same Filter. The operation types are explained in detail below.

TABLE 26.2 Calculation Operations

Operation Description

bitwise ANDBitwise AND operation is done bit-by-bit on the provided values. This means that the resulting value of any given bit is “1” only when it has the value “1” in both of the values to be compared.

sum of Sums the values of the defined fields.

TABLE 26.3 Comparison Operations


betweenMatches when the value on the left-hand side of this operation is in the range of the right-hand side.

containsMatches when the element on the left-hand side of this operation contains one of the elements on the right-hand side.

defined

Matches when the field is found in the log data.If this operation is not used for checking that a certain field is found in the log data, the Filter applies the Undefined Value Policy setting for missing fields as explained in Table 26.5.

equal toMatches when the value on the left-hand side of this operation is equal to the value on the right-hand side.

greater thanMatches when the value on the left-hand side of this operation is larger than the value on the right-hand side.


greater than or equal

Matches when the value on the left-hand side of this operation is larger or the same as the value on the right-hand side.

inMatches when the element on the left-hand side of this operation belongs to the element on the right-hand side.

is false Matches when the value of a Boolean type of field is false.

is true Matches when the value of a Boolean type of field is true.

like (case insensitive)

Matches when the value on the left-hand side of this operation is equal to the right-hand side without considering character capitalization.

like (case sensitive)

Matches when the value on the left-hand side of this operation is equal to the right-hand side when considering character capitalization.

map size exceeded

Matches when the size of the selected map structure is exceeded.

require all occurrences of

Matches only when all the values match.

require any occurrence of

Matches when any of the values matches.

less thanMatches when the value on the left-hand side of this operation is smaller than the value on the right-hand side.

less than or equalMatches when the value on the left-hand side of this operation is smaller or the same as the value on the right-hand side.

TABLE 26.4 Logical Operations


AND (Require all of)

Matches when all of the operations in the Filter are true.

OR (Require any of)

Matches when any of the operations in the Filter is true.

NOT Matches when all of the operations in the Filter are false.

TABLE 26.3 Comparison Operations (Continued)



Task 4: Add Field ValuesYou must add one or more values (for example, an IP address or a port number) to each field in the Filter. When you use the Filter, the field values are compared to the values the fields have in log data to select the logs that match the Filter.

Task 5: Define Handling of Missing FieldsIn addition to selecting fields, operations, and field values, you can define how log data is filtered if one or more of the fields in the Filter are not found in log data. For example, you may have used the destination address field in the Filter, but destination address is not found in audit logs. By default, log data matches the Filter only if all the fields in the Filter are also found in log data. This is set by the default setting False by comparison for Undefined value policy. If you are only interested in logs that have all the fields in the Filter, you do not need to define how missing fields are handled. If you want to define in more detail how missing fields are handled, you have two options:• The Defined operation (one of the Comparison operations) allows you to define

which fields in the Filter the log data must always have. • The Undefined value policy setting defines whether log data matches the Filter if

there are missing fields.The Defined operation is particularly useful if you use a complex Filter with many fields, but you are only interested in logs that always have certain fields.

Illustration 26.3 Using the Defined Operation in a Filter

Illustration 26.3 gives an example of the use of the Defined operation. Both of the AND operations require that the log data has the fields preceded by the Defined operation (the IP destination and Destination port fields). The log data that does not have these fields would not match the Filter. You can use one of the four Undefined value policy settings to define how missing fields are handled. The setting works differently depending on the structure of the Filter. The results of logical operations (AND, OR, NOT) in the Filter depend on the


Undefined value policy setting. A logical operation is usually either true or false. However, if one or more of the fields in the Filter are missing from the log data, the logical operation may also be undefined. For example:• An AND operation can only be true if all of the operations under it in the Filter are

true. If one or more of the operations under it are undefined because of fields missing from the log data, the AND operation is also undefined.

The Undefined value policy settings are described in Table 26.5.

These four different Undefined value policy settings are compared below with an example.

TABLE 26.5 Undefined Value Policy Settings

Setting Description

False by comparison

The default setting. A Comparison operation is false if log data does not have all the fields used in the Filter. It depends on the structure of the Filter whether the log data matches the Filter or not. For example, if the outermost operation in the Filter is AND, the log data does not match the Filter if any of the inner operation is false.

False by filterLog data does not match the Filter (the Filter is false), if the outermost operation in the Filter is undefined because log data does not have all the fields used in the Filter.

True by filterLog data matches the Filter (the Filter is true), if the outermost operation in the Filter is undefined because log data does not have all the fields used in the Filter.

Undefined

If the outermost operation is undefined because log data does not have all the fields used in the Filter, the undefined result is passed to the software component that uses the Filter. The handling of the undefined result varies according to the StoneGate component that uses the Filter.

In most cases, this setting works in the same way as False by filter. If the outermost operation is undefined because log data does not have all the fields in the Filter, the data does not usually match the Filter. However, the IPS Analyzer handles the undefined result as True by filter, which means that the log data matches the Filter.


Illustration 26.4 Undefined Values When Matching an Event

The example Filter in Illustration 26.4 has the IP destination and Destination port fields. ICMP traffic, for example, does not have the Destination port field. If ICMP traffic is matched with the example Filter, the filtering results vary according to the selected Undefined value policy setting:• False by comparison: The AND operations are false. As a result, also the OR

operation is false. The event does not match the Filter.• False by filter: The AND operations are undefined (neither true nor false). As a

result, also the OR operation is undefined. The setting interprets the undefined result as false. The event does not match the Filter.

• True by filter: The AND operations are undefined (neither true nor false). As a result, also the OR operation is undefined. The setting interprets the undefined result as true. The event matches the Filter.

• Undefined: The AND operations are undefined (neither true nor false). As a result, also the OR operation is undefined. The Undefined setting passes the undefined value to the StoneGate component that uses the log data. The handling of the data varies according to the component. Most components handle the data in the same way as False by filter, so that the event does not match this Filter. The IPS Analyzer, in contrast, handles the undefined value as True by filter, so that the event matches the Filter if the Filter is used by the Analyzer.

Task 6: Define A Type for the FilterYou can optionally add a type tag to the Filter to group it with other Filters of the same type. You can then look for the Filter according to Filter Type when you later want to use it.

Using Fi ltersFilters are a useful tool in selecting just the necessary log data for closer inspection.You can use Filters for:• browsing logs, alerts, and audit data• checking alert event traces• pruning log data (see Log Management, on page 309)• archiving, exporting and deleting logs, alerts and audit data (see Log Management,

on page 309)• creating reports (see Reports, on page 335).

Using Filters 305

Temporary Filters and Browsing Logs InteractivelyLogs and alerts often require active filtering to display events of interest. You can create temporary Filters for browsing logs interactively in the Query panel in the Logs view.You can select one or several fields from the log data and use them as a new temporary Filter. You can also add new fields to the temporary Filter you have created.In addition to the temporary Filters, you can also select permanent Filters for use. You can enable/disable Filters and negate the Filter to view the logs that specifically do not match the Filter. The filtering can be defined to display events that match all the Filters (AND operation), or alternatively events that match any of the defined Filters (OR operation). You can also save temporary Filters in the Query panel. If you do not save the temporary Filters, they will be discarded when the Logs view is closed.

Examples of Fi ltersThe examples in this section illustrate common uses for Filters and general steps on how the scenarios are configured.

Creating a Temporary Filter in the Logs ViewThe administrator at Company A wants to create a Filter for viewing logs containing a certain IP address in the Logs view. To do this, the administrator:1. Selects a log entry with the desired IP address in the Logs view.2. Selects the IP address in the Details panel and creates a temporary Filter based

on the IP address.

Creating a Filter for Logs Concerning Authenticated UsersCompany B wants a report of StoneGate users who have authenticated themselves within a certain time frame. To create the report, the company’s administrator needs a Filter to select the logs concerning the authenticated users. The administrator:1. Creates a new Filter.2. Selects the Auth. User field to filter the user names of authenticated users.3. Selects the “equal to” operation.4. Adds the wildcard “*” as the value to the Auth. User field to match all

authenticated users in log data.

Creating a Filter for Pings in a Network Excluding a HostCompany C’s administrator has noticed that the number of ping attempts (ICMP echo requests) in the internal network has increased. The administrator wants a report of all the pings that have been made lately in the local network to make sure, for example, that the servers in the internal network have not been taken over by an outsider. The administrator frequently pings from the HOST2 workstation in the


internal network. The administrator wants to create a report of the ping attempts and wants to exclude pings from HOST2 from the report. The administrator needs a new Filter for generating the report. The administrator:1. Creates a new Filter in which the source IP address field in log data is compared

to the internal network’s addresses and the ICMP type is compared to Echo.2. Adds a condition that the IP address in the log data may not belong to the

HOST2 workstation.

Illustration 26.5 Filter Excluding A Host

Examples of Filters 307


CHAPTER 27 Log Management

Log management is the process of configuring when logs are produced, which of the produced logs are stored, and when stored logs can be deleted or archived.


Overview to Log Management, on page 310 Configuration of Log Management, on page 311 Using Log Management, on page 317 Examples of Log Management, on page 319

309

Overview to Log ManagementStoneGate logs network traffic as well as important events of the system operation. Log entries are the fundamental resource for checking and proving your system. For example, logs are useful when troubleshooting common network issues. In addition, logs enable you to analyze network traffic to justify the need for extra resources or other actions to make the service more functional. Log entries also provide forensic evidence if malicious activities are detected in the inspected traffic. Log data does not need to be stored forever. Entries older than a certain time, standard HTTP requests to Web servers, and similar routine entries can be costly to archive. We recommend deleting routine or expired entries to avoid slowing the system or consuming too much storage space. You can schedule automatic log management tasks for this.The same log management tools can be used for StoneGate Firewall/VPN, StoneGate IPS, as well as StoneGate SSL VPN logs. The correlation of logs from the Firewall, the IPS, and the SSL VPN allows you to form a comprehensive picture of what is going on in the network at any given time.

Logs ViewThe Logs view allows you to either view current log entries as they arrive to the Log Server or browse historical data stored in the log files, including alert and audit entries. In addition to Firewall logs, the Logs view also displays IPS and SSL VPN log entries and alert entries. Log, alert and audit entries internally use UTC (GMT) timestamps for easy use in environments that span across timezones. By default, log browsing uses the local timezone set in the operating system of the computer on which the Management Client runs. You can select the timezone for log browsing in the task bar of the Logs view.

Log EntriesLog entries are most often records of connections that pass through the firewall, triggered by a match in an access rule that has an option that calls for a log entry to be generated. Each connection can be logged, but that may take up excessive disk space and bandwidth. Because of this, we recommend logging only traffic that deserves more scrutiny. The system can also produce detailed Diagnostic logs that give you information on troubleshooting a particular feature of StoneGate.

Alert EntriesAlert entries are notifications of events that require the administrator’s attention. In addition to alerts that are produced by matches to rules that have the logging option set, alerts can also be produced by a test failing, by a monitored element becoming unreachable, by problems related to the functioning of the system, and by failures in communications between the system components. Problems in the operation of the system trigger a predefined System Alert. You can also create custom alerts.

310 Chapter 27: Log Management

Because alert entries require the administrators’ immediate action, they are presented more visibly than other information in the Management Client, for example, in the System Status view and in the Logs view. They can also be escalated so that notifications are sent out from the system to the administrators.For more information on alerts, see Alert Escalation, on page 323.

Audit EntriesAudit entries provide a record of what has happened in the Management Center, such as creation, modification and deletion of elements, administrator logins, and the execution of scheduled tasks. Audit data does not include information on installing or uninstalling management system components, or on any firewall-related events that are already reported to the Log Server. Only administrators who have been granted permission to browse audit logs have access to audit data. By examining the audit logs, it is possible to trace, for example, what kind of administrator actions have been performed and by whom. This data may prove to be important when trying to figure out possible configuration errors and in other comparable events. When a secondary Management Server is configured in the system, audit entries are replicated between the primary and secondary Management Servers.For more information on audit entries, see Audit Entry Types, on page 447.

Configuration of Log ManagementThe following illustrations demonstrate how different log data is logged and stored in StoneGate.Illustration 27.1 shows the processing of log entries.

Illustration 27.1 Log Entry Processing

Events on Firewalls produce log entries, which are sent to the Log Server. The Log Server then stores the entries or just relays them to the Logs view to be viewed in the Current Logs mode, depending on the type of the log entry.Illustration 27.2 shows the processing of alert entries.


Illustration 27.2 Alert Entry Processing

All the StoneGate system components can send alert entries. The alert entries are sent to the Log Server where they are stored.Both the Management Server and the Log Server can send audit entries. The audit entries are stored on the Management Server or the Log Server that originally created them.Sometimes a certain rule generates both useful and unnecessary log entries. In such a case, it is sometimes easiest to reduce the amount of logs by pruning log entries. Alert entries and audit entries cannot be pruned.

Illustration 27.3 Pruning Log Entries

Illustration 27.3 shows the pruning of log entries. The Log Server receives log entries from the firewall nodes. All log entries that the administrators consider irrelevant can be discarded automatically using the Immediate Discard filters. The Immediate


Discard filters delete all the log entries that match the defined filters immediately as they arrive to the Log Server. The log entries passed through these filters are displayed in the Management Client’s Logs view (if the Current Logs mode is activated).The Discard Before Storing filters are used for filtering out log entries before they are stored. For example, troubleshooting messages may be useful in the Current Logs mode but they may not be needed in the log files. Thus, the Discard Before Storing filters can be used to avoid storing events that are needed only temporarily in the Management Client. Any log entries that are stored can be freely browsed in the Logs view at any later time.The log entries are stored in log files. If these files are not removed, they will eventually fill up the entire drive. Log Data tasks can be used for managing the logs by deleting, archiving and exporting information in the log files. In addition to executing the tasks manually, the tasks can also be scheduled to be executed automatically at regular intervals.You can generate reports based on stored log entries, see Reports, on page 335.

Default ElementsFilters are an essential tool for handling StoneGate logs. The same filters can be used for multiple filtering tasks: to reduce the amount of generated log data and discard irrelevant events, to select log entries for display, or to export and archive logs. You can use predefined filters and also create new filters.For more information on filters, see Overview to Filters, on page 298.

Configuration WorkflowThe following sections provide an overview of the configuration tasks related to configuring and customizing Log Management. Detailed step-by-step instructions for configuring the elements and policies can be found in the Online Help of the Management Client and the Administrator’s Guide PDF, in the section called Monitoring.

Task 1: Set Log Spooling PolicyThe Log Spooling Policy is configured in the Advanced Settings tab of each Firewall engine.When the Log Server is unreachable or stops because the disk is full, logs are temporarily spooled on the Firewall engines and delivered to the Log Server when it becomes available again. However, if available space on the /spool/log partition of the Firewall engine begins to run out as well, logs are discarded in four stages according to the amount of available space left.• Stage 1: Some monitoring data is not sent to the Management Server. Status and

load values are still sent to the Management Server. An Alert warning that the Firewall engine’s buffers are reaching capacity is generated.


• Stage 2: Only log entries marked as Essential and Alerts are stored on the Firewall engine. Log entries marked Transient and Stored are discarded. If the Stop Traffic option is specified in the Firewall’s Advanced Settings, traffic processing stops and the node sends itself offline. If the Discard log option is specified in the Firewall’s Advanced Settings, the process continues to stage 3.

• Stage 3: Only Alerts are stored on the Firewall engine. No log entries are stored, not even log entries marked as Essential.

• Stage 4: If the connection to the Log Server still has not been restored and the Firewall engine’s disk is almost full, all logging and alerting stops. However, traffic is still processed by the Firewall.

Caution – .Do not modify the advanced settings without due consideration. An invalid configuration of the parameters may lead to system instability or malfunction.

Task 2: Set Logging OptionsBefore log data of traffic handled by the firewall nodes can be viewed or used in any meaningful way, the logging options for access and inspection rules must first be configured in the Firewall Policy.By default, an access rule’s logging level is set to Undefined. The log entry triggered by the rule in question will be handled by default as a Stored-type log entry (it is stored in the Log Server archives). An inspection rule’s logging level is also Undefined by default, but an event that matches the rule will not produce any log entry. You can override the default logging levels by setting another logging level in the access or inspection rule. The default logging levels will also be overridden, if there is a prior matching rule with the action set to Continue. In that case the access or inspection rule will use the logging level set in the Continue rule.Table 27.1 explains the logging levels.

TABLE 27.1 Log Levels

Log Level Explanation

Alert An alert entry is generated.

Stored A log entry is generated and stored on the Log Server.

Essential

When the Log Server is unavailable, log entries are temporarily stored on the Firewall engine. When the Firewall engine is running out of space to store the log entries, it begins discarding log data in order of importance (see Log Files, on page 318 for more information).


You can further modify the access rule’s logging options by choosing whether log accounting information is generated for connections that match the access rule. Log accounting data is generated at the end of a connection. It contains information on the elapsed time and the number of bytes sent and received. You must collect this data if you want to generate reports based on traffic volumes.In the inspection rule’s logging options you can also choose to store the packet payload data extracted from the traffic that matches the inspection rule. Storing the packet payload data provides information to additional log fields according to traffic type. The additional log fields are listed in Log Fields Controlled by the Additional Payload Option, on page 454.

Task 3: Configure Log PruningYou can manage the amount of log data by defining log pruning in the Log Data Pruning view. Log pruning is needed, for example, when a certain rule generates both useful and unnecessary log entries. Log pruning gives you the ability to discard newly-generated irrelevant log entries at the Log Server. Only administrators who have the right to manage log pruning have access to the Log Data Pruning view.

TransientA log entry is only available for immediate display in the Logs view and is not stored.

None The rule does not produce any log entries.

TABLE 27.1 Log Levels

Log Level Explanation


Illustration 27.4 Log Pruning

Illustration 27.4 shows the two pruning options available for the log entries: Immediate Discard, which deletes log entries immediately as they arrive to the Log Server, and Discard before Storing, which deletes log entries before they are put in the active storage directory, allowing administrators to view the log entries in the Current Logs mode in the Logs view before they are deleted (in effect, this option converts Essential or Stored type log entries into Transient log entries). The log entries are pruned by selecting filters for these two pruning stages. The pruning is then done as described in Illustration 27.3 on page 312. Only logs can be pruned: alerts and audit entries are never pruned.

Caution – Be careful when defining the pruning filters. The matching log events are irreversibly deleted at the Log Server. It is preferable to adjust log generation options instead of letting log entries be generated and then pruning them, as this wastes system resources.

Task 4: Define Log TasksLog Tasks are used for exporting, archiving, and deleting logs. Only administrators who have the right to manage logs can create and run log tasks. Exported logs can be imported to other applications using tabulated CSV files or XML. It is also possible to schedule these tasks to run automatically. The greater the volume of log data, the more such operations are needed. For example, if the number of stored log entries is


constantly high, it may be useful to export and delete logs automatically according to suitable filters and schedules.You can define log tasks and run them manually as necessary or automatically according to a schedule. There are predefined log tasks for exporting, archiving, and deleting logs. The task properties define what each task does when executed. Table 27.2 explains the different types of log tasks and the operation types for the export task.

You can specify a starting time and frequency for the defined tasks. The starting time is defined in the Management Client’s local time. This needs to be taken into account if the Log Server has a different time zone.

Using Log ManagementThere are many ways to configure log management and to make it easier and more efficient. You can, for example, use filters to delete unnecessary logs and specify log data tasks for archiving, deleting and exporting logs.

TABLE 27.2 Log Task Types

Log Task Explanation

Export Log Task

Export XML: Copies the selected log data to a separate file in XML format. You can use the file in other applications, for example, spreadsheet applications. The exported data is not removed from the log files.Export CSV: Copies the selected log data to a separate file in comma-separated (CSV) format. You can use the file in other applications, for example, spreadsheet applications. The exported data is not removed from the log files.Export IPS Recordings as PCAP/Snoop: Exports IPS and Firewall traffic recordings to be viewed in an external application in PCAP or Snoop format. The exported data is not removed from the log files.

Archive Log Task

Copies the selected log data to separate files in StoneGate log file format. The archive task can optionally also delete the original data after it has been copied. It can also delete some other set of selected data.

Delete Log TaskDeletes the selected data from the current log files on the Log Server.

Using Log Management 317

Log FilesA separate log file is created for the logged events each hour. The log files are stored by default in the <installation directory>/data/storage/ directory on the Log Server. The log files have the following naming: YYYYMMDD_hh_C<ORIGINATOR>_MMDDhhmmsssss.arch.• The date YYYYMMDD_hh refers to the date and hour of the logged events. • The rest of the file name starting with “_C” refers to the file creation date and the <ORIGINATOR> refers to the originator of the logged events (this can be the Component ID number with the IP address of the originator, for example, “C28__192.168.10.21”).

The dates in the file name use UTC (GMT) time.It is important to ensure that there is enough free disk space for logging. If the Log Server approaches the maximum disk capacity, you will receive an alert notification. You must quickly respond to the capacity alert. If the Log Server continues to operate without intervention at that point, it will eventually fill the disk and stop working until you clear the log data.

Caution – When you receive the “Log Server, disk near capacity” alert, you must take immediate action to prevent the Log Server from stopping due to low disk space.

Additional Archive DirectoriesLog files are archived by default in the Log Server’s default archive directory. You can define up to 32 alternative or additional directories to archive some or all of the logs for example on a network drive. This will free resources on the Log Server. See Advanced Log Server Configuration, on page 459 for details.

Enabling/Disabling DiagnosticsIn addition to standard log messages, additional diagnostic information can be displayed in the Logs view to troubleshoot the StoneGate system. Such diagnostic information can be useful in determining why a VPN connection, user authentication, or some other feature does not function properly.

Acknowledging AlertsNew alerts are in the active state and they remain active until an administrator acknowledges them. After you receive an alert notification, you must acknowledge the alert in the Logs view. When you acknowledge an alert, the alert is no longer processed and no more notifications are sent.


In the Logs view, the properties of each acknowledged alert display the alert event traces, that is, the information on the sent notifications, the administrator who acknowledged the alert and when, etc.

Alert EscalationIn a system with default settings, administrators must actively monitor the system to notice any alert entries signalling problems in the system’s operation. Alert escalation can be set up to send messages out from the StoneGate system to draw the attention of administrators concentrated on other tasks. See Alert Escalation, on page 323.

Exporting Log Data to Syslog ServersLog entries that pass the Immediate Discard filters can be exported from a Log Server to external syslog servers. The log entries are selected for syslog by using filters.

Note – The timestamps in syslog messages use the Log Server’s local time.

Combinations of a filter type and match can be used to specify criteria for sending log data to the syslog server. Filter settings are utilized only if you have defined filtering profiles for the data to be transmitted.Filters can be created in the Management Client and then exported to a file to be used for syslog filtering. The data to be sent to the syslog server will be filtered based on the filters and the settings in the Log Server’s configuration file.See Advanced Log Server Configuration, on page 459 for details.

Examples of Log ManagementThe examples in this section illustrate some common uses for log management in StoneGate and general steps on how each scenario is configured.

Archiving Old LogsLast month’s logs are taking up too much disk space on the Log Servers at Company A, but some of the logs are still needed for the company’s records. The administrators decide to archive the needed logs on another server and to delete last month’s log data from the Log Servers. Because not all the logs from last month need to be archived, they delete the unnecessary logs altogether. They want to repeat the same archiving operation once a month from now on. To do this the administrators:


1. Create a new Archive Log Task for archiving the data with the following settings:

2. Save the new Archive Log Task. 3. Create a new Scheduled Task for running the Archive Log Task and set it to be

repeated monthly.4. Save the Scheduled Task.

Filtering Out Irrelevant Logs

Illustration 27.5 Company B’s Network

Server A provides services to users in Network X, as well as to Server B. The administrators are interested in tracking how many of the users in Network X actually use Server A. Server B also connects frequently to Server A, and generates a large amount of traffic.Since Server B makes very frequent connections to Server A and the administrators are only interested in connections from other hosts in Network X to Server A, the administrators decide to eliminate logs that are a result of Server B’s connections. All hosts in Network X including Server B are currently logged according to a single rule. Creating a separate rule to handle just the Server B connections with logging set to “None” would create unnecessary clutter in the policy. The administrators decide to set up log pruning to filter the logs so that only the relevant ones are stored on the Log Server. To do this the administrators:

TABLE 27.3 Archive Log Task for Company A

Option Setting

Time Range Last Full Month

Filter for CopyingA custom filter which matches the important log data that the administrators want to archive.

Filter for Deletion Match All to delete all last month’s logs from the Log Server.

Archive Target Directory

A network drive.


1. Select one of the irrelevant log entries in the Logs view.2. Create a temporary filter based on the log entry, and save the filter as a

permanent filter.3. Add the new filter to the Discard Before Storing list in the Log Data Pruning view.



CHAPTER 28 Alert Escalation

Alert Escalation means defining when and how the system notifies the administrators when an alert entry is created.


Overview to Alert Escalation, on page 324 Configuration of Alert Escalation, on page 324 Using Alert Escalation, on page 330 Examples of Alert Escalation, on page 332

323

Overview to Alert EscalationAlert entries inform the administrators if there is a problem with the StoneGate system or firewall engines, a test or a task has failed, or a certain inspection or access rule has matched. Alert entries can be viewed in the Logs view just like log entries and audit entries.By default, notifications of new alert entries are shown in the Management Client and administrators must be logged in to the system to notice that an alert entry has been triggered. You can also configure StoneGate to send alert notifications out from the system as e-mail, SMS text messages, SNMP traps, or have alert entries trigger the execution of your own custom scripts that define some other action to be taken. You can define each aspect of the process in very fine detail, for example, differently for different administrators, for different types of alert entries, and different times of the day.

Configuration of Alert EscalationElements related to alert escalation are stored under Alert Configuration in the Configuration view.

Illustration 28.1 Alert Handling Process

1. The Firewall nodes send alert entries to the Log Server when a matching access or inspection rule contains an Alert element in its rule options or when a failure is detected in a running test that is correctly configured. Depending on the engine version and hardware, the nodes may also send alert entries about changes in their status (for example, changes in interface or hard disk the status of the nodes’ interfaces or hard disks). The Management Server sends alerts to the Log Server if a task (for example, a policy installation or backup task) fails or if critical system events occur. When a secondary Management Server is configured in the system, only the currently active Management Server sends alerts.

1

3

2

4

324 Chapter 28: Alert Escalation

2. The Log Server receives the alerts and stores them. At this point, administrators can view alerts through the Logs view.

3. When an alert is received, the Log Server matches it to the Alert Policy installed on the Log Server. The Alert Policy rules define which alerts are escalated through Alert Chains based on the component that sent the Alert entry and what the related Alert element is.

4. The Alert Chains define which administrators receive notifications, and in which order and in which ways those notifications are sent. The Alert Chains are a combination of:• Alert Channels, which can include a user notification in the status bar of

Management Clients, an e-mail, an SMS text message, an SNMP trap, or an action defined in an external script.

• Delays that allow time for the administrators to acknowledge the alert before the next notification is sent.

For example, an Alert Chain can first notify one of the administrators by e-mail, wait for acknowledgement for 10 minutes, and if the alert is not acknowledged in time, StoneGate can notify this or some other administrator with a mobile phone text message. Alert notifications are sent until the alert is acknowledged in the Logs view by one of the administrators, or when the Alert Chain is completed.

Default ElementsThe system includes default elements for escalating alerts. The default alert escalation policy is configured and used right after installation when you start the Log Server. The only alerts you will receive without further configuration are alerts that are triggered by problems in StoneGate’s operation.By default, all alerts are escalated through the User Notification channel to all administrators. The User Notification displays a small blinking icon in the bottom right corner of the Management Client whenever new alerts are received. The icon works as a shortcut that can be used to open the Logs view and display the alerts.The default configuration includes the following elements:• System Alert element: the System Alert is used for alerts triggered by critical

events in the operation of StoneGate, including tasks (for example, a policy installation or backup task) that fail. (See Default System Situations below.)

• Default Alert element: the Default Alert is used by default in default inspection rules. You can use it in policies to define when you want to trigger an alert.

• Test Alert element: the Test Alert is used to test Situations. You can use it in policies to define when you want to trigger a test alert.

• Default Alert Policy: the Default Alert Policy contains a rule that escalates all alerts using the Default Alert Chain.

• Default Alert Chain: the Default Alert Chain escalates all alerts to all administrators using the User Notification channel (as explained above).


• Default System Situations: the Default System Situations contain definitions for problems in the system that trigger a System Alert. There are no configurable parameters for Default System Situations.

Default System SituationsStoneGate has predefined Default System Situations for both the Firewall and IPS to represent certain critical system events. These situations trigger a System Alert. The Default System Situations are not configurable and they are not used in Firewall policies. However, when you configure alert escalation, make sure that your custom Alert Policies escalate the System Alerts as well, because the System Alerts always require administrator action.

Configuration WorkflowThe following sections provide an overview of the configuration tasks related to customizing alert escalation. Detailed step-by-step instructions for configuring the elements and policies can be found in the online help of the Management Client and the Administrator’s Guide PDF, in the section called Management Center Configuration.

Task 1: Define Custom AlertsIf you prefer not to use the Default Alert element, you can define your own custom Alert elements. This allows you to define a customized alert message and the SNMP code for each kind of alert if you want to set up StoneGate to send SNMP traps when alerts are triggered.The alerts you see in the Logs view contain much more information than you define for your custom Alert element; alert entries are always triggered by some event, and information regarding the event (such as the Situation that matched in an inspection rule) is automatically included in the alert entry in the Logs view and when the alert entry is escalated (how much information is included depends on the Alert Channel).

Task 2: Define Alert ChainsAlert Chains define how, in which order and to whom the notifications on alert entries are sent.

Illustration 28.2 Alert Chain


Alert Chains contain a list of actions that are executed from top to bottom. Each row in an Alert Chain defines a Channel and a Destination address for the notification. The available alert channels are explained in the table below.

Each Alert Chain row also contains three optional fields:• The Threshold to Block field is used to limit the maximum number of notifications

sent within a defined time period.• The Delay field defines the number of minutes before processing the next row in

the alert chain.• You can add a free-form comment to the rule in the Comment field.The last row of each Alert Chain is a Final Action that you can configure according to what you want to happen when the end of the Alert Chain is reached without anyone

TABLE 28.1 Alert Channels

Alert Channel Description

CUSTOM SCRIPTExecutes a script stored on the Log Server. The Destination cell must contain the name of the script.

DELAY

Does not send any notification. Instead, the DELAY channel allows you to add a delay without taking any action. Because any of the other rows can also set a delay, the DELAY channel is most useful if you want to add a delay at the top of the Alert Chain before any action.

SMSSends a text message using a GSM mobile phone you attach to the Log Server. The Destination cell must contain the mobile phone number the text message is sent to.

SMTPSends an e-mail. The Destination cell must contain e-mail address(es) in a form that your SMTP server is able to use.

SNMPSends an SNMP trap. The Destination cell is not used with this channel.

USER NOTIFICATION

Adds a blinking icon in the bottom right corner of the Management Client. The Destination cell may be set to ANY or it may contain particular Administrator elements.


acknowledging the alert entry in the Logs view. The Final Actions are explained in the table below.

Task 3: Define Alert PoliciesThe Alert Policy defines if any particular alert entry is escalated or not. An Alert Policy contains rules for matching incoming alert entries. Alert entries that match an Alert Policy rule are escalated to the Alert Chain defined in that particular rule. If an alert entry does not match any rule in the Alert Policy, the alert entry is not escalated.The fields in Alert Policy rules are explained in the table below.

TABLE 28.2 Final Actions

Final Action Explanation

None Stops the escalation of this alert entry.

Acknowledge

Acknowledges the alert entry automatically, so that it is not shown as an active alert entry anymore.Use this option with care, as acknowledging the alert entry makes it unlikely that administrators would notice the existence of the alert entry in the Management Client.

RedirectContinues the alert escalation from the top of the Alert Chain you select in the second pull-down menu.

ReturnReturns the processing to the Alert Policy. The processing continues from the next rule below the rule that redirected the processing to this Alert Chain.

TABLE 28.3 Alert Policy Fields

Field Explanation

SenderAllows you to limit the rule to match alerts entries generated by one or more particular StoneGate components.

Alert and SituationAllows you to limit the rule to match alert entries that are based on one or more particular Alert elements or Situation elements.

TimeAllows you to limit the time of day and weekdays when the rule is active. The time parameter allows, for example, defining different notifications for weekends or night time.


Alert Policies are stored on the Management Server and you must install the Alert Policy on a Log Server whenever you change the Alert Policy rules or the Alert Chains used by those rules (even if the Log Server is installed on the same computer as the Management Server). If the Log Server has no Alert Policy installed, alert entries are escalated according to the Default Alert Policy.

Task 4: Configure Alert ChannelsTo use the Alert Channels, most alert channels require that you first configure that Alert Channel’s parameters in the properties of the Log Server element(s). The Alert Channels that require configuration are presented in the table below.

As the different Alert Channels have varying possibilities for relaying information, the amount of information the alert notification gives regarding the Situation depends on

Severity

Allows you to limit the rule to match alert entries that have a Severity value from within a certain range, so that you can, for example, escalate only the most severe alerts, say, those with a severity between 8 and 10 using the e-mail Alert Channel, and then escalate the other alerts only through a User Notification in the Management Client.

ChainDefines the Alert Chain that is used for escalating matching alert entries.

Comment Your optional free-form comment for this rule.

TABLE 28.4 Configurable Alert Channels

Alert Channel Configuration

Custom Script Define the absolute path to the script to be executed.

SMTP (E-mail)Define the SMTP server’s address and the sender information that is used in the e-mail: the e-mail sender name and return address.

SMS (Text Message)Define the COM Port with a connected SMS-capable GSM mobile phone or modem. You must also type in the PIN Code if the mobile phone requires the PIN code.

SNMP Define the SNMP Gateways used.

TABLE 28.3 Alert Policy Fields (Continued)

Field Explanation


the Alert Channel used. The information included in alert notifications is detailed by Alert Channel in the table below.

Using Alert EscalationSome form of alert escalation is useful in any environment to attract the attention of the administrators to at least those alert entries that indicate problems in the StoneGate system components, and possibly alert entries related to a test that fails or the Firewall policy’s access or inspection rule that has matched traffic.Alert escalation is highly configurable, so you can for example:• Define which alert entries are escalated to which administrators based on who is

responsible for which components.• Configure different alert escalation rules for weekends and evenings.• Set up alert escalation so that if administrators responsible for, say, a branch office

site do not acknowledge an alert, the alert escalation continues to administrators at a nearby site or at the headquarters.

Designing Alert Policies and Alert ChainsAs in most policies in StoneGate, the system reads the Alert Policies and Alert Chains from top down, so the order of the rules is important. In Alert Policies, rules must proceed from those with the most limited scope to those that are the most general. In Alert Chains, the order of the rules determines the order in which the alert notifications are sent.

TABLE 28.5 Contents of Escalated Alerts

Alert Channel Information Included in the Notification

Custom ScriptDepends on the script you create. See Using a Custom Script for Alert Escalation, on page 331.

SMTP (E-mail)SMTP notifications contain the full details of the alert, the full situation description, and the contents of all hex viewable fields as a hexidecimal dump and ASCII.

SMS (Text Message)

The maximum length for an SMS notification is 160 characters. Only the log fields that can be fit into the notification message are selected, in the following order: SID name, Severity, SRC IP address, DST IP address, DST port, Sender, Logical Interface, Creation time.

SNMP

Only the log fields that fit into the notification message are selected, in the following order: SID name, Severity, SRC IP address, DST IP address, DST port, Sender, Logical Interface, Creation time, Excerpt, Application protocol fields.


As Alert Chains can redirect the processing to some other Alert Chain as the Final Action, it is possible to create a loop in which the alert entry circulates through the same Alert Chains until the alert entry is acknowledged. If you want such a setup, you must be careful that you will not end up having unacknowledged alert entries trigger the blocking of important alert notifications (as set in the Threshold to Block field in Alert Chains), and you must make sure that you define suitable delays between the notifications to prevent the Log Server from cycling through the Alert Chains too quickly, which may create a large number of alert notifications in a short period of time.

Using a Custom Script for Alert EscalationFor custom script alert channel, you must define the absolute path to the script to be executed (if it is not pre-filled correctly). There is an example notification script <installation directory>/data/notification/notify.bat in Windows (notify.sh in Linux/Unix) that can be modified for your own use. On Linux/Unix, the sgadmin user needs read, write, and execute permissions in the script’s directory.The alert information is given to the script as command arguments as described in the table below.

TABLE 28.6 Arguments Passed to Custom Scripts

Argument number Content Description

1 Alert ID Identifies the alert uniquely in the system.

2 Alert Name The name defined in the alert properties.

3 Alert OriginatorThe IP address of the Sensor, Analyzer, Firewall, or other system component that generated this alert.

4 Alert Date The date when the alert was originally generated.

5 Alert Message A short alert description.

6 Alert Severity The severity value of the alert.

7Alert Short Description

The contents of the Comment field in the alert properties.

8 Event IDIPS only: reference to the event ID that triggered the alert.

9Situation Description

Long description of the situation that triggered the alert.

Using Alert Escalation 331

When the alert script is executed, the output (stdout) is appended to the notify.out file in the script’s directory. The error output (stderr) is appended to the notify.err file in the script’s directory.The Linux/Unix script in Illustration 28.3 is an example of how to create an operating system log entry using the custom script alert notification.

Examples of Alert EscalationThe examples in this section illustrate some common uses for Alert Escalation in StoneGate and the general steps on how each scenario is configured.

Disabling All Alert Escalation for a Specific SituationThe administrators at company A notice that the system is producing an alert every time that someone mistypes their password when logging in using the Management Client. They decide that they do not want to receive alert notifications about failed logins, because they have set up their StoneGate IPS system to detect if there are several failed logins within a short period of time (such a pattern could indicate an attempt from some malicious party to gain access to the system).The administrators:1. Create a new Alert Chain and name it Auto-acknowledge.2. Set the final action for the Auto-acknowledge Alert Chain to Acknowledge without

adding any new rows.3. Add the following new rule at the top of the Alert Policy:

Illustration 28.3 Example Custom Alert Script

#!/bin/sh# This script uses the ‘logger’ utility to create an operating system# log entry of the StoneGate Log Server alert notification.PATH=/bin:/usr/bin

# Create log entry: “StoneGate Alert (<ALERT_ID>): Severity <SEVERITY> # : <ALERT_NAME> : <ALERT_DESCRIPTION>”

/usr/bin/logger “StoneGate Alert ($1): Severity $6 : $2 : $5”

exit 0

TABLE 28.7 Alert Policy Rule Example

Sender Alert and Situation Chain

ANY“Management Server: Login Failed” Situation element

“Auto-acknowledge” Alert Chain


4. Refresh the new Alert Policy on the Log Server.• After this change, the alerts for failed logins are still generated and stored, but

they do not trigger any alert notification and they never show up as active alerts in the System Status view or the Logs view. For example, the administrators can still generate reports that include the numbers of failed login attempts to make sure they notice if there are excessive failed logins.

Escalating Alerts Based on ResponsibilitiesCompany B has two sites, a branch office (BO) and a headquarters (HQ) site, which both have their own administrators. Both sites have a StoneGate Firewall and a Log Server, and the shared Management Server is located at the HQ.For the most severe alert entries, the administrators decide to set up alert escalation to the shared mobile phone each site has for the administrator on duty. If the administrator on duty at one site does not acknowledge the alert entry within 15 minutes, the alert notification is sent to the administrator on duty at the other site.For less severe alert entries, the alerts are only escalated to the site where the alert entry is created. At first, the less severe notifications are sent only through a User Notification in the Management Client. After an hour, the alert notification is sent to the shared mobile phone of the site where the alert entry is created.This scenario could be configured in other ways as well, but this time, the administrators:1. Create new Alert Chains for high-severity and low-severity alert entries for both

the HQ and the BO sites. There are four Alert Chains in total:• “HQ Important Alerts” contains the following rules:

• The administrators create two rules instead of redirecting the processing from one Alert Chain to the other; the Alert Chains would point at each other, which could create a loop. That is not what the administrators want in this case.

TABLE 28.8 “HQ Important Alerts” Alert Chain

Channel Destination Delay

SMS [Phone number for HQ shared mobile phone] 15 min

SMS [Phone number for BO shared mobile phone]

Examples of Alert Escalation 333

• “HQ Minor Alerts” contains the following rules:

• The “BO Important Alerts” and “BO Minor Alerts” Alert Chains are basically the same as the HQ Alert Chains, just with BO Administrators and phone number.

2. Create a new Alert Policy with the following rules:

3. Define the SMS channel in the HQ Log Server’s properties.4. Define the SMS channel in the BO Log Server’s properties.5. Install the new Alert Policy on both Log Servers.

TABLE 28.9 “HQ Minor Alerts” Alert Chain

Channel Destination Delay

USER NOTIFICATIONHQ Administrator AHQ Administrator B[etc.]

60 min

SMS [Phone number for HQ shared mobile phone]

TABLE 28.10 Example Alert Policy

Sender Alert and Situation Severity Chain

HQ FirewallHQ Log ServerManagement Server

ANY 5...10 HQ Important Alerts

HQ FirewallHQ Log ServerManagement Server

ANY 1...4 HQ Minor Alerts

BO FirewallBO Log Server

ANY 5...10 BO Important Alerts

BO FirewallBO Log Server

ANY 1...4 BO Minor Alerts


CHAPTER 29 Reports

Reports are summaries of logged firewall and IPS events as well as monitoring statistics.


Overview to Reports, on page 336 Configuration of Reports, on page 337 Using Reports, on page 344 Examples of Reports, on page 349

335

Overview to ReportsStoneGate provides extensive reporting tools for generating reports on the logged firewall and IPS events. You can create reports on log, alert, and audit entries as well as statistical monitoring information. A variety of report designs are ready for use in StoneGate and new reports can be designed and customized specifically for your needs. The data can be illustrated with different types of charts and tables.This chapter explains the configuration of reports in the Reports view. For information on viewing log data in a graphical format in the Logs view, see Management Client Basics, on page 65.

Illustration 29.1 StoneGate Management Center Reporting

You can view the generated reports on the screen, print the reports, or export them as PDF files or in tab-delimited text format. When you view the reports on the screen, you can interactively highlight and select for display the different items in the charts. You can also e-mail the generated reports automatically from StoneGate to a selected address.

336 Chapter 29: Reports

Configuration of ReportsReports are summaries of log data and statistical monitoring information in StoneGate. Reports consist of report Items, report sections, and report designs. The following illustration describes the relation between them.

Illustration 29.2 Report Elements

A report is based on a report design, which defines how the report is generated. The report design specifies, for example, the length of the reporting period and the time resolution for the report. The report design consists of one or more report sections. A report section defines how the information is displayed graphically. Each report section contains one or more report items, which represent different types of items in log data and statistical monitoring information (for example, traffic load values or the number of allowed connections). Report items most often correspond to values in log fields. The generated report shows the report items in the way defined in the report sections’s properties.Illustration 29.3 shows how the report designs, report sections and report items are displayed in the Management Client.

Illustration 29.3 Report Designs, Report Sections, and Report Items

Report Design

Report Section

Report Item


The actual report is generated by starting a report task, which creates the report based on the selected report design. Each report section has its own summary in the report. Depending on the summary type, the summary can be presented as a bar chart, a curve chart, a pie chart, or a table. The summary type defines how the data is displayed in the report. There are four types of report section summaries. Table 29.1 describes the summary types.

TABLE 29.1 Summary Types

Type Description Chart Type

Progress Summary

Illustrates how events are spread out within the reporting period. This summary type is useful for finding trends in the data.For example, a summary of the amount of traffic in a network during a 24-hour period.

A bart chart or a curve chart.

Top Rate Summary

Illustrates events with the highest occurrences. This summary type is useful for highlighting the most common values in the data. For example, a summary of the IP addresses that have received the most connections in a network yesterday.The first report item in a top rate summary section must have a sorting criteria “by X” (e.g., Allowed connections by source IP address), because the sorting criteria is applied to all the items of the section for ranking the top rates.

A bar chart or a pie chart. A bar chart is more suitable for displaying a large number of top rates, whereas a pie chart is better at illustrating the relative proportions of the top rates.

Period Total Summary

A simple table for displaying the exact event counts. This summary type is useful for providing data for further processing, for example, in a spreadsheet application.

A table.


Default ElementsThe predefined StoneGate report items, report sections, and report designs are displayed on the Design tab of the Reports view. The report item types are explained in Table 29.2.

Drill-down Top Rate Summary

First creates a top rate summary of events. Then the sections under the drill-down top rate summary section use the data the top rate summary has selected to produce further charts and tables.For example, a drill-down top rate summary could first create a top rate summary of the IP addresses in your network that have received the most connections within a week. It could then produce a progress summary from this data to show in detail how the connections to the IP addresses are spread throughout the week.In addition to report items, you can add a progress summary section, a top rate summary section or a period total summary section under the drill-down top rate summary section in the report design. The items and sections added to the drill-down top rate summary section are indicated with an asterisk (*).Note that all the sections that you place under the drill-down top rate summary section in the report design become part of the drill-down top rate summary (except another drill-down section, which begins another drill-down top rate summary section).

A bar chart or a pie chart.

Static Information

Illustrates current values for items in the database (for example, the number of administrators or the version of an engine).

A table.

TABLE 29.2 Predefined Report Item Types

Report Item Type Explanation

Common General items that count log data from any StoneGate component.

TABLE 29.1 Summary Types (Continued)

Type Description Chart Type


Note – The selection and names of predefined report designs, report sections, and reports items may change when you update StoneGate. The changes do not affect the report designs that you have created using the predefined report designs, report sections, and report items of an earlier StoneGate version.

Configuration WorkflowThe following sections provide an overview of the configuration tasks related to configuring and customizing reports in the Reports view. Detailed step-by-step instructions for configuring reports can be found in the online help of the Management Client and the Administrator’s Guide PDF, in the section called Monitoring.

Task 1: Create a New Report DesignThere are several ways to create new report designs. You can start by defining a new empty report design or create a report design by copying and then modifying one of the predefined report designs or sections.You can create and modify report designs on the Design tab of the Reports view. The left panel shows the predefined report designs, report sections, and report items. You can copy them to create new report designs. The comments in the properties of predefined report designs and report sections explain their usage.

Counters Items for statistical monitoring information and log data.

Firewall and VPN

Items for firewall/VPN logs. All the items except items used for accounting data (indicated with the “Bits” or “Seconds” criterion) are used both for firewall and VPN logs. The items for VPN accounting data are listed under a separate VPN category.

IPS Items for IPS logs.

InspectionItems for logs generated by the deep inspection option in rule properties.

SSL VPN Items specific for SSL VPN logs.

Audit Items for audit logs.

TABLE 29.2 Predefined Report Item Types (Continued)

Report Item Type Explanation


Task 2: Define the Report Design’s PropertiesThe report design’s properties specify, for example, the time period for the report. You can also use a filter for selecting the data for the report and set an expiration date for removing the report from the Reports view.You can define a period comparison for the report design. This allows you to compare values between different time periods. You can, for example, compare the statistics of a report item on different weekdays or during previous reporting periods.The different properties of the report designs are explained in detail in Table 29.3.

TABLE 29.3 Report Design Properties

Property Explanation

NameA name for the report design. It is used in the Reports view and in the reports.

CategoryAn optional category for the report to group it (for example, Internal or External). The category information also defines which template is used if the report is exported as a PDF file.

Comment

An optional free-form comment for internal use. Comments added to report designs are not copied into the generated reports. If you want to include visible comments in a report, add the comments to individual sections of a generated report.

PeriodA time frame for the report. This affects the dates offered by default when you generate a report using this design.

Compare WithAllows you to enter a number and select a period to include the comparison data from a previous period of the same length.

Time Resolution

Allows you to define the level of detail in the progress charts and tables. The options you are presented with are automatically selected according to the period you have chosen. A small time resolution increases the level of detail, but having too detailed information may make the produced charts difficult to read.

Resolve IP Addresses Using

Allows you to select whether StoneGate network elements and/or a DNS are used to resolve the IP addresses in the report.

Report Expiration

Allows you to define the number of days after which the reports generated by this design expire (are automatically deleted). If you choose Never, you must manually delete all reports created using this design when you no longer need them. You can also change the expiration setting of individual generated reports after they have been generated if you want it to be different from the default value you set here.


Task 3: Select Report SectionsA report section represents a collection of report item data in reports. Each report section has a separate summary in the report. You can create one or several empty report sections and then select their contents. Alternatively, you can add predefined report sections to your report design and then modify their contents and properties.In the report section’s properties, you can define how the data in each report section is displayed in the report. Table 29.4 explains in detail the different properties you can set for a report section.

Log Data TypesAllows you to select the type of logs from which the data is selected for the report.

Filter

Allows you to select a filter that is applied to the reports you generate using this design. This makes it possible to restrict the volume of data that is included in the reports. You can, for example, select only traffic to/from a certain network.

TABLE 29.4 Report Section Properties


NameA name for the report section. It is used in the Reports view and in the reports.

CommentAn optional free-form comment that is shown above the section data in the report when you print or export the report.

Section TypeThe type of summary. The choice you make here affects what kind of chart you can choose in Preferred Chart Type. The different section types are explained in Table 29.1.

Preferred Chart Type

The default chart type for the section. The available choices depend on the section type you choose. A period total summary is a table by definition, so it cannot be displayed as a chart.

Unit for Traffic Rates

The unit for data in tables and graphs.

Maximum Number of Top Items

The maximum number of graphical data markers with the highest number of occurrences that are shown in a chart. This choice only affects top rate summaries.

Print/Export Content

Allows you to choose whether you want the export file of the finished reports to include a table, a chart, or both.

TABLE 29.3 Report Design Properties (Continued)



Task 4: Select Report ItemsA report item represents a value (for example, allowed traffic in bits, or the number of allowed connections) that you want to count in log data or statistical monitoring information. You can add one or several predefined report items to the report section(s) in your report design. You cannot create new report items.There are four ways in which the data for the report items is generated:• A count of how many log entries have a certain value within the reporting period. For

example, the Allowed connections report item counts the log entries that have the value Allowed in the Action field. This is how the results for most report items are summed.

• A count of how many log entries have a certain value within the reporting period grouped by the additional “by X“ criteria. For example, Allowed connections by source IP address presents a chart for an adjustable number of IP addresses that have the most allowed connections within the reporting period.

• Sums or averages of traffic volumes in log entries for report items of the “traffic” type (for example, Allowed traffic). The data for traffic volumes is generated by rules that have the accounting option enabled in the Firewall Policy.

• Sums or averages of statistical monitoring data for report items in the Counters branch of the Items tree.

• Values stored in the Management Server’s database for items of the Static Information section type.

The information from log data is collected from the logs in the active log storage. StoneGate stores the log data according to the logging options set in the Firewall Policy.The monitoring data used for report items of the Counters type comes from stored monitoring statistics, which are not as detailed as the monitoring statistics displayed in the System Status view.

Log Data TypesAllows you to select the type of logs from which the data is selected for the report.

Filter

Allows you to select a filter that is applied to the reports you generate using this design. This makes it possible to restrict the volume of data included in the reports. You can, for example, select only traffic to/from a certain network.

Related Element

Used with Period Total and Static Information section types to select the element(s) for which the data is reported (for example, the Administrators whose login information is reported for the Successful login(s) item).

TABLE 29.4 Report Section Properties (Continued)



Using ReportsThis section explains how you can generate, export, and post-process reports.

Generating ReportsThe actual reports are generated by executing a report task on the selected report design in the Browsing and Scheduling tab of the Reports view. The report designs that are selected for use are displayed on the right panel. The scheduled report tasks and the tasks that have been started are displayed under the relevant report design. The left panel displays the generated reports.

Illustration 29.4 Reports and Report Tasks

When you start a report task, it is sent to the Log Servers for processing. The task’s progress is shown next to the task under the selected report design. Each Log Server processes the task and returns the summary data for each report section. Finally, the data from the Log Servers is merged into one report. If one of the Log Servers used for reporting cannot be contacted for any reason, the execution of the task is delayed until the Log Server becomes available.

Note – Each report task needs to scan through the selected log data only once. It requires less processing to generate more sections in a report than to generate a separate report, which requires scanning the data again.

In the report task’s properties, you can define the reporting period for the report. The reporting period defines the time range for which the report is generated. If the defined reporting period is in the past, the report task can be executed immediately as all the data is already available. For a reporting period in the future, the task can be executed when the reporting period has elapsed so that the data is available. The task also allows defining a waiting period before executing the task (for example, to select a suitable time for generating the report or to ensure that all the data is available on the Log Servers if the reporting period is in the future). The reporting period is defined in your local time and it is automatically converted, if necessary, to the corresponding


time in the stored data (UTC). You can also select in the report task properties the storage from which the report data is selected.You can schedule a report task to repeat in the future for any reporting period. If a period comparison is defined in the report design, it is possible to execute the task for each reporting period or for each comparison period. For example, a reporting period of one day with a comparison period of the previous six days could be scheduled to be run every day or every seven days.

Using Filters with ReportsYou can use filters to select which data from all the available data is included in the reports. The data can be selected as follows:• Report task data: the data can be selected specifically for the report task to be

executed by selecting a filter in the task properties.• Report design data: the data for the report can be selected by selecting a filter in

the report design properties.• Report section data: the data can be selected separately for each report section by

selecting a filter in the report section properties.• Report item data: for the finest detail accuracy, the data can be selected for each

report item in a report section.The data is filtered top-down when generating a report. First, the data is selected from all the available logged data using the filter selected in the report design, or alternatively the filter selected specifically for the reporting task is used. Then the data for each section is selected from the report data. Finally, data for each report item can be selected from the data selected for the report section.

Exporting ReportsYou can export the generated reports from the system as PDF and tab-delimited text files. Exporting to a file can be done automatically in the report task, or manually on the Browsing and Scheduling tab.The automatic report exporting puts the produced PDF and text reports in the <installation directory>/data/reports/files/report_design/ directory on the Management Server. The report files are named according to the report’s time range as follows: startdate_starttime_enddate_endtime_N.pdf (or .txt), where N is a sequential number (starting from 1) that identifies files with the same time range. For example, 20061223_100000_20061224_180000_1.txt is the first text report generated for the time range from 23 Dec 2006 10:00:00 to 24 Dec 2006 18:00:00.

PDF Report FilesPDF files are suitable, for example, for printing, archiving, distributing by e-mail or on the Web. The exported PDF reports are designed to fit well on both the US Letter and the A4 paper sizes for printing.

Using Reports 345

You can customize the page layout with style templates. The PDF style templates are placed locally in your user directory in the operating system, in the folder .stonegate/reports/style. A style template category.pdf in this directory is used for a report, where category is the category assigned to the report. If the category.pdf file cannot be found, the Default.pdf file is used instead (if available).The PDF style template can use one or more pages:• One page template: the page is a content page template.• Two pages: the first page is a title page and the second page is a content page

template.• Three pages or more: all the pages except the last two are title pages, the second

to last page is the content page template, and the last page is a report trailer page.

Tab-Delimited Text Report FilesTab-delimited text files are designed to be used for further processing. The tab-delimited text files contain the statistics in tabulated tables. The Tab characters and the operating environment specific line endings delimit the text.

TABLE 29.5 Structure of a Tab-Delimited Text Report File

Line No. File Content Description

1<Report Title>, <Start Time> - <End Time>

Start and End Time define the reporting period in format YYYY/MM/DD hh:mm:ss.

2 <empty line>

3<Section Content for each section>

Each section of the report follows the format described below.

Line No. Section Content Description

1<Section Name>[; <Section Comment>]

Optional Section Comment with a leading semi-colon (;) may follow the Section Name.

2 <empty line>

3- <Section Data> | “No data”

Section Data follows the format described below. If the section contains no data, the text “No data” is displayed instead.

Section’s last line

<empty line>

Line No. Section Data Content Description


Illustration 29.5 Example of a Plain Text Report File

Illustration 29.5 shows an example of a plain text report file. The report title line indicates the report name Firewall Daily Summary and the reporting period starting on October 16, 2006 at midnight and ending on October 23, 2006 at midnight.

1 <Table Heading>

Tab delimited column labels. Some columns may not have a label, and labels may be padded with trailing spaces.

2 <empty line>

3- <Table rows>Tab delimited values. Value in any given column can be empty. The column values are not padded.

Section data’s last line

<empty line>

TABLE 29.5 Structure of a Tab-Delimited Text Report File (Continued)

Firewall Daily Summary, 2006-10-16 00:00:00 - 2006-10-23 00:00:00 General Summary; Summary on general firewall activity of the period. Traffic, Mon 3230184 Bits Sent, Mon 3230184 Bits Received, Mon 0 Bits Firewall records, Mon 1752 Accounted records, Mon 845 Allowed connections, Mon 880 Discarded connections, Mon 3 Refused connections, Mon 0 Traffic, Sun 3233984 Bits Sent, Sun 3233984 Bits Received, Sun 0 Bits Firewall records, Sun 1754 Accounted records, Sun 846 Allowed connections, Sun 881 Discarded connections, Sun 3 Refused connections, Sun 0

Using Reports 347

Post-Processing Report FilesYou can customize reports by post-processing them after running the report task. The post-processing is enabled in the task properties by selecting the Post Process option.Post-processing runs the <installation directory>/data/reports/bin/sgPostProcessReport.bat (in Windows) or .sh script (in Linux/Unix) on the Management Server, and passes command arguments to the script. Table 29.6 explains the possible command arguments.

The script needs to parse the values from the command arguments to use the values for post-processing. Only parameters that have a defined value are forwarded to the post-processing script. When a parameter has multiple values, each of the values is forwarded as a separate command argument. For example, when the report has the two categories “ABC Corp.” and “weekly report”, these values are forwarded to the script as “-report_categ ABC Corp.” and “-report_categ weekly report”.

TABLE 29.6 Command Arguments for Post-Processing Reports

Command Argument Explanation

-report_name name The name of the report.

-report_file_title title The title of the report file.

-report_categ name A category assigned to the report (and to the report file).

-creation_time YYYY/MM/DD hh:mm:ss

The report creation time.

-period_begin YYYY/MM/DD hh:mm:ss

The begin time of the reporting period.

-period_end YYYY/MM/DD hh:mm:ss

The end time of the reporting period.

-pdf_file filename The name of the report file for PDF export.

-text_file filename The name of the report file for export as plain text.

-filter_name filter The name of the filter assigned to the task.

-filter_categ name The category assigned to the task filter.


Using the System ReportThe System Report is a special report that contains information about the StoneGate system. It includes details of administrator and monitoring user activity, administrator and monitoring user access settings, configuration and changes to the Firewall and IPS engines, and the configuration of the Management Server. The System Report is intended to help you provide the required data for auditing in compliance with regulations, such as the Payment Card Industry (PCI) Data Security Standard. The System report is generated, exported, and edited in the same way as other types of reports: the only difference is the content of the report. While other reports are based on log data and traffic statistics, the System Report is based on statistics collected from the StoneGate system itself.

Examples of ReportsThe examples in this section illustrate common uses for reports and general steps on how the scenarios are configured.

Creating a New Report Design from Predefined Report DesignsThe administrator at Company A wants to create a report design to produce reports that combine selected data from the predefined Firewall Daily Summary and IPS Daily Summary. He:1. Copies one of these predefined summaries as a new Firewall and IPS Daily

Summary report design. 2. Deletes unnecessary report sections from the new report design.3. Copies the desired report sections from the other predefined report design to

the new report design.

Creating a Report of VPN UsersCompany B wants to know which employees use client-to-gateway VPNs at a certain time. The company’s administrator creates a report of the VPN users. He:1. Creates a new empty report design.2. Selects the time period in the report design’s properties.3. Creates two report sections.4. Copies Allowed connections by user from the predefined report items to one of

the report sections.5. Copies Traffic by user from the predefined report items to the other report

section.

Examples of Reports 349


Virtual Private Networks

CHAPTER 30 Overview to VPNs

This chapter provides an introduction to Virtual Private Networks (VPN) and the IPsec standards that VPNs in StoneGate are based on.


Introduction to VPNs, on page 354 IPsec VPNs, on page 355 VPN Topologies, on page 358

353

Introduction to VPNsVirtual Private Networks (VPNs) allow secure communications over insecure networks. VPNs secure the communications through authentication, encryption, and integrity checking mechanisms:• Authentication provides a way for the devices at both ends of the VPN to make sure

that the other end is who it claims to be. This prevents malicious parties from obtaining confidential data or access by posing as a legitimate partner.

• Encryption scrambles the transmissions to prevent anyone from viewing the content, providing privacy for the communications. When the VPN traffic is sent over the Internet, someone can easily intercept the communications, but the encryption hides the actual information content and the communicating hosts.

• Integrity checking is used to detect if packets have been modified in transit, which could be a sign of malicious tampering (or simply transmission errors).

Typically, VPNs are used to secure connections between the corporate LAN and a branch office, a supplier or partner office, telecommuters, or mobile workers.The gateway devices handling a VPN (including the StoneGate firewalls) are called security gateways (SGWs) when building VPNs. There are two types of VPNs you can build:• Gateway-to-gateway VPNs are created between two gateway devices that provide

access to the VPN for other devices.• Client-to-gateway VPNs are created between a gateway device and an individual

computer, such as a mobile computer of a travelling user, that is running VPN client software.

Illustration 30.1 Gateway-to-Gateway and Client-to-Gateway VPNs

StoneGate Firewall/VPN follows the IPsec (Internet Protocol security) standards when building VPNs. Most of the settings you must select to establish a VPN are directly related to concepts that are defined in the IPsec standards, so having a basic understanding of IPsec helps you directly in your configuration tasks. This chapter concentrates on those and other general VPN-related concepts. The next chapter, VPN Configuration, on page 361, then explains how the concepts explained here are implemented in StoneGate.SSL VPNs are available as separate StoneGate SSL VPN appliance products. See the StoneGate SSL VPN Administrator’s Guide for information on configuring SSL VPNs.

354 Chapter 30: Overview to VPNs

IPsec VPNsStoneGate uses the IPsec protocol standards to implement VPNs at the IP network layer. This means that IPsec allows any IP traffic to be transported in the VPN regardless of which higher-level protocol the traffic uses on top of IP. IPsec is part of both the IPv4 and IPv6 standards. IPsec is defined in RFC 4301.Although this section introduces general concepts of the IPsec standard, most of these concepts are also directly present as options in the VPN-related dialogs and views in the Management Client.

TunnelsWhen there is traffic that needs to be sent through a VPN, the gateway or VPN Client at the communication source contacts the gateway at the communication destination to establish a VPN tunnel. ‘Tunnel’ is a descriptive term for how the traffic is handled, since the original packets ‘disappear’ inside the VPN tunnel when they are encapsulated inside VPN packets at one end and then ‘appear’ again at the other end looking just as they were before they entered the tunnel. In between, all that is visible is the tunnel itself (the encrypted packets).The hosts that communicate through the tunnel are not aware of the VPN - from the point of view of the communications going through the tunnel, the situation is no different than if the two gateways were connected directly to each other. From the point of view of the gateways, the situation is naturally more complex.

Security Associations (SA)For any communications to be able to use the VPN, the gateways must first construct and then maintain the VPN tunnels. To do this, the gateways must decide on which settings to use between each other and store this information so that it can be used for handling the traffic throughout the lifetime of the VPN tunnel.The settings that are used for a tunnel are stored in Security Associations (SA). One SA stores information about a specific type of settings for a particular VPN tunnel, so there is always more than one SA within a single VPN.You may see the term SPI (security parameter index) sometimes used in conjunction with SAs in IPsec VPNs. The SPI is simply an identification code that the gateway uses to keep track of some types of SAs.For security reasons, each SA has an expiration time after which the gateways discard the old SAs and agree on new ones if there is still traffic going through the VPN.

Internet Key Exchange (IKE)The SAs are created in a process called the Internet Key Exchange (IKE) negotiations. During the IKE negotiations, the security gateways agree on the parameters to use, such as the encryption keys needed to hide the data and the authentication methods. This information is then stored in the SAs.

IPsec VPNs 355

The IKE negotiation consists of two phases:• During the IKE Phase 1 negotiations, the gateways authenticate themselves to each

other and establish a secure (encrypted) channel for the Phase 2 negotiations. Authentication in Phase 1 can be done with signatures, or with public or pre-shared keys. These parameters are then stored in SAs (called IKE SAs).

• During the IKE Phase 2 negotiations, the gateways select parameters for encrypting the traffic going through the VPN tunnels. These parameters are then stored in SAs (called IPsec SAs).

The IKE Phase 1 can be negotiated using two different methods:• The Main Mode is the primary and recommended method that protects the

identities of the communicating parties. It also allows for greater flexibility in the settings used.

• The lighter Aggressive Mode can be used as an alternative, but unless public key authentication is used, this mode does not provide identity protection. Particularly the use of the Aggressive Mode with pre-shared key authentication is strongly discouraged for security reasons.

The negotiation in Phase 2 is known as Quick Mode as it is much faster than the IKE SA in Phase 1. Since the Phase 1 negotiations involve quite heavy computation, it is common to configure the Phase 1 SAs to expire less frequently than the Phase 2 SAs.

Perfect Forward Secrecy (PFS)As stated above, it is possible to configure the IKE Phase 1 negotiations to occur less frequently than Phase 2 negotiations to improve performance. However, this kind of arrangement is less secure than renegotiating both phases again, since the Phase 2 negotiations generate encryption keys based on information from the Phase 1 negotiations. To counter this, you can activate Perfect Forward Secrecy (PFS) that ensures that the encryption keys for Phase 2 negotiations are created independently. When the negotiations are independent of each other, any one key that is compromised can only be used to decrypt communications sent between two Phase 2 negotiations instead of potentially breaching all communications between two Phase 1 negotiations, which cover a longer period of time.

AH and ESPOnce a VPN tunnel is up, any traffic going through the tunnel is sent either as Authentication Header (AH) or Encapsulating Security Payload (ESP) packets:• The IPsec AH protocol does not provide data encryption, so plain AH does not result

in a VPN in the full meaning of the word. The transferred data can be seen by anyone who can intercept the packets in transit. AH can be used to provide authentication and data integrity in communications that do not need encrypting.

• The IPsec ESP protocol provides authentication, encryption, and integrity checking, providing secure data transfer. This protocol corresponds to what is usually meant with the term VPN, as the transferred data is hidden from outsiders.


The standards also have a provision to use a combination of ESP and AH, but this option is no longer supported on StoneGate starting from version 4.2. Even if you have older engines, we recommend primarily using just ESP with your VPNs. ESP with AH does not provide significant security improvements in the type of VPNs StoneGate establishes.As a general guideline, use ESP for any normal VPN tunneling (data encapsulated in ESP payload). There is very rarely any need to use AH alone. AH alone may be used when no encryption is required for the data, but ESP with Null encryption can also be used to achieve this same purpose.

AuthenticationAuthentication always requires exchange of information between the two authenticating parties. The information exchange must be done securely in such a way that the exchanged information cannot be used by others even if they are able to intercept it.The confidentiality of authentication exchanges is most often achieved through digital signatures or through encrypting the authentication messages with a pre-shared key.• Digital signatures use a public-private key pair to sign messages. This method

requires that digital certificates signed by a mutually trusted Certificate Authority (CA) are present.

• VPN authentication with a pre-shared key does not require the presence of digital certificates. It requires the exchange of a secret encryption key that is known by both communicating parties.

Both methods can be secure enough for VPNs if used correctly, but the security of the pre-shared key method is much more sensitive to how it is set up. If pre-shared keys are used for authentication, the keys must be long and random to be sufficiently secure. The pre-shared key is not a password: the key itself is not sent over the network in the authentication process, since there is no way to do that securely at this stage. Instead, the key is used to encrypt the authentication communications. The same key is necessary to decrypt the communications, so only a legitimate party is able to successfully partake in the communications. The pre-shared key must be kept absolutely secret, since the security of this setup completely relies on the assumption that nobody except the legitimate parties know the key.The authentication and encryption methods available in StoneGate are listed in Supported Authentication and Encryption Methods, on page 373.

IPsec VPNs 357

Tunnel and Transport ModesIPsec supports two different modes for securing the traffic.• The tunnel mode encapsulates the complete original packet into a new packet and

is meant for gateway-to-gateway and client-to-gateway VPNs. StoneGate always uses the tunnel mode.

• The transport mode does not encapsulate the packets. The IPsec standard provides the transport mode for host-to-host communications and it is not used in StoneGate.

VPN TopologiesStoneGate VPN tunnels can be defined using different topologies:• Full-mesh topology connects each site to every other site in the same VPN. All

gateways are central gateways, which establish tunnels with all other gateways in the VPN.

• Star topology connects sites behind satellite gateways to the sites behind central gateways. No VPN tunnels are established between the satellite gateways.

• VPN hub topology, available only for client-to-site VPNs, routes VPN client connections through a VPN hub gateway to other sites through site-to-site VPNs. The hub gateway can be either a central or a satellite gateway.

Usually, the VPN configuration of any organization is a mix of the different topologies, but they are a useful starting point for planning your VPNs.The full mesh topology, presented in Illustration 30.2, is formed between sites that must all be able to connect to any other site.

Illustration 30.2 Full Mesh VPN Topology

In a full-mesh topology, all security gateways are defined as central gateways so that each gateway can establish, when needed, a VPN tunnel with the other gateways in the VPN. This allows VPN communications from any one site to any other site.


When VPNs are formed with partner organizations or small remote offices, VPN connectivity is needed between a number of remote sites and a main site, but not from one remote site to another.

Illustration 30.3 Star VPN Topology

The star topology is defined with satellite gateways that connect only to the central gateway(s). There is no VPN between the satellite gateways. This reduces the number of VPN tunnels that the gateways need to maintain compared to full-mesh topology, which can save resources on the gateways. Different topologies are often combined in practice. This is shown in Illustration 30.4.

Illustration 30.4 Combination of Different Topologies

As seen here, replacing two of the central gateways from our full mesh example (Illustration 30.2) with satellite gateways actually results in a VPN where all but two gateways still have a VPN with each other.

VPN Topologies 359


CHAPTER 31 VPN Configuration

A virtual private network (VPN) extends a secured private network over public networks by encrypting connections so that they can be transported over insecure links without compromising confidential data. For this purpose, the devices that create the VPN check the identity of the other parties by the way of authentication. A VPN also includes integrity checking to ensure the communications are not tampered with.


Overview to VPN Configuration, on page 362 Configuration of VPNs, on page 362 Using VPNs, on page 372 Examples of VPN Configurations, on page 380

361

Overview to VPN ConfigurationVPNs in StoneGate are implemented according to the IPsec standard. This chapter assumes that you are already familiar with the basic concepts of building IPsec VPNs and concentrates on the features available in StoneGate. As many of the settings relate directly to basic IPsec concepts, you must be familiar with those to fully understand the possible configuration options. For a general overview to VPNs and IPsec, see Overview to VPNs, on page 353.In StoneGate, you can create two main types of VPNs:• You can create a VPN between two or more gateway devices that provide VPN

access to several hosts in their internal networks. This is called a gateway-to-gateway VPN.

• You can create a VPN between a gateway device at a site and a VPN client running on a laptop of a travelling user or some other individual computer, like a desktop PC at a home office. This is called a client-to-gateway VPN.

Because StoneGate follows the IPsec standards, you can create VPNs with gateway devices and VPN clients from many different manufacturers. This allows you to create VPNs with partner organizations that have an IPsec VPN gateway.

Configuration of VPNsA VPN is established either as a gateway-to-gateway VPN between two gateway devices or between a gateway device and a VPN client.The gateway devices are called Security Gateways (SGW). There are two general types of security gateways in StoneGate:• Internal Security Gateways are StoneGate Firewall/VPN engines that are managed

by the same Management Server you are connected to with your Management Client to configure the VPN.

• External Security Gateways are all other IPsec-compatible gateway devices, including StoneGate firewall/VPN devices that are managed by some different Management Server than the one you are connected to with your Management Client to configure the VPN.

If you want to establish a client-to-gateway VPN with VPN clients, the recommended option is to use the StoneGate IPsec VPN Client, which is available for Windows platforms. You can alternatively use some third-party IPsec-compatible VPN client, but third-party clients do not support all features offered by StoneGate. VPN clients cannot connect directly to SOHO firewalls, but you can forward connections the clients take to a central gateway through a site-to-site VPN to a remote site.If you use the StoneGate IPsec VPN Client, the VPN configuration you create in the Management Client is also used for creating the configuration for the VPN Clients. The VPN Clients then download the settings from the VPN gateway(s) either manually or automatically whenever there are relevant changes. Each downloaded configuration contains the settings for connecting to that particular gateway, such as information on

362 Chapter 31: VPN Configuration

which encryption methods are used and which internal networks clients access through the VPN.Due to the various authentication and encryption methods that are supported in IPsec VPNs, the number of settings available for VPN configuration is rather high. To save you from repeated configuration work, there are reusable profiles for different types of settings. These and other elements related to VPN configuration are pictured in Illustration 31.1, excluding elements that are related to managing certificates (those are presented in Illustration 31.2).

Illustration 31.1 Elements in the VPN Configuration (Excluding Certificate-Related Elements)

As shown in the illustration above, there are four main points of configuration for VPNs:1. In the Firewall element, you select which of the Gateway Settings elements the

firewall uses in its role as a VPN gateway. These are general settings such as VPN tunnel negotiation retry and recovery options. The selected Gateway Settings affect all VPNs that the firewall establishes.

2. The Gateway element sets VPN-related settings particular to one Firewall/VPN device. There can be one or more Gateway elements for each Firewall element, so these settings may affect one or more of the VPNs that the firewall establishes.• The Gateway element refers to a Gateway Profile, which contains information

related to the type of gateway, such as the supported encryption methods. For Internal StoneGate gateways, these settings are fixed based on the engine version.

• You also select the Sites for each internal and external Gateway. The Sites collect together those (real or translated) IP addresses from the Gateways’ internal networks that are valid in communications through VPNs.

• SOHO firewalls are configured slightly differently. They are inserted in VPNs in SOHO Gateways elements, which can contain several SOHO firewalls. The Sites for these groups are selected automatically based on the Corporate interfaces defined for each SOHO firewall included in the group.

1. 2. 3. 4.


3. The VPN element is the main container for IPsec VPN settings.• The VPN element refers to a VPN Profile, which contains the authentication and

encryption settings (IKE settings) that are essential in configuring a VPN.• The VPN element also defines the structure of the VPN (topology) and the

settings for individual VPN tunnels (such as the selection of standby tunnels in a Multi-Link configuration).

4. The firewall’s policy controls VPN traffic in the same way as any other traffic.• The Access Rules determine which connections are actually directed out

through the VPN and which traffic is allowed in from the VPN.• The NAT Rules define what kind of address translation is done for VPN

connections. The VPN tunnel communications are always subject to NAT as usual, but the traffic going in and out of the tunnel is only subject to NAT if address translation is specifically enabled for the VPN.

VPN CertificatesCertificates are usually necessary for providing authentication in a VPN. In gateway-to-gateway VPNs and VPNs with third-party VPN clients, you can alternatively use a pre-shared key for authentication. With StoneGate VPN Clients, the authentication is always either a hybrid authentication that requires both the presence of a valid certificate on the gateway and the correct username and password from the VPN Client user, or certificate exchange authentication, where both the gateway and the VPN Client need their own certificate.Certificates often provide better real-world security than pre-shared keys, since pre-shared keys rely on administrators to remember to renew the keys periodically and may require the keys to be transferred to other sites. Certificates also expire and must be renewed, but only at an interval of a few years (three years, if created internally in StoneGate). Certificate creation and renewal can be completely automatic for StoneGate gateways if the Management Server’s internal certificate authority is used.Certificate-based authentication is illustrated below.

Illustration 31.2 Certificate-Based Authentication in the VPN Configuration


As shown in Illustration 31.2, a certificate request is needed for generating a certificate for a component. The certificate request creation steps depend on the component. For internal security gateways, this may be either automatic or administrators may generate the requests through a manual action in the Management Client. The certificate request is signed by a Certificate Authority (CA) that the VPN gateways involved in the VPN are configured to trust. Signing the certificate request creates the actual certificate, which is then transferred to the correct component. With internal gateways, the Management Server can automatically also sign the request and transfer the certificate to the gateway without further actions from you.

The Internal Certificate AuthorityThe Management Server has an internal CA. If you want to create a certificate for an internal gateway using the internal CA, all of the actions are done in the Management Client, and may be even completed automatically without any action from you.If you want to use the internal CA to sign certificates for VPN clients or external gateways, certificate requests and signed certificates must be exported, transferred, and imported through manual actions. The internal CA does not support certificate revocation lists.

External Certificate AuthoritiesExternal CAs can be used to create certificates for one or more gateways or VPN clients in a VPN. All IPsec certificates follow the ITU-T X.509 standard (which is a common standard also used in TLS/SSL, HTTPS, etc.). You can freely choose whether to sign any of the VPN certificate requests using the internal CA or some external CA. Different gateways in a VPN can have certificates signed by different CAs.To make StoneGate accept certificates signed by an external CA, you must define the external CA as an element in StoneGate and add the CA on the trusted list of Gateways and/or VPNs. To do this, the public key of the external CA must be imported in StoneGate. External CAs are especially useful when creating VPNs with partner organizations, since this allows both organizations to use their own preferred CA. External CAs may also allow using certificate revocation lists.The external CA must support PKCS#10 certificate requests in PEM format and the signed certificates must also be in the PEM format. Furthermore, the CA must be able to copy all attributes from the certificate request into the certificate. Especially X.509 extension Subject Alternative Name must be copied as it is in the request because the value is used for authentication.

Certificate Revocation ListsCertificate Revocation Lists (CRL) can be used to cancel a certificate before it reaches its expiration, for example, if there is reason to suspect that unauthorized parties have obtained a copy of it. If you want to use CRLs in the VPN


authentication, you must use an external CA to manage the certificates. The internal CA does not support CRLs.The CRL servers are accessed using LDAP or HTTP (depending on what the certificate specifies). If all CRL servers defined for the CA are unreachable, all the certificates of the CA are considered invalid until the CRL can be checked again.

Default ElementsThere are several default elements for VPN configuration in the Virtual Private Networks branch of the element tree.Under Profiles, there are the following default elements:• Several different Gateway Profiles are included for the various StoneGate versions.

The StoneGate profiles are automatically attached to internal security gateways based on their software version. To use all features offered by StoneGate, match any external StoneGate gateways with the correct profile according to their software version.

• With any third-party VPN devices, you can freely choose whether to use one of the profiles provided, even if there is a default profile for the type of gateway to which you are creating a VPN. The Default (All Capabilities) profile allows any of the available options to be selected for the Gateway.

• Gateway Default Settings is a pre-defined Gateway Settings element that you use with most of your Firewall/VPN engines.

• VPN-A Suite VPN Profile contains the VPN settings specified for the cryptographic suite “VPN-A” in RFC 4308. You can use it for any of your VPNs, and it can especially help you to establish a VPN with third-party VPN devices to make sure that the same encryption and authentication methods are selected at both ends, although you must still match settings related to other parts of the configuration.

Under Gateways, there is the Client gateway element that is used to represent any VPN clients in a VPN, regardless of whether they are StoneGate VPN Clients or any third-party VPN clients.Under Certificates, the Internal IPsec CA Certificate Authority represents the Management Server’s internal Certificate Authority. You can use the element to define certificate trust relationships if you configure other CAs in the system.

Configuration WorkflowThe following sections provide an overview of the configuration tasks related to configuring and customizing VPNs. Detailed step-by-step instructions for configuring the elements and policies can be found in the online help of the Management Client and the Administrator’s Guide PDF, in the section called Virtual Private Networks.


Task 1: Define the Gateway SettingsEach firewall, except SOHO Firewalls, has settings that are common to all VPNs the firewall establishes, set in the Gateway Settings element. These settings are mostly for performance tuning, and in most cases, there is no need to change these settings. The settings may be useful for advanced users when there is some particular need to change them.The Default Gateway Settings include settings for tunnel negotiation retry and tunnel recovery, anti-clogging, certificate caching, and the maximum values for the length of encryption keys and for the number of IKE SAs.

Task 2: Define the Gateway ProfileFor Internal security gateways, the system selects the Gateway Profile automatically based on the version of StoneGate installed, and you cannot change it. For External security gateways, you can select a pre-defined profile or define a new profile yourself. The pre-defined Client Gateway for VPN clients always refers to a default Mobile Client Gateway Profile.The Gateway profile introduces information about the type of device so that the system is aware of the features and options available. The general settings directly affect the settings used in VPNs. The authentication and encryption settings defined in the Gateway Profile do not directly influence which of the displayed settings are used for any VPNs; it is more of a configuration aid and a reference for the system for checking that the settings defined for the VPNs correspond to the options supported by the gateway devices involved.

Task 3: Define the Security GatewaysThe Gateway element is used to define settings for the internal and external gateway devices in their role as a VPN gateway. ‘Internal’ and ‘external’ refer to whether or not the gateway is managed by the Management Server where the element is defined.A single Gateway element per gateway device is usually sufficient because you can use the same Gateway in several different VPNs and override the Gateways settings (such as trusted CAs and Site definitions) in the VPN Profile or the VPN element as necessary. However, it is possible to create several Gateway elements to represent a single firewall/VPN engine as long as they have different VPN endpoints (unique single firewall NDI or cluster CVI IP addresses).The special pre-defined Client Gateway represents VPN clients in client-to-gateway VPNs. A client-to-gateway VPN with StoneGate VPN Clients must always be set up using the Client element. In most cases, we recommend using the Client Gateway element with third-party VPN clients as well. However, it is possible to configure an individual third-party VPN client using an external Gateway element instead, if there is a specific need to do so.For SOHO firewalls, the Security Gateways are defined by combining the SOHO firewall elements into one or more SOHO Gateways elements, which are then used to create VPNs in the same way as Security Gateway elements for other types of StoneGate


devices. The SOHO Gateways element contains a simplified set of options compared to normal Security Gateway elements.

Task 4: Define the Protected SitesRouting for the VPN is defined using Site elements, which contain the IP addresses that you want to be able to communicate through the VPN. The Sites are always added globally for a Gateway for all VPNs where the Gateway is used, but individual Sites can be disabled in any given VPN. The Sites of a Gateway contain the IP addresses of all protected hosts that potentially send or receive VPN traffic.You have the option to include a Site that is automatically populated and updated according to the definitions of the Routing view. All interfaces and networks are included in the automatic Site, except the external interfaces (those with the Any Network element). The Sites of the SOHO Gateways Group is always automatically populated with the networks defined as Corporate in the SOHO firewall engine elements included in the group. You can disable any automatically added interfaces and networks globally or on a per-VPN-basis as needed.If you use NAT to translate the source IP addresses of traffic going out through a Gateway, you must use the translated addresses to define the Sites. The NAT addresses cannot be added to the Site automatically.In a client-to-gateway VPN, the Any Network element must be included in one of the Sites under the Gateway to which clients connect if you want to forward traffic from a VPN client through the Gateway to the Internet. You cannot add any Sites under the Client Gateway element.StoneGate VPN Clients download the IP address definition for the Site(s) from the Gateway. The Site element also contains the DNS server settings for StoneGate VPN Clients and an option to prevent the StoneGate VPN Clients from establishing a VPN to a Site when they are within some other Site, for example, so that a user with a laptop can access resources at another site through a gateway-to-gateway VPN (without logging in with the VPN Client) when the laptop user is at the office.

Note – Inclusion in a Site does not give access. Access rules define which connections are allowed between the defined Sites.

Task 5: Create CertificatesCertificates can be used for authenticating the remote gateway or VPN client to prevent malicious parties from posing as a legitimate partner. If you select pre-shared keys as the authentication method, certificates are not needed. If you select the hybrid authentication method for StoneGate VPN Clients, only the gateway needs a certificate.A maximum of one certificate for each CA is needed regardless of how many VPNs you create. When a component needs a certificate, it must create a certificate request:


• For internal security gateways, the certificate handling can be completely automatic, if the certificate is signed using the internal CA, or you create the certificate request manually in the Management Client.

• For external security gateways, the certificate request must be created in the system that is used to manage the gateway.

• For VPN clients, the certificate request is created in the VPN client.The certificate request is then signed using StoneGate’s internal certificate authority or some external certificate authority that you configure all VPN devices to trust. After signing, the certificate is valid and can be transferred to the component that needs it. Internally signed certificates are automatically transferred to the engines used as internal gateways.

Task 6: Define the VPN ProfileAll VPNs must refer to a VPN Profile. The same VPN Profile can be shared by several VPNs if the settings fit, and allow you to easily copy the settings to create modified versions of the same basic set.The VPN Profile contains settings related to the authentication, integrity checking, and encryption. In other words, the VPN profile is the main point of configuration for IKE and IPsec settings (the settings used or agreed on during IKE Phase I and Phase II negotiations). You are generally free to choose any combination of settings you like as long as all gateways and VPN clients involved support those settings. See Supported Authentication and Encryption Methods, on page 373 for more information on these settings.The authentication methods for VPN Clients are selected separately in the VPN Profile: a certificate-based method is always included in the VPN, but you can optionally add pre-shared key for third-party clients and hybrid authentication for StoneGate VPN Clients.

Task 7: Define the VPN ElementThe VPN element collects together the Gateways and the VPN profile, provides the settings for defining the topology and the tunnels of the VPN, and contains a general setting for whether NAT rules are applied to traffic going in and out of the VPN.On the Overall Topology tab, you can select whether the Gateways are Central or Satellite in each VPN:• A Central Gateway establishes VPN tunnels with any other Central or Satellite

Gateway in the VPN (it works as a hub gateway). Central gateways are typically located at headquarters-type offices to which several other sites connect for different services.

• A Satellite Gateway establishes VPN tunnels only with Central Gateways (it works as a spoke gateway). Satellite gateways are typically located at remote offices to which only the central site hosts may connect.

The Sites and networks that are accessible through the VPN are also shown on the Topology tab. However, the sites and networks are a not VPN-specific, but a part of the


Gateway definition. You can adjust the sites and networks through the VPN element, but any changes you make for one VPN also concern all other VPNs where the same Gateway element is used.On the Tunnels tab, you select the options for tunnels at the Gateway and end-point levels. Tunnels are generated based on the overall topology (from central gateways to all other central gateways and to satellite gateways). However, tunnels are not generated for unsupported configurations, such as between the Client gateway and any SOHO Gateways. You can then further adjust the tunnels generated:• At the gateway-to-gateway level, you can further limit which Gateways form tunnels

with each others and change some of the properties for all tunnels between two particular Gateways, such as the VPN Profile used.

• At the endpoint-to-endpoint level, you can disable individual tunnels and select which of the tunnels are used as standby tunnels in a Multi-Link configuration. You can also define, at the tunnel level, which VPN Profile is used if there are multiple tunnels between two Gateways. However, at this level, only the IPsec (Phase 2) settings have effect.

Note – Although the VPN Endpoints usually correspond to the NetLink interfaces in a Multi-Link configuration, the VPN endpoint settings are separate from the NetLink and Multi-Link definitions. For example, a NetLink that is set to Standby can still be used as an active endpoint for VPN traffic.

From within the VPN element, you can also view warnings and errors regarding the configuration (indicated as Issues). Always check if any problems are shown when you have edited the VPN.

Task 8: Modify the Firewall PolicyAfter completing the tasks above, your VPN is configured, but no traffic can use the VPN until you define which traffic uses the VPN in your Access rules.The communications between the defined Gateways to establish the VPN are allowed based on the VPN definitions and the rules in the Default template, so you do not need to include the Gateway addresses in the VPN Access rules, unless you use your own customized top-level template.SOHO firewall engines always allow the VPN connections from all Corporate interfaces to the VPN and from the VPN to the Corporate interfaces. Use Access rules at the other end of the VPN control the traffic.The VPN Access rules are basically the same as all other Access rules: you define certain matching criteria and all traffic that matches is then handled according to the Action set for the rule. In addition to the Source and Destination IP addresses and the Service, VPN rules can be matched based on the Source VPN that incoming traffic uses to enter the firewall. Traffic can be selected for a VPN with the Use VPN rule action, which has three main options:


• Apply VPN means that the firewall tries to send the traffic through the VPN you specify, but if this is not possible (for example, if establishing the VPN fails), the rule is ignored, and the rule matching process continues from the next rule.

• Enforce VPN means that traffic that matches the rule must use the VPN specified. If this is not possible, the traffic is dropped.

• Forward can be applied to traffic coming in or going out through a client-to-gateway VPN. It can be used to forward VPN client connections either through a gateway-to-gateway VPN or as normal unencrypted traffic to some destination outside the gateway’s local networks. The Forward action can also be used to forward connections from the internal networks to VPN clients that have the Virtual Adapter feature activated and a VPN already established from the client end.

NAT rules only apply to the encrypted packets (the VPN tunnel) by default. Unless you define otherwise, the addresses of the packets going through the VPN tunnel are not translated, so they are the same when they enter and when they leave the VPN tunnel when handled by StoneGate. You can enable NAT for traffic going through the VPN tunnels for each VPN separately in the VPN element’s properties. As usual, the Access rules are checked before any NAT operation for any new connections, so those must use the untranslated source and destination addresses. Since the traffic is naturally placed in the VPN tunnel after any NAT operations, you must define the Sites using the translated addresses when NAT is applied to the traffic.

Note – NAT is needed for the NAT Pool feature in VPN client communications. If you want to use the NAT pool defined at the Gateway level, NAT must be enabled in the VPN element for your client-to-gateway VPN(s).

If address translation is done between two VPN Gateways or between VPN clients and a Gateway, you must usually define Locations and Contact Addresses. This is because the untranslated address of the gateway may still appear in the packet payload for the VPN negotiations even as the source or destination in the packet headers is translated. With internal Gateways, the Contact Addresses you may have defined for other system communications for these components are valid and most likely correct for VPNs as well. For more information, see Using a NAT Address for a VPN Endpoint, on page 373.StoneGate has a policy validation tool for checking whether the rules in a policy are valid (for example, whether there are misconfigured rules or rules that do not match any traffic). It is a good idea to validate the VPN rules in your policy before uploading it to the engines. For more information about policies, see Firewall Policies, on page 153.When the policy is refreshed on the firewall, the new policy starts matching traffic. When a new connection is allowed into a VPN, the firewall negotiates the tunnel. This is usually a quick operation, but some delay is possible. Once the tunnel is up, further connections (also from different hosts) can then use the existing tunnel.


Task 9: Configure VPN Clients and External GatewaysStoneGate VPN Clients download their settings from each Gateway they connect to either in a manual configuration download operation or automatically. All necessary IPsec and address management settings are included in the download. The decision on whether a particular connection is sent through the VPN tunnel or not is based on which IP addresses you have defined for the Sites behind the Gateway. You can alternatively have a setup where all traffic is forwarded into the VPN.For third-party VPN Clients and any external security gateways, you must duplicate the settings you defined for StoneGate in the configuration of the VPN client or gateway in question. This includes all IPsec-related settings, such as the authentication, encryption, and integrity checking options as well as the protected networks defined for the Sites (the IP addresses that are allowed in the VPN as a source or destination IP address). For more information, see Configuring VPNs with External Gateways, on page 377.

Using VPNsThis section covers the following topics:• VPN Logs, on page 372.• Using a Dynamic IP Address for a VPN Endpoint, on page 372.• Using a NAT Address for a VPN Endpoint, on page 373.• Supported Authentication and Encryption Methods, on page 373.• Configuring VPNs with External Gateways, on page 377.• Clustering and VPNs, on page 379.• Multi-Link VPN, on page 379.

VPN LogsThe VPN negotiations and new connections are logged as informational messages and can be viewed in the Logs view like any other logs. New connections that are allowed through the VPN (the actual traffic using the VPN) are logged just like any other traffic according to the logging options you set for your VPN Access rules.If there are VPN-related problems, you can activate diagnostic logs for IPsec for the firewall in question to get more detailed information on the VPN negotiations. The Troubleshooting section in the online help and the Administrator’s Guide contains further information for situations where you are having problems with your VPNs, including information on common errors you may see in the logs.

Using a Dynamic IP Address for a VPN EndpointIf a VPN endpoint has a Dynamic (DHCP- or PPPoE-assigned) IP address, some restrictions apply:In a gateway-to-gateway VPN, each VPN tunnel can have a dynamic IP address at only one end. The VPN can be established only one way: from the endpoint with a dynamic IP address to the endpoint with a static IP address. If there is not frequent enough


traffic from the dynamic IP gateway to establish and keep up the VPN tunnel at all times, you can send some traffic (for example, using the Tester) through the VPN from the site with the dynamic IP gateway to ensure the tunnel is up and ready for traffic coming from the static IP gateway.• A client-to-gateway VPN is not possible with endpoints that have a dynamic IP

address. To work around this, clients can connect to a gateway with a static IP address, which can then be configured to forward the traffic through a gateway-to-gateway VPN to the gateway with a dynamic IP address.

When a dynamic IP address is used, certificate-based authentication methods must be set up so that the security gateway uses some other identifier than the IP address. The alternatives are DNS name, e-mail address, or the certificate’s Distinguished Name (DN).

Using a NAT Address for a VPN EndpointIf a gateway does not have a public IP address as a VPN endpoint, you have two options to make your VPN work.First option is to use UDP encapsulation, which protects the VPN traffic from being modified by NAT. StoneGate VPN Clients also support TCP tunneling, which works similarly, but allows also forwarding the traffic through any port you define.The second option is to configure the VPN with contact addresses as follows:• Any firewall that is used as an internal security gateway in a NAT environment must

have the Location and Contact Address definitions correctly defined for the interface(s) involved. There are no VPN-specific options in the Location and Contact Address definitions, so the same general configuration applies to all system communications.

• In most cases, any external Gateway must be defined using its private IP address and the public IP address must be added as the Contact Address for the contacting StoneGate Firewall’s Location.

• StoneGate VPN Clients download their configuration from the gateway (firewall). If the Location and Contact Address are correctly defined for the endpoint interface in the Firewall element, the configuration includes both the private and the public IP address, and the VPN can be established successfully. If no Contact Address is defined at all, the VPN Client only receives the private IP address and cannot establish the VPN successfully when outside the corporate network.

Supported Authentication and Encryption MethodsYour company’s security policy must contain guidelines for selecting authentication and encryption methods. The main consideration for selecting the authentication and encryption settings in your VPN configuration is that you fulfill the requirements of the security policy and other security requirements that concern your organization.The tables in this section list the different message digest algorithms (for integrity checking), authentication methods, and encryption methods that are available in StoneGate. The IPsec standards mandate support for some options, while additional

Using VPNs 373

options may also be provided by IPsec-compatible products. RFC 4305 lists the IPsec standard requirements.The tables below contain estimates of how common support for the various algorithms is in IPsec-compatible products. This information may be of some use when deciding on methods to use, especially when establishing a VPN with a third-party VPN device, even though no decisions can be made without referring to the documentation on methods supported by the device in question.

Message Digest AlgorithmsMessage digest algorithms (Table 31.1) are used to ensure integrity of data (that the packets have not been changed in transit). These algorithms are often also referred to using the HMAC (keyed-Hash Message Authentication Code) abbreviation.

TABLE 31.1 Supported Message Digest Algorithms

Algorithm Description

AES-XCBC

128-bit hash algorithm. Available only for checking the integrity of the IPsec traffic.Many IPsec-compatible VPN devices do not support this algorithm, but support is becoming increasingly common.Reference: RFC 3566.

MD5

128-bit hash algorithm (also referred to as HMAC-MD5). Available for checking the integrity of the IKE negotiations and IPsec traffic.Most IPsec-compliant VPN devices still support this algorithm, but support may become less common in the future.Reference: RFC 1321.

SHA-1

160-bit hash algorithm (sometimes referred to as HMAC-SHA-1). Available for checking the integrity of the IKE negotiations and IPsec traffic.All VPN devices must support this algorithm to be fully IPsec-compliant.Reference: RFC 4494.


Authentication MethodsAuthentication (Table 31.2) ensures that the remote party is who they claim they are (for example, to prevent a man-in-the-middle attack).

TABLE 31.2 Supported Authentication Methods

Method Description

Pre-Shared Key

Also referred to with the acronym PSK. Authentication is done using a string of characters that is manually entered in the configuration of the VPN devices. Security depends greatly on the complexity and length of the string of characters used, which is why an automatically generated, long string is strongly recommended. You can automatically generate the key in the Management Client or using some external tool. The key must also be periodically changed.Note that the pre-shared key is an encryption key, not a password, and following any normal password selection guideline does not produce a sufficiently long or complex key.It is more secure to use the main mode (not the aggressive mode) for IKE negotiations if you use pre-shared key authentication.All VPN devices must support this method to be fully IPsec-compliant.

RSA SignaturesAuthentication is done using certificates and a digital signature generated according to the RSA algorithm.Most IPsec-compliant VPN devices support this method.

DSS Signatures

Authentication is done using certificates and a DSS (Digital Signature Standard) digital signature (generated according to the DSA, Digital Signature Algorithm).Many IPsec-compatible VPN devices do not support this method.

Using VPNs 375

Encryption AlgorithmsEncryption algorithms (Table 31.3) scramble the data being sent so that it is not viewable while in transit but can be decrypted by the recipient.

TABLE 31.3 Supported Encryption Methods

Method Description

AES-128 Advanced Encryption Standard (also referred to as Rijndael) with a 128-bit/192-bit/256-bit encryption key. The AES-128 option uses 128-bit keys by default, but accepts stronger 192-bit or 256-bit keys if requested by the other gateway.Most IPsec-compliant VPN devices support either one or both key lengths of these methods, and support is becoming more common.Reference: RFC 4309.

AES-256

DES

Data Encryption Standard (also referred to as the Data Encryption Algorithm, DEA), uses a 56-bit encryption key.Do not use DES if you can avoid it. DES has been largely abandoned because the short key makes it vulnerable to attacks. If you must use DES, make sure that PFS is enabled, that the encryption keys are frequently renegotiated, and that any sensitive information is encrypted using a more secure method before it is sent through the VPN.Many IPsec-compliant VPN devices still support this method, but support is becoming less common.Reference: RFC 2405.

3DES

Triple-DES (also referred to as TDES or Triple Data Encryption Algorithm, TDEA), uses 168-bit encryption achieved with three different 56-bit encryption keys.3DES is quite processor-heavy considering the level of protection it offers and is therefore not the most efficient method. It may not be optimal for VPNs that handle large traffic volumes or systems that otherwise have a high load.Most IPsec-compliant VPN devices support this method.Reference: RFC 2451.

Blowfish

Uses up to 448-bit keys. StoneGate uses 128-bit keys by default, but accepts up to 448-bit keys if requested by the other gateway.Many IPsec-compatible VPN devices do not support this method.Reference: RFC 2451.


FIPS 140-2 ModeStoneGate options can be restricted to only settings that comply with the Federal Information Processing Standard FIPS 140-2 requirements. The FIPS mode allows the DES, 3DES, and AES-128 encryption algorithms and SHA-1 hash algorithm. The MD5, Blowfish, Twofish, CAST-128, and Null algorithms are not allowed in the FIPS mode. The FIPS mode also disables the plain AH IPsec mode.

Configuring VPNs with External GatewaysIn StoneGate, the term ‘external gateway’ refers to any VPN gateway that is not controlled by the Management Server on which you are configuring the gateway element. A StoneGate gateway under your administration is an external gateway only if it is managed by a different Management Server than the one you use for configuring the VPN at any given time. In the case of external StoneGate gateways, you can export and import some settings, such as the VPN Profiles, between the two Management Servers, but many of the configurations must be manually constructed on both Management Servers.Often, external gateways are VPN gateways at a partner organization, and not StoneGate firewall/VPN devices. The IPsec standard allows creating a VPN between gateways of different brands, and in theory this is a straightforward process of selecting the desired settings identically for both gateways. The settings that match are:

Twofish

Uses up to 256-bit keys. StoneGate uses 128-bit keys.Twofish is a development of the Blowfish algorithm. It has a larger block size (128 bits compared to 64 bits in Blowfish).Many IPsec-compatible VPN devices do not support this method.

CAST-128

Sometimes also referred to as CAST5. Uses 128-bit keys.Many IPsec-compatible VPN devices do not support this method.Reference: RFC 2451.

Null

No encryption. Traffic is sent as cleartext just like any non-VPN traffic and can be viewed by anyone who intercepts it in transit.Null encryption is useful only in special cases. Do not select it for any VPN that requires protected data transfer.Most IPsec-compliant VPN devices support this method.Reference: RFC 2410.

TABLE 31.3 Supported Encryption Methods (Continued)

Method Description

Using VPNs 377

• The IKE (Phase 1) settings.• The IPsec (Phase 2) Settings.• The Site definitions (IP addresses) defined for both gateways at both ends.When the settings are identical, the VPN works. Unfortunately, there are some practical problems that complicate matching the settings.The first problem you can run into when you configure a VPN between different brand gateways is how to agree on common settings. Each and every setting must match to produce a fully functional VPN, and the supported options may be different on the different gateways. The authentication and encryption methods that StoneGate supports are listed in Supported Authentication and Encryption Methods, on page 373. A related problem is that there is no one common standard for naming the different options, so the two gateways may actually use a different name for the same authentication or encryption method.You may also encounter problems with some external gateways that have some default settings hidden from the user. For example, some gateways have a fixed setting for the Security Association (SA) granularity. Still, you must select the setting on StoneGate that matches the setting used on the other gateway for the VPN to fully work.The Site definitions, which define the IP addresses accessible through each Gateway, are a commonly mismatched setting. These definitions must match between the two Gateways, since the Gateways check the information with each other and do not establish a VPN if the definitions do not match. On StoneGate, you must make sure that the network(s) included in the Site under the external Gateway match exactly the definition of the networks (or individual IP addresses) included as locally protected networks for the VPN for the remote device. You must also communicate the IP addresses included in the internal Gateway’s Site definition (as enabled for this VPN) to the administrator of the external Gateway.

Note – Site definitions are always defined for the Gateway element and are therefore used in all VPNs where the same Gateway is used. If you add a new Site for the Gateway in one VPN, disable it in other VPNs where you do not want the Site to be included.

A good resource for checking whether a VPN gateway is interoperable with other IPsec gateways is the IPsec consortium website at www.vpnc.org/. The IPsec consortium has also come up with two example scenarios (called Interoperability Profiles) for which different manufacturers have provided set-up instructions, allowing you to see how the same settings are configured in different products. Stonesoft has provided a profile for the first scenario (available at the IPsec Consortium website).


http://www.vpnc.org/

Clustering and VPNsA StoneGate Firewall/VPN cluster can be used for VPNs requiring no additional manual configuration. Clustering provides additional high availability and load balancing at the security gateway with multiple nodes in a cluster. In case one of the nodes is put offline or fails, the remaining nodes in the cluster take over the VPN traffic that was handled by that node.

Multi-Link VPNUsing Multi-Link enhances the reliability of the VPN communications by offering network connection high availability with ISP-multihomed VPNs. StoneGate can balance the traffic load between multiple network links and fail over when a link goes down. This reduces the possibility of link congestion or ISP network connectivity breaks. Multi-Link is not a part of the IPsec standards.

Note – Multi-Link is a StoneGate-specific feature supported only with StoneGate gateways at both ends. If an external gateway allows configuring multiple VPN tunnels between two devices, you may be able to enjoy some of the benefits to the extent that the events can be controlled by the StoneGate alone.

In a Multi-Link configuration, the traffic can use one of multiple alternative tunnels to reach the same destination. This ensures that even if one or more tunnels fail, the VPN service continues as long as there is some tunnel available.

Illustration 31.3 Example of a Multi-Link VPN with Standby Tunnels

Multi-Link can be used between two StoneGate gateways when one or both gateways use multiple network connections. Illustration 31.3 shows a Multi-Link VPN between two Gateways that both have multiple Internet connections. In this configuration, ISP 2 at Gateway B acts as a backup link for VPN traffic. The three tunnels (one from each ISP at Gateway A) with their endpoints in the ISP 2 network have been set to standby, so that they are only used if ISP 1 fails. The standby selection in a VPN is independent from other configurations, so other VPNs can still use both ISP 1 and ISP 2

Using VPNs 379

continuously. The standby setting is not tied to a particular ISP (NetLink) either, so it would be possible to set, for example, just the ISP A to ISP 2 tunnel back to active use while leaving other standby settings as they are.VPN traffic is balanced between the tunnels based on the link availability checks on each VPN tunnel. If one of the links fails or becomes congested, the VPN traffic is routed through the other tunnels. Standby tunnels are used if all active tunnels become unavailable. Individual tunnels can be also completely disabled so that they are not used for that specific VPN under any conditions.StoneGate VPN Clients can also use Multi-Link. If one of the gateway’s links fails, the VPN Client connects to the next available NetLink.

Examples of VPN ConfigurationsThe examples in this section illustrate some common uses for VPNs in StoneGate and general steps on how each scenario is configured.

Creating a VPN Between Three OfficesCompany A has a central headquarters site and two remote offices, each with their own StoneGate Firewall/VPN device. The company needs secured communications links between the branch offices and the headquarters, because the branch office users need access to various services, such as file servers, located at the headquarters.

Illustration 31.4 Company A’s Networks

There is no need for secure connectivity between the remote offices, since all shared servers are at the central site, and internal e-mails and other communications that may need to be handled confidentially are also handled by central servers at the headquarters.All firewall/VPN engines have a public IP address towards the Internet. The Internal networks at each site use private IP addresses, but there is no need to translate the VPN traffic, since all offices use their own distinct address space.


The security policy of the company dictates the use of a certificate-based authentication method for the VPN. The Administrators decide to use StoneGate’s internal Certificate Authority for issuing the VPN certificates.The administrators:1. Create internal Gateway elements for all three firewall/VPN engines with each

engine’s public IP address as the VPN endpoint. Automatic Certificate Management option is left on.

2. Add Site elements for all Gateways, and add the entire local internal network as the content for each Site.

3. Create a new VPN Profile and select RSA Encryption as the authentication method.• All three Gateways will be automatically generated the correct type of certificate.

4. Create a VPN element “Inter-Office VPN” that includes the headquarters Gateway as the Central Gateway and the two other Gateways as Satellite Gateways.

5. Add the following types of Access rules in the policy of the headquarters firewall:

6. Add the following types of Access rules in the policy of both branch office firewalls:

7. Refresh the policies of all firewalls.

TABLE 31.4 Example VPN Access Rules for the Headquarters Firewall

Source Destination Action

Network elements for Branch office 1 and Branch office 2 internal IP addresses

Network elements for Headquarters internal networks

Use VPN - Enforce VPN “Inter-office VPN”


Network elements for Branch office 1 and Branch office 2 internal IP addresses




Network element for each Branch office’s internal IP addresses




Network element for each Branch office’s internal IP addresses



Creating a VPN for Mobile UsersCompany A from the first example above also has service technicians and salespeople at all offices who must be able to connect to their office network to access information when they are on customer visits. They need to add VPN client access to their existing VPN infrastructure. The administrators decide they want to use the StoneGate VPN Client, since all their users are running a compatible Windows operating system.As the authentication method, the administrators decide to use passwords stored in the Management Server’s internal database.The administrators also want to set the system up so that the service technicians and salespeople have only one point of access so that they can connect without having to choose which gateway to connect to. That one point is the headquarters Gateway, which has gateway-to-gateway VPN tunnels to both branch offices that can be used for forwarding traffic to those sites as needed. The existing DHCP server at the headquarters can be used for assigning IP addresses to the VPN clients’ Virtual Adapter, which is required for this kind of forwarding.The administrators:1. Edit the headquarters Gateway element and select the Virtual Adapter as the

method for StoneGate VPN Client address management.2. Edit the VPN Profile to use Hybrid Authentication for authenticating the VPN

client users.3. Create a VPN element “Remote User VPN” that includes the headquarters

Gateway as the Central Gateway and the default Client Gateway element as a Satellite Gateway.

4. Add the Branch office networks in a new “Forward Addresses” Site element under the headquarters gateway to make those IP addresses route through the “Remote User VPN”.

5. Disable the “Forward Addresses” Site in the existing “Inter-Office VPN” between the Headquarters and the Branch offices.• Sites are global for all VPNs, so this Site must be specifically disabled to avoid

a misconfiguration in the other VPN.6. Create User Group and User elements to define the user names and passwords

for the VPN client users.


7. Add the following types of Access rules in the policy of the headquarters firewall:

8. Refresh the policy of the headquarters firewall.9. Create a customized installation package of the StoneGate VPN Client, so that

the users can install using a silent installation package that does not require their input.• The administrators include the Gateway configuration in the package so that the

users do not need to download it even when connecting for the first time.• They set the silent installation to install the Virtual Adapter so that the VPN

Clients can use the DHCP-assigned addresses for VPN communications.

Creating a VPN when NAT Is UsedCompany B have just decided to partner up with another company for a large project. Since the companies will need to exchange a lot of sensitive information, they decide to establish a VPN.The external Gateway is behind a NAT device that translates between its internal and external IP address. This needs to be taken into consideration, since both addresses are needed in the VPN configuration.Additionally, both companies use the same address space internally, so they must apply NAT for all connections through the VPN as well.

Illustration 31.5 NAT for VPN Between Company B’s Internal Network and Partner


Source Destination Action Users Authenti-cation

Source VPN

ANYHeadquarters internal networks

Use VPN - Enforce VPN “Remote User VPN”

“VPN Client Users” User Group

“User Password” Authenti-cation Service

VPN Client DHCP addresses

Branch offices’ internal IP addresses

Use VPN - Forward VPN “Inter-Office VPN”

Match Any Mobile User VPN


NAT is to be applied at both Company B and their Partner Company before traffic enters the VPN from each end. This way, routing problems caused by the same network appearing in two different locations can be avoided, since each end uses the translated addresses for the network at the other end.The Administrators:1. Create an internal Gateway element for their own firewall/VPN engine with the

engine’s public IP address as the VPN endpoint.2. Create a new Location element and select it for their Firewall element.3. Create an external Gateway element for the partner’s VPN device using the

internal IP address as the VPN endpoint, and adding the external (translated) IP address as the Contact Address for the Location created in the previous step.

4. Create a Network element “HQ NAT Address Space” for the addresses that Company B plans to use for translating their internal IP addresses.

5. Add only the Network created in the previous step in the Site for the internal gateway.

6. Create a Network element “Partner Network” for the addresses that the partner company plans to use for translating their internal IP addresses.

7. Add the “Partner Network” as the only network in the Partner Gateway’s Site.8. Create a new VPN Profile and select all settings so that they match those agreed

with the partner company.9. Create a VPN element “Partner VPN” that includes the headquarters Gateway as

the Central Gateway and the partner Gateway as a Satellite Gateway.10.Add the following types of Access rules in the policy of the headquarters firewall:

11.Add the following types of NAT rules in the same policy:



Network element “Partner Network”

Network element “HQ NAT Address Space”

Use VPN - Enforce VPN “Partner VPN”

Headquarters network (real IP addresses)


Use VPN - Enforce VPN “Partner VPN”

TABLE 31.8 Example VPN NAT Rule for the Headquarters Firewall

Source Destination NAT

Headquarters network (real IP addresses)


Static source translation to “HQ NAT Address Space”


• To make the static address translation work, the administrators take care that the translated address space is as large as the original address space.

12.Refresh the policy of the firewall.


Network element “HQ NAT Address Space”

Static destination translation to headquarters network (real IP addresses)

TABLE 31.8 Example VPN NAT Rule for the Headquarters Firewall

Source Destination NAT



Administration

CHAPTER 32 Categories

A Category is a label for grouping together related elements. Categories make it easier to manage large networks by restricting which elements are displayed at any given time.


Overview to Categories, on page 390 Configuration of Categories, on page 390 Using Categories, on page 391 Examples of Categories, on page 392

389

Overview to CategoriesIn a large system, there can be hundreds of elements, but you usually do not need to work with all of the elements at the same time. Categories allow you to group together related elements according to any criteria you want. For example, you can create Categories based on the sites you manage, or to separate elements used in Firewall and IPS configuration. Using Categories restricts which elements are displayed. Elements that do not belong to the selected Category are filtered out so that only the relevant elements are visible. This allows you to manage a large number of elements more efficiently by making it easier to find the elements that are needed.

Configuration of CategoriesCategories are found in the Configuration view under All Elements→Administration.Unlike most other elements, Categories that you create are listed as branches in the All Elements tree. You can create as many Categories as you need. An element may belong to more than one Category. You can modify the contents of the Categories by adding or removing elements.

Default ElementsThe System and Not Categorized Categories exist by default.All the default elements that belong to the system have been assigned the System Category. This way, you can display the System elements with any other Category selected when you use it in a combined Category Filter (see Combining Categories, on page 392 for an example). The Not Categorized Category contains all elements that do not belong to any specific Category. This makes it easy to find elements that have not been assigned a Category yet. It is also the Category filter that is selected by default.

Configuration WorkflowThe following sections provide an overview of the configuration tasks related to Categories. Detailed step-by-step instructions can be found in the online help of the Management Client and the Administrator’s Guide PDF, in the section called Elements.

Task1: Create CategoriesYou can create as many Categories as you need. For example, you can create a Category for each site you manage, or separate Categories for elements used in Firewall and IPS configuration. You define the Categories and the elements that belong to them, so you can base the categorization on any criteria you want.

390 Chapter 32: Categories

Task 2: Associate Elements with CategoriesElements can be associated with Categories in two ways: you can assign elements to a Category, or you can assign Categories to an element. The effect is the same in both cases, but one approach may be preferable, depending on the situation. When there are existing elements and a new Category, it may be more convenient to assign the elements to the Category. When there are existing Categories and new elements, it may be more convenient to select the Category for the element when defining its properties. One element can belong to more than one Category.Most elements can be added to Categories. However, the following types of elements cannot be added to a Category:• Access Control Lists• Administrator Roles• Administrators• Backups• Other Categories (however, you can select several Categories for viewing)• Incident Cases• Locations• Monitoring Users• Updates• Authentication Services• Users• IPS Inspection Protocols• IPS Logical Interfaces• Monitoring Users• Vulnerabilities• Tasks

Task 3: Select a Category to Filter the Displayed ElementsCategories are selected for filtering in the Category Filter Toolbar. Selecting a Category filters the elements that are displayed in all views. You can select multiple Categories to create combined Category Filters. See Combining Categories, on page 392 for an example.

Using CategoriesCategories are useful whenever you need to make a distinction between elements. Categories can be used to group together related elements, such as those used in IPS or Firewall configuration, or to show only a subset of elements at one particularly large site. Categories are also particularly useful in Managed Service Provider (MSP) environments, for example, to distinguish elements belonging to different sites.

Using Categories 391

Examples of CategoriesThe examples in this section illustrate some common uses for Categories in StoneGate and general steps on how each scenario is configured.

Creating Separate Categories for Different SitesCompany A is a large enterprise planning a new system. The system will include 12 different sites, each of which will contain 10 networks. The administrators at each site only need to see the networks at their own sites. To restrict which networks are displayed, the following steps are taken:1. The headquarters administrator creates Categories to represent each of the 12

sites.2. The headquarters administrator creates elements to represent each site’s

configuration and assigns the appropriate Category to each element while defining its properties.

3. The administrators at each site select the appropriate Category as the active filter so that only the elements in their own site’s configuration are displayed.

Combining CategoriesCompany B has sites in New York, Toronto, and Mexico City. The network elements have already been divided into Categories according to the site they belong to. Usually, administrators only need to work with one site at a time, but today Administrator A needs to apply the same configuration changes to the New York and Toronto sites. Administrator A does not want to create a new Category for this temporary need. To be able to see elements belonging to both the New York and Toronto sites without losing their site-specific Categories, Administrator A does the following:1. Selects the New York and Toronto Categories in the Category filtering toolbar.

Illustration 32.1 Combined Categories in the Category Filtering Toolbar

2. Applies the filter so that elements at both the New York and Toronto sites are displayed, and elements in the Mexico City Category are filtered out.

3. Makes the configuration changes on the two sites.4. Deactivates the Category filter to display all elements again.

392 Chapter 32: Categories

CHAPTER 33 Incident Cases

The Incident Case element is a tool for investigating incidents of suspicious activity.


Overview to Incident Cases, on page 394 Configuration of Incident Cases, on page 394 Using Incident Cases, on page 396 Example of an Incident Case, on page 397

393

Overview to Incident CasesWhen suspicious activity is detected, it is important to collect all the information about the incident and act quickly. The Incident Case element allows you to gather together all the data, actions, system configuration information, and files related to a specific incident. This information is useful for effective incident investigation, and also helps to provide evidence in the case of legal action.

Configuration of Incident CasesIncident cases are found in the Configuration view in the Administration branch of the All Elements tree.When you open an incident case, the Data Collection, Player List, and Journal tabs are visible. You can open other tabs through the View menu or by using the forward and back browsing buttons in the toolbar. The following tabs are available:

Configuration WorkflowThe following sections provide an overview of the configuration tasks related to incident cases. Detailed step-by-step instructions can be found in the online help of the Management Client and the Administrator’s Guide PDF, in the section called Monitoring.

Task 1: Create an Incident CaseThe Incident Case element stores all the information related to the incident. You can give the Incident case one of four pre-defined priorities ranging from Low to Critical.

TABLE 33.1 Incident Case tabs

Tab Explanation

Data CollectionAllows you to attach information that is needed to provide context for investigating an incident.

Player ListLists the elements or IP addresses that were involved in the incident.

JournalAllows you to record comments about administrator actions during the incident investigation.

HistoryAutomatically gathers and displays all the log and audit entries that track actions performed in this incident case.

394 Chapter 33: Incident Cases

Task 2: Attach DataThe following types of data can be attached to the Incident Case:

Task 3: Attach PlayersA player is any element or IP address that was involved in the incident. Attaching players to an incident case creates a reference to a StoneGate element.

Task 4: Write Journal EntriesThe journal allows administrators to keep a record of what actions they have performed and why they have performed them while investigating the incident. It is especially useful when more than one administrator is investigating the same incident simultaneously.

Task 5: Close the Incident CaseThe Incident Case element also allows you to track the current state of the investigation by setting the incident case’s State at the appropriate stages of incident investigation to one of the following four values:• Open• Under Investigation• False Positive• Closed.When the investigation is finished, you can close the incident case. The incident case stays in the system, but its state is marked as closed. It is a good idea to keep resolved incident cases as a record of past incidents or for future reference in dealing with new incidents. However, if you determine that there is no need to keep a particular incident case, you can delete it.

TABLE 33.2 Data Collection

Data Item Explanation

LogsLog, alert, and audit entries from firewall or IPS engines and Log and Management servers.

Policy SnapshotA record of record of a configuration stored in the upload history. Policy Snapshots help to establish which policies were in place at the time of the incident.

MemoA simple text file for attaching excerpts of text, for example, by copying and pasting from e-mail, IRC or instant messaging.

FileAny type of file. For example, saved reports, text files, saved e-mail messages, packet capture files, or screenshot images.

Configuration of Incident Cases 395

Using Incident CasesThere are many ways an administrator can become aware of suspicious activity in the system. However, the most likely way is by noticing something unusual in the logs or audit entries, or being warned about a potential problem in an alert. Once a suspicious event is detected, the workflow generally follows one of these scenarios:

Investigation by One Administrator1. The administrator creates a new incident case.2. The administrator collects data and players, and attaches them to the incident

case.3. The administrator reacts to contain the incident, for example, by stopping an

engine or changing a Firewall policy.4. The administrator may try to eradicate the problem, for example, by installing

software patches or updating anti-virus programs.5. When the problem is resolved, the administrator closes the incident case.

Investigation by More Than One Administrator1. An administrator creates a new incident case.2. The administrator delegates work to other administrators.3. Each administrator collects data and players, and attaches them to the incident

case.4. An administrator reacts to contain the incident, for example, by stopping an

engine or changing a Firewall policy.5. An administrator may try to eradicate the problem, for example, by installing

software patches or updating anti-virus programs.• The administrator can write a new comment in the incident journal to inform the

other administrators about what has been done.6. When the problem is resolved, the administrator closes the incident case.

Investigation of a False Positive1. The administrator creates a new incident case.2. While collecting data, the administrator discovers that the suspicious event was

not a real problem.3. The administrator marks the incident case as a false positive.


Example of an Incident CaseThe administrator receives an IPS alert that there is active two-way backdoor traffic between a server in the organization's internal network and an unknown host in the Internet. The administrator then:1. Opens a new incident case to help manage this incident.2. Searches for previous logs from the Firewall and IPS engines to identify the

vulnerability that allowed the server to be compromised.3. Attaches the relevant logs to the incident case.4. Re-installs the server, and installs patches to prevent the same vulnerability

from being exploited again.5. Closes the incident case.

Example of an Incident Case 397


Appendices

APPENDIX A StoneGate-Specific Ports

The following illustrations show the connections between the StoneGate components, as well as the ports that are used for gateway-to-gateway VPN and client-to-gateway VPN connections. The complete list of ports is presented in the table that follows.

Illustration A.1 Basic Communications Between StoneGate Components

401

Illustration A.2 Service Communications of Firewall/VPN Engine

Illustration A.3 Communications between SOHO Firewall engines and SMC components

402 Appendix A: StoneGate-Specific Ports

The following table lists all the ports used in communication between various StoneGate Firewall/VPN components. The ports used by StoneGate IPS are detailed in StoneGate IPS Reference Guide.

TABLE A.1 StoneGate-Specific Ports

Listening Host Port/Protocol Contacting

Hosts Service DescriptionService Element

Name

DHCP server 67/UDPFW/VPN Engine

DHCP requests relayed by the firewall and requests from a firewall that uses dynamic IP address.

BOOTPS (UDP)

DNS server 53/TCPFW/VPN Engine

Optional dynamic DNS updates for inbound load sharing

DNS (TCP)

DNS server 53/UDP

Management Client, Management Server, Log Server

DNS queries to resolve DNS names

DNS (UDP)

External LDAP server

389/TCPManagement Server, FW/VPN Engine

External LDAP queries. LDAP (TCP)

FW/VPN Engine

15000/TCPManagement Server, Analyzer

Blacklist entries sent to firewall SG Blacklisting

FW/VPN Engine

161/UDP SNMP server SNMP monitoring. SNMP (UDP)

FW/VPN Engine

2535/TCP VPN Client VPN Client configuration downloadSG VPN Client Configuration

FW/VPN Engine

2543/TCP Any User authentication (Telnet)SG User Authentication

FW/VPN Engine

2746/UDP VPN Client UDP encapsulated IPsecSG UDP Encapsulation

FW/VPN Engine

3000-3001/UDP3002-3003, 3010/TCP

FW/VPN Engine

Heartbeat and state synchronization between the cluster nodes.

SG State Sync (Multicast), SG State Sync (Unicast), SG Data Sync

403

FW/VPN Engine

4500/UDP VPN Client NAT-Traversal for VPN Client. NAT-T

FW/VPN Engine

4950/TCPManagement Server

Engine remote upgradeSG Remote Upgrade

FW/VPN Engine


Policy upload SG Commands

FW/VPN Engine

500/UDPVPN Client, external VPN gateway

Internet Key Exchange (IKE) for IPsec.

ISAKMP (UDP)

FW/VPN Engine


StoneGate internal LDAPS replication.

LDAPS (TCP)

FW/VPN Engine

67/UDP Any DHCP relay on firewall engine. BOOTPS (UDP)

FW/VPN Engine

68/UDP DHCP server Replies to DHCP requests. BOOTPC (UDP)

FW/VPN Engine


Connectivity monitoring, status monitoring for old version engines

SG Monitoring

Log Server 3020/TCPFW/VPN Engine, Log Server

Log and alert messages, monitoring (status, statistics).

SG Log

Log Server8914-8918/TCP

Management Client, Monitoring Server

Management Client and Monitoring Server connections to the Log Server.

SG Data Browsing, SG Data Browsing (Monitoring Server)

Log Server 8923/TCPSOHO Firewall engine

SOHO Firewall logging connections to the Log Server.

SG SOHO Log

Management Server

3021/TCPFW/VPN Engine

Engine's initial contact. SG Initial Contact

Management Server

3023/TCPFW/VPN Engine

Monitoring (status) connection.SG Reverse Monitoring

TABLE A.1 StoneGate-Specific Ports (Continued)



Name


Management Server

5936/TCP Log Server Log Server's initial contact.SG Log Initial Contact

Management Server

8902-8913/TCP

Management Client, Log Server, Alert Server, Monitoring Server

Management Client, Log Server, Alert Server, and Monitoring Server connections to the Management Server.

SG Control

Management Server

8906/TCP

FW/VPN Engine with dynamic IP address

Management connection for engine with a dynamic IP address.

SG Dynamic Control

Management Server

8922/TCPSOHO Firewall engine

SOHO Firewall configuration and status communication to the Management Server.

SG SOHO Control

Management Server

8924/TCPSOHO Firewall engine

SOHO Firewall initial contact (certificate request) to the Management Server

SG SOHO Initial Contact

Monitoring Agent on Server Pool members

7777/UDPFW/VPN Engine

If servers belonging to a Server Pool are configured with the Monitoring Agent, the engines will frequently poll the servers’ Monitoring Agent on this port for availability and load information.

SG Server Pool Monitoring

Monitoring Server

8919-8921/TCP

Monitoring Client

Monitoring Client connection to Monitoring Server.

SG Control (Monitoring Client)

NTP server 123/UDPSOHO Firewall engine

Time synchronization. NTP (UDP).

Primary Management Server

8903, 8907/TCP

Secondary Management Server

Management database replication to the secondary Management Server.

SG Control

RADIUS server

1812, 1645/UDP

FW/VPN Engine

RADIUS authentication requests.RADIUS (Authentication), RADIUS (Old)




Name

405

RPC server111/UDP, 111/TCP

FW/VPN Engine

RPC number resolve.SUNRPC (UDP), Sun RPC (TCP)

Secondary Management Server

8902, 8905, 8913/TCP

Primary Management Server

Management database replication to the secondary Management Server.

SG Control

SNMP Server 162/UDPFW/VPN Engine

SNMP traps from the engine. SNMP Trap (UDP)

Stonesoft Server


Queries availability of new dynamic update packages and engine upgrades.

HTTPS

TACACS+ server

49/TCPFW/VPN Engine

TACACS+ authentication requests. TACACS (TCP)

VPN Client 2535/TCPFW/VPN Engine

Configuration downloadSG VPN Client Configuration

VPN Client 2543/TCPFW/VPN Engine

User authenticationSG User Authentication

VPN Client 2746/UDPFW/VPN Engine

UDP encapsulationSG UDP Encapsulation

VPN Client 500/UDPFW/VPN Engine

Internet Key Exchange (IKE) for IPsec

ISAKMP (UDP)




Name


APPENDIX B Command Line Tools

This appendix describes the command line tools for StoneGate Management Center and the engines.


Management Center Commands, on page 408 Engine Commands, on page 416.

407

Management Center CommandsMost of the Management Server and Log Server commands are found in the <installation directory>/bin/ directory. In Windows, the command line tools are *.bat script files. In Linux and Unix, the files are *.sh scripts.

Note – Using the Management Client is the recommended configuration method, as most of the same tasks can be done through it.

The command for post-processing report files is in the <installation directory>/data/reports/bin/ directory. It runs the sgPostProcessReport.bat (in Windows) or .sh script (in Linux/Unix) on the Management Server.

TABLE B.1 Management Center Command Line Tools

Command Description

sgArchiveExport i=INPUT_FILEpass=PASSWORD [ e=FILTER_EXPRESSION ] [ f=FILTER_FILE ] [ format=CSV|XML ] [ host=ADDRESS ] [ login=LOGIN_NAME ] [ o=OUTPUT_FILE ] [ -v ] [ -h ]

Displays or exports logs from the log archive files. This command is available only on the Log Server.Enclose the file and filter names in double quotes if they contain spaces.i=INPUT_FILE parameter defines the source archive from which the logs will be exported.pass=PASSWORD parameter defines the password for the user account used for this export.e=FILTER_EXPRESSION parameter defines the filter that you want to use for filtering the log data for exporting. Type the name as shown in the Management Client. f=FILTER_FILE parameter defines the StoneGate filter exported to a file that you want to use for filtering the log data for exporting.format=[CSV|XML] parameter defines the file format for the output file. If this parameter is not defined, the XML format is used.host=ADDRESS parameter defines the address of the Management Server used for checking the login information. If this parameter is not defined, Management Server is expected to be on the same host where the script is run.login=LOGIN_NAME parameter defines the username for the account that is used for this export. If this parameter is not defined, the username root is used.o=OUTPUT_FILE parameter defines the destination file where the logs will be exported. If this parameter is not defined, the output is displayed on screen.-h option displays information on using the script.-v option displays verbose output on the command execution.

408 Appendix B: Command Line Tools

sgBackupLogSrv

Creates a backup of Log Server configuration data. The backup file is stored in the <installation directory>/backups/ directory. You can restore the backup using the sgRestoreLogBackup command. When creating or restoring the backup, twice the size of log database is required on the destination drive. Otherwise, the backup or restoration process fails.

sgBackupMgtSrv

Creates a backup of all Management Server configuration and database data. The backup file is stored in the <installation directory>/backups/ directory. You can restore the entire backup (the Management Server database and/or configuration files) using the sgRestoreMgtBackup command. You can restore just the Management Server database using the sgRecoverMgtDatabase command.When creating or restoring the backup, twice the size of the Management Server database is required on the destination drive. Otherwise, the backup or restoration process fails.

sgCertifyLogSrv

Certifies the Log Server on the Management Server. The certificate is required to allow secure communication between the Log Server and the Management Server.As long as the new certificate is issued by a trusted certificate authority, renewing the certificate does not require changing the configuration of any other system components.

sgCertifyMgtSrv

Recreates the Management Server’s certificate. The Management Server certificate is required for secure communications between the StoneGate system components, as well as for the VPN connections that use the certificate authentication.As long as the new certificate is issued by a trusted certificate authority, renewing the certificate does not require changing the configuration of any other system components.

sgCertifyMonitoringServer

Certifies the Monitoring Server on the Management Server. The certificate is required to allow secure communication between the Monitoring Server and the Management Server.As long as the new certificate is issued by a trusted certificate authority, renewing the certificate does not require changing the configuration of any other system components.

TABLE B.1 Management Center Command Line Tools (Continued)

Command Description

Management Center Commands 409

sgChangeMgtIPOnLogSrv NEW_IP_ADDR

Changes the Management Server’s IP address on the Log Server. Use this command to configure a new Management Server’s IP address on the Log Server. Restart the Log Server after this command.NEW_IP_ADDR is the new Management Server’s IP address.

sgChangeMgtIPOnMgtSrv NEW_IP_ADDR

Changes the Management Server’s IP address. Use this command when you want to change the Management Server’s IP address to reflect changes made in the operating system. Restart the Management Server after this command. NEW_IP_ADDR is the new Management Server’s IP address

sgClient Starts the StoneGate Management Client.

sgCreateAdminCreates a superuser administrator account. The Management Server needs to be stopped before running this command.

sgDeleteElement

[-host=MANAGEMENT_SERVER_ADDRESS][-user=LOGIN_NAME][-password=PASSWORD][-name=ELEMENT_TO_DELETE][-multiple=DELETE_ALL_MATCHES][-type=TYPE_OF_OBJECT][-listType=ALLOWED_OBJECT_TYPE][ -h ]

Deletes elements from the Management Server database. Run the command without arguments to see usage instructions.host=MANAGEMENT_SERVER_ADDRESS parameter defines the address of the Management Server from whose database the element(s) are deleted. If this parameter is not defined, the default address 127.0.0.1 is used for the operation.user=LOGIN_NAME parameter defines the username for the account that is used for this operation. If this parameter is not defined, the username root is used.password=PASSWORD parameter defines the password for the user account used for this operation.name=ELEMENT_TO_DELETE parameter defines the name of the element(s) to be deleted. Be default, only the first matching element is deleted.multiple=DELETE_ALL_MATCHES option defines that all the elements matching the value(s) set for the selected parameter(s) (for example, the name parameter) are deleted.type=TYPE_OF_OBJECT parameter defines the Type of the element(s) to be deleted.listType=ALLOWED_OBJECT_TYPE option lists the values that may be used with the type parameter.-h option displays information on using the script.


Command Description


sgExport [-host=host] -login=login name -password=password -file=file path and name -type= <all|nw|ips|sv|rb|al>

[-recursion] [-system] [-name= <Element Name 1, Element Name 2, ...>]

Exports StoneGate Management Server database elements to an XML file. Run the command without arguments to see usage instructions.The optional Host parameter specifies the IP address of the Management Server. If no specific host address is given, the host where the script is executed is used for the operation.Login and password can be for any valid Administrator account that has the required privileges assigned in the profile used.The type parameter specifies which types of elements are included in the export file: all=all exportable elements, nw=network elements, ips=IPS elements sv=services, rb=security policies, al=alerts.The optional recursion parameter includes referenced elements in the export, for example, the network elements used in a policy that you export.The optional system parameter includes in the export any system elements that are referenced by the other elements.The optional name parameter allows you to specify by name the element(s) that you want to export.

sgHA [host=host] login=login name password=password

[-h|--help]

[-set-active]

[-set-standby]

[-force-active]

[-sync]

Switches between the active and the standby management servers.-h | --help options display the help message.-set-active option sets a standby management server as the active management server, sets the formerly active management server as a standby management server, and synchronizes the database between them.-set-standby option sets the active management server as a standby management server.-force-active option sets a standby management server as the active management server without synchronizing the database with the formerly active management server.-sync option functions differently on a standby management server and an active management server. If you run it on an active management server, it replicates the active database to every standby management server that does not have the Disable Database Replication option selected in its properties. If you run it on a standby management server, it replicates the active database from the active management server only to this standby management server (regardless of whether the Disable Database Replication option is or is not selected in the standby management server’s properties).


Command Description


sgImport [host=host] login=login name password=password file=file path and name

Imports StoneGate Management Server database elements from an XML file. Run the command without arguments to see usage instructions.The optional Host parameter specifies the address of the host that holds or will hold the import file. If no specific host address is given, the host where the script is executed is used for the operation.Login and password can be for any valid Administrator account.When importing, existing (non-default) elements are overwritten, unless the element types mismatch.

sgImportExportUser [host=host] login=login name pass=password action=[import|export] file=file path and name

Imports and exports a list of Users and User Groups in an LDIF file from/to the Management Server’s internal LDAP database. To import User Groups, all User Groups in the LDIF file must be directly under the stonegate top-level group (dc=stonegate).Host specifies the address of the host that holds or will hold the LDIF file. If no specific host address is given, the host where the script is executed is used for the operation.Example: sgImportExportUser login=ricky pass=abc123 action=export file=c:\temp\exportedusers.ldif

The user information in the export file is stored as plaintext. Handle the file securely.

sgInfo

Creates a ZIP file that contains copies of configuration files and the system trace files containing logs on problem situations. The ZIP file is stored in the user’s home directory. The file location is displayed on the last line of screen output. Provide the generated file to Stonesoft support for troubleshooting purposes.

sgReinitializeLogServerRecreates the Log Server configuration if the configuration file has been lost.


Command Description


sgReplicate [-h|--help]

[-nodiskcheck]

[-backup backupname]

-standby-server management-name

Replicates Management Server backup to the Secondary Management Server.-h | --help options display the help message-backup backupname option specifies the location of the backup file. If this is not specified, you are prompted to select the backup file from a list of files found in the backups directory.-nodiskcheck option disables the free disk space check before the backup restoration.-standby-server management-name option specifies the Secondary Management Server on which the backup is replicated.

sgRestoreArchive ARCHIVE_DIR

Restores logs from archive files to the Log Server. This command is available only on the Log Server. ARCHIVE_DIR is the number of the archive directory (0 – 31) from where the logs will be restored. By default, only archive directory 0 is defined. The archive directories can be defined in the <installation directory>/data/LogServerConfiguration.txt file: ARCHIVE_DIR_xx=PATH.

sgRestoreCertificateRestores the Certificate Authority (CA) or the Management Server certificate from a backup file in the <installation directory>/backups/ directory.

sgRestoreLogBackupRestores the Log Server (logs and/or configuration files) from a backup file in the <installation directory>/backups/ directory.

sgRestoreMgtBackupRestores the Management Server (database and/or configuration files) from a backup file in the <installation directory>/backups/ directory.

sgShowFingerPrintDisplays the CA certificate’s fingerprint on the Management Server.

sgStartLogDatabaseStarts the Log Server’s database. (The Log Server’s database is started and stopped automatically when starting/stopping the Log Server service.)

sgStartLogSrv Starts the Log Server and its database.


Command Description


sgStartMgtDatabaseStarts the Management Server’s database. (The Management Server’s database is started and stopped automatically when starting/stopping the Management Server service.)

sgStartMgtSrv Starts the Management Server and its database.

sgStartMonitoringServer Starts the Monitoring Server used by the Monitoring Client.

sgStopLogDatabase Stops the Log Server’s database.

sgStopMgtDatabaseStops the Management Server’s database. (The Management Server’s database is started and stopped automatically when starting/stopping the Management Server service.)

sgStopMonitoringServer Stops the Monitoring Server used by the Monitoring Client.

sgStopRemoteMgtSrv [-host HOST] [-port PORTNUM] [-login LOGINNAME] [-pass PASSWORD]

Stops the Management Server service when run without arguments. To stop a remote Management Server service, provide the arguments to connect to the Management Server.HOST is the Management Server’s host name if not localhost.PORT is the Management Server’s Management Client port number (by default, 8902).LOGINNAME is a StoneGate administrator account for the login.PASSWORD is the password for the administrator account.


Command Description


sgTextBrowser pass=PASSWORD [ e=FILTER_EXPRESSION ] [ f=FILTER_FILE ] [ format=CSV|XML ] [ host=ADDRESS ] [ login=LOGIN_NAME ] [ o=OUTPUT_FILE ] [ m=current|stored ] [ -v ] [ -h ]

Displays or exports current or stored logs. This command is available only on the Log Server.Enclose the file and filter names in double quotes if they contain spaces.pass=PASSWORD parameter defines the password for the user account used for this operation.e=FILTER_EXPRESSION parameter defines the filter that you want to use for filtering the log data. Type the name as shown in the Management Client. f=FILTER_FILE parameter defines the StoneGate filter exported to a file that you want to use for filtering the log data.format=[CSV|XML] parameter defines the file format for the output file. If this parameter is not defined, the XML format is used.host=ADDRESS parameter defines the address of the Management Server used for checking the login information. If this parameter is not defined, Management Server is expected to be on the same host where the script is run.login=LOGIN_NAME parameter defines the username for the account that is used for this export. If this parameter is not defined, the username root is used.o=OUTPUT_FILE parameter defines the destination file where the logs will be exported. If this parameter is not defined, the output is displayed on screen.m=current|stored parameter defines whether you want to view or export logs as they arrive on the Log Server (current) or logs stored in the active storage directory (stored). If this option is not defined, the current logs are used.-h option displays information on using the script.-v option displays verbose output on the command execution.


Command Description


Engine CommandsStoneGate engine commands can be run from the command line on the firewalls. Engine commands are not supported on SOHO firewalls.

TABLE B.2 StoneGate-specific Command Line Tools on Engines

Command Engine Type Description

sg-blacklist [-i FILENAME] [-f FILENAME] [-v]show |

add [src ADDR/MASKLEN] [dst ADDR/MASKLEN][ proto {tcp|udp|icmp|NUM}] [srcport PORT[-PORT][dstport PORT[-PORT][duration NUM] |del [src ADDR/MASKLEN] [dst ADDR/MASKLEN][ proto {tcp|udp|icmp|NUM}] [srcport PORT[-PORT][dstport PORT[-PORT][duration NUM] |iddel NODE_ID ID |flush

firewall

Used to manage blacklisting on the engine command line if blacklisting is configured. You must enter one of the commands, as well as any parameters required by the command.-i option takes input to add/delete from a file.-f option only shows entries in one blacklist file.-v option enables verbose mode.show command shows the currently active blacklist entries.add command adds a new blacklist entry with the specified parameters.del command deletes a blacklist entry that contains the specified parameters.iddel NODE_ID ID command deletes a blacklist entry on the specified node number with the specified ID number.flush command clears all blacklist entries.src ADDR/MASKLEN parameter defines the source address to add or delete in the blacklist entry.dst ADDR/MASKLEN parameter defines the destination address to add or delete in the blacklist entry.proto {tcp|udp|icmp|NUM} parameter defines the protocol type and number to add or delete in the blacklist entry.srcport PORT[-PORT] parameter defines the TCP/UDP source port or range to add or delete in the blacklist entry.dstport PORT[-PORT] parameter defines the TCP/UDP destination port or range to add or delete in the blacklist entry.duration NUM parameter defines the duration of the blacklist entry in seconds.


sg-bootconfig

[--primary-console=tty0|ttyS PORT,SPEED][--secondary-console= [tty0|ttyS PORT,SPEED]][--flavor=up|smp][--initrd=yes|no][--crashdump=yes|no|Y@X][--append=kernel options][--help]apply

firewall

Can be used to edit boot command parameters for future bootups.--primary-console=tty0|ttyS PORT,SPEED parameter defines the terminal settings for the primary console.--secondary-console= [tty0|ttyS PORT,SPEED] parameter defines the terminal settings for the secondary console.--flavor=up|smp [-kdb] parameter defines whether the kernel is uniprocessor or multiprocessor.--initrd=yes|no parameter defines whether Ramdisk is enabled or disabled.--crashdump=yes|no|Y@X parameter defines whether kernel crashdump is enabled or disabled, and how much memory is allocated to the crash dump kernel (Y). The default is 24M. X must always be 16M.--append=kernel options parameter defines any other boot options to add to the configuration.--help parameter displays usage information.apply command applies the specified configuration options.

sg-clear-all firewall

Use this only if you want to return a StoneGate appliance to its factory settings.Clears all configuration from the engine. You must have a serial console connection to the engine to use this command.

TABLE B.2 StoneGate-specific Command Line Tools on Engines (Continued)


Engine Commands 417

sg-cluster

[status [-c SECONDS]][online][lock-online][offline][lock-offline][standby]

firewall

Used to display or change the status of the node.status [-c SECONDS] command displays cluster status. When -c SECONDS is used, status is shown continuously with the specified number of seconds between updates.online command sends the node online.lock-online command sends the node online and keeps it online even if another process tries to change its state.offline command sends the node offline.lock-offline command sends the node offline and keeps it offline even if another process tries to change its state.standby command sets an active node to standby.

sg-contact-mgmt firewall

Used for establishing a trust relationship with the Management Server as part of engine installation or reconfiguration (see sg-reconfigure below). The engine contacts the Management Server using the one-time password created when the engine’s initial configuration is saved.

sg-logger

-f FACILITY_NUMBER -t TYPE_NUMBER

[-e EVENT_NUMBER] [-i "INFO_STRING"][-s] [-h]

firewall

Can be used in scripts to create log messages with the specified properties.-f FACILITY_NUMBER parameter defines the facility for the log message.-t TYPE_NUMBER parameter defines the type for the log message.-e EVENT_NUMBER parameter defines the log event for the log message. The default is 0 (H2A_LOG_EVENT_UNDEFINED).-i "INFO_STRING" parameter defines the information string for the log message.-s parameter dumps information on option numbers to stdout-h parameter displays usage information.




sg-raid

[-status] [-add] [-re-add] [-force] [-help]

firewall

Configures a new hard drive on a StoneGate appliance. This command is only available for StoneGate appliances that support RAID (Redundant Array of Independent Disks) and have two hard drives.-status option displays the status of the hard drive.-add options adds a new empty hard drive. Use -add -force if you want to add a hard drive that already contains data and you want to overwrite it.-re-add adds a hard drive that is already partitioned. This command prompts for the drive and partition for each degraded array. Use -re-add -force if you want to check all the arrays.-help option option displays usage information.

sg-reconfigure

[--boot][--maybe-contact][--no-shutdown]

firewall

Used for reconfiguring the node manually.--boot option applies bootup behavior. Do not use this option unless you have a specific need to do so.--maybe-contact option contacts the Management Server if requested. This option is only available on firewall engines.--no-shutdown option allows you to make limited configuration changes on the node without shutting it down. Some changes may not be applied until the node is rebooted.

sg-selftest [-d] [-h] firewallRuns cryptography tests on the engine.-d option runs the tests in debug mode.-h option displays usage information.

sg-status [-l] [-h] firewall

Displays information on the engine’s status.-l option displays all available information on engine status.-h option displays usage information.



Engine Commands 419

sg-toggle-active SHA1 SIZE |--force [--debug]

firewall

Switches the engine between the active and the inactive partition. This change takes effect when you reboot the engine.You can use this command, for example, if you have upgraded an engine and want to switch back to the earlier engine version. When you upgrade the engine, the active partition is switched. The earlier configuration remains on the inactive partition. To see the currently active (and inactive) partition, see the directory listing of /var/run/stonegate (ls-l /var/run/stonegate.The SHA1 SIZE option is used to verify the signature of the inactive partition before changing it to active. If you downgrade the engine, check the checksum and the size of the earlier upgrade package by extracting the signature and size files from the sg_engine_[version.build]_i386.zip file.--debug option reboots the engine with the debug kernel.--force option switches the active configuration without first verifying the signature of the inactive partition.

sg-upgrade firewallUpgrades the node by rebooting from the installation CD-ROM. Alternatively, the node can be upgraded remotely using the Management Client.

sg-version firewallDisplays the software version and build number for the node.




The table below lists some general operating system commands that may be useful in running your StoneGate engines. Some commands can be stopped by pressing Ctrl+c.

sginfo

[-f] [-d] [-s] [-p] [--] [--help]firewall

Gathers system information you can send to Stonesoft support if you are having problems. Use this command only when instructed to do so by Stonesoft support.-f option forces sgInfo even if the configuration is encrypted.-d option includes core dumps in the sgInfo file.-s option includes slapcat output in the sgInfo file.-p option includes passwords in the sgInfo file (by default passwords are erased from the output).-- option creates the sgInfo file without displaying the progress--help option displays usage information.



TABLE B.3 General Command Line Tools on Engines

Command Description

dmesgShows system logs and other information. Use the -h option to see usage.

halt Shuts down the system.

ipDisplays IP-address related information. Type the command without options to see usage. Example: type ip addr for basic information on all interfaces.

pingTool for sending ICMP echo packages to test connectivity. Type the command without options to see usage.

ps Reports status of running processes.

rebootReboots the system. Upon reboot, you enter a menu with startup options. For example, this menu allows you to return the engine to the previous configuration.

scp Secure copy. Type the command without options to see usage.

sftpSecure FTP (for transferring files securely). Type the command without options to see usage.

Engine Commands 421

sshSSH client (for opening a terminal connection to other hosts). Type the command without options to see usage.

tcpdumpGives information on network traffic. Use the -h option to see usage.

topDisplays the top CPU processes taking most processor time. Use the -h option to see usage.

tracerouteTraces the route packets take to the specified destination. Type the command without options to see usage.

vpninfoOutputs various VPN related information. Type the command without options to see usage.

TABLE B.3 General Command Line Tools on Engines (Continued)

Command Description


APPENDIX C Predefined Aliases

Aliases are special, generic elements that can represent any other network element. They are context dependent: unlike other elements, an Alias does not have a fixed value. Its value depends on the firewall on which the policy containing the Alias element is installed. The value of the Alias is defined for each StoneGate engine element in the Alias element’s properties.


Pre-Defined User Aliases, on page 424 System Aliases, on page 425

423

Pre-Defined User Al iasesUser Aliases are usually created by administrators, but there are also some pre-defined user aliases in the system. User Aliases are preceded with one $ character. Table C.1 lists all the editable user Aliases automatically created by StoneGate Management Center. Note that these aliases do not receive any value unless you edit them.

TABLE C.1 System-defined User Aliases

Predefined User Alias Description

$ Allowed ICMP Local Sources

Defines source IP addresses, probably part of the $ Local Protected Sites, allowed to ping the local StoneGate VPN-only security gateway.

$ Allowed ICMP Remote Sources

Defines source IP addresses, probably part of the $ Remote Protected Sites, allowed to ping the local StoneGate VPN-only security gateway through the VPN tunnel.

$ Allowed SSH Local Sources

Defines source IP addresses, probably part of the $ Local Protected Sites, allowed to initiate a SSH connection directly to the local StoneGate VPN-only security gateway.

$ Allowed SSH Remote Sources

Defines source IP addresses, probably part of the $ Remote Protected Sites, allowed to initiate a SSH connection through the VPN tunnel in destination of the local StoneGate VPN-only security gateway.

$ DHCP address pools

Addresses that can be allocated by DHCP server(s).

$ DHCP address pools for IPsec VPN Clients

Address pools for assigning virtual IP addresses to VPN clients.

$ DHCP servers DHCP servers.

$ DHCP servers for IPsec VPN Clients

The DHCP servers defined for assigning virtual IP addresses to VPN clients.

424 Appendix C: Predefined Aliases

System AliasesSystem Aliases are non-editable Aliases created by StoneGate. The System Aliases are preceded with two $$ characters. Table C.2 lists the definitions of all the System Aliases. These aliases automatically receive the correct value when the value exists.

TABLE C.2 System Aliases

System Alias Description

$$ DHCP Enabled Interface AddressesIP addresses of CVIs which have DHCP relay enabled.

$$ DHCP Interface X.dns IP address of the DNS for interface number X.

$$ DHCP Interface X.gatewaysIP address of the default router for interface number X.

$$ DHCP Interface X.ipDynamic IP address allocated for interface number X.

$$ DHCP Interface X.netNetwork behind the dynamic IP interface number X.

$$ Local Cluster All addresses of the cluster.

$$ Local Cluster (CVI addresses only) All CVI addresses of the cluster.

$$ Local Cluster (DHCP Interface Addresses)

Dynamic IP address of the engine itself.

$$ Local Cluster (NDI addresses only) All NDI addresses of all nodes in the cluster.

$$ Local Cluster (NDI for heartbeat addresses only)

Heartbeat NDI addresses of all nodes in the cluster.

$$ Local Cluster (NDI for management addresses only)

Management NDI address(es) of all nodes in the cluster.

$$ Log Servers IP addresses of all Log Servers.

$$ Management Servers IP addresses of all Management Server.

$$ Valid DHCP Address Pools for IPsec VPN clients

Address pools defined in the Internal VPN Gateway properties for assigning virtual IP addresses to VPN clients.

$$ Valid DHCP Servers All DHCP servers defined for the firewall.

$$ Valid DHCP Servers for IPsec VPN clients

The DHCP servers defined in the VPN security gateway properties for assigning virtual IP addresses to VPN clients.

425

426 Appendix C: Predefined Aliases

APPENDIX D Regular Expression Syntax

Regular expressions are used to define patterns in traffic for custom Situations, which can be used in Inspection rules in StoneGate Firewall and IPS.


Syntax for StoneGate Regular Expressions, on page 428 Special Character Sequences, on page 431 Pattern-Matching Modifiers, on page 432 Variable Extensions, on page 434 Parallel Matching Groups, on page 437

427

Syntax for StoneGate Regular ExpressionsStoneGate custom Situations are often defined as text strings using regular expression patterns for matching byte sequences in network traffic.The expression matching starts always at the beginning of the traffic stream. For this reason, ‘.*’ is usually necessary at the beginning of a regular expression to indicate that there can be an undefined number of bytes in the traffic stream preceding the expression.The regular expression string consists of one or more branches that are separated by the ‘|’ logical OR symbol as follows: “branch-1|branch-2| . . .”. A branch contains one or more regular expressions one after another. The Situation matches if any of the regular expression branches separated by ‘|’ matches to the network traffic byte stream.

Note – Regular expressions are case sensitive. Also, the space characters are included in the matching process, whether or not they are encoded as ‘\x20’.

The StoneGate regular expressions are described in Table D.1.

TABLE D.1 StoneGate Regular Expression Syntax

Sequence Description Example

<char> Matches only the defined characters.‘2’, ‘A’, ‘foo’ match exactly to the defined characters: ‘2’, ‘A’, and ‘foo’ respectively.

. (dot)

matches any character, including the null character \x00 and a missing character. Matches also other than printable characters, such as the linefeed.

‘.’ matches any single character or byte.

\x<hex>

Matches the hexadecimal byte value ranging from \x00 to \xFF. To include linefeed or carriage return in the regular expression patterns, use the hexadecimal values ‘\x0a’ (linefeed) and ‘\x0d’ (carriage return). For example, use the linefeed character to match a string in the beginning or end of a line.

‘\x4d’ matches hexadecimal value ‘4d’ which represents the decimal value 77 and the ASCII character ‘M’.

[<char>] Match any of the characters in the list.

‘[15aB]’ matches when any of the characters ‘1’, ‘5’, ‘a’, or ‘B’ in the matching location of the inspected string.

428 Appendix D: Regular Expression Syntax

It is also possible to indicate repeated, consecutive regular expressions by using quantifiers as described in Table D.2.

[^<char>]Matches when none of the characters in the list is present.

‘[âBc]’ matches if none of the characters ‘a’, ‘B’, or ‘c’ is present in the matching location of the inspected string.

[<char1>–<char2>]

Matches all the characters ranging from <char1> to <char2>, these two characters included.

‘[a–f]’ matches any character within the range from ‘a’ to ‘f’, with ‘a’ and ‘f’ included.

[:<class>:]

Used in bracket expression to match any character of the defined class. The <class> can be: alnum [0-9A-Za-z], alpha [A-Za-z], ascii (ascii char), blank (space or tab), cntrl (control char), digit [0-9], graph (alnum or punct), lower [a-z], print (printable char), punct [.,”’!?;:], space (any space char), upper [A-Z], word (alnum + ‘_’ char), xdigit [0-9A-Fa-f].

‘[[:digit:]]’ matches any digit, e.g. 1, 5, or 7.

\<char>

Used for escaping special metacharacters to be interpreted as normal characters, in this case as <char>. The metacharacters are: \|)(][^-*+?.#

‘\[’ matches the ‘[’ character instead of interpreting it as the regular expression class metacharacter.

#<text>

Anything starting with ‘# ’ up to the linefeed (\x0a) or the carriage return (\x0d) character is considered as a comment and not used in the matching process.

‘# my comment.’ is not used in the matching process.

(<expr1>|<expr2>)

Matches if either the sub-expression <expr1> or <expr2> matches.

‘a(bc|de)’ matches ‘abc’ and ‘ade’.

TABLE D.1 StoneGate Regular Expression Syntax (Continued)

Sequence Description Example

TABLE D.2 StoneGate Regular Expression Quantifiers

Quantifier Description Example

<expr>*Matches if there are zero or more consecutive <expr> strings.

‘a*’ matches ‘<empty>’, ‘a’, ‘aa’ and so on.

<expr>+Matches if there are one or more consecutive <expr> strings.

‘a+’ matches ‘a’, ‘aa’, ‘aaa’ and so on, but not the empty string.

429

The ‘*’ and ‘+’ wildcard characters in the middle of a regular expression pattern can easily result in an expression that has a very large number of different matching states. For this reason, they must be used with care. The computed matching pattern can grow exponentially, thus becoming too complex for efficient use on the Sensors.Use the “{num,max}” quantifier where possible, instead of the ‘*’ and ‘+’ wildcards. Variables can also be used to break down the pattern to smaller chunks as described in Variable Extensions, on page 434.Illustration D.1 provides an example regular expression.

<expr>? Matches if there is zero or one <expr> string. ‘a?’ matches ‘<empty>’ and ‘a’.

<expr>{n,m}

{num} matches exactly num times the expression.{num,} matches num or more times the expression.{num,max} matches at least num and no more than max times the expression.

“a{5,}” matches five or more consecutive ‘a’.“a{5,7}” matches five, six, or seven consecutive ‘a’.

TABLE D.2 StoneGate Regular Expression Quantifiers (Continued)

Quantifier Description Example

Illustration D.1 Example regular expression

# This expression matches any of the following patterns in the traffic:# ‘/bin/{ash|bash|csh|ksh|sh|tcsh}’

# First, match ‘/bin/sh’ with zero or more characters in front of it:.*/bin/sh|# or match ‘/bin/’ with zero or more characters in front of it,# followed by ‘ash’, ‘csh’, or ‘ksh’:.*/bin/[ack]sh|# or match ‘/bin/’ with zero or more characters in front of it,# followed by ‘bash’ or ‘tcsh’:.*/bin/(ba|tc)sh

# Alternatively, this expression with all the patterns can be integrated# into one, for example: .*/bin/(ba|tc|[ack])?sh


Special Character SequencesThe printable characters are defined simply by typing them in the regular expression. The hexadecimal values \xHH can also be used to match any byte value (e.g., ASCII character). In addition, there are some shorthands for common non-printable characters and character classes. The special character sequences are listed in Table D.3.

TABLE D.3 Special Character Sequences

Sequence Description

\a Bell (BEL) = \x07

\t Horizontal tab (HT) = \x09

\n Linefeed (LF) = \x0A

\f Formfeed (FF) = \x0C

\r Carriage return (CR) = \x0D

\e Escape (ESC) = \x1B

\OOO Octal code OOO of the character.

\xHH Hexadecimal code HH of the character.

\c<char> Control character that corresponds to Ctrl+<char>

\w "word" class character = [A-Za-z0-9_]

\W Non-"word" class character = [Â-Za-z0-9_]

\s Whitespace character = [ \t\r\n\f]

\S Non-whitespace character = [^ \t\r\n\f]

\d Digit character = [0-9]

\D Non-digit character = [^0-9]

\bBackspace (BS) = \x08Note: allowed only in bracket expressions.

\Q

<expr>\E

Quotes all metacharacters between the \Q and \E. Backslashes are considered as normal characters. For example, “\QC:\file.exe\E” matches the “C:\file.exe” string, not the “C:\x0Cile.exe” string where \x0C is the formfeed “\f”.

431

Pattern-Matching ModifiersThe StoneGate regular expression syntax has Perl-like extensions. The pattern-matching modifiers are extensions that can be used to control the matching process in more detail. The modifiers are enabled with (?<modifiers>) and disabled with a minus (?-<modifiers>), where <modifiers> is a list of one or more modifiers.The modifiers (?C), (?L), and (?s)are enabled by default. The pattern-matching modifiers are listed in Table D.4.

TABLE D.4 Pattern-Matching Modifiers


(?i)

“Case insensitive mode”When enabled, case insensitive matching is used for the uppercase and lowercase letters. Thus, a letter matches regardless of its capitalization. When disabled, the letters are matched case-sensitively so that capitalization is taken into account in the matching process.

(?s)

“Single line mode”When enabled, the dot character ‘.’ matches also the null character \x00 and a missing character in addition to matching any character (including linefeed and other non-printable characters). When disabled, the linefeed or a missing character are not matched.This modifier is enabled by default. Use (?-s) to disable it.

(?x)

“Extended readability mode”When enabled, equals to enabling (?C), (?L), and (?S). Comments, linefeeds and spaces are not used in the matching process, allowing to use them for readability of the expression.When disabled, equals to disabling (?C), (?L), and (?S).Comments, linefeeds and spaces are used in the matching process.

(?C)

“Allow comments mode”When enabled, anything after the hash character ‘# ’ is considered as a comment and not included in the matching process. When disabled, the hash character ‘# ’ and anything following are not used in the matching process. This modifier is enabled by default. Use (?-C) to disable it.

(?L)

“Ignore linefeeds mode”When enabled, the linefeed and carriage return characters are not included in the matching process unless specifically defined (\x0A or \n for linefeed and \x0D or \r for carriage return). When disabled, the linefeeds and carriage returns are used in the matching process.This modifier is enabled by default. Use (?-L) to disable it.


(?S)

“Ignore spaces mode”When enabled, the space and horizontal tab characters are not used in the matching process unless specifically defined (\x20 for space and \x09 or \t for horizontal tab). When disabled, the space and horizontal tab characters are used in the matching process.

(?<modifiers>:<sub-expr>)

Applies the <modifiers> modifiers only to the subexpression <sub-expr>. These modifiers are not used in other parts of the regular expression.

TABLE D.4 Pattern-Matching Modifiers (Continued)


433

Variable ExtensionsVariables can be used to define regular expression patterns that are related to each other. These relations can be expressed with the variables so that the regular expression matches only when all the related patterns match. Complex matching with multiple Situations is also possible as the variables and the variable values are shared with all the Situations in a Situation Group. A variable extension can use the following expressions: • A value setting expression defines the values for one or more variables when the

corresponding top-level branch matches. For example, (?{var_a=1}) sets the value 1 for the variable var_a.

• A conditional expression inspects the values defined for one or more variables so that the corresponding top-level branch matches, and the optional variable setting expressions are processed only if the conditional expression is true. For example, (?{var_b==1}) matches when the variable var_b is equal to 1.

• When using both variable expression types for the same top-level branch, the implication operator ‘->’ must be used. For example, (?{var_a==1->var_a=0}) matches when the variable var_a is equal to 1, and finally sets the value for this variable to be 0.

Each variable is unique within the Situation or Situation Group where the variable is used. The name of a Situation variable can be anything consisting of alphanumeric and underscore characters [A-Za-z_0-9]. The variable name must not begin with a digit. The variable has a boolean value that can be either 0 or 1. The variable values persist through each individual traffic stream.Variables can be used only at the end of each expression’s top-level branches. They cannot be used inside the grouping parentheses ‘()’. A variable extension is processed only when its top-level branch matches.

Note – In variable expressions a single equal sign ‘=’ sets a value for a variable, whereas two consecutive equal signs ‘==’ evaluate the value of a variable.

Variables are defined with the expressions listed in Table D.5.

TABLE D.5 Variable Extensions


(?{<var>=<value>})The expression matches and the <var> variable’s value is set to <value> (0 or 1). Multiple value setting expressions can be defined by separating them with a comma ‘,’.

(?{<var>=<value>,ignore})Sets the <var> variable’s value to <value> (0 or 1). The ignore keyword is used to indicate a partial match that does not trigger response alone but requires another matching branch.


Variables are used in the two top-level branches that are separated by the logical OR symbol ‘|’.

The expression in Illustration D.2 detects two different strings in the same connection. The variable is used so that the response is triggered only when the first branch matches, followed by the second branch match. Either of the branches do not trigger the response alone.

Note – A ‘*’ or ‘?’ wildcard in a middle of an expression can result to a computed matching pattern that is too complex for efficient use on the Sensors. Therefore, it is recommended to divide the pattern into two branches as in Illustration D.2.

(?{<var>==<value>})The expression matches only when the <var> variable’s value is <value>. Multiple conditional expressions can be defined by separating them with ‘&&’.

(?{<var1>==<value1>-><var2>=<value>})

The expression matches only when the <var1> variable’s value is <value1>. When the condition is true, the <var2> variable’s value is set to <value2>.

TABLE D.5 Variable Extensions (Continued)


Illustration D.2 Expression with Variables

# Expression matches only when ‘POST /attack.asp?’ string is followed # by ‘Content-Type: application/x-www-form-urlencoded’ string # with any number of bytes in between.

(?i)#case-insensitive mode

.*POST /attack.asp\?(?{match=1,ignore})|#does not trigger response alone

.*Content-Type: application/x-www-form-urlencoded(?{match==1->match=0})

435

$offset System VariableThe special $offset variable can be used in the variable expressions. This variable indicates the byte that is under inspection when counted from the beginning of the traffic stream. For example, 20 bytes before the expression and the 10th byte under inspection gives the offset value of 29.The syntax is the same as for other variables (see Table D.5), except that the variable’s value is not user-changeable.

Illustration D.3 provides an offset example that matches only when the traffic has 20 bytes followed by the 5 byte match, giving the offset value of 24

TABLE D.6 $offset Variable Comparison


(?{$offset==<value>})

The expression matches only when the $offset variable’s value is <value>. The offset value is the byte under inspection (e.g., 20 leading bytes + 10 byte match -> offset value 29). Other operators can also be used with the $offset variable: less than ‘<‘, less than or equal ‘<=‘, greater than ‘>‘, greater than or equal ‘>=‘.Multiple conditional expressions can be defined by separating them with ‘&&’.

Illustration D.3 Expression with Variables

# Expression matches when ‘\xff\x53\x4d\x42\x25’ string # is 20 bytes from the beginning of the traffic stream:# 20 bytes and the 5th byte under inspection -> offset of 24 bytes.

.*\xff\x53\x4d\x42\x25(?{$offset==25})


Paral lel Matching GroupsStoneGate allows you to set different regular expressions to be matched in parallel groups within one Situation Context. Normally, manual situation group definitions are not needed and StoneGate automatically compiles all your custom Situations in the same group (group 0).Manual group definitions is needed if the IPS policy upload fails due to fingerprint/DFA compilation problems that may occur with complex regular expressions.To use grouping, add a new preprocessing tag to the beginning of the regular expression:

TABLE D.7 Preprocessing Tag for Setting a Group for Matching

Syntax Description

#!!GROUP(X)Comment#!!#

'X' is the group number from 0 to 7. The comment is optional. If you do not specify the group with this tag, the Situation is processed in group zero.

Illustration D.4 Setting a parallel Matching Group

#!!GROUP(1)This heavy regular expression is matched in parallel matching group 1.#!!#

#Insert regular expression below

437


APPENDIX E Log Field Values

This appendix lists Log view columns and explains the various informative messages you may see in logs. This appendix also explains the connection states that are used both in the Connections view and in the Logs view.


Log Entry Table, on page 440 Facility Field Values, on page 442 Type Field Values, on page 443 Action and Event Occurrences, on page 444 VPN-Related Information Messages, on page 445 Audit Entry Types, on page 447 Syslog Entries, on page 453 Log Fields Controlled by the Additional Payload Option, on page 454 Connection States, on page 455

439

Log Entry TableThe following table lists all fields of the log entry table.

TABLE E.1 Fields of the Log Entry Table

Field Description

Time Entry creation time

Sender Firewall or server node IP address that passes this information

Facility Firewall subsystem. For more information on facility values, see Table E.2.

Type Log entry severity type. For more information on type values, see Table E.3.

Event Logged event, e.g., New connection, Connection closed, Connection discarded

ActionConnection action. The action values are Discard, Allow, Wait for further actions, Refuse, and Wait for authentication.

Protocol Connection IP protocol

Src Addr Packet source IP address

Dst Addr Packet destination IP address

Src Port Packet source protocol port

Dst Port Packet destination protocol port

Rule TagRule tag value of acceptance rule. When clicking on the cell, you get a Rule definition dialog box indicating the name of the policy, sub-policy, or template that generated the log record.

NAT Src Addr Translated packet source IP address

NAT Dst Addr Translated packet destination IP address

NAT Src Port Translated packet source protocol port

NAT Dst Port Translated packet destination protocol port

Src IF Defined source interface number for the firewall cluster

Protocol Agent value Protocol Agent numerical code

Alert Firewall Engine-generated system or custom alert

Syslog

Syslog is a system service used in some operating systems, e.g., UNIX- and software packages. It is not a real standard but a de-facto standard that transports events and log information in UNIX server environment. For more information on syslog and syslog types, refer to RFC 3164.

440 Appendix E: Log Field Values

ICMP type

The Internet Control Message Protocol is an extension to the Internet Protocol (IP) that supports packets containing error, control and informational messages. ICMP messages are sent using the basic IP header. The first octet of the data portion of the datagram is an ICMP “type” field. For more information, refer to RFC 792 and RFC 950.

ICMP codeICMP code attribute. Many of the ICMP types have a code field. ICMP code provides further information about message type (i.e., network unreachable). For more information, refer to RFC 792 and RFC 950.

ICMP ID

ICMP identifier recorded by the engine when ICMP packets pass through the firewall. ICMP identifier may be used by the echo sender to aid in matching the replies with the echo requests. For example, the identifier might be used like a port in TCP or UDP to identify a session. For more information on ICMP ID and the ICMP protocol, refer to RFC 792 and RFC 950.

IPsec SPI

The IPsec Security Parameter Index is the connection identifier of an IPsec connection. IPsec is a set of protocols supporting secure exchange of packets. Used for the implementation of VPNs, it provides transport and tunnel encryption modes. IPsec is defined in RFC 2401.

Round tripRound trip time for outbound Multi-Link link testing. Time indicated is from sending queries to the first reply. The unit is 0.01 seconds

Elapsed timeElapsed time of connection in seconds. It will be indicated only when accounting entries are created, that means, when a connection is closed.

Bytes sentNumber of bytes sent during connection. As it happens with the elapsed time, the bytes sent will be indicated just when accounting entries are created.

Bytes rcvd. Number of bytes received during connection

Auth. user Username of authorized user

Src VLAN Source VLAN ID number (up to 4095)

Info message Informative message text

TABLE E.1 Fields of the Log Entry Table (Continued)

Field Description

441

Facil ity Field ValuesThe following table lists the possible values for the Facility field in the log entry table.

TABLE E.2 Facility Field Values

Value

Accounting

Authentication

Cluster Daemon

Cluster Protocol

Connection Tracking

Data Synchronization

DHCP Client

DHCP Relay

IPsec

Load Balancing Filter

License

Logging System

Log Server

Invalid

Management

Monitoring

Network Address Translation

NetLink Incoming HA

Packet Filter

Protocol Agent

Server Pool

SNMP Monitoring

State Synchronization


Type Field ValuesThe following table lists the possible values for the Type field in the log entry table.

System

Syslog

Tester

Undefined

User Defined

TABLE E.2 Facility Field Values (Continued)

Value

TABLE E.3 Type Field Values

Value

Critical Error

Debug high

Debug low

Debug mid

Diagnostic

Emergency - System Unusable

Error

Informational

Internal Max

Max

Notification

System Alert

Undefined

Warning

443

Action and Event OccurrencesThe following table show the most common log occurrences for the Action and Event fields.

A successful engine login causes an event that is displayed in the Logs view with the following type of message in the Info Message field: date time login[id]:USERNAME LOGIN on ‘device’. A failed login causes an info message of the following type: date time login[id]:FAILED LOGIN (#) on ‘device’ FOR ‘UNKNOWN’.

TABLE E.4 Action and Event Occurrences

Action Event Description

Allow New connection A new connection is allowed through the firewall.

Allow Related ConnectionA related connection is allowed through the firewall. For example, an FTP data connection.

Allow Related PacketA related packet is allowed through the firewall. For instance, ICMP error messages related to an earlier TCP connection.

Allow New VPN connectionA new VPN connection is allowed through the firewall.

Discard Connection Discarded A connection is discarded by the firewall.

Discard Packet Discarded A packet is discarded by the firewall.

Refused Connection Refused A connection is refused by the firewall.

Authentication service startedWent Online

Both messages together indicate firewall startup.

New configuration successfully installed

New configuration is installed on the firewall.

Security Policy reload New security policy is loaded on the firewall.


VPN-Related Information MessagesThe table below lists the most common VPN-related log messages. Some messages can only be seen when the VPN diagnostics are enabled. The messages listed below appear in the logs as part of IPsec info, Diagnostic, or Warning messages. Note that the messages may be different between different engine versions. The messages below are valid at least for StoneGate Firewall/VPN 3.0 and earlier.

TABLE E.5 Common VPN-related Log Messages

Information Message Description

No IKE SA found [...]

This message is visible only when IPsec diagnostics are enabled.The gateway did not find the packet a part of any connection with an existing VPN tunnel. Negotiation of a new VPN tunnel follows.Repeated negotiations for the same connection are normal in a Multi-Link environment.

IKE Phase-1 initiator doneIKE Phase-1 responder done

IKE Phase-1 negotiations were successfully completed, Phase-2 negotiations will begin.Which message is displayed depends on whether the gateway is the initiator or the responder in the negotiation.

IKE Phase-2 initiator doneIKE Phase-2 responder done

IKE Phase-2 negotiations were successfully completed. The VPN tunnel is now established and ESP or AH message(s) will appear shortly. Which message is displayed depends on whether the gateway is the initiator or the responder in the negotiation.

ESP [...]AH [...]

Traffic going through the VPN tunnel. When you enable IPsec diagnostics you may see more of these messages.

Remote identity [...] used in IKE negotiation doesn’t match to policy [...]

The IKE Phase 1 ID defined for the external security gateway in StoneGate is different from the ID with which the gateway actually identified itself. The ID and its type are set for each tunnel End-Point in the properties of the external Gateway.

SPD doesn’t allow connection [...]

Most likely indicates that the Site definitions do not match the IP addresses used. Check the addresses included under the Sites for both Gateways, and also that the translated addresses are included under the Site, if NAT is used for communications inside the VPN.

445

Can not get QM policy [...]

Indicates that there is a mismatch in granularity settings between the negotiating gateways.In StoneGate, granularity is controlled with the Security Association Granularity setting on the IPsec Settings tab of the VPN Profile properties.

Can not get policy [...] No matching connection

May indicate that the gateway has no valid VPN certificate.

[...] No proposal chosen

IKE negotiations failed because of a mismatch in the configurations of the two negotiating parties. You must define a matching pair for all settings; double-check all settings at both ends.

[...] Payload malformed [...]Most likely due to a mismatch in preshared keys between the initiator and the responder. May also be due to corruption of packets in transit.

TABLE E.5 Common VPN-related Log Messages (Continued)

Information Message Description


Audit Entry TypesThe following table explains the audit entry types.l

TABLE E.6 Audit Entry Types

Type Definition

audit.info Internal messages of the audit system

audit.start Start of an audit

audit.stop End of an audit

stonegate.admin.changeIp.mgtserverAudited when management server IP address is changed

stonegate.admin.changeMgtIp.logserverAudited when log server management IP address is changed

stonegate.admin.comment.change Audited when a comment is changed

stonegate.admin.create Creation of an administrator

stonegate.admin.delete Deletion of an administrator

stonegate.admin.loginAudited when the administrator logs in to the management server

stonegate.admin.logoutAudited when the administrator logs out from the management server

stonegate.admin.name.change Change of administrator name

stonegate.admin.password.change Change of password for an administrator

stonegate.admin.permission.change Change of permissions for an administrator

stonegate.admin.session Audits administrator sessions

stonegate.alertAudited when management system sends an alert

stonegate.alert.policy.uploadUploading a policy to an alert server - success or failure

stonegate.audit.archive.create Audited when audit data archive is created

stonegate.audit.archive.delete Audited when audit data archive is deleted

stonegate.audit.archive.restore Audited when audit data archive is restored

stonegate.audit.purge Audited when audit data is purged

447

stonegate.backup.createAudited when a backup is created in the origin server

stonegate.backup.deleteAudited when a backup is deleted in the origin server

stonegate.backup.restoreAudited when a backup is restored in the origin server

stonegate.database.migrate Audited when the server database is migrated

stonegate.database.password.change Audited when database password is changed

stonegate.directarchive.startAudited when the direct archive option is set to ON

stonegate.directarchive.stopAudited when the direct archive option is set to OFF

stonegate.export.start Audited when an export operation is started

stonegate.firewall.connections.terminate Audited when a connection is terminated

stonegate.firewall.diagnostic Diagnostic mode selected for a firewall

stonegate.firewall.disable.userdatabase Audited when user database is disabled

stonegate.firewall.enable.userdatabase Audited when user database is enabled

stonegate.firewall.initial.contactFirewall performed initial contact to management server

stonegate.firewall.initial.generate Initial configuration generated for a firewall

stonegate.firewall.monitor.offA firewall monitoring change by an administrator to deactivated

stonegate.firewall.monitor.onA firewall monitoring change by an administrator to activated

stonegate.firewall.policy.uploadUploading a policy to a single firewall - success or failure

stonegate.firewall.rebootA firewall reboot by an administrator through the management system

stonegate.firewall.reset.database Audited when the user database is reset

TABLE E.6 Audit Entry Types (Continued)

Type Definition


stonegate.firewall.state.lockofflineA firewall state change by an administrator to locked offline

stonegate.firewall.state.lockonlineA firewall state change by an administrator to locked online

stonegate.firewall.state.offlineA firewall state change by an administrator to offline

stonegate.firewall.state.onlineA firewall state change by an administrator to online

stonegate.firewall.state.standbyA firewall state change by an administrator to standby

stonegate.firewall.time.adjust Firewall node time adjustment

stonegate.firewall.upgrade.endFirewall node upgrade end through management system

stonegate.firewall.upgrade.startFirewall node upgrade start through management system

stonegate.import.start Audited when an import operation is started

stonegate.ips.analyzer.diagnostic Diagnostic mode selected for an analyzer

stonegate.ips.analyzer.monitor.off Monitoring mode offline for a sensor

stonegate.ips.analyzer.monitor.on Monitoring mode online for a sensor

stonegate.ips.analyzer.policy.uploadUploading a policy to an analyzer - single analyzer cluster success or failure

stonegate.ips.analyzer.rebootAnalyzer reboot through the management system

stonegate.ips.analyzer.state.lockoffline Analyzer state changed to locked offline

stonegate.ips.analyzer.state.lockonline Analyzer state changed to locked online

stonegate.ips.analyzer.state.offline Analyzer state changed to offline

stonegate.ips.analyzer.state.online Analyzer state changed to online

stonegate.ips.analyzer.state.standby Sensor state changed to standby

stonegate.ips.analyzer.time.adjust Analyzer node time adjusted


Type Definition

449

stonegate.ips.analyzer.upgrade.endAnalyzer node upgrade through management system ends

stonegate.ips.analyzer.upgrade.startAnalyzer node upgrade through management system begins

stonegate.ips.sensor.diagnostic Diagnostic mode selected for a sensor

stonegate.ips.sensor.monitor.off Monitoring mode offline for a sensor

stonegate.ips.sensor.monitor.on Monitoring mode online for a sensor

stonegate.ips.sensor.policy.uploadUploading a policy to a sensor - single sensor success or failure

stonegate.ips.sensor.rebootSensor rebooted through the management system

stonegate.ips.sensor.state.lockoffline Sensor state changed to locked offline

stonegate.ips.sensor.state.lockonline Sensor state changed to locked online

stonegate.ips.sensor.state.offline Sensor state changed to offline

stonegate.ips.sensor.state.onlineSensor state change by an administrator to online

stonegate.ips.sensor.state.standby Sensor state changed to standby

stonegate.ips.sensor.time.adjust Sensor node time adjusted

stonegate.ips.sensor.upgrade.endSensor node upgrade through management system ends

stonegate.ips.sensor.upgrade.startSensor node upgrade through management system begins

stonegate.license.activateAudited when a license file or a license component is activated

stonegate.license.delete Audited when a license component is deleted

stonegate.license.import Audited when a license file is imported

stonegate.license.inactivate Audited when a license is deactivated

stonegate.logdatamanager.abortAudited when a scheduled task is aborted in the log server


Type Definition


stonegate.logdatamanager.completeAudited when a scheduled task is completed in the log server

stonegate.logdatamanager.createAudited when a scheduled task is created in the log server

stonegate.logdatamanager.deleteAudited when a scheduled task is deleted in the log server

stonegate.logdatamanager.modifyAudited when a scheduled task is modified in the log server

stonegate.logdatamanager.start Audited when the user manually starts a task

stonegate.logpruningfilter.applyAudited when a pruning filter is applied to the log server

stonegate.logpruningfilter.deleteAudited when a pruning filter is deleted from the log server

stonegate.logpruningfilter.refresh

Audited when, following to a log server re-logging to the management, all the pruning filters are retrieved at the management and re-applied

stonegate.logreception.start Log reception process begins

stonegate.logreception.stop Log reception process ends

stonegate.logserver.certify Audited when the log server is certified

stonegate.mgtserver.certifyAudited when the management server is certified

stonegate.object.delete Audited when an object is deleted

stonegate.object.insert Audited when a new object is added

stonegate.object.update Audited when an object is updated

stonegate.policy.display Generate a policy for display

stonegate.policy.upload.end Uploading a policy ends

stonegate.policy.upload.start Uploading a policy starts

stonegate.server.diskfull Audited when the log server disk gets full

stonegate.server.start Audited when the log server is started


Type Definition

451

stonegate.server.stop Audited when the log server is stopped

stonegate.vpn.certificate.downloadAudited when client downloaded a VPN certificate

stonegate.vpn.certificate.request Audited when a VPN certificate is requested

stonegate.vpn.certificate.sign Audited when a VPN certificate is signed

stonegate.vpn.gateway.remove Audited when a VPN gateway is removed

stonegate.vpn.site.remove Audited when a VPN site is removed

stonegate.vpn.validity.check Audited when the VPN validity is checked


Type Definition


Syslog EntriesThe following table presents the categories for messages that appear in log entries sent to an external syslog server.

TABLE E.7 Syslog Entries

Value

Clock daemon for BSD systems

Clock daemon for System V systems

File transfer protocol

Kernel messages

Line printer subsystem

Mail system

Messages generated internally by syslogd

Network news subsystem

Network time protocol

Random user-level messages

Security/authorization messages

Security/authorization messages (private)

System daemons

UUCP subsystem

453

Log Fields Control led by the Additional Payload Option

The following table presents the log fields that may be logged when the Additional Payload option is selected in inspection rule options.

TABLE E.8 Additional Payload Log Fields

Value

DNS qname

FTP command

FTP reply

FTP server banner

HTTP header

HTTP header name

HTTP request URI

HTTP request method

HTTP request version

ICMP field datagram reference

Imf encoded word

Imf header field

Imf token

SMTP command

SMTP misplaced command

SMTP recipient

SMTP reply

SMTP reverse path

SMTP server banner


Connection StatesThe following states are used both in the State column in the Connections view and (in part) in the Logs view in conjunction with info messages or logs on the closing of connections. They reflect the standard states regarding the initiation and termination of TCP connections as seen by the firewall in the transmissions. Table E.9 lists the possible states.

TABLE E.9 Connection States

State Description

Related New connection related to an existing one is expected soon.

New New connection is being opened.

TCP established Normal status of TCP connections for data transfer.

TCP closingClosing packet (FIN) sent by one end of the connection (simultaneous).

TCP syn seen Very first packet sent by one end of the connection.

TCP fin wait 1One end of the connection waits for sending FIN packet (active close).

TCP fin wait 2 One end of the connection waits for receiving ACK packet.

TCP time wait One end of the connection acknowledged closing packet (FIN).

TCP close waitOne end of the connection waits for the FIN packet (passive close).

TCP last ack One end of the connection sent a FIN packet (passive close).

TCP syn ack seenSecond phase of the TCP three-way handshake, the server has replied to client sent SYN with SYN+ACK, next status will be established.

TCP time wait ackWaiting ACK for the FIN status before going to time wait status (active close).

TCP closing ackWaiting ACK for the FIN before going to closing status (active close).

TCP close wait ackWaiting ACK for the FIN before going to close wait status (passive close).

UDP established UDP connection is recognized.

ICMP echo Ping reply is expected.

455

ICMP reply wait Other ICMP request/reply types.

IPsec established IPsec tunnel packet is recognized.

CP established StoneGate cluster protocol packet is recognized.

Unknown established Connection from other transport level protocol.

Remove Connection cannot be physically removed yet.

Remove soon

Expecting to still see some packets (multiple reset packet), so delaying the removal for a few seconds. Eliminates unnecessary packet filtering and possible logging of dropped packets.

Invalid The communication has violated the protocol.

UnknownSomething unexpected has happened (for example, memory corruption) and the node has an inconsistent status of the connection.

TABLE E.9 Connection States (Continued)

State Description


APPENDIX F Schema Updates for External LDAP Servers

To use external LDAP servers to store user and user group information for user authentication, you must import or otherwise add the StoneGate-specific LDAP classes and attributes to the external LDAP servers’ schema.The StoneGate specific attribute and class names start with “sg”. The classes are listed in Table F.1.

The StoneGate specific attributes are listed in Table F.2.

TABLE F.1 StoneGate Specific LDAP Classes

Class Description

sggroup StoneGate user group

sguser StoneGate user account

TABLE F.2 StoneGate Specific LDAP Attributes

Attribute Related Classes Description

sgactivation sguser Activation date for the user account.

sgauth sggroup, sguser Authentication service for the user or group.

sgdelay sggroup, sguserNumber of days the user account is valid after the activation.

sgexpiration sguserLast day when the user account is valid and the user can log in.

457

Example schema updates are provided in the Management Servers’ <installation directory>/samples/LDAPSamples/LDAP/ directory:• SG_AD.ldif is an example schema update for Windows 2003 Active Directory.• SG-v3.schema is an example schema update in the LDAPv3 format (RFC 2252)

used by OpenLDAP v.2.0.x, for example.• SG-schema.conf is an example schema update in slapd.conf format, used by

Netscape Directory server and OpenLDAP v.1.2.11, for example.In addition to updating the directory schema, there may be some server-specific requirements. For the Netscape and the OpenLDAP v1.2.11 servers, you must configure the following lines to the LDAP server’s slapd.conf configuration file after stopping the LDAP service:

For the OpenLDAP v1.2.11 servers, you must configure the following lines to the LDAP server’s slapd.conf configuration file after stopping the LDAP service:

sggrouptype sggroupIndicates the type of the group: a subtree or discrete group.

sgmember sggroupThe Distinguished Name (DN) for the user member of this group.

sgpassword sguser MD5 message digest hash of the user password.

sgpresharedkey sguser IPsec PreSharedKey for the user account.

sgsubjectaltnames

sguserIPsec certificate SubjectAltNames for the user account.

sgvirtualip sggroup, sguser Virtual IP allocation allowed for the user.

Illustration F.1 Additional Configuration for OpenLDAP v1.2.11 and Netscape Server

include /etc/openldap/slapd.at.confinclude /etc/openldap/slapd.oc.confinclude /etc/openldap/sg-schema.confschemacheck on

Illustration F.2 Additional Configuration for OpenLDAP v2.0.x

include /etc/openldap/schema/core.schemainclude /etc/openldap/schema/cosine.schemainclude /etc/openldap/schema/inetorgperson.schemainclude /etc/openldap/schema/sg-v3.schema

TABLE F.2 StoneGate Specific LDAP Attributes (Continued)

Attribute Related Classes Description

458 Appendix F: Schema Updates for External LDAP Servers

APPENDIX G Advanced Log Server Configuration

Normally, it is not necessary to configure the Log Server any more than it is possible through the Log Server element in the Management Client. However, under special circumstances, you may want more control over the way the Log Server behaves. To control the Log Server in detail, you can edit the log server configuration file as explained in this section.The Log Server configuration information is stored in the <installation directory>/data/LogServerConfiguration.txt file on the Log Server machine.

Note – You must restart the Log Server service after making configuration file changes to have the changes take effect.

All configuration parameters are listed in the following table. Most of the parameters are already set during installation.

TABLE G.1 Log Server Configuration Parameters in LogServerConfiguration.txt file

Parameter name Description

ARCHIVE_DIR_0

Directory that is used for storing the logs archived by the Log Data tasks. By default, ARCHIVE_DIR_0=${SG_ROOT_DIR}/data/archive. You can define up to 32 directories: ARCHIVE_DIR_0 … ARCHIVE_DIR_31.

AUDIT_ARCHIVE_DIRDirectory used for archiving audit logs. By default, ${SG_ROOT_DIR}/data/audit/archive.

459

AUDIT_DISK_LIMIT

Defines the threshold for minimum available disk space for audit logs. If the free disk space goes below this limit, the Log Server considers that the disk is full and stops storing audit logs.

AUDIT_LOG_DIRDirectory used for audit logs. By default, ${SG_ROOT_DIR}/data/audit/log.

AUTO_ACK_ALERT_NB

The number of alerts that are automatically acknowledged if active alert list is full (5000 by default). The alerts are acknowledged by lowest severity and oldest timestamp first.

DISK_TRESHOLD_IN_KBYTES

Defines the threshold for minimum available disk space (in kilobytes). If the free disk space goes below this limit, the Log Server considers that the disk is full and stops storing log records (100000 by default).

FILESTORAGE_ALERT_DIRRoot directory for the Alerts. By default, ${FILESTORAGE_DIR}/Alerts.

FILESTORAGE_ALERT_EVENT_TRACES_DIRRoot directory for the Alert event traces. By default, ${FILESTORAGE_DIR}/AlertEvent.

FILESTORAGE_IPS_DIRRoot directory for the IPS logs. By default, ${FILESTORAGE_DIR}/IPS.

FILESTORAGE_IPS_RECORDINGS_DIRRoot directory for the StoneGate IPS event recording files. By default, ${FILESTORAGE_DIR}/IPS_Recordings.

FILESTORAGE_STONEGATE_DIRRoot directory for the firewall logs. By default, ${FILESTORAGE_DIR}/Firewall.

SNMP_COMMUNITYSNMP community string used for sending SNMP messages from the Log Server (public by default).

SNMP_ENTERPRISE_OIDSNMP Enterprise Object Identifier (OID) used for SNMP messages sent from the Log Server (.1.3.6.1.4.1.1369 by default).

TABLE G.1 Log Server Configuration Parameters in LogServerConfiguration.txt file (Continued)


460 Appendix G: Advanced Log Server Configuration

LOG_BACKUP_DIR

Directory for the Log Server backup files. By default, ${SG_ROOT_DIR}/backups. The backup files must be moved to a separate media after creating a backup.

LOG_EXPORT_DIRDirectory used for storing the files exported by the Log Data tasks. By default, ${SG_ROOT_DIR}/data/export.

LOG_FW_PORT

Log Server port that listens for connections from the StoneGate Firewall/VPN and IPS engines (3020 by default). Changing this value requires reinstalling the Log Server software.

LOG_LOGFILE_DIRDirectory used for storing the logfile.txt that logs the task scheduler operations. By default, ${SG_ROOT_DIR}/data.

LOG_QUERY_TIMEOUTTimeout (in milliseconds) for queries in the Logs view (30000 ms by default).

LOG_SCRIPT_DIRDirectory for the scripts used in Log Data tasks. By default, ${SG_ROOT_DIR}/data/script.

LOG_SERVER_ADDIP address of the Log Server. Changing this value requires reinstalling the Log Server software.

MAX_ACTIVE_ALERT_NBMaximum number of active alerts. If there are more alerts, they are automatically acknowledged (50000 by default).

MGT_SERVER_ADDIP address of the Management Server. Use the sgChangeMgtIPOnLogSrv.bat (or .sh) to change this value.

PHY_EXE

The script used for starting the Log Server database. By default, bin\\sgStartLogDatabase.bat or bin/sgStartLogDatabase.sh.

PHY_LOCLog Server database location. By default, ${SG_ROOT_DIR}/data/db/logserver.



461

PHY_PORTLog Server database port that the Log Server connects to (1314 by default).

SYSLOG_CONF_FILE

Configuration file for syslog data. By default, the file is stored in ${SG_ROOT_DIR}/data/fields/syslog_templates.This parameter is currently needed only when StoneGate IPS is configured to send syslog data to Bradford Networks’ NAC Director or Campus Manager. The bradford_syslog_conf.xml file is then used as the configuration file.

SYSLOG_EXPORT_FORMATDefines the file format used for syslog exporting. Either CSV or XML.

SYSLOG_EXPORT_ALERTDefines whether to export StoneGate Alerts to syslog. Either YES or NO.

SYSLOG_EXPORT_FWDefines whether to export StoneGate Firewall/VPN logs to syslog. Either YES or NO.

SYSLOG_EXPORT_IPSDefines whether to export StoneGate IPS logs to syslog. Either YES or NO.

SYSLOG_FILTER_MATCH

Defines how many of the defined filters a log event has to match to forward the event to the syslog server. The value “ALL” sends only those events that match all defined filters. The value “ONE” sends all events that match any of the defined filters. The value “NONE” sends only those events that match none of the defined filters.

SYSLOG_FILTER_TYPE

Defines how the defined filters are used for sending events to the syslog server. The value “KEEP” sends all the matching events. The value “DISCARD” sends only the events that do not match.

SYSLOG_MESSAGE_PRIORITYThe priority (0–191) of the syslog message is included at the beginning of each UDP packet (the default is 6). See RFC 3164.




SYSLOG_PORTPort for syslog connections. The default port is 514 (UDP).

SYSLOG_SERVER_ADDRESSThe IP address of the syslog server used for sending log events to syslog.

SYSLOG_USE_DELIMITER

Defines whether to use double quotes (“) in syslog messages to delimit the field values. The default setting “ALWAYS_EXCEPT_NULL” uses double quotes only for non-empty fields. “NEVER” does not use delimiters. “ALWAYS” uses double quotes as delimiters for all empty and non-empty field values.



463


APPENDIX H Server Pool Monitoring Agents

This appendix provides details for configuring Monitoring Agents that are available for monitoring Server Pool members in the context of inbound traffic management. For details on how to configure Server Pools, load balancing, as well as (un)installing and enabling Monitoring Agents, see the Administrator’s Guide.


General Features of Monitoring Agents, on page 466 Configuring Monitoring Agents, on page 466 Monitoring Agent Command Line Tools, on page 481

465

General Features of Monitoring AgentsWhen you have a Server Pool in your network hosting services that must be available at any time, it is essential to monitor the health and availability of the servers In case problems occur, it is also important to have the ability to automatically perform actions on the servers. For these purposes StoneGate offers the Monitoring Agent feature for Server Pools. It is a software agent that is installed on all Server Pool members to monitor them. This ensures that the services provided by the servers are always available to users. The Monitoring Agents are configured in the sgagent.local.conf and sgagent.conf files. The agents are configured manually to perform the desired actions and tests. StoneGate engines will frequently poll the Monitoring Agents for information on the servers, such as the load, possible log messages, and the status of the servers. The status can be either OK or Excluded. The OK status implies that the server handles the established connections properly, and it is ready to accept new connections. If the server status is Excluded, all established and new connections are directed to other members of the Server Pool, instead of the Excluded one.One of the core features of the Monitoring Agent is the tester that checks whether the servers function properly. Tests can be configured by using built-in internal tests, but new scripts may also be written. The tester runs all tests that are defined in the sgagent.conf file, located on each server in the pool. Depending on the results of the test, certain actions may be performed. If a test fails, an alert is sent to the StoneGate engines, and optionally, the tester can take the non-functional server out of the Server Pool by setting its status to Excluded.

Configuring Monitoring AgentsThe Server Pool Monitoring Agent must be installed on each member of the Server Pool. The configuration is done in two files, sgagent.local.conf and sgagent.conf. Both files reside in the following directories on each server:• Solaris: opt/sgagent/etc/ • Linux: etc/stonegate/• Windows: Program Files\Stonesoft\StoneGate Monitoring Agent\ The sgagent.local.conf file has server-specific information, and if edited, it will be different on each server. If default values are used, however, there is no need to edit this file. The sgagent.conf file has information that refers to the entire Server Pool. The pool members are typically very similar with respect to configuration and function, thus all members in the pool normally have identical sgagent.conf files. We will now take a closer look at both files and their configuration syntax.

sgagent.local.confThe server-specific file sgagent.local.conf includes information required by the monitoring system to identify the Server Pool member, in case default values are not

466 Appendix H: Server Pool Monitoring Agents

used. If the file is not configured, the Monitoring Agent will use the system hostname as the default value to identify the member. If edited, this file must be different on each Server Pool member. If you wish the Monitoring Agent to use a different name in its configuration for a Server Pool member than the system hostname, you may give the new name with the host statement.

With the set statement, you can set any string to have a specific value that the Monitoring Agent will use in the configuration. For example, if the server has multiple IP addresses, and thus localhost cannot be used as the default value, the server’s IP address(es) may be defined with the set statement. For example, to configure the member of the pool where sgagent.local.conf resides, to use server1 as its host name instead of the system level configuration, and to set the string hostip to 192.168.1.1 in all Monitoring Agent files, you could use:

sgagent.confThe file common to all Server Pool members is called sgagent.conf. Here you define attributes for the entire Server Pool, unlike with sgagent.local.conf where the configuration is specific to the server where the file resides. Since in most cases the Server Pool members are similar with respect to configuration and function, the tests performed on each member are also similar. Thus, the sgagent.conf file is usually identical on each server. The most convenient way to edit the file is to do it first on one server, and then copy the file to the other servers in the Server Pool. The sgagent.conf file contains two sections: the statement section and the test section. See Table H.1.

host nameset name value

host server1set hostip 192.168.1.1

467

Statement SectionIn the statement section, you can define general commands for the tester. If you wish the statement to apply to certain Server Pool members only, the statement must start with the begin host command followed by the name of the Server Pool member. The command is left out if the statement applies to all servers in the pool. The next line defines the setting in question. The third line is reserved for the end command to end

TABLE H.1 An Example sgagent.conf File

# ---------------------------START OF STATEMENT SECTION

begin host server1config boot-delay 5:00 # set the config delay on the slow member

end

begin host not server1config boot-delay 20 # 20s config delay on other members

end

config alert-interval 1:00:00config startup-script /etc/scripts/startup.sh

# Monitor one minute load average and set alert threshold at 5load-index 500 load-average-1

# ---------------------------START OF TEST SECTION# Tests

test "webster listening"interval 2:00action excluderecovery 10:00

command portlistening 80 %hostip% # Check that this member's# port 80 is listening.

test "server1 running baz"interval 10:00action excludehost server1script /etc/init.d/baz start

command servicerunning baz

test "external1"interval 10:00action alert

command external 3 700 /usr/lib/webster/test.sh 212.20.2.21


the statement. This is required only if the statement has begin host at the beginning.

In case the statement is to apply to all members in the pool, you can simply use:

begin host hostname

The begin host command may be followed by actual server names or an exclusion. In an exclusion, begin host is followed by not and the server name, instead of the simple server name. This indicates that the setting is to be applied to all other servers except the one following not. For example, the following statement would apply to all members in the pool except server1:

Setting optionsWhen you want to configure a particular setting the syntax starts with the command config. We will next look at the different setting options.

port number [0-65535]

The port that the Server Pool uses for communication with the engines can be defined with the port statement. This is fully configurable by the user, however, all Server Pool members must use the same port number (and thus the port setting cannot start with the begin host command). By default, if there is no user-defined port statement, the port is set to 7777 (UDP). If you use another port instead of the default port, you need to modify the access rules in StoneGate to allow connections to the new port.For example, if the communication between the engine(s) and the Server Pool members uses port 5555 instead of the default port, you will state:

boot-delay time

begin host hostnameconfig settingend

config setting

begin host not server1config settings end

config port 5555

469

Boot delay defines the amount of time the tester waits before starting the tests after the system has been booted up or restarted. The syntax of time is [(hh:)mm:]ss. For example:• 1 hour is noted as 1:00:00 • 30 minutes is noted as 30:00• 60 seconds is noted as 60 By default, the system waits 30 seconds after the tester process has started before it begins testing. The tester thus ensures that all necessary processes have completed their startup, as otherwise they may cause an inadvertent test failure. For example, to set a boot delay of 20 seconds on server1:

alert-interval time

Alert interval indicates the amount of time the system waits before sending a new alert in response to a test failure. Otherwise, for example, a test that fails every 15 seconds would send an alert every 15 seconds, potentially overloading the system or the alert recipient. The syntax of time is [(hh:)mm:]ss. By default the tester will wait for 1 hour before sending a new alert. For example, an alert interval of 1 hour on servers 1 and 2 would be:

alert-script path

This contains the path to the user-created script to be run each time an alert is issued. By default, an alert is sent to the StoneGate engines. However, if you wish to be alerted by other means (e.g., e-mail, sms) an alert script needs to be created, and its path must be specified here. You must use quotation marks if the path contains spaces. For example, alertscript.sh will be run every time an alert is generated:

startup-script path

This setting contains the path to the user-created script to be run when the agent starts. You must use quotation marks if the path contains spaces.

begin host server1config boot-delay 20end

begin host server1 server2config alert-interval 1:00:00end

config alert-script /etc/test/alertscript.sh


For example, when the agent starts on server1 startup.sh will be run:

overload-script path

This contains the path to the user-created script to be run in case the load index raises above the threshold value. The concept of load index will be explained below. You must use quotation marks if the path contains spaces. For example, when the threshold value of the load index is reached on server2, the overload.sh script will be run:

listen IP_address[:port]

You can set the Monitoring Agents to use alias IP addresses. By default, if there is no user-defined listen statement, the first IP address of the interface is used. Accordingly, if there is no port defined with an IP address, the default port (7777) is used.For example, to make the Monitoring Agent of server2 listen to the IP address 192.168.10.31 using the default port 7777:

load-index threshold index_name [index-parameter]

You can set the Monitoring Agent to measure the load on the server. The load-index setting defines the method that is used to measure the load. The index_name parameter may be a complex expression combining multiple methods with basic arithmetic operations (+ - * /), such as “index-name + index-name”. It is preferable to apply the same method of measurement to all members of the Server Pool. The load measurement occurs periodically, and each measurement generates an integer value. The range of possible values depends on the measurement. The resulting value is compared to threshold given in the load-index statement, and in case the value is higher than the threshold, a log message and an alert are generated.The index-name (i.e., the selected measure) can be one of the following: • processor-load time

The general processor load level over a time window can be measured with the processor-load measurement. The parameter of processor-load is the length

begin host server1config startup-script /etc/test/startup.shend

begin host server2config overload-script /etc/test/overload.shend

begin host server2config listen 192.168.10.31end

471

of the time period for the measurement. The time argument is given in the following format: [(hh:)mm:]ss. Each time the processor-load is measured, the average load over the time period is calculated. The returned value is a percentage value (0-100), where the value 100 refers to the maximal load on the processor(s).

• processor-kernel-load time

The processor-kernel-load measurement may only be used to measure the processor time spent in the kernel mode over a time window. The parameter of processor-kernel-load is the length of the time period for measuring the processor load in the kernel mode. The time argument is given in the following format: [(hh:)mm:]ss. The average load over the period is calculated each time the processor load is measured. The returned value is a percentage value (0-100), where the value 100 refers to the maximal load on the processor(s).

• load-average-x

Load average is a traditional load measurement in UNIX environment. The value is the average number of processes waiting to be executed. The number after load-average indicates the number of minutes over which the average is calculated. There are three load average methods: load-average-1, load-average-5, and load-average-15. The three values are standard, and they are the values you get, for example, with the uptime command in UNIX. Windows environments do not offer a load-average value natively, but StoneGate generates a similar reading based on the available statistics.

• load-average-1

Standard 1 minute load average multiplied by 100.• load-average-5

Standard 5 minute load average multiplied by 100.• load-average-15

Standard 15 minute load average multiplied by 100.Generally, the load-average measurement offers a better reading than the processor-load. The processor-load measures past tendencies, and thus it is a somewhat accurate measure in cases where you can trust past performance being a reliable indicator of future. The load-average, on the other hand, measures the size of the execution queue, in other words, how many processes are waiting due to reserved resources. Therefore, the load-average measurement may be considered more predictive. An example of the load-index statement is the following:

The example demonstrates how the measurement of load-average-5 is used on all servers except server1 to compare against the threshold value 4. When the load-average is higher than 4, a log message is generated. In this statement, server1 is

begin host not server1load-index 400 load-average-5end


ignored in the load-index measurement. Typically, server1 would have its own statement, such as the one below:

Test SectionThe second part of the sgagent.conf file is used for the actual tests. A test will always begin with a test name definition followed by parameter lines, each of which defines a parameter for the test. The only mandatory parameter is command, which specifies the test expression. All other parameters (test, interval, action, host, script, and recovery) are optional and have their default values if not specified for the test. See Table H.2.

test name

The test field refers to the name of the test and is defined by the user. The name must be descriptive in order to give the user enough information on what has happened in case of a failure, as the name of the test will appear in the logs and alerts. The test name may be any string. You must use quotation marks if the name contains spaces.

interval time

The interval field defines how often the test is executed. The interval time is noted as [(hh:)mm:]ss. For example:• 1 hour is noted as 1:00:00 • 30 minutes is noted as 30:00 • 60 seconds is noted as 60.If no interval time is defined, the default value of 60 seconds will be used.

action action

The action field informs the tester what to do in case the test fails. There are two alternatives for the action parameter: alert and exclude.• alert creates a log entry and runs the alert script, if one is defined for the test.

begin host server1load-index 400 load-average-1end

TABLE H.2 Test Section Syntax

test nameinterval timeaction actionhost hostnamescript {always|number} pathrecovery {always|time}command test_expression parameters

473

• exclude sets the server status to Excluded and creates an alert. In the Excluded state the member will be excluded from the Server Pool. No new connections will be directed to the excluded member and the current connections are moved to the other members of the pool. If no action is set for the test, alert will be used as the default action.

host hostname

The host field defines the server to be tested. The name of the server must match the one given in the host field of sgagent.local.conf. You can also list multiple server names, as long as they are separated by spaces. If no specific server is defined, by default, the test is performed on all Server Pool members.

script repeat path

The script field specifies the path to the script that is executed every time the test fails. The repeat parameter defines the number of failures after which the script is no longer run, unless the agent status changes. For example, the following line informs the tester that after the fourth failure the script is no longer run, unless the status of the server changes:

If no argument is given the script is run only after the first failure. The counter is reset each time the server status changes, or the test succeeds. You must use quotation marks in case the path contains spaces.

script always path

The difference between script and script always is that script always will run without restrictions on the number of failures. You must use quotation marks in case the path contains spaces.

recovery time

The recovery field with the time parameter “[(hh:)mm:]ss” determines how long the tester reruns a failed test in case the test would succeed again. If the test is successful in the defined time period after the test failure, the server state is changed back from Excluded to OK. For example, recovery 5:00 indicates that a recovery occurs if the test succeeds within five minutes of a failure (assuming that no other test has failed meanwhile).

recovery always

The recovery always field indicates that there are no time limits on how long the tester waits for the test to succeed again. The server is recovered from Excluded to OK state when the test is again successful.

command test_expression parameters

script 4 /etc/init.d/script.sh


The last line in the test section specifies which test script to use, and it also sets possible parameters that a specific test may need. This line is mandatory. For example:

The example instructs the tester to run the multi-ping test script. Three attempts to run the test will be made. The timeout for this particular test is one second (1000 milliseconds) and the addresses to be pinged are 192.168.2.2 and 212.20.2.2. For more information on the test, see Internal Tests, on page 476.

command external retry timeout path_to_script parametersFor an external test, use the external command. The retry option specifies how many times the script is run before the test is considered failed. The timeout parameter specifies how long (in milliseconds) the tester waits for the test result. With path_to_script you can define the path to the external test script. Furthermore, if you need additional parameters set to the external script, they are defined after path_to_script. Note that quotation marks are needed if the path contains spaces. See the following example:

The example instructs the tester not to use any built-in test scripts but instead run /usr/lib/testscript/test.sh. Four attempts are made with the time-out period of 1.5 seconds. The IP address is 192.168.1.1. Alternatively, the IP address may be substituted with %hostip% if the variable hostip is set in the sgagent.local.conf file of each Server Pool member, as shown below:

Examples:To further clarify the test system, let us review an example where an administrator adds a test for checking whether the server is listening on a particular port. The following lines are added in the sgagent.conf files:

command multi-ping 3 1000 192.168.2.2 212.20.2.2

command external 4 1500 /usr/lib/testscript/test.sh 192.168.1.1

command external 4 1500 /usr/lib/testscript/test.sh %hostip%

test “port listening test” interval 2:00action excludehost server1script /etc/init.d/port startrecovery 10:00command portlistening 80 192.168.1.1

475

The test ensures that server1 is listening to traffic on port 80. The test is performed every two minutes, and in case of a failure, the server will be excluded from the Server Pool, and it will stop accepting connections. There is also a script that the tester runs when the test fails. Should the subsequent tests succeed within 10 minutes of the failure, recovery occurs and the server returns back to the OK state. Finally, the command line informs the tester about the test to be performed and any additional information the test needs. In this example, the port information and the IP address of the server are required.Another option is to create an external test. An example might be a test for ensuring that multiple services are running at the same time. You can do this by combining pre-defined tests with AND, OR, and NOT operators, or you can write your own script. The use of an external script must be noted in the sgagent.conf file, as shown by the following example:

In this example, test called “multiple_services” will be run. The test will run every 10 minutes, and in case of a failure an alert is generated. There will be three attempts to run the test before it is considered failed, and the tester will wait for one second before the test is timed out. Furthermore, the additional parameter 192.168.1.1 is required.

Note – External tests must be programmed to return an exit code of 0 (zero) to indicate success. Any non-zero return value would thus be considered failed.

Internal TestsAll built-in tests available for the Server Pool monitoring are listed below. Each test has an example configuration, which however may differ from what you need to configure for your own environment. The syntax for the tests is as described previously. Most importantly, you will use command to configure the test to be used and any optional parameters for that particular test, as for example:

Note that some of the internal tests may not work under VMware.

swapfree limit

test “multiple_services”interval 10:00action alertcommand external 3 1000 /usr/lib/server/test.sh 192.168.1.1

command networkinterface-up eth0


The test checks the available swap space. If the current amount of free swap space drops below limit (given in kilobytes), the test fails.

processcount count

The test checks how many processes are currently running. If the number of processes exceeds count, the test fails.

multi-ping retry timeout ip_address [ip_address [...]]

The test sends ICMP Echo Request messages to the defined IP addresses and waits for the replies. The test fails if none of the IP addresses answers to the ping query. Parameter retry specifies how many ICMP Echo Request packets will be sent to each IP address, and timeout defines how long (in milliseconds) the tester waits for the reply.

filesystem partition free_space

File system tests are used for checking whether there is enough space left on a particular partition. The test fails if the amount of free_space (in kilobytes) is

test “swapfree test”interval 1:00host server2action alertcommand swapfree 1500

test process_countinterval 60host server2action alertcommand prosesscount 2500

test “multi-ping test”interval 30host server2action excludecommand multi-ping 3 1000 192.168.1.2 192.168.1.254

477

lower than the free space on the partition. The partition may also be identified by its path.

Note – File system tests are quite taxing on the operating system and short interval values must not be used. It is recommended that the interval be at least 15 minutes.

servicerunning service_name

This test checks whether the specified service is running on the server. The test fails if the specified service/process is not running. On Windows platforms, the test checks whether the service called service_name is running. In UNIX environments, the test checks whether the process named service_name is running.

iplistening ip_address

The test checks if the specified IP_address is listening on the server. The test fails if the host does not have the specified IP address.

portlistening port [ip_address [protocol]]

test “free space in filesystem”interval 15:00host server2action alertcommand filesystem /var/tmp 1000

test “is ntp running -test”interval 15script /etc/init.d/ntpd startaction excluderecovery 1:00command servicerunning ntpd

test ip-listeninginterval 30host server2action excludecommand iplistening 192.168.1.1


This test checks whether the specified port is listening on the server(s). The test fails if the port is not in the listen state. The protocol may be TCP or UDP.

portanswer retry timeout query response port [ip_address]

The test checks whether the TCP port answers to a TCP query, and gives the expected response. The test fails if the port does not answer, or the answer differs from the expected response. After sending a query to the port, the tester will start waiting immediately, and it will wait for the time period specified in timeout (in milliseconds). If no response is received within the time period, the test fails. The retry count specifies how many attempts are made before declaring the test failed.

Notice that if no query parameter is specified, nothing will be sent to the port.

Note – The Telnet protocol executes certain handshake procedures invisible to the client prior to beginning the connection. If you use portanswer to test a Telnet service, test the handshake procedure, not the Telnet prompt.

httpanswer retry timeout url file port [ip_address]

The test ensures that the server answers to url requests with the correct file from the specified port. The test fails if the port does not answer to an HTTP query, or the answer differs from the contents of the file. The retry count specifies how many attempts will be made before the test is considered failed. Parameter timeout defines how long the tester will wait for the reply before a retry. In addition, in case the retry count limit is reached, timeout will determine when to declare the test failed. If no ip_address is specified, by default the tester will use the localhost address to which to send the query.

networkinterface-up interface

test port-listeninginterval 30host server2 server3action excludecommand portlistening 80

command portanswer 2 1000 “” “” 4567

test http_answeringinterval 30action excludecommand httpanswer 4 3500 /www.example.com/index.html /web/file.html 80

479

This test checks that the given interface is up. The test fails if the specified network interface does not exist or it is down. In Windows, this test behaves similar to the linkstatus test described next.

networkinterface-linkstatus interface

This test checks the link-layer status of the given interface. The test fails if the specified network interface is not linked.

file-exists path

This test is used to check that an important file exists on the server(s). The test fails if the file identified by the path does not exist.

test etc0_upinterval 45action alertcommand networkinterface-up eth0

test “link status on eth0”interval 45action alertcommand networkinterface-linkstatus eth0

test “index -file exists”interval 2:00action alertcommand file-exists /important/index.html


Monitoring Agent Command Line ToolsYou can give certain options to the Monitoring Agent using sgagentd in the command line. For example, you may test different configurations before activating them. This is done by using sgagentd -d test. The command line syntax is shown in Table H.3.

With the sgmon command you can run a program that sends a query to a running StoneGate Monitoring Agent. It is an additional way to remotely monitor your Server Pool members. The sgmon tool sends a UDP query to the specified host and waits for a response until received, or until the time-out limit is reached. To get the status locally, you may give localhost as the host argument. Note that the host argument is mandatory in the sgmon command. The syntax for sgmon is shown in more detail in Table H.4. The sgmon tool is always installed along with the Monitoring Agent. In Linux/Solaris, the installation package will create a link to the sgmon program in /

TABLE H.3 Command Line Tool

# sgagentd -h

Usage:sgagentd [options] [command [args]]

Options:-d Don’t Fork as a daemon.

All log messages will be printed to stdout or stderr only.

-v level Set the verbosity level. The default level is 5. Levels 6-8are for debugging where available.

-c path Use path as the first search directory for the configuration.

Commands:test [files]

Run in the test mode - status queries will not receive response. In case you provide the files, they are used for reading the configuration instead of the default files. If option -d is not used, the output is directed to syslog or eventlog instead of the console where the command was run.

syntax [files]Check the syntax in the configuration file. The filenames may be

given as arguments, or if no files are provided the defaultconfiguration files are checked. If option -d is not used, the

output is directed to syslog or eventlog instead of the consolewhere the command was run.

481

usr/bin. In Windows, sgmon will be installed in the same directory as the Monitoring Agent.

TABLE H.4 Remote Query Tool

# sgmon -hUsage:sgmon [-p port] [-t timeout] [-a id] host [command]

Options:-p portConnect to the specified port instead of the default port.-t timeoutSet the timeout (in seconds) for waiting for the response.-a idAcknowledge the received log messages up to the id. Each response message has an id, and you may acknowledge more than one message at a given time by using the id parameter. Note that messages acknowledged by sgmon will no longer appear in the StoneGate firewall logs.

Parameters:host The ip address of the host to connect to.commandThe request to be sent. If not given, the status is requested. Possible commands are:status - request the status informationinfo - request the information on the agent versionproto - query the highest supported protocol versionReturn value:0 if the response was received1 if the query timed out-1 in case of an error


APPENDIX I SNMP Traps and MIBs

StoneGate Firewall/VPN engines can send SNMP traps on system events. The traps are configured using SNMP Agent elements. Additionally, the Tester entries can be configured to send SNMP traps. The SNMP traps are listed in Table I.1.

The STONESOFT-SMI-MIB defines the top-level enterprise registrations for the Stonesoft’s products in the .iso.org.dod.internet.private.enterprises.stonesoft branch (OID .1.3.6.1.4.1.1369). The StoneGate specific MIBs are:• STONESOFT-FIREWALL-MIB (Table I.2)• STONESOFT-NETNODE-MIB (Table I.3).

TABLE I.1 SNMP Traps for StoneGate Firewall/VPN

Trap Name Objects Included Description

fwPolicyInstall fwSecurityPolicy Policy was installed on the firewall.

nodeBoot - Node bootup complete.

nodeHwmon nodeHwmonEventHardware monitoring system has detected problems

nodeOffline nodeOperState Node changed to offline or standby state.

nodeOnline nodeOperState Node changed to online state.

nodeShutdown - Node is shutting down.

nodeTestFailure nodeTestIdentityTest subsystem reported a test failure on the node.

nodeUserLogin nodeLastLoginLogin initiated on the node’s console or through SSH.

483

The StoneGate Firewall/VPN MIB files can be downloaded from the Stonesoft website at http://www.stonesoft.com/.The StoneGate Firewall/VPN also supports objects in the following standard MIBs:• IF-MIB (RFC 2863) (Table I.4)• IP-MIB (RFC 2011) (Table I.5)• SNMP-USER-BASED-SM-MIB (RFC 3414) (Table I.6).• SNMPv2 MIB (RFC 3418) (Table I.7)

TABLE I.2 STONESOFT-FIREWALL-MIB Objects

Object Name Object Description in MIB

fwPolicyTime The time when the security policy was installed to the firewall

fwSecurityPolicy Name of the current security policy on the firewall

fwSoftwareVersion Version string of the firewall software

TABLE I.3 STONESOFT-NETNODE-MIB Objects


nodeClusterId The identification number of the cluster this node belongs to

nodeCPULoad The CPU load percentage on the node

nodeHwmonEvent Reason for the hardware monitoring event

nodeLastLogin The most recent login event on the node

nodeLastLoginTime Timestamp of the most recent login event on the node

nodeMemberId Node's member identification within the cluster

nodeOperState The operative (clustering) state of the node

nodeTestIdentity Identification string of a nodeTest

nodeTestResult The most recent result of the nodeTest

nodeTestResultTime The timestamp of the most recent result of the nodeTest

484 Appendix I: SNMP Traps and MIBs


TABLE I.4 IF-MIB Supported Objects


ifAdminStatus

The desired state of the interface. The testing(3) state indicates that no operational packets can be passed. When a managed system initializes, all interfaces start with ifAdminStatus in the down(2) state. As a result of either explicit management action or per configuration information retained by the managed system, ifAdminStatus is then changed to either the up(1) or testing(3) states (or remains in the down(2) state).

ifAlias

This object is an 'alias' name for the interface as specified by a network manager, and provides a non-volatile 'handle' for the interface. On the first instantiation of an interface, the value of ifAlias associated with that interface is the zero-length string. As and when a value is written into an instance of ifAlias through a network management set operation, then the agent must retain the supplied value in the ifAlias instance associated with the same interface for as long as that interface remains instantiated, including across all re- initializations/reboots of the network management system, including those which result in a change of the interface's ifIndex value. An example of the value which a network manager might store in this object for a WAN interface is the (Telco's) circuit number/identifier of the interface. Some agents may support write-access only for interfaces having particular values of ifType. An agent which supports write access to this object is required to keep the value in non-volatile storage, but it may limit the length of new values depending on how much storage is already occupied by the current values for other interfaces.

ifDescrA textual string containing information about the interface. This string includes the name of the manufacturer, the product name and the version of the interface hardware/software.

ifHighSpeed

An estimate of the interface's current bandwidth in units of 1,000,000 bits per second. If this object reports a value of `n' then the speed of the interface is somewhere in the range of `n-500,000' to `n+499,999'. For interfaces which do not vary in bandwidth or for those where no accurate estimation can be made, this object contains the nominal bandwidth. For a sub-layer which has no concept of bandwidth, this object must be zero.

ifIndex

A unique value, greater than zero, for each interface. It is recommended that values are assigned contiguously starting from 1. The value for each interface sub-layer must remain constant at least from one re-initialization of the entity's network management system to the next re- initialization.

ifInDiscards

The number of inbound packets which were chosen to be discarded even though no errors had been detected to prevent their being deliverable to a higher-layer protocol. One possible reason for discarding such a packet could be to free up buffer space. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime.

485

ifInErrors

For packet-oriented interfaces, the number of inbound packets that contained errors preventing them from being deliverable to a higher-layer protocol. For character- oriented or fixed-length interfaces, the number of inbound transmission units that contained errors preventing them from being deliverable to a higher-layer protocol. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime.

ifInMulticastPkts

The number of packets, delivered by this sub-layer to a higher (sub-)layer, which were addressed to a multicast address at this sub-layer. For a MAC layer protocol, this includes both Group and Functional addresses. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime.

ifInOctets

The total number of octets received on the interface, including framing characters. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime.

ifInUcastPkts

The number of packets, delivered by this sub-layer to a higher (sub-)layer, which were not addressed to a multicast or broadcast address at this sub-layer. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime.

ifLastChangeThe value of sysUpTime at the time the interface entered its current operational state. If the current state was entered prior to the last re-initialization of the local network management subsystem, then this object contains a zero value.

ifLinkUpDownTrapEnable

Indicates whether linkUp/linkDown traps are generated for this interface. By default, this object must have the value enabled(1) for interfaces which do not operate on 'top' of any other interface (as defined in the ifStackTable), and disabled(2) otherwise.

ifMtuThe size of the largest packet which can be sent/received on the interface, specified in octets. For interfaces that are used for transmitting network datagrams, this is the size of the largest network datagram that can be sent on the interface.

TABLE I.4 IF-MIB Supported Objects (Continued)



ifName

The textual name of the interface. The value of this object must be the name of the interface as assigned by the local device and must be suitable for use in commands entered at the device's `console'. This might be a text name, such as `le0' or a simple port number, such as `1', depending on the interface naming syntax of the device. If several entries in the ifTable together represent a single interface as named by the device, then each will have the same value of ifName. Note that for an agent which responds to SNMP queries concerning an interface on some other (proxied) device, then the value of ifName for such an interface is the proxied device's local name for it. If there is no local name, or this object is otherwise not applicable, then this object contains a zero-length string.

ifNumberThe number of network interfaces (regardless of their current state) present on this system.

ifOperStatus

The current operational state of the interface. The testing(3) state indicates that no operational packets can be passed. If ifAdminStatus is down(2) then ifOperStatus is down(2). If ifAdminStatus is changed to up(1) then ifOperStatus changes to up(1) if the interface is ready to transmit and receive network traffic; it changes to dormant(5) if the interface is waiting for external actions (such as a serial line waiting for an incoming connection); it remains in the down(2) state if and only if there is a fault that prevents it from going to the up(1) state; it remains in the notPresent(6) state if the interface has missing (typically, hardware) components.

ifOutDiscards

The number of outbound packets which were chosen to be discarded even though no errors had been detected to prevent their being transmitted. One possible reason for discarding such a packet could be to free up buffer space. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime.

ifOutErrors

For packet-oriented interfaces, the number of outbound packets that could not be transmitted because of errors. For character-oriented or fixed-length interfaces, the number of outbound transmission units that could not be transmitted because of errors. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime.

ifOutOctets

The total number of octets transmitted out of the interface, including framing characters. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime.



487

ifOutUcastPkts

The total number of packets that higher-level protocols requested be transmitted, and which were not addressed to a multicast or broadcast address at this sub-layer, including those that were discarded or not sent. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime.

ifPhysAddress

The interface's address at its protocol sub-layer. For example, for an 802.x interface, this object normally contains a MAC address. The interface's media-specific MIB must define the bit and byte ordering and the format of the value of this object. For interfaces which do not have such an address (e.g., a serial line), this object must contain an octet string of zero length.

ifPromiscuousMode

This object has a value of false(2) if this interface only accepts packets/frames that are addressed to this station. This object has a value of true(1) when the station accepts all packets/frames transmitted on the media. The value true(1) is only legal on certain types of media. If legal, setting this object to a value of true(1) may require the interface to be reset before becoming effective. The value of ifPromiscuousMode does not affect the reception of broadcast and multicast packets/frames by the interface.

ifSpeed

An estimate of the interface's current bandwidth in bits per second. For interfaces which do not vary in bandwidth or for those where no accurate estimation can be made, this object must contain the nominal bandwidth. If the bandwidth of the interface is greater than the maximum value reportable by this object then this object must report its maximum value (4,294,967,295) and ifHighSpeed must be used to report the interface’s speed. For a sub-layer which has no concept of bandwidth, this object must be zero.

ifTypeThe type of interface. Additional values for ifType are assigned by the Internet Assigned Numbers Authority (IANA), through updating the syntax of the IANAifType textual convention.

TABLE I.5 IP-MIB Supported Objects


icmpInAddrMaskReps The number of ICMP Address Mask Reply messages received.

icmpInAddrMasks The number of ICMP Address Mask Request messages received.

icmpInDestUnreachs The number of ICMP Destination Unreachable messages received.

icmpInEchoReps The number of ICMP Echo Reply messages received.

icmpInEchos The number of ICMP Echo (request) messages received.




icmpInErrorsThe number of ICMP messages which the entity received but determined as having ICMP-specific errors (bad ICMP checksums, bad length, etc.).

icmpInMsgsThe total number of ICMP messages which the entity received. Note that this counter includes all those counted by icmpInErrors.

icmpInParmProbs The number of ICMP Parameter Problem messages received.

icmpInRedirects The number of ICMP Redirect messages received.

icmpInSrcQuenchs The number of ICMP Source Quench messages received.

icmpInTimeExcds The number of ICMP Time Exceeded messages received.

icmpInTimestampReps The number of ICMP Timestamp Reply messages received.

icmpInTimestamps The number of ICMP Timestamp (request) messages received.

icmpOutAddrMaskReps The number of ICMP Address Mask Reply messages sent.

icmpOutAddrMasks The number of ICMP Address Mask Request messages sent.

icmpOutDestUnreachs The number of ICMP Destination Unreachable messages sent.

icmpOutEchoReps The number of ICMP Echo Reply messages sent.

icmpOutEchos The number of ICMP Echo (request) messages sent.

icmpOutErrors

The number of ICMP messages which this entity did not send due to problems discovered within ICMP such as a lack of buffers. This value must not include errors discovered outside the ICMP layer such as the inability of IP to route the resultant datagram. In some implementations there may be no types of error which contribute to this counter's value.

icmpOutMsgsThe total number of ICMP messages which this entity attempted to send. Note that this counter includes all those counted by icmpOutErrors.

icmpOutParmProbs The number of ICMP Parameter Problem messages sent.

icmpOutRedirectsThe number of ICMP Redirect messages sent. For a host, this object will always be zero, since hosts do not send redirects.

icmpOutSrcQuenchs The number of ICMP Source Quench messages sent.

icmpOutTimeExcds The number of ICMP Time Exceeded messages sent.

icmpOutTimestampReps The number of ICMP Timestamp Reply messages sent.

icmpOutTimestamps The number of ICMP Timestamp (request) messages sent.

TABLE I.5 IP-MIB Supported Objects (Continued)


489

ipAdEntAddr The IP address to which this entry's addressing information pertains.

ipAdEntBcastAddr

The value of the least-significant bit in the IP broadcast address used for sending datagrams on the (logical) interface associated with the IP address of this entry. For example, when the Internet standard all-ones broadcast address is used, the value will be 1. This value applies to both the subnet and network broadcasts addresses used by the entity on this (logical) interface.

ipAdEntIfIndexThe index value which uniquely identifies the interface to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value of RFC 1573's ifIndex.

ipAdEntNetMaskThe subnet mask associated with the IP address of this entry. The value of the mask is an IP address with all the network bits set to 1 and all the hosts bits set to 0.

ipAdEntReasmMaxSizeThe size of the largest IP datagram which this entity can re-assemble from incoming IP fragmented datagrams received on this interface.

ipDefaultTTLThe default value inserted into the Time-To-Live field of the IP header of datagrams originated at this entity, whenever a TTL value is not supplied by the transport layer protocol.

ipForwardingThe indication of whether this entity is acting as an IP router in respect to the forwarding of datagrams received by, but not addressed to, this entity. IP routers forward datagrams. IP hosts do not (except those source-routed via the host).

ipForwDatagrams

The number of input datagrams for which this entity was not their final IP destination, as a result of which an attempt was made to find a route to forward them to that final destination. In entities which do not act as IP routers, this counter will include only those packets which were Source-Routed via this entity, and the Source-Route option processing was successful.

ipFragCreatesThe number of IP datagram fragments that have been generated as a result of fragmentation at this entity.

ipFragFailsThe number of IP datagrams that have been discarded because they needed to be fragmented at this entity but could not be, e.g., because their Don't Fragment flag was set.

ipFragOKs The number of IP datagrams that have been successfully fragmented at this entity.




ipInAddrErrors

The number of input datagrams discarded because the IP address in their IP header's destination field was not a valid address to be received at this entity. This count includes invalid addresses (e.g., 0.0.0.0) and addresses of unsupported Classes (e.g., Class E). For entities which are not IP routers and therefore do not forward datagrams, this counter includes datagrams discarded because the destination address was not a local address.

ipInDeliversThe total number of input datagrams successfully delivered to IP user-protocols (including ICMP).

ipInDiscards

The number of input IP datagrams for which no problems were encountered to prevent their continued processing, but which were discarded (e.g., for lack of buffer space). Note that this counter does not include any datagrams discarded while awaiting re-assembly.

ipInHdrErrorsThe number of input datagrams discarded due to errors in their IP headers, including bad checksums, version number mismatch, other format errors, time-to-live exceeded, errors discovered in processing their IP options, etc.

ipInReceivesThe total number of input datagrams received from interfaces, including those received in error.

ipInUnknownProtosThe number of locally-addressed datagrams received successfully but discarded because of an unknown or unsupported protocol.

ipNetToMediaIfIndexThe interface on which this entry's equivalence is effective. The interface identified by a particular value of this index is the same interface as identified by the same value of RFC 1573's ifIndex.

ipNetToMediaNetAddress The IpAddress corresponding to the media-dependent `physical' address.

ipNetToMediaPhysAddress The media-dependent `physical' address.

ipNetToMediaType

The type of mapping. Setting this object to the value invalid(2) has the effect of invalidating the corresponding entry in the ipNetToMediaTable. That is, it effectively disassociates the interface identified with said entry from the mapping identified with said entry. It is an implementation- specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use. Proper interpretation of such entries requires examination of the relevant ipNetToMediaType object.

ipOutDiscards

The number of output IP datagrams for which no problem was encountered to prevent their transmission to their destination, but which were discarded (e.g., for lack of buffer space). Note that this counter would include datagrams counted in ipForwDatagrams if any such packets met this (discretionary) discard criterion.



491

ipOutNoRoutes

The number of IP datagrams discarded because no route could be found to transmit them to their destination. Note that this counter includes any packets counted in ipForwDatagrams which meet this `no-route' criterion. Note that this includes any datagrams which a host cannot route because all of its default routers are down.

ipOutRequestsThe total number of IP datagrams which local IP user- protocols (including ICMP) supplied to IP in requests for transmission. Note that this counter does not include any datagrams counted in ipForwDatagrams.

ipReasmFails

The number of failures detected by the IP re-assembly algorithm (for whatever reason: timed out, errors, etc.). Note that this is not necessarily a count of discarded IP fragments since some algorithms (notably the algorithm in RFC 815) can lose track of the number of fragments by combining them as they are received.

ipReasmOKs The number of IP datagrams successfully re-assembled.

ipReasmReqdsThe number of IP fragments received which needed to be reassembled at this entity.

ipReasmTimeoutThe maximum number of seconds which received fragments are held while they are awaiting reassembly at this entity.

TABLE I.6 SNMP-USER-BASED-SM-MIB Objects


usmStatsDecryptionErrorsThe total number of packets received by the SNMP engine which were dropped because they could not be decrypted.

usmStatsNotInTimeWindowsThe total number of packets received by the SNMP engine which were dropped because they appeared outside of the authoritative SNMP engine's window.

usmStatsUnknownEngineIDsThe total number of packets received by the SNMP engine which were dropped because they referenced an snmpEngineID that was not known to the SNMP engine.

usmStatsUnknownUserNamesThe total number of packets received by the SNMP engine which were dropped because they referenced a user that was not known to the SNMP engine.

usmStatsUnsupportedSecLevelsThe total number of packets received by the SNMP engine which were dropped because they requested a security Level that was unknown to the SNMP engine or otherwise unavailable.




usmStatsWrongDigestsThe total number of packets received by the SNMP engine which were dropped because they didn't contain the expected digest value.

usmUserSpinLockAn advisory lock used to allow several cooperating Command Generator Applications to coordinate their use of facilities to alter secrets in the usmUserTable.

usmUserStatus

The status of this conceptual row. Until instances of all corresponding columns are appropriately configured, the value of the corresponding instance of the usmUserStatus column is 'notReady'. In particular, a newly created row for a user who employs authentication, cannot be made active until the corresponding usmUserCloneFrom and usmUserAuthKeyChange have been set. Further, a newly created row for a user who also employs privacy, cannot be made active until the usmUserPrivKeyChange has been set. The RowStatus TC [RFC2579] requires that this DESCRIPTION clause states under which circumstances other objects in this row can be modified: The value of this object has no effect on whether other objects in this conceptual row can be modified, except for usmUserOwnAuthKeyChange and usmUserOwnPrivKeyChange. For these 2 objects, the value of usmUserStatus MUST be active.

TABLE I.7 SNMPv2-MIB Supported Objects


snmpEnableAuthenTraps

Indicates whether the SNMP entity is permitted to generate authenticationFailure traps. The value of this object overrides any configuration information; as such, it provides a means whereby all authenticationFailure traps may be disabled. Note that it is strongly recommended that this object be stored in non-volatile memory so that it remains constant across re-initializations of the network management system.

snmpInASNParseErrsThe total number of ASN.1 or BER errors encountered by the SNMP entity when decoding received SNMP messages.

snmpInBadCommunityNamesThe total number of SNMP messages delivered to the SNMP entity which used a SNMP community name not known to said entity.

snmpInBadCommunityUsesThe total number of SNMP messages delivered to the SNMP entity which represented an SNMP operation which was not allowed by the SNMP community named in the message.

snmpInBadVersionsThe total number of SNMP messages which were delivered to the SNMP entity and were for an unsupported SNMP version.

TABLE I.6 SNMP-USER-BASED-SM-MIB Objects (Continued)


493

snmpInPktsThe total number of messages delivered to the SNMP entity from the transport service.

snmpProxyDrops

The total number of GetRequest-PDUs, GetNextRequest-PDUs, GetBulkRequest-PDUs, SetRequest-PDUs, and InformRequest-PDUs delivered to the SNMP entity which were silently dropped because the transmission of the (possibly translated) message to a proxy target failed in a manner (other than a time-out) such that no Response-PDU could be returned.

snmpSetSerialNo

An advisory lock used to allow several cooperating SNMPv2 entities, all acting in a manager role, to coordinate their use of the SNMPv2 set operation. This object is used for coarse-grain coordination. To achieve fine-grain coordination, one or more similar objects might be defined within each MIB group, as appropriate.

snmpSilentDrops

The total number of GetRequest-PDUs, GetNextRequest-PDUs, GetBulkRequest-PDUs, SetRequest-PDUs, and InformRequest-PDUs delivered to the SNMP entity which were silently dropped because the size of a reply containing an alternate Response-PDU with an empty variable-bindings field was greater than either a local constraint or the maximum message size associated with the originator of the request.

sysContactThe textual identification of the contact person for this managed node, together with information on how to contact this person. If no contact information is known, the value is the zero-length string.

sysDescrA textual description of the entity. This value must include the full name and version identification of the system's hardware type, software operating-system, and networking software.

sysLocationThe physical location of this node (e.g., `telephone closet, 3rd floor'). If the location is unknown, the value is the zero-length string.

sysNameAn administratively-assigned name for this managed node. By convention, this is the node's fully-qualified domain name. If the name is unknown, the value is the zero-length string.

sysObjectID

The vendor's authoritative identification of the network management subsystem contained in the entity. This value is allocated within the SMI enterprises subtree (1.3.6.1.4.1) and provides an easy and unambiguous means for determining `what kind of box' is being managed. For example, if vendor `Flintstones, Inc.' was assigned the subtree 1.3.6.1.4.1.4242, it could assign the identifier 1.3.6.1.4.1.4242.1.1 to its ̀Fred Router'.

TABLE I.7 SNMPv2-MIB Supported Objects (Continued)



sysServices

A value which indicates the set of services that this entity may potentially offers. The value is a sum. This sum initially takes the value zero, Then, for each layer, L, in the range 1 through 7, that this node performs transactions for, 2 raised to (L - 1) is added to the sum. For example, a node which performs only routing functions would have a value of 4 (2^(3-1)). In contrast, a node which is a host offering application services would have a value of 72 (2^(4-1) + 2^(7-1)). Note that in the context of the Internet suite of protocols, values must be calculated accordingly: layer functionality 1 physical (e.g., repeaters) 2 datalink/subnetwork (e.g., bridges) 3 Internet (e.g., supports the IP) 4 end-to-end (e.g., supports the TCP) 7 applications (e.g., supports the SMTP) For systems including OSI protocols, layers 5 and 6 may also be counted.

sysUpTimeThe time (in hundredths of a second) since the network management portion of the system was last re-initialized.

TABLE I.7 SNMPv2-MIB Supported Objects (Continued)


495


APPENDIX J Guidelines for Building Network Security

This appendix gives some general guidelines for building solid network security solutions. It will not provide a definite reference for a perfectly secure implementation; nor will it provide an exhaustive description of all possible security considerations. Instead, it will present some important points that are good to keep in mind when building your network security with the use of firewalls. These points are proven to be noteworthy by experienced network security specialists. Your actual security implementation will, of course, depend on many variables that are characteristic to your own network and organization.


The Main Security Objectives, on page 498 The Corporate Information Security Policy, on page 498 Designing the Network Topology, on page 499 Designing the Policy, on page 501 Logs and Alert Notifications, on page 504 Conclusions, on page 504

497

The Main Security ObjectivesThe main objectives for any information security policy are the three following concepts:• confidentiality• integrity• availabilityConfidentiality means that classified data will not be compromised in any circumstances to any unauthorized parties. The threats to confidentiality vary from e-mail privacy violation to disclosure of business critical secrets.Integrity means that data, in storage or in transit, will not be modified by any unauthorized parties.Availability means that the data and the resources will be continuously available to the authorized parties.Your information security policy must aim at safeguarding these objectives. In order to achieve this goal, it is important to try to define any possible weak spots in your systems and networks, and to use any required means to fortify them. Such weak spots can be a cause of accidental damage to your invaluable business assets, and they can also be exploited by malicious intruders or attackers.

The Corporate Information Security PolicyThe overall corporate information security policy consists of many different factors, data networks security being one of them. The top management of any organization must set a clear direction to information security. They must demonstrate their support and commitment issuing a well defined information security policy across the organization.There must be a written policy document publicly available to all members of the organization. It must include at least the following considerations:• definition of information security, its scope, objectives, and importance• statement of management intention, supporting the goals and principles of

information security• explanation of specific security policies, principles, standards, and compliance

requirements that serve as a collection of guidelines.There must also be a defined process for updating and auditing the policy, in order to adapt it in the rapidly changing environment.Firewall is a device that is used to enforce certain parts of the security policy. They are mainly used for controlling the access of information, and for ensuring the correct and secure operation of the data infrastructure. In the following sections, we will give some useful guidelines how to use firewalls in implementing network security.

498 Appendix J: Guidelines for Building Network Security

Designing the Network TopologyFirewalls are the key components for enforcing the network security policy. By definition, firewalls connect (and simultaneously, separate) networks on different security levels. Firewalls are used to connect internal networks to the public Internet, as well as different parts of the internal network. All the traffic that is subject to monitoring must pass through at least one firewall. The more security requirements a network has, the more important it is to protect it with a series of firewalls. This will lead to a tree-like topology, where the most sensitive private networks, for example, R&D, human resources or accounting intranets, are located the furthest away from the unsecured public networks. This is a good rule of thumb for designing your network topology. Figure J.1 exemplifies a simple tree topology.

Illustration J.1 Example of a Simple Tree Network Topology

Most organizations must have certain publicly available services such as Web, FTP, and e-mail servers in their network. However, it is not safe to place such services in your internal network because they can fairly easily be exploited in a harmful way. Direct connections from outside to your internal network must be limited to the minimum. By default, such services should be located in a special screened subnetwork, often called demilitarized zone (DMZ). The connections from the Internet to the DMZ should be protected by a firewall. Moreover, the necessary connections from the DMZ to the intranet must also go through a firewall. In addition, you can define a rule that lets the servers in the DMZ accept only certain types of service requests. This will reduce the risk of attacks towards your public servers. Figure J.2 shows a protected DMZ.

499

Illustration J.2 DMZ Protected by a Firewall Cluster

As regards Domain Name System (DNS) servers, it is advisable to have a different DNS for external and internal use. A DNS should not reveal the structure of your internal network to outside parties. To locate the publicly available DNS in a DMZ protected by a firewall is a good solution. The internal DNS should be located on a protected intranet.Often, however, there is a need to have connections between two or more protected sites over an unsecured network. In order to provide data security in such situations, it is recommended to use Virtual Private Networks. VPN offers encryption and authentication services, so that the integrity and confidentiality of data can be preserved with a reasonable guarantee even when transmitted over a hostile public network. When a tree network topology is implemented, it is important to ensure that the networks are connected only through firewalls. There should be no loopholes that would offer a connection bypassing the firewalls. In Figure J.3, there is an example of a loophole that undermines the otherwise well planned and secure network topology. A mobile phone is used as a modem for an unsecured connection to the Internet from a computer located in an intranet. These types of situations can easily go unnoticed. However, they should be eliminated.


Illustration J.3 A Warning Example of a Loophole

High AvailabilityNaturally, in any network topology it is of utmost importance to avoid any possible single points of failure. A breakdown or congestion of a single firewall node could block the whole network. The solution is to use redundancy protection by clustering firewalls, and preferably also other crucial network elements (such as routers, switches, critical servers, ISP links, and VPN links). The resulting high availability together with load balancing possibility will decrease this risk significantly.

Designing the PolicyAfter discussing how topology issues affect the general network security, we shall next describe general guidelines for planning a solid policy. Again, it is impossible to describe a complete set of rules that would guarantee your network’s security. Yet we can offer some good points that should be taken into account when planning the rules. Let us first consider some general policy issues, which determine the building of a policy.

User AuthenticationThe firewall policies without user authentication monitor and filter traffic only on the basis of IP addresses and some protocol information (protocol type, possible ports, and so on). Forging of IP addresses is not complicated, and not even antispoofing measures provide absolute security against IP address spoofing. The use of spoofed addressed can grant hackers access to sensitive hosts, and cause considerable damage. The introduction of user authentication in the relevant parts of the policy will

501

add an extra dimension to your network security. This way only trusted people can be given permission to certain types of connections.

Inbound and Outbound ConnectionsIt is important to bear in mind that accepting a connection from the public network or opening an outbound connection from the internal network, contains a potential data security risk to your network. For example, in an open TCP/IP connection, there is a data flow in both directions, and this can be exploited for harmful intentions. The use of firewalls with well-crafted policies to determine whether an opened connection is permissible reduces the hazards. Additional protection can be gained by using content screening servers. Nevertheless, the risks cannot be eliminated totally. Thus, the enforcers of the security policy must be wary of not having a fake sense of security. A successful security policy requires continuous maintenance and vigilance.To allow connections from the Internet to your internal network is always potentially hazardous, because of Trojan Horses and viruses, for example. Therefore, the inbound connections should be kept to the minimum. The few types of inbound connections that are truly necessary should be defined very accurately. The permitted protocols should be the ones known to be safe and easy to control. In order to avoid direct connections from outside to your network, it is recommended to pass the inbound traffic via a firewall protected DMZ (see Figure J.2).As regards the outbound connections, a strict security policy will increase the administrative workload, if a specific permission must be applied for most outbound connections. On the other hand, a loose policy will generate less administrative work, while it will possibly allow, for example, the use of unsecured peer-to-peer programs. It is good to remember, however, that whenever outbound connections are allowed, it is always possible that some malicious parties would try to exploit them. For example, if a harmful agent program gets inside your network, it can use the outbound connections for smuggling confidential data to an information thief. There is no one right answer for determining which is a tolerable level of risks involved in connections; it has to be judged case by case. A well designed firewall policy combined with proper education of network users in good security practices should, however, diminish the security risks caused by opened connections.

General Policy Design GuidelinesA firewall without a well designed policy is practically useless from the network security point of view. If the rules can be bypassed easily, the firewall will lose most of its usefulness.It is advisable to start the designing of the policy from the rules relating specifically to the most sensitive and most accurately defined destinations, such as single hosts and firewalls. Then you can continue defining rules concerning less sensitive and larger network objects, such as groups and entire networks.


A non-detailed abstraction of the order of rules is given in Table J.1. Note that this is merely an example, not a norm.

TABLE J.1 Rule Order Outline

Source Destination Service Action Explanation

The permitted IP addresses (such as the Management Server’s or Superuser’s)

The IP addresses of the Firewalls

Any AllowDefine all the allowed connections to firewall nodes.

AnyThe IP addresses of the Firewalls

Any Discard

The drop rule for any other connections to firewalls’ interfaces not specified by previous rules.

The permitted IP addresses (such as the firewalls’ or Superuser’s)

Management Server

Any Allow

Define all the allowed connections to the firewall Management Server

AnyManagement Server

Any Discard

The drop rule for any other connections to the Management Server not specified by previous rules.

The specifically allowed IP addresses (such as administrators’ or specifically permitted networks’)

For example, Authentication Server, CIS, DMZ, intranets.

Carefully defined permitted services.

Allow

Define all the allowed, well defined, connections to other sensitive targets (such as authentication servers, content screening servers, sensitive intranets, other internal networks, and DMZ networks).

Any

For example, Authentication Server, CIS, DMZ, intranets.

Any Discard

A drop rule for any unspecified connections to each of these targets should be defined.

503

Logs and Alert Notif icationsAn important part of a network security policy is the monitoring of connections with logging. In case something hazardous actually occurs, there cannot be too much log data to help in finding out what is happening or what has happened. An IPS system helps in gathering this data and detecting possible intrusion attempts.One major concern in logging is, of course, the vast amount of data produced. It is not practical to store all logs, regardless of their significance. With a properly defined log filter the amount of data can be reduced to a reasonable level without compromising the efficiency of network security monitoring.The same applies also for alert notifications; it is important that the alert notification threshold is defined to such a level that the number of generated alerts stays manageable. Too many alerts is not desirable, but nor is too few alerts. You must discover the golden mean also in this issue.

ConclusionsThis appendix has discussed the role of the firewall in the overall scheme of information and network security policy. Undeniably, the firewall is an essential component in that sense, but it is not the only one, and you may want to add, for example, an IPS system to further raise your defences. However, you must bear in mind that all network security solutions have their limitations. You should always remember that firewalls require continuous maintenance and monitoring. Your security policy and the policies must be adjusted according to the changing requirements in the network environment. Nevertheless, careful planning of policies and the use of clustering make firewalls powerful network security devices.

The permitted internal network’s IP addresses

Any

Carefully defined permitted services.

Allow

Define all the allowed connections from internal networks to the public networks (Internet).

Any Any Any Discard

The drop rule for every connection that has not been specifically defined above.

TABLE J.1 Rule Order Outline (Continued)

Source Destination Service Action Explanation


APPENDIX K Multicasting

This appendix describes the general principles of multicasting and how it can be used used with Cluster Virtual Interfaces (CVIs) in StoneGate firewall clusters.

Note – The Packet Dispatch CVI mode should be used instead of multicast CVIs as it uses unicast and requires no additional switch or router configuration. The other CVI modes are provided mainly for backward compatibility.


The General Features of Multicasting, on page 506 IP Multicasting Overview, on page 506 Internet Group Management Protocol, on page 507 Ethernet Multicasting, on page 508 Multicasting and StoneGate, on page 508

505

The General Features of MulticastingMulticasting differs in certain important respects from unicasting and broadcasting as a transmission technique. A distinction can be made between multicasting traffic at the network layer (based on special class D IP addresses) and at the data link layer (based on multicast MAC addresses). The general differences how multicasting can be distinguished from unicasting and broadcasting are highlighted below.

Multicasting vs. UnicastingIn unicasting, the transmitted datagrams are intended only for a single host having a unique address. In multicasting, the data is transmitted likewise to a single address (i.e., the multicast group address), but the actual data reaches all the hosts that belong to the group identified by the multicast address in question. This way the data needs only be sent once, and not separately to each host. This naturally saves bandwidth.

Multicasting vs. BroadcastingIn broadcasting, the data is sent from a host to other hosts within a given network, and consequently, they must all use their resources to process the data. In contrast, in multicasting, the hosts that do not belong to a multicast group will not have to use their resources for multicast data. Moreover, multicasting is not restricted to a single network, and hosts on remote networks may receive IP multicast datagrams provided that they belong to a specific host group, and that there are multicast routers forwarding the traffic. Thus, IP multicasting can in principle be used globally whereas broadcasting is limited to a single network.

IP Multicasting OverviewIn the RFC 1112, IP multicasting is defined as the transmission of an IP datagram to a group of hosts identified by a single IP destination address. In addition to this common multicast group address, the hosts in the group all have separate and unique unicast addresses. The actual multicast host group may consist of any number of hosts, possibly even located in different networks. The number may vary over time, as hosts can join in and leave from a group at any time. Moreover, a particular host may belong to several groups simultaneously.The multicast group addresses are class D addresses. They are identified by the high-order initial four bit sequence 1110. In the dotted decimal notation, the multicast group address range runs from 224.0.0.0 to 239.255.255.255. There are certain special addresses: • 224.0.0.0 is never assigned• 224.0.0.1 is assigned to the permanent group of all hosts, including gateways, in

the local network.• 224.0.0.2 is assigned to all local multicast routers

506 Appendix K: Multicasting

Multicast IP addresses are not allowed to be used as source addresses. A multicast source address implies forging of an IP address.The multicast groups are either permanent or transient. Permanent groups have administratively assigned IP addresses, while the addresses of the transient multicast groups can be assigned dynamically from the pool of multicast addresses not reserved for permanent groups. The IP address of an established permanent group will persist even if the group would not have any members at a given time. The transient groups will cease to exist as soon as they no longer have member hosts, and the assigned multicast address is released.See, for example, http://www.iana.org/assignments/multicast-addresses for a list of addresses registered with IANA.

Multicasting ApplicationsOn the basis of the comparisons above, multicasting may be considered a viable option for many types of transmissions. Multicasting is widely used in local area networks for various purposes. Moreover, multicasting can be used both for receiving a publicly transmitted session on an intranet, or for transmitting an internal communication to a public network (e.g., for announcing a product launch). Multicasting is particularly important solution for bandwidth-intensive applications, such as multimedia. The most typical protocol for multicast traffic is UDP.Multicasting may be a suitable solution, for example, for the following applications:• work groups, electronic whiteboards• video/voice-over-IP conferences• real-time streaming media (e.g., Internet radio)• file transfer• spreading of any information to certain selected destinations.

Internet Group Management ProtocolInternet Group Management Protocol (IGMP) is an integral part of Internet Protocol. The IGMP messages are encapsulated in IP datagrams. IGMP is used both between hosts and multicast routers, and between multicast routers. It keeps multicast routers informed of the multicast group memberships on a given local network. Each host supporting multicasting must join the multicast group with the address 224.0.0.1 on each network interface at the initialization time. They shall remain members of this group as long as they are active. With IGMP, the hosts located on a LAN can inform the routers that they want to be able to receive multicast messages from external networks.

Membership MessagesMulticast routers use IGMP for enquiring periodically which multicast groups have members in the connected local networks. This is carried out by sending Host Membership Query messages to the all-hosts address 224.0.0.1. The hosts receiving

507

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

the query respond by sending Host Membership Reports to all neighboring multicast routers.A host joining a new group will immediately transmit a report, instead of waiting for a query. When a host wishes to stop receiving a multicast transmission, it will send a Leave Report message with the destination address 224.0.0.2 to all subnet routers. A router receiving a Leave Report message will send in response a Group Specific Query to the multicast address in order to check whether there still are hosts in that group. In case no response is received, multicasting to that address will be stopped.

Ethernet MulticastingSo far we have seen how multicasting is implemented at the network layer and how multicast IP addresses differ from other types of IP addresses. In addition, we must also distinguish multicasting at the data link layer where stations are identified, not only by their network level IP addresses, but also by their Media Access Control (MAC) addresses. As opposed to unicast and broadcast addresses, the relation of multicast addressing to IP addressing applies also at this level.Most local area network (LAN) topologies allow for multicasting by using some kind of group addressing scheme. Some topologies offer better support for multicasting than others. In Ethernet (as defined in IEEE 802.3), all MAC addresses that have the least significant bit of the most significant byte as “1” are multicast addresses. Thus, for example, 01:00:00:00:00:00 and 49:aa:bb:cc:dd:ee are both multicast MAC addresses; while 02:00:00:00:00:00 and fe:fe:fe:fe:fe:fe are not. The devices with a given multicast MAC defined are able to listen to all traffic sent to that particular MAC address.A specific subset of MAC addresses is reserved for mapping the IP multicasting addresses to data link layer addresses. In Ethernet, the multicast MAC addresses that correspond to multicast IP addresses range from 01:00:5e:00:00:00 to 01:00:5e:7f:ff:ff.

Multicasting and StoneGateNote – The Packet Dispatch CVI mode should be used instead of multicast CVIs as it uses unicast and requires no additional switch or router configuration. The other CVI modes are provided mainly for backward compatibility.

After distinguishing between network layer multicasting and data link layer multicasting, we can now have a look at how Stonesoft’s StoneGate high availability firewall uses multicasting and unicasting.When using clustering technology, the clustered firewall nodes share a common unicast IP address at each Cluster Virtual Interface (CVI). The shared IP address is assigned to those interfaces that handle traffic between networks that is to be distributed and load-balanced between all nodes, as opposed to the type of traffic


where the end-point is one specific node only. Any node-specific traffic (such as management connections) is handled by Node Dedicated Interfaces (NDIs). Due to these CVIs, the cluster is seen as a single virtual entity by any other network device, rather than a group of individual nodes. Traffic addressed to this type of interface is load-balanced between the nodes by the cluster’s load balancing filter. The load balancing filter is in charge of distributing specific connections between individual nodes. Only one node in a cluster handles a given connection addressed to the cluster’s common IP address, while the other nodes will ignore it. In addition to the shared unicast IP address, each node must also share a data link layer address (MAC) at the CVI. Only this way will each of the nodes be provided with the exact same traffic. There are different options for the cluster-wide MAC address, and the selection depends on the features of the other connected networking devices, such as switches and hubs. This document will not act as a definitive reference for different types of switch configurations, but it will give an overview of possible considerations when implementing StoneGate firewall clusters in different types of network environments. The method can be selected based on the surrounding network devices. Unicast MAC configuration can be used with hubs and with switches that support sending a specified unicast MAC address to several ports at the same time. When a layer2 network is not able to do this, multicast MAC can be used instead. Since send all packets to all ports anyway, unicast MAC mode gives better performance with hubs. However, in large networks with large amounts of traffic, the action of sending packets to all ports can create extra load. In that situation, static MAC address forwarding tables can be used to limit traffic to Cluster multicast MAC to cluster ports only. With switches that do not support static MAC address forwarding tables, IGMP snooping can be used for the same task. With switches, Packet Dispatch mode creates less load to switches than unicast MAC or multicast MAC modes.The different configuration options are presented below. For further reference on different types of configurations, visit http://www.stonesoft.com.

Unicast MACA common unicast MAC can be defined at the CVIs if the cluster is connected to hubs or switches that can forward frames with a unicast destination to multiple ports. This way the network devices will forward the same packets to each of the connected firewall nodes sharing this combination of unicast IP and MAC addresses. This mode is recommended whenever the networking devices support sending packets to a specified unicast MAC address to a predefined set of ports at the same time (as opposed to one port, which is typically the default). Hubs by default support this; however, with switches this is not as frequent, and they usually need additional configuration. With unicast MAC only the switches directly connected to the cluster need special configuration.

509


Note – Unlike multicast MAC addresses, there can be only one unicast MAC address defined per Interface ID. Thus, all the NDIs and the unicast CVIs on the same physical interface use the same MAC address.

In addition to the common CVI IP address, each node may optionally have unique unicast IP addresses defined at the same physical interface as the CVI. These unicast IP addresses are assigned to Node Dedicated Interfaces (NDI), and used when an individual node is the end-point of a connection. Since there can only be one unicast MAC address at a given interface, also the node-specific NDI IP addresses are mapped to the common unicast MAC.Figure K.1 exemplifies the IP and MAC address configuration of a cluster’s interfaces that are connected to an external network. By default, the CVI of each node share one unicast IP address. The CVI is mapped to a common unicast MAC address. In addition, for each node, an NDI is defined at the same physical interface as the CVI. The NDI IP addresses are unique, but they all are mapped to the same unicast MAC as the CVI IP address, as there can be only one unicast MAC defined for a physical interface. Traffic directed from the Internet to the cluster’s external CVI IP address is sent by the connected switch or hub to all nodes, since they all are identified by the same unicast MAC.

Illustration K.1 CVI with Unicast MAC

Multicast MACIn case it is not feasible to use a switch that works in unicast mode with clusters, a shared multicast MAC may be defined for the cluster nodes. Most switches support this mode, however, not all switches in the same virtual LAN (VLAN) need to be configured. By default, most switches send packets with a multicast MAC address to all ports connected to the same VLAN. If the size of the VLAN is small, this type of flooding is acceptable. However, with larger VLANs performance problems may occur

Interface(external)

Node 1 Node 2 Node 3

CVI IP address 212.20.1.254 212.20.1.254 212.20.1.254CVI unicast MAC 08:08:08:08:08:08 08:08:08:08:08:08 08:08:08:08:08:08NDI IP address 212.20.1.21 212.20.1.22 212.20.1.23NDI unicast MAC 08:08:08:08:08:08 08:08:08:08:08:08 08:08:08:08:08:08



as the device needs to send each packet to each port connected to the same VLAN. In some switches it’s possible to prevent this by statically restricting multicast traffic with a given MAC address to some predefined ports only.

Note – Some networking devices discard ARP replies specifying a multicast MAC. In this case, static ARP entries must be used.

Figure K.2 presents an example where a common multicast MAC is configured for all cluster nodes. For instance, if a switch is not able to send packets with the same unicast MAC to multiple ports, this type of configuration may be used. Each node has also a unique unicast MAC address mapped to the corresponding IP addresses defined at the NDIs.

Illustration K.2 CVI with Multicast MAC

Multicast MAC with IGMPInternet Group Management Protocol (IGMP) can be used in combination with multicast MAC addresses to avoid flooding with switches that do not support statically defined destinations for multicast. In this mode, switches are configured to send multicast traffic only to the ports from which they have received IGMP Host Membership Report messages corresponding to the MAC address in question. Multicast with IGMP must be selected as the mode for the cluster, and IGMP snooping enabled on the switch. For the IGMP messaging, a common multicast IP address for the cluster nodes should be specified. The multicast MAC address is then computed automatically based on it. Do note, however, that the CVIs are still identified solely by the common unicast IP address; the multicast IP address is only used as the source address for the IGMP messages sent to the switch.

Interface (external) Node 1 Node 2 Node 3CVI IP address 212.20.1.254 212.20.1.254 212.20.1.254CVI multicast MAC 09:08:08:08:08:08 09:08:08:08:08:08 09:08:08:08:08:08NDI IP address 212.20.1.21 212.20.1.22 212.20.1.23NDI unicast MAC 04:08:08:08:08:08 06:08:08:08:08:08 08:08:08:08:08:08


511

Note – Some routers that use router redundancy protocols such as HSRP or VRRP listen to all multicast traffic in addition to the routing related traffic. Thus, multicast packets are re-routed to the network. To prevent this, you can either configure the router to send this traffic only to the cluster ports or define the router’s access control list (ACL) to drop all incoming packets with the cluster’s multicast MAC.


Legal Information

LicensesStonesoft products are sold pursuant to their relevant End-User License Agreements. By installing or otherwise using Stonesoft products in any way, end-users agree to be bound by such agreement(s). See Stonesoft's website, www.stonesoft.com for further details.If Licensee is acquiring the Software, including accompanying documentation on behalf of the U.S. Government, the following provisions apply. If the Software is supplied to the Department of Defense (“DoD”), the Software is subject to “Restricted Rights”, as that term is defined in the DOD Supplement to the Federal Acquisition Regulations (“DFAR”) in paragraph 252.227-7013(c) (1). If the Software is supplied to any unit or agency of the United States Government other than DOD, the Government’s rights in the Software will be as defined in paragraph 52.227-19(c) (2) of the Federal Acquisition Regulations (“FAR”). Use, duplication, reproduction or disclosure by the Government is subject to such restrictions or successor provisions.

Product Export RestrictionsThe products described in this document are subject to export control under the laws of Finland and the European Council Regulation (EC) N:o 1334/2000 of 22 June 2000 setting up a Community regime for the control of exports of dual-use items and technology (as amended). Thus, the export of this Stonesoft software in any manner is restricted and requires a license by the relevant authorities.

Licenses 513

http://www.stonesoft.com/

Patent NoticeMulti-Link, Multi-Link VPN, and the StoneGate clustering technology—as well as other technologies included in StoneGate—are protected by pending patent applications in the U.S. and other countries.

End-User Licence AgreementThe use of the Stonegate products is subject to the then current end-user license agreement, which can be found at the Stonesoft website: www.stonesoft.com/en/support/eula.html.

Software Licensing InformationThe StoneGate software includes several open source or third-party software packages to support certain features. This section provides the appropriate software licensing information for those products.

GNU General Public LicenseVersion 2, June 1991Copyright (C) 1989, 1991 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USAEveryone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.PreambleThe licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Library General Public License instead.) You can apply it to your programs, too.When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it.For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software.Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations.Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all.The precise terms and conditions for copying, distribution and modification follow.

514 Legal Information



GNU GENERAL PUBLIC LICENSETERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION1. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may

be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you".

Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided

that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program.You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.

2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:

a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.

b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.)

These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.

3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:

a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)

The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code.

4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your

Software Licensing Information 515

rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it.

6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.

7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances.It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice.This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.

8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License.

9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.

10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally.

NO WARRANTY11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE

EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

END OF TERMS AND CONDITIONSHow to Apply These Terms to Your New ProgramsIf you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms.


To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. <one line to give the program's name and a brief idea of what it does.>Copyright (C) <year> <name of author> 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USAAlso add information on how to contact you by electronic and paper mail.If the program is interactive, make it output a short notice like this when it starts in an interactive mode: Gnomovision version 69, Copyright (C) year name of authorGnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details.The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, the commands you use may be called something other than `show w' and `show c'; they could even be mouse-clicks or menu items--whatever suits your program.You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the program, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the program‘Gnomovision’ (which makes passes at compilers) written by James Hacker. <signature of Ty Coon>, 1 April 1989 Ty Coon, President of ViceThis General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Library General Public License instead of this License.

GNU LESSER GENERAL PUBLIC LICENSEVersion 2.1, February 1999Copyright (C) 1991, 1999 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USAEveryone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.[This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence the version number 2.1.]PreambleThe licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users.This license, the Lesser General Public License, applies to some specially designated software packages--typically libraries--of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below.When we speak of free software, we are referring to freedom of use, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish); that you receive source code or can get it if you want it; that you can change the software and use pieces of it in new free programs; and that you are informed that you can do these things.To protect your rights, we need to make restrictions that forbid distributors to deny you these rights or to ask you to surrender these rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library or if you modify it.For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights.We protect your rights with a two-step method: (1) we copyright the library, and (2) we offer you this license, which gives you legal permission to copy, distribute and/or modify the library.


To protect each distributor, we want to make it very clear that there is no warranty for the free library. Also, if the library is modified by someone else and passed on, the recipients should know that what they have is not the original version, so that the original author's reputation will not be affected by problems that might be introduced by others.Finally, software patents pose a constant threat to the existence of any free program. We wish to make sure that a company cannot effectively restrict the users of a free program by obtaining a restrictive license from a patent holder. Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license.Most GNU software, including some libraries, is covered by the ordinary GNU General Public License. This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs.When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library.We call this license the "Lesser" General Public License because it does Less to protect the user's freedom than the ordinary General Public License. It also provides other free software developers Less of an advantage over competing non-free programs. These disadvantages are the reason we use the ordinary General Public License for many libraries. However, the Lesser license provides advantages in certain special circumstances.For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License.In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software. For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU operating system, as well as its variant, the GNU/Linux operating system.Although the Lesser General Public License is Less protective of the users' freedom, it does ensure that the user of a program that is linked with the Library has the freedom and the wherewithal to run that program using a modified version of the Library. The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, whereas the latter must be combined with the library in order to run.GNU LESSER GENERAL PUBLIC LICENSETERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION0. This License Agreement applies to any software library or other program which contains a notice placed by the copyright holder or other authorized party saying it may be distributed under the terms of this Lesser General Public License (also called "this License"). Each licensee is addressed as "you".A "library" means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables.The "Library", below, refers to any such software library or work which has been distributed under these terms. A "work based on the Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term "modification".)"Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library.Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does.1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library.You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:a) The modified work must itself be a software library.b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change.


c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License.d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful.(For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.)These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library.In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices.Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy.This option is useful when you wish to copy part of the code of the Library into a program that is not a library.4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange.If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code.5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables.When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law.If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.)Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself.6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that workunder terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications.You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things:a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified


Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.)b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. c) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution. d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place.e) Verify that the user has already received a copy of these materials or that you have already sent this user a copy.For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute.7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things:a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above.b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work.8. You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.9. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Library (or any work based on the Library), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Library or works based on it.10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties with this License.11. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library.If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply, and the section as a whole is intended to apply in other circumstances.It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice.This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.12. If the distribution and/or use of the Library is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Library under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License.13. The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version


or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation.14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OROTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFYAND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONSHow to Apply These Terms to Your New LibrariesIf you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the ordinary General Public License). To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found.<one line to give the library's name and a brief idea of what it does.>Copyright (C) <year> <name of author>This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version.This library 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 Lesser General Public License for more details.You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USAAlso add information on how to contact you by electronic and paper mail. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the library, if necessary. Here is a sample; alter the names:Yoyodyne, Inc., hereby disclaims all copyright interest in the library `Frob' (a library for tweaking knobs) written by James Random Hacker.<signature of Ty Coon>, 1 April 1990Ty Coon, President of ViceThat's all there is to it!

OpenSSL ToolkitThis software includes the OpenSSL toolkit.LICENSE ISSUES==============The OpenSSL toolkit stays under a dual license, i.e. both the conditions of the OpenSSL License and the original SSLeay license apply to the toolkit. See below for the actual license texts. Actually both licenses are BSD-style Open Source licenses. In case of any license issues related to OpenSSL please contact [email protected] License---------------Copyright (c) 1998-2000 The OpenSSL Project. 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.All advertising materials mentioning features or use of this software must display the following acknowledgment:“This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit.(http://www.openssl.org/)”The names “OpenSSL Toolkit” and “OpenSSL Project” must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact [email protected] derived from this software may not be called “OpenSSL” nor may “OpenSSL” appear in their names without prior written permission of the OpenSSL Project.Redistributions of any form whatsoever must retain the following acknowledgment: ‘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.This product includes cryptographic software written by Eric Young, ([email protected]). This product includes software written by Tim Hudson ([email protected]).Original SSLeay License-----------------------Copyright (C) 1995-1998 Eric Young ([email protected]). All rights reserved.This package is an SSL implementation written by Eric Young ([email protected]). The implementation was written so as to conform with Netscape’s SSL. This library is free for commercial and non-commercial use as long as the following conditions are aheared to. The following conditions apply to all code found in this distribution, be it the RC4, RSA, lhash, DES, etc., code; not just the SSL code. The SSL documentation included with this distribution is covered by the same copyright terms except that the holder is Tim Hudson ([email protected]). Copyright remains Eric Young's, and as such any Copyright notices in the code are not to be removed. If this package is used in a product, Eric Young should be given attribution as the author of the parts of the library used. This can be in the form of a textual message at program startup or in documentation (online or textual) provided with the package.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 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.All advertising materials mentioning features or use of this software must display the following acknowledgement: “This product includes cryptographic software written by Eric Young ([email protected])” The word ‘cryptographic’ can be left out if the rouines from the library being used are not cryptographic related:-).If you include any Windows specific code (or a derivative thereof) from the apps directory (application code) you must include an acknowledgement: ‘This product includes software written by Tim Hudson ([email protected])”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.The licence and distribution terms for any publically available version or derivative of this code cannot be changed. i.e. this code cannot simply be copied and put under another distribution licence [including the GNU Public Licence.]

OpenLDAPThis software includes the OpenLDAP client developed by The OpenLDAPFoundation. Original version of the OpenLDAP client can be downloaded from http://www.openldap.org This software includes the OpenLDAP server. The OpenLDAP Public License Version 2.7, 7 September 2001Redistribution and use of this software and associated documentation ("Software"), with or without modification, are permitted provided that the following conditions are met:1. Redistributions of source code must retain copyright statements and notices,


2. Redistributions in binary form must reproduce applicable copyright statements and notices, this list of conditions, and the following disclaimer in the documentation and/or other materials provided with the distribution, and3. Redistributions must contain a verbatim copy of this document.The OpenLDAP Foundation may revise this license from time to time. Each revision is distinguished by a version number. You may use the Software under terms of this license revision or under the terms of any subsequent revision of the license.THIS SOFTWARE IS PROVIDED BY THE OPENLDAP FOUNDATION AND CONTRIBUTORS “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 OPENLDAP FOUNDATION 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.OpenLDAP is a trademark of the OpenLDAP Foundation.Copyright 1999-2001 The OpenLDAP Foundation, Redwood City, California, USA. All Rights Reserved. Permission to copy and distributed verbatim copies of this document is granted.

libradius1This software includes the libradius1 package.Copyright (C) 1995,1996,1997,1998 Lars Fenneberg <[email protected]>Permission to use, copy, modify, and distribute this software for any purpose and without fee is hereby granted, provided that this copy ight and permission notice appear on all copies and supporting documentation, the name of Lars Fenneberg not be used in advertising or publicity pertaining to distribution of the program without specific prior permission, and notice be given in supporting documentation that copying and distribution is by permission of Lars Fenneberg.Lars Fenneberg makes no representations about the suitability of this software for any purpose. It is provided "as is" without express or implied warranty.------------------------------------------------------------------------------Copyright 1992 Livingston Enterprises, Inc.Livingston Enterprises, Inc. 6920 Koll Center Parkway Pleasanton, CA 94566Permission to use, copy, modify, and distribute this software for any purpose and without fee is hereby granted, provided that this copyright and permission notice appear on all copies and supporting documentation, the name of Livingston Enterprises, Inc. not be used in advertising or publicity pertaining to distribution of the program without specific prior permission, and notice be given in supporting documentation that copying and distribution is by permission of Livingston Enterprises, Inc.Livingston Enterprises, Inc. makes no representations about the suitability of this software for any purpose. It is provided "as is" without express or implied warranty.------------------------------------------------------------------------------[C] The Regents of the University of Michigan and Merit Network, Inc. 1992, 1993, 1994, 1995 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 and this permission notice appear in all copies of the software and derivative works or modified versions thereof, and that both the copyright notice and this permission and disclaimer notice appear in supporting documentation.THIS SOFTWARE IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE REGENTS OF THE UNIVERSITY OF MICHIGAN AND MERIT NETWORK, INC. DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE SOFTWARE WILL MEET LICENSEE'S REQUIREMENTS OR THAT OPERATION WILL BE UNINTERRUPTED OR ERROR FREE. The Regents of the University of Michigan and Merit Network, Inc. shall not be liable for any special, indirect, incidental or consequential damages with respect to any claim by Licensee or any third party arising from use of the software.------------------------------------------------------------------------------Copyright (C) 1991-2, RSA Data Security, Inc. Created 1991. All rights reserved.License to copy and use this software is granted provided that it is identified as the “RSA Data Security, Inc. MD5 Message-Digest Algorithm” in all material mentioning or referencing this software or this function.License is also granted to make and use derivative works provided that such works are identified as “derived from the RSA Data Security, Inc. MD5 Message-Digest Algorithm” in all material mentioning or referencing the derived work. RSA Data Security, Inc. makes no representations concerning either the merchantability of this software or the suitability of this software for any particular purpose. It is provided “as is” without express or implied warranty of any kind.These notices must be retained in any copies of any part of this documentation and/or software.


TACACS+ ClientThis software contains TACACS+ client.Copyright (c) 1995-1998 by Cisco systems, Inc.Permission to use, copy, modify, and distribute this software for any purpose and without fee is hereby granted, provided that this copyright and permission notice appear on all copies of the software and supporting documentation, the name of Cisco Systems, Inc. not be used in advertising or publicity pertaining to distribution of the program without specific prior permission, and notice be given in supporting documentation that modification, copying and distribution is by permission of Cisco Systems, Inc.Cisco Systems, Inc. makes no representations about the suitability of this software for any purpose. THIS SOFTWARE IS PROVIDED “AS IS” AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.MD5C.C - RSA Data Security, Inc., MD5 message-digest algorithmCopyright (C) 1991-2, RSA Data Security, Inc. Created 1991. All rights reserved.License to copy and use this software is granted provided that it is identified as the “RSA Data Security, Inc. MD5 Message-Digest Algorithm” in all material mentioning or referencing this software or this function.License is also granted to make and use derivative works provided that such works are identified as “derived from the RSA Data Security, Inc. MD5 Message-Digest Algorithm” in all material mentioning or referencing the derived work.RSA Data Security, Inc. makes no representations concerning either the merchantability of this software or the suitability of this software for any particular purpose. It is provided “as is” without express or implied warranty of any kind.These notices must be retained in any copies of any part of this documentation and/or software.

libwwwThis software contains libwww software.Copyright © 1995-1998 World Wide Web Consortium, (Massachusetts Institute of Technology, Institut National de Recherche en Informatique et en Automatique, Keio University). All Rights Reserved.This program is distributed under the W3C's Intellectual Property License. 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 W3C License http://www.w3.org/Consortium/Legal/ for more details.------------------------------------------------------------------------------Copyright © 1995 CERN. "This product includes computer software created and made available by CERN. This acknowledgment shall be mentioned in full in any product which includes the CERN computer software included herein or parts thereof."

W3C® SOFTWARE NOTICE AND LICENSEhttp://www.w3.org/Consortium/Legal/2002/copyright-software-20021231This work (and included software, documentation such as READMEs, or other related items) is being provided by the copyright holders under the following license. By obtaining, using and/or copying this work, you (the licensee) agree that you have read, understood, and will comply with the following terms and conditions.Permission to copy, modify, and distribute this software and its documentation, with or without modification, for any purpose and without fee or royalty is hereby granted, provided that you include the following on ALL copies of the software and documentation or portions thereof, including modifications: 1. The full text of this NOTICE in a location viewable to users of the redistributed or derivative work. 2. Any pre-existing intellectual property disclaimers, notices, or terms and conditions. If none exist, the W3C Software Short Notice should be included (hypertext is preferred, text is permitted) within the body of any redistributed or derivative code. 3. Notice of any changes or modifications to the files, including the date changes were made. (We recommend you provide URIs to the location from which the code is derived.)THIS SOFTWARE AND DOCUMENTATION IS PROVIDED "AS IS," AND COPYRIGHT HOLDERS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF THE SOFTWARE OR DOCUMENTATION WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.COPYRIGHT HOLDERS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THE SOFTWARE OR DOCUMENTATION.The name and trademarks of copyright holders may NOT be used in advertising or publicity pertaining to the software without specific, written prior permission. Title to copyright in this software and any associated documentation will at all times remain with copyright holders.____________________________________This formulation of W3C's notice and license became active on December 31 2002. This version removes the copyright ownership notice such that this license can be used with materials other than those owned by the W3C, reflects that ERCIM is now a host of the W3C, includes references to this specific dated version of the license, and removes the ambiguous


grant of "use". Otherwise, this version is the same as the previous version and is written so as to preserve the Free Software Foundation's assessment of GPL compatibility and OSI's certification under the Open Source Definition. Please see our Copyright FAQ for common questions about using materials from our site, including specific terms and conditions for packages like libwww, Amaya, and Jigsaw. Other questions about this notice can be directed to [email protected] Reagle <[email protected]>Last revised by Reagle $Date: 2003/01/16 15:01:10 $Last revised by Reagle $Date: 2003/01/16 15:01:10 $

XML-RPC C Library LicenseThis software contains software covered by the XML-RPC C Library License.Copyright (C) 2001 by First Peer, Inc. All rights reserved.Copyright (C) 2001 by Eric Kidd. All rights reserved.Redistribution and use in source and binary forms, with or without modification, are 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 of the author may not be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS `ÀS 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.

Expat LicenseThis software contains software covered by the Expat License.Copyright (c) 1998, 1999, 2000 Thai Open Source Software Center LtdPermission 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.

ABYSS Web Server LicenseThis software contains software covered by the ABYSS Web Server LicenseCopyright (C) 2000 by Moez Mahfoudh <[email protected]>. All rights reserved.Redistribution and use in source and binary forms, with or without modification, are 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 of the author may not be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS `ÀS 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.

Python 1.5.2 LicenseThis software contains software covered by the Python 1.5.2 License.Copyright 1991, 1992, 1993, 1994 by Stichting Mathematisch Centrum, Amsterdam, The Netherlands.All Rights ReservedPermission 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 names of Stichting Mathematisch Centrum or CWI or Corporation for National Research Initiatives or CNRI not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission.While CWI is the initial source for this software, a modified version is made available by the Corporation for National Research Initiatives (CNRI) at the Internet address ftp://ftp.python.org.STICHTING MATHEMATISCH CENTRUM AND CNRI DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL STICHTING MATHEMATISCH CENTRUM OR CNRI 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 Apache Software License, Version 1.1This product includes software developed by the Apache Software Foundation (http://www.apache.org/)."Copyright (C) 1999 The Apache Software Foundation. All rights reserved.Redistribution and use in source and binary forms, with or without modification, are 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 end-user documentation included with the redistribution, if any, must include the following acknowledgment: "This product includes software developed by the Apache Software Foundation (http://www.apache.org/)." Alternately, this acknowledgment may appear in the software itself, if and wherever such third-party acknowledgments normally appear.4. The names "log4j" and "Apache Software Foundation" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact [email protected]. Products derived from this software may not be called “Apache”, nor may “Apache” appear in their name, without prior written permission of the Apache Software Foundation.THIS SOFTWARE IS PROVIDED `ÀS 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 APACHE SOFTWARE FOUNDATION 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 Apache Software Foundation. For more information on the Apache Software Foundation, please see <http://www.apache.org/>.

Bouncy Castle notice and license.Copyright (c) 2000 The Legion Of The Bouncy Castle (http://www.bouncycastle.org) 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.


Package: discover-dataDebian package author: Branden RobinsonThe contents of this package that are not in the debian/ subdirectory are simple compilations of data and are therefore not copyrightable in the United States (c.f. _Feist Publications, Inc., v. Rural Telephone Service Company, Inc., 499 U.S. 340 (1991)_)._Feist_ holds that: Article I, s 8, cl. 8, of the Constitution mandates originality as a prerequisite for copyright protection. The constitutional requirement necessitates independent creation plus a modicum of creativity. Since facts do not owe their origin to an act of authorship, they are not original and, thus, are not copyrightable. Although a compilation of facts may possess the requisite originality because the author typically chooses which facts to include, in what order to place them, and how to arrange the data so that readers may use them effectively, copyright protection extends only to those components of the work that are original to the author, not to the facts themselves. This fact/expression dichotomy severely limits the scope of protection in fact-based works. Therefore, the hardware information lists that comprise the "meat" of this package enjoy no copyright protection and are thus in the public domain. Note, however, that a number of trademarks may be referenced in the hardware lists (names of vendors and products). Their usage does not imply a challenge to any such status, and all trademarks, service marks, etc. are the property of their respective owners.The remainder of this package is copyrighted and licensed as follows: Package infrastructure: Copyright 2001,2002 Progeny Linux Systems, Inc. Copyright 2002 Hewlett-Packard Company Written by Branden Robinson for Progeny Linux Systems, Inc.lst2xml conversion script: Copyright 2002 Progeny Linux Systems, Inc. Copyright 2002 Hewlett-Packard Company Written by Eric Gillespie, John R. Daily, and Josh Bressers for Progeny Linux Systems, Inc.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 COPYRIGHT HOLDER(S) 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 (c) 1999, 2004 Tanuki SoftwarePermission is hereby granted, free of charge, to any person obtaining a copy of the Java Service Wrapper and associated documentation files (the "Software"), to deal in the Softwarewithout restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sub-license, and/or sell copies of the Software, and to permit persons towhom 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 NON-INFRINGEMENT. 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.Portions of the Software have been derived from source code developed by Silver Egg Technology under the following license:Copyright (c) 2001 Silver Egg TechnologyPermission 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, sub-license, 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.



Glossary

A

Access Control ListA list of Elements that can be used to define the Elements that an administrators with restricted permissions can access. See also Administrator Role and Granted Element.

Access RuleA row in a Firewall or IPS policy that defines how one type of IPv4 connection is handled by providing matching criteria based on the source, destination, and protocol information. Confer to IPv6 Access Rule, on page 545.

ActionWhat the firewall engine should do with a packet that matches the criteria for a particular rule in the security policy.

Active Management ServerSee Primary Management Server, on page 551.

Address rangeA Network Element that defines a range of IP addresses. Use to avoid having to repeatedly type in the same IP addresses when defining address ranges that do not correspond to whole networks.

Address Resolution Protocol (ARP)An Internet standard (RFC 826) protocol used to associate IP addresses with the media hardware address of a network interface card on a local area network (LAN).

529

AdministratorAn Element that defines the details of a single person that is allowed to log on to the SMC using the Management Client or to a Monitoring Server using the Monitoring Client, depending on the Administrator Role.

Administrator RoleAn Element that defines which actions an Administrator with restricted permissions is allowed to take. See also Granted Element and Permission Level.

Aggressive ModeThe authentication of two IPsec end-points with only three messages, as opposed to Main Mode’s six. Aggressive mode also does not provide PFS support, and SA negotiation is limited. See Main Mode, on page 547. See also Security Association (SA), on page 555.

AH (Authentication Header)See Authentication Header (AH), on page 532.

Alert ChainA list of rules defining which Alert Channels are used, and in which order, when an alert entry is directed to the Alert Chain from an Alert Policy to be escalated out from the Management Center. See also Alert Escalation.

Alert ChannelA method of sending alerts out from the Log Server. You can send alerts via SMTP (e-mail), SNMP, SMS text messages, or some other action you define in a custom script. Alert Channels are defined in the Log Server’s properties, after which they can be used in Alert Chains.

Alert ElementAn Element that gives the name and description to an Alert Event. The Alert element can be used as a matching criteria in the rules of an Alert Policy.

Alert EntryA log message with an alert status that has been raised based on some Situation (which you can see in the Logs View). Alert entries trigger Alert Escalation.

Alert EscalationSending alerts out from the Management Center to administrators through Alert Channels (such as e-mail) according to a predefined Alert Chain until the original Alert Entry is acknowledged by some administrator in the Logs View.

530

Alert EventA pattern in traffic or a problem in the system’s operation that matches to some Situation used in a policy or internally in the system, and thus triggers an Alert Entry.

Alert PolicyA list of rules defining if an Alert Entry is escalated and which Alert Chain is used for escalating which type of alert entries. See also Alert Escalation.

Alert ServerA StoneGate Management Center component that handles receiving and handling of Alerts. The Alert Server cannot be installed separately, it is integrated in the Log Server installation.

AliasAn Element that can be used to represent other network elements in configurations. It differs from a group element in that it does not represent all the elements at once: the value it takes in a configuration can be different on each engine where it is used.

Allow ActionAn Access Rule parameter that allows a connection matching that rule to pass through the firewall to its destination.

Analyzer1) A device in the StoneGate IPS system that analyzes the log information from Sensors according to its policy to find patterns, so that separate log entries can be combined together.2) The Network Element that represents an Analyzer device in the Management Center.

AntispoofingTechnique used to protect against malicious packages whose IP header information has been altered. See also IP Spoofing, on page 544.

ApplicationA category of Tags for Situations. Meant for grouping Situations that detect known vulnerabilities in a particular software application.

Application Layer Gateway; Application Level FirewallA firewall system, or gateway, in which packets are examined based on the application protocol being used (e.g., telnet, FTP, SMTP). Proxies for each application-level service are installed on the gateway, and are often configured to relay a conversation between two systems. That is, a packet’s destination is the gateway, which then establishes a separate connection to the other system to complete the connection.

531

Apply VPN ActionA Firewall Access Rule parameter that allows matching connection, if a VPN is established, but does not stop the policy traversal if a VPN is not established.

ARP (Address Resolution Protocol)See Address Resolution Protocol (ARP), on page 529.

Asymmetric EncryptionA cryptographic technology that uses a pair of keys. The message is encrypted with the public half of a pair and can then be decrypted only with the matching private half of the key pair. Public key technology can be used to create digital signatures and deal with key management issues. Also referred to as public key encryption. See also Symmetric Encryption, on page 558 and Public-key Cryptography, on page 552.

AuditingA Management Center feature that logs Administrators’ actions and allows Superusers to view and manage these logs to keep track of system changes.

AuthenticationThe process of proving that someone or something is who or what they claim to be. For example, typing a simple username-password combination is a form of authentication.

Authentication Header (AH)A security protocol supported by the IPsec protocol to enhance traffic security. It enables the authentication and integrity of data against packet corruption or tampering. AH protocol can use SHA-1 or MD5 to generate a hash signature based on a secret component from the SA, the packet payload and some parts of the packet header. See also Security Association (SA), on page 555.

Authentication Token/AuthenticatorA portable device for authenticating a user. Authentication tokens typically operate by challenge/response, time-based code sequences, or other techniques. One of the most commonly used tokens is the RSA SecurID card.

AuthorizationThe process of giving someone/something permission to do or have something. Usually related to authentication; once a user has authenticated (proved who they are), they are authorized (given permission) to perform certain actions.

532

B

Balancing ModeA StoneGate cluster mode that attempts to divide the traffic as equally as possible between the online engines participating in the cluster. Confer to Standby Mode, on page 557.

Bandwidth ManagementThe process of determining and enforcing bandwidth limits and guarantees for different types of traffic either together with Traffic Prioritization or on its own. Also see QoS Class, on page 552 and QoS Policy, on page 552.

Bastion HostA system that has been hardened to resist attack, and which is installed on a network. It is a system that is expected to come under attack. They are often components of firewalls, or public systems (e.g., Web servers, anonymous FTP servers).

BlacklistingThe process of blocking unwanted network traffic either manually or with blacklist requests from a Sensor, Analyzer, or Management Server.

Boot RecoveryA StoneGate setting that brings the engines automatically back online after boot-up.

Border RoutingRouting of connections between different autonomous systems.

Buffer OverflowWhen a program’s data in the memory of a computer exceeds the space reserved for it (the buffer), data may in some circumstances be written on other parts of the memory area. Attackers may use buffer overflows to execute harmful program code on a remote system.

BugtraqA mailing list for discussing network security related issues, such as vulnerabilities.

Bulk Encryption AlgorithmDescribes symmetric encryption algorithms which operate on fixed-size blocks of plaintext and generates a block of ciphertext for each.

533

C

CASee Certificate Authority (CA), on page 534.

CANA candidate for a CVE entry.

Capture InterfaceA Sensor interface that can listen to traffic passing in the network, but which is not used for routing traffic through the Sensor. See also Inline Interface.

CategoryA way of organizing elements and policies to display a specific subset at a time when configuring a large StoneGate system in the Management Client to make it easier to find the relevant elements when configuring the system. For example, a Managed Service Provider (MSP) who manages networks of several different customers can add a customer-specific category to each element and policy to be able to view one customer’s elements and policies at a time.

CertificateElectronic identification of a user or device. Certificates prove the user or device is who/what they claim to be. This is done through using public/private key pairs and digital signatures. Certificates are used in StoneGate for authenticating communications between the system components and for Virtual Private Network (VPN) authentication. Digital certificates are granted and verified by a Certificate Authority (CA), such as the internal CA included in the Management Server.

Certificate Authority (CA)A trusted third-party organization or company that issues digital certificates, used to create digital signatures and public-private key pairs. The role of the CA in this process is to guarantee that the individual granted the unique certificate is, in fact, who he or she claims to be.

Challenge/ResponseAn authentication technique whereby a server sends an unpredictable challenge to the user, who computes a response using some form of authentication token, which can be an authenticator, or pre-shared keys used to encrypt random data.

534

ChecksumA one-way function applied to a file to produce a unique “fingerprint” of the file for later reference. File tampering can then be discovered by verifying the checksum value in the future.

CISSee Content Inspection Server (CIS), on page 536.

ClientIn a client-server architecture, a client is usually an application running on a computer or a workstation that uses services provided by a Server.

Client-to-Gateway VPNA Virtual Private Network (VPN) between a software client and a Security Gateway (SGW). Allows connecting mobile and home office workers safely to corporate resources using a secure (authenticated and encrypted) connection through insecure networks.

ClusterA group of devices, or nodes, that share a given work load. In StoneGate, you can cluster Firewalls and Sensors to share the load and provide redundancy, allowing, for example, scheduled maintenance that takes one node out of service without interrupting services to the users.

Cluster ModeDetermines if all members of a cluster participate to traffic processing at all times (Balancing Mode) or if other members remain inactive until a traffic-processing member stops processing traffic (Standby Mode).

Cluster Virtual Interface (CVI)A logical interface shared by all nodes in a cluster. A CVI is assigned an IP and MAC address, which are then used by every node in a cluster for communication. These interfaces give the cluster a single identity on the network, reducing the complexity of routing and network design. CVIs handle the traffic directed to the firewall for inspection in firewall clusters.

Combined Sensor-Analyzer1) StoneGate IPS device that has both Sensor and Analyzer engines running simultaneously on the same hardware.2) The Network Element that represents a Combined Sensor-Analyzer device in the Management Center.

535

Connection TrackingThe set of data maintained for a connection. Used for relating incoming packets to existing connections. Connection tracking information also includes information to necessary for NAT (Network Address Translation), Load Balanced Routing and Protocol Agents. May also contain accounting information.

Contact AddressThe IP address that is needed to contact a device performing a function in the StoneGate Management Center when there is NAT (Network Address Translation) being performed in between the two devices and thus the actual IP address assigned to the network interface cannot be used directly.

Content Inspection Server (CIS)A server that performs detailed examination of a connection’s data and assists in the determination to allow or discard packets. Common examples include virus scanning or filtering of Web URLs. Also known as content screening.

Continue ActionA policy parameter that sets default values to those used in the rule. The defaults are used in all subsequent rules except where specifically overridden until some other rule with the Continue action changes the values or the policy ends.

ContextAn Element that is added to a Situation to define what the Situation should match. Provides a framework for defining parameters, which are most entered as a regular expression, or through a set of fields and options that the administrators adjust.

CRL ServerA server that maintains a Certificate Revocation List (CRL), which can be used in Authentication to check if the certificate has been cancelled.

Custom AlertAn Alert Element that is defined by a StoneGate administrator, as opposed to a ready-made Default Element created by Stonesoft.

CVEA dictionary that provides common names for publicly known information security vulnerabilities and exposures and thus a standardized description for each vulnerability that links the vulnerability information of different tools and databases.

CVI (Cluster Virtual Interface)See Cluster Virtual Interface (CVI), on page 535.

536

D

Default ElementAn Element that is present in the system at installation, or is added to the system during an upgrade or from a Dynamic Update (Package). Default elements cannot be modified or deleted by administrators, but they may be modified or deleted by dynamic update packages or upgrades.

DefragmentationThe process by which a large block of data is broken up into smaller pieces (datagrams), so that it can be packaged and transmitted by the underlying network technology (Fragmentation). Once the smaller pieces arrive at their destination, the datagrams are reassembled into the larger block of data (defragmentation).

DHCP (Dynamic Host Configuration Protocol)A protocol for dynamically assigning IP addresses and other network information to an interface, based on BOOTP. A device on a network with no network information can broadcast a request for an IP address, subnet mask, default gateway and other information from a DHCP server on that same network. DHCP is defined in RFC 2131.

DiagramAn Element that contains one or more network diagrams created using the Diagram Editor.

Digital CertificateSee Certificate, on page 534.

Discard ActionAn Access Rule parameter that stops all connections matching to the rule without sending any notification to the connecting host. Confer to Refuse Action, on page 553.

Dispatch ClusteringSee Packet Dispatch, on page 550.

DMZ NetworkA DMZ (DeMilitarized Zone Network) is a network separate from both internal and external networks, and connected through a gateway. Often used for isolating bastion hosts or publicly available machines, e.g., mail and HTTP servers are typically located on a DMZ network. Sometimes also referred to as a screened subnetwork.

537

DNS SpoofingAn attack method whereby the DNS name of a system is assumed by a malicious system, either by corrupting the name service cache of a victim, or by compromising a domain name server for a valid domain. The victim system is then directed to the malicious system instead of the original server.

DoS Attack (Denial of Service)An attack with the objective of causing enough disruption in a computer system that its usability to legitimate users suffers. For example, and attacker may target a website so that it becomes overloaded, and slows down so much that it becomes unusable for people wishing to view it.

DSCP (DiffServ Code Point)The Differentiated Services (DiffServ) Type of Service (ToS Flag) field added to packets in the network.

DSCP MarkA field in QoS Policy rules that writes a particular DSCP (DiffServ Code Point) marker to the packets, if the QoS Policy is applied on the interface the packets use to exit the firewall.

DSCP MatchA field in QoS Policy rules that assigns the QoS Class specified in the rule to incoming packets that have a specific DSCP (DiffServ Code Point) marker set, if the QoS Policy is applied on the interface the packets use to enter of the firewall.

Dynamic IP addressAn IP address that is assigned by using the DHCP (Dynamic Host Configuration Protocol).

Dynamic NATA way to translate network addresses, where for each original address, a translated address and possibly a port are selected dynamically from a predefined pool.

Dynamic Update (Package)A file supplied by Stonesoft that provides updates to Default Elements and policies, most importantly to the Situation and Vulnerability information that is used for traffic inspection in Inspection Rules.

538

E

ElementA StoneGate object representing the equipment in your physical networks or some area or concept of configuration. Elements may, for example, represent a single device such as a server, a range of IP addresses, or some configuration aid in the Management Center, such as a Category. Also see Network Element, on page 549.

EncryptionUsed for data security, encryption translates any data into a secret code. Public-key encryption and symmetric encryption are the main types of encryption. Decrypting ciphertext (encrypted data) into plaintext requires access to a secret key.

Encryption DomainNetworks that are defined to be behind a certain VPN gateway in a Virtual Private Network (VPN) configuration.

Encryption KeyThe data that is used to convert plaintext to ciphertext. In symmetric algorithms, the same key is the decryption key as well. In public key algorithms, a different, but related key is used to convert the ciphertext back into plaintext.

Encryption PolicySettings that define which encryption and authentication methods are used to establish a Virtual Private Network (VPN).

Enforce VPN ActionA firewall Access Rule parameter that forces connections matching the rule to use a Virtual Private Network (VPN). If establishing the VPN fails for any reason, the connections are discarded. See also Apply VPN Action, on page 532.

EngineThe device that runs firewall, sensor, or analyzer software; a standard server or a StoneGate appliance. Represented by a Node in the Management Client.

Ethernet RulesA set of rules in the IPS Policy that define which Ethernet traffic is allowed or discarded by a Sensor in Transparent Access Control Mode.

ExpressionAn Element that can be used to accurately define a whole complex set of elements by including and excluding elements using logical expressions.

539

F

FilterA description of log fields and their values combined together using operators for the purpose of sorting in or out log, alert, and audit entries. Used, for example, to filter out logs from the display in the Logs View so that those entries that are interesting at the moment can be found more easily.

Firewall1) A Network Element that represents the firewall device in the Management Center. Either a Single Firewall or a Firewall Cluster.2) The device running the StoneGate firewall software.

Firewall ClusterA Group of two or more Firewall Engines that work together as if they were a single firewall.

Firewall EngineThe device that runs firewall software; a standard server or a StoneGate appliance Represented by the Firewall Node in the Management Client.

Firewall NodeAn individual Firewall Engine in the Management Client, representing a device that runs firewall software as part of a Firewall Cluster or a Single Firewall.

Forward ActionA firewall Access Rule parameter that allows a connection from a VPN Client to be forwarded to a Gateway-to-Gateway VPN so that the users can access resources that require a VPN also at other sites than the one they first connect to.

FragmentationThe process by which a large block of data is broken up into smaller pieces (datagrams), so that it can be packaged and transmitted by the underlying network technology (fragmentation). Once the smaller pieces arrive at their destination, the datagrams are reassembled into the larger block of data (Defragmentation).

G

GatewayAn element that represents the firewall/VPN engine in the VPN.

540

Gateway CertificateA Certificate used for authenticating a Gateway to other Gateways and VPN Clients in a VPN.

Gateway ProfileAn element that defines a set of VPN-related capabilities that a VPN Gateway supports.

Gateway SettingsAn element that contains general settings for StoneGate firewall/VPN engines related to VPN performance.

Gateway-to-Gateway VPNIn StoneGate, a Virtual Private Network (VPN) element which is set up so that the VPN is established between two gateway devices providing connectivity to networks behind the gateways.

Granted ElementAn Element or Security Policy that an administrator has been given permission to edit and install when their Administrator Role would otherwise prevent them from doing so.

GroupA Network Element that includes other elements and represents them all at once in policies and other parts of the configuration. For example, you can define a Group of several WWW-servers, and then use the Group element in policies when you need to make a rule that concerns all of the WWW-servers.

H

HardwareA category of Tags for Situations. Meant for grouping Situations that detect known vulnerabilities in applications that run on a particular hardware platform.

Hash SignatureA cryptography-related concept that refers to a digital fingerprint associated with a given message and computed with one-way algorithms. Hash signatures are used to secure the integrity of encrypted data, ensuring that no tampering has taken place during transmission. See also Client-to-Gateway VPN, on page 535, and SHA-1, on page 556.

541

HeartbeatA protocol that the nodes of a Firewall Cluster or Sensor Cluster use to monitor each other and for other tasks that are needed for collaboration between each Node.

High AvailabilityThe implementation of clustering technology, hot standby technology, or general redundancy in a system to increase the availability of an application, service, or network beyond what a single system is capable of providing. Increased availability is achieved by eliminating all single points of failure, with clustering technology providing the highest level of availability.

Host1) A Network Element that represents any single device that has an IP address.2) Any device connected to a TCP/IP network, including the Internet, with one or more IP addresses. Hosts are distinguishable from gateways or routers, in that they do not forward, or route, packets to other networks.

Hot StandbyA solution where one node handles the work load with the support of a back-up node, which takes over connections in case of failure in the first node.

Hybrid AuthenticationA system using both Asymmetric Encryption and Symmetric Encryption. Asymmetric techniques are used for key management and digital signatures. The symmetric algorithms are used to encrypt the bulk of data with reduced strain on resources.

I

IKE ProposalThe suggested encryption algorithms, authentication methods, hash algorithms, and Diffie-Hellman information in the Security Association (SA) component of an IPsec VPN. The initiator of an IPsec tunnel can make multiple proposals, but the responder only sends one proposal in return. See also Internet Key Exchange (IKE), on page 543 and Security Association (SA), on page 555.

Incident CaseAn Element that administrators can use to gather together all the data, actions, system configuration information, and files related to a specific incident of suspicious activity.

542

Incident HistoryA collection of all the logs and audit entries that track actions performed in a particular Incident Case window.

Info PanelA tab in Management Client windows that shows information on the selected element or other object. The Info view shows, for example, the nodes belonging to a selected cluster.

Inherited RuleA rule either hidden or shown on a grey background in a Security Policy or Template Policy which has been added in a template higher up in the policy hierarchy so that it has been passed down to the security policy or template policy. Inherited rules are enforced just as any other rules, but they can be edited only in the template where the rule was originally added.

Inline InterfaceA Sensor interface that combines together two physical interfaces, enabling the traffic to be routed through as if the Sensor was an extension of the network cable, but allowing the Sensor to actively monitor packets and connections and stop them according to its Access Rules and Inspection Rules.

Insert PointThe place in a Security Policy or Template Policy where new rules can be inserted when no rules have been inserted in that place yet (shown as a green row) or the place in a template policy where rules can be inserted in inheriting policies and template policies (shown as an orange row).

Inspection RuleA row in a Firewall or IPS policy that defines options for deeper inspection and reactions to traffic accepted in Access Rules. The matching in Inspection Rules is done based on matching information provided by Situation elements. Confer to Access Rule, on page 529.

Internal NetworkThe networks and network resources that StoneGate is protecting. In StoneGate, there is no concept of internal and external networks in the system.

Internet Key Exchange (IKE)A protocol defined by the IPsec (IP Security) standard for securely exchanging key-related information between connecting hosts when establishing a Virtual Private Network (VPN).

543

Internet Service Provider (ISP)A company that provides Internet connectivity to subscribers.

Intrusion Detection System (IDS)A system that monitors network traffic for determining, and making administrators aware of data security exploits or attempts by providing logs or other network information. Confer to Intrusion Prevention System (IPS).

Intrusion Prevention System (IPS)A system that monitors network traffic (like an Intrusion Detection System (IDS)) and has the capability of actively stopping traffic if it is deemed malicious or otherwise unwanted.

IP Address Bound LicenseA License file for the engines that includes the information on the IP address of the component it licenses. If you need to change the IP address of the component, you must request an IP address change at the Stonesoft Licensing website. On engines, an alternative to a Management Bound License, on page 547.

IPComp (IP Payload Compression Protocol)A protocol used to reduce the size of IP datagrams. Increases the overall communication performance between a pair of communicating gateways by compressing the datagrams, provided the nodes have sufficient computation power, and the communication is over slow or congested links. IPComp is defined in RFC 2393.

IP Splicing (or Hijacking)An attack performed by intercepting and using an active, established session. Often occurs after the authentication phase of the connection is complete, giving the attacker the permissions of the original, authenticated user. Encryption at the session or network layer is typically the best defense from such an attack.

IP SpoofingA technique used to obtain unauthorized access to computers by sending connection requests with tampered headers, simulating a trusted source.

IPsec (IP Security)A set of protocols supporting secure exchange of packets. Used for the implementation of Virtual Private Network (VPN) solutions, IPsec provides transport and tunnel encryption modes. IPsec is defined in RFC 2401.

544

IPsec ProposalSuggested encryption algorithms, hash algorithms, authentication methods, etc. to be used for an IPsec (IP Security) tunnel. See also IKE Proposal, on page 542.

IPS PolicyThe Security Policy for IPS Sensors and Analyzers containing the Access Rule and Inspection Rule definitions that determine how traffic is inspected and how the system reacts when a match is found.

IPv6 Access RuleA row in an IPS policy that defines how one type of IPv6 connection is handled by providing matching criteria based on the source, destination, and protocol information. Confer to Access Rule, on page 529.

ISAKMP (Internet Security Association Key Management Protocol)An open-ended encoding protocol necessary for IKE negotiation when establishing Security Associations. See also Security Association (SA), on page 555.

ISP (Internet Service Provider)See Internet Service Provider (ISP), on page 544.

J

JournalA tool in the Incident Case window that allows administrators to create a permanent record of their actions while investigating an incident.

Jump ActionA Security Policy parameter that directs the inspection to a Sub-Policy, against which connections matching the rule with the Jump action are checked. Can be used to speed up traffic processing, as connections that do not match the Jump rules are not checked against rules in the sub-policies.

L

LicenseFiles you import to the system to tell the Management Server that the components you have installed have been legally purchased. You generate the Licenses at the Stonesoft Licensing website and import them to the Management Server using the Management Client.

545

LifetimeThe interval at which the IPsec participants should begin to negotiate a replacement Security Association (SA) (soft lifetime) or the interval at which the current SA for an IPsec tunnel is no longer valid (hard lifetime) in a Virtual Private Network (VPN).

Load BalancingA process for distributing work evenly across multiple, available devices to avoid overwhelming any single system.

Load Balancing FilterA software component that determines which network connections should be handled by a particular node in a cluster, based on address information, current load, performance of individual machines, and other factors.

Load Balanced RoutingA method for choosing routes to destinations based on determining the fastest response time through multiple gateways. The application of Multi-Link technology to determine which network link provides the best round trip time.

Load SharingThe distribution of work between multiple devices. Similar to Load Balancing, but not as effective, since the techniques used do not ensure an equal distribution of the work load. Load sharing is typically a static method of distributing a load, whereas load balancing is often a dynamic method.

LocationAn Element that groups together system components that are on the same side of a device doing NAT (Network Address Translation). Used to define Contact Addresses for components that communicate within the StoneGate Management Center.

Log ServerA component of the Management Center responsible for storing and managing log (and alert) data.

Log SpoolA temporary storage area in a firewall node for log data before it is sent to a Log Server.

Logical InterfaceAn IPS Element used in the IPS policies to represent one or more physical network interfaces as defined in the Sensor properties.

546

Logs ViewA tool that allows browsing logs, alerts, audit data, and connections each in an adapted version of the same user interface.

M

Main ModeAn IKE negotiation mode, which exchanges six messages between the end-points of an IPsec tunnel to complete the negotiation of authentication and keys for a Virtual Private Network (VPN). Optionally, Perfect Forward Secrecy (PFS) can be applied to protect further negotiations. See also Aggressive Mode, on page 530 and Perfect Forward Secrecy (PFS), on page 550.

Management Bound LicenseA License file for StoneGate engines that is based on information on the Management Server’s Proof of License (POL) code. An alternative to an IP Address Bound License, on page 544.

Management CenterThe system consisting of a Management Server, one or more Log Servers and none to several Monitoring Servers that is used to manage the Firewall Engines, and to store and manage traffic and system related data.

Management ClientA graphical user interface component that provides the tools for configuring, managing, and monitoring the firewalls, sensors, analyzers, and other components in the StoneGate system. The Management Client connects to the Management Server to provide these services based on the Administrator information that you use when launching the Management Client software.

Management NetworkThe network used for communication between firewalls, Management Servers, Log Servers and the Management Client.

Management ServerA system component that stores all information about the configurations of all firewalls, sensors, analyzers, and other StoneGate components in the system, monitors their state, and provides access for Management Clients when administrators want to change the configurations or command the engines. The most important component in the system.

547

Maximum Transmission Unit (MTU)The largest physical size of a datagram that can be transmitted over a network without fragmentation. Often expressed in bytes, it can apply to frames, packets, cells or other media, depending on the underlying topology.

Monitored ElementA StoneGate server or engine component that is actively polled by the Management Server, so that administrators can keep track of whether it is working or not. All StoneGate system components are monitored by default.

Monitoring AgentA software component that can be installed on servers in a Server Pool to monitor the server’s operation for the purposes of Traffic Management.

Monitoring ClientA stand-alone Logs View and Policy Snapshot viewer, which can be used for restricted view-only access as configured in each Monitoring User’s profile. Connects through the optional Monitoring Server component.

Monitoring ServerAn optional StoneGate component used as a gateway by the Monitoring Client for viewing logs.

MulticastA technique by which a set of packets are sent to a group of machines sharing a common address. Unlike broadcast, it does not include all machines, and unlike unicast, it usually has more than one member of the group.

Multi-Layer InspectionA hybrid firewall technology that incorporates the best elements of application level and network level firewalls, with additional technology to enable the secure handling of many connection types.

Multi-LinkPatented Stonesoft technology to connect one site to another, or to the Internet, using more than one network link. Applications of Multi-Link technology include inbound and outbound traffic management for unencrypted as well as VPN traffic. See also Outbound Multi-link, on page 550.

548

N

NAT (Network Address Translation)A mechanism for assigning local networks a set of IP addresses for internal traffic and another for external traffic. It increases security by hiding internal IP addresses and enables hosts with "invalid" (non-routable) addresses to communicate on the Internet.

NDI (Node Dedicated Interface)See Node Dedicated Interface (NDI), on page 549.

NetLinkAn Element used for implementing routing of StoneGate’s Multi-Link features. NetLinks can represent any IP-based network links (such as ISP routers, xDSL, leased lines, dial-up modems). Netlinks are combined together into an Outbound Multi-link.

Network Element1) All Elements that represent one or more components that have an IP address, that is, a general category (‘Network Elements’) for those elements that represent physical devices and networks in StoneGate.2) The Network Element called Network that represents a (sub)network of computers. Used for rules and configurations that are common for all hosts in a specific (sub)network.

NodeThe representation of an individual firewall, sensor or analyzer Engine in the Management Client.

Node Dedicated Interface (NDI)A network interface with a unique IP address for each machine. The only interface type for single firewalls. Not used for operative traffic in firewall clusters and sensors. Firewall clusters use a second type of interface, Cluster Virtual Interface (CVI), for operative traffic. Sensors have two types of interfaces for traffic inspection, the Capture Interface and the Inline Interface.

O

Operating SystemA category of Tags for Situations. Meant for grouping Situations that detect known vulnerabilities in a particular operating system or applications that run on that operating system.

549

Outbound Multi-linkAn Element used for combining NetLinks for load balancing outbound traffic. The NetLinks included in a Outbound Multi-link element are frequently tested to determine which is the fastest NetLink for new outbound connections.

P

PacketA segment of data sent across a network that includes a header with information necessary for the transmission, such as the source and destination IP addresses.

Packet DispatchA Cluster Virtual Interface (CVI) mode in which only one node in the cluster receives packets. This dispatcher node then forwards the packets to the correct node according to Load Balancing, as well as handles traffic as a normal node. The recommended cluster mode for new installations.

Packet FilteringA method of controlling access to a network, or set of networks, by examining packets for source and destination address information, and permitting those packets to pass, or halting them based on defined rules.

Packet SnifferSee Sniffer, on page 557.

Perfect Forward Secrecy (PFS)A property of IKE transactions that enhances the secrecy of keys, but requires additional processing overhead. PFS ensures that the distribution of key-related information remains independent from previously existing key material. See also Internet Key Exchange (IKE), on page 543.

Permission LevelThe general level of rights that an Administrator has. There are three permission levels: Unrestricted Permissions (Superuser), Restricted Permissions, or No Permissions (Monitoring Client Only). Restricted Permissions are defined with Administrator Roles and Granted Elements.

Permit ActionAn Inspection Rule action that stops the inspection of all traffic that matches to the rule that uses the Permit action and lets the traffic continue to its destination.

550

PlayerAny element or IP address that was involved in an incident that is being investigated using the Incident Case element.

PolicyA container for the Access rules, Inspection rules, and NAT rules.

Policy RoutingUser-defined routing based on information that is not normally used in routing, such as the source IP address, port information, or service type.

Policy SnapshotA record of policy configuration that shows the configuration in the form that it was installed or refreshed, including the rules of the policy, the elements included and their properties, as well as the time when the policy was uploaded, and which administrator performed the upload. Helps in keeping track of configuration changes.

Port Address Translation (PAT)A process, similar to NAT (Network Address Translation), where the source or destination port is changed to a different port. PAT is often used to disguise, or masquerade a service in place of another. See also NAT (Network Address Translation), on page 549.

Pre-shared KeyA string of characters that is stored on two (or more) systems and that is used for authenticating or encrypting communications between the systems.

Primary Management ServerThe Management Server that is actively used for configuring the system in a system that has at least one Secondary Management Server.

Proof of License (POL)A code used for verifying the legitimate purchase of StoneGate software products. Used for generating License files at the Stonesoft website.

Proof of Serial Number (POS)Identification code attached to StoneGate appliances.

ProtocolAn element that is used inside Service elements to specific a Protocol Agent for the Firewall Access Rules and the protocol of the traffic for the Inspection Rules.

551

Protocol AgentA process on the firewalls that assists the engine in handling a particular Protocol. Protocol Agents ensure that related connections for a service are properly grouped and evaluated by the firewall engine, as well as assisting the engine with content filtering or network address translation tasks. See also Connection Tracking, on page 536.

Protocol TagA type for Protocol elements that are only used to define the protocol of traffic for inspection against the inspection rules. Confer to Protocol Agent.

Proxy ARPProxy ARP option on a device that does routing means that the device relays broadcast messages between two hosts that are in separate physical networks, but still have IP addresses from the same network. This proxy is needed for the ARP requests, as broadcast messages are not normally relayed from one network to another. See also Address Resolution Protocol (ARP), on page 529.

PruningDeleting log entries according to Filters either as the logs arrive on the Log Server or before they are stored (after displaying them in the current view in the Logs view).

Public-key CryptographyA cryptographic system that uses a pair of keys: a public key, used to encrypt a message, and a private (secret) key that can decrypt the message. This is also called asymmetric encryption.

Q

QoS ClassAn Element that works as a link between a rule in a QoS Policy and one or more firewall Access Rules. The traffic allowed in the access rule is assigned the QoS Class defined for the rule, and the QoS class is used as the matching criteria for applying QoS Policy rules.

QoS PolicyA set of rules for Bandwidth Management and Traffic Prioritization for traffic that has a particular QoS Class, or rules for assigning QoS Classes based on a DSCP Match found in the traffic.

552

R

RefragmentationA technique to fragment outbound packets from the firewall in the same manner in which they were fragmented when the firewall received them. See also Virtual Defragmentation, on page 562.

Refuse ActionAn Access Rule parameter that blocks the packet that matches the rule and sends an error message to the originator of the packet. Confer to Discard Action, on page 537.

Regular ExpressionA string that describes a set of strings. Used in many text editors and utilities to search for text patterns and, for example, replace them with some other string. In StoneGate, regular expressions are used, for example, for defining patterns in traffic that you want a certain Situation to match when you give the Situation a Context that calls for a Regular Expression.

Related ConnectionA connection that has a relationship to another connection defined by a Service. For example, the FTP protocol defines a relationship between a control connection, and one or more data connections at the application level. The firewall may be required to allow a connection that would otherwise be discarded, if it is related to an already allowed connection.

Request for Comments (RFC)A document that outlines a proposed standard for a protocol. RFCs define how the protocol should function, and are developed by working groups of the Internet Engineering Task Force (IETF), and reviewed and approved by the Internet Engineering Steering Group (IESG). See http://www.rfc-editor.org/.

Retained LicenseA Management Bound License that has been used to install a policy on an engine and has then been unbound without relicensing or deleting the engine the license was bound to. Retained licenses cannot be bound to any engine before the engine the license was previously bound to is deleted or has a new policy refresh with a valid license.

RFCSee Request for Comments (RFC).

553

RootkitA set of tools that intruders to computer systems use for hiding their presence and the traces of their actions.

RouteThe set of routers or gateways a packet travels through in order to reach its destination. In TCP/IP networks, individual packets for a connection may travel through different routes to reach the destination host.

RouterA Network Element representing a physical router in your network. Most often used to indicate next-hop routers in the Routing view and in Network Models.

Routing TableA database maintained on every router and gateway with information on paths to different networks. In StoneGate, the routing table is represented graphically in the Routing view.

RuleAn expression used to define the eventual outcome of packets arriving at the firewall, which match certain conditions (e.g., source and destination address, protocol, user).

Rule OptionAdditional actions or features that are applied to a packet matching a given rule, shown in the Options cell in policies. Rule options, for example, specify whether or not to log connection information or send an alert when the rule matches.

S

SA (Security Association)See Security Association (SA), on page 555.

Secondary IP addressAn IP address used for identifying an element with multiple addresses as a source or destination of traffic, defined in addition to a primary IP address.

Secondary Log ServerA Log Server defined as a backup channel for components that primarily send their logs to some other Log Server.

554

Secondary Management ServerA redundant Management Server that replicates the configuration data from the Primary Management Server under normal conditions so that the services offered by the Management Server can be used without interruption if components fail or are otherwise unavailable.

Secret Key CryptographySee Symmetric Encryption, on page 558.

Security Association (SA)A unidirectional, logical connection established for securing Virtual Private Network (VPN) communications between two sites. A security association records the information required by one site to support one direction of the IPsec connection whether inbound or outbound. It uses transport mode for communications between two hosts and tunnel mode for communication between security gateways. See also Authentication Header (AH), on page 532.

Security Gateway (SGW)A device, typically a firewall, that performs encryption/decryption on Virtual Private Network (VPN) packets sent between Sites through untrusted networks.

Security Parameter Index (SPI)A value used by AH and ESP protocols to help the firewall cluster select the security association that will process an incoming packet. See also Authentication Header (AH), on page 532.

Security PolicyThe set of templates, policies, and sub-policies together or individually that define what traffic is acceptable and what traffic is unwanted. Policies are defined using the Management Client, stored on the Management Server and installed on firewalls, sensors, and analyzers, which then use their installed version of the policies to determine the appropriate action to take regarding packets in the network.

SensorA StoneGate IPS component that captures all the traffic from a physical network link, inspects it according to its policy, and if installed inline, selects which connections are allowed to continue. Provides data for the Analyzer (see Analyzer, on page 531).

Sensor ClusterGroup of two or more IPS Sensor nodes that work together as if they were a single Sensor.

555

Server1) A Network Element representing a physical server in your network. Generally, server elements are only defined to configure a specific server for use with the Management Center (such as a RADIUS server used for authenticating administrators), but generic Servers can be used in Network Models instead of Host elements to better illustrate the network layout.2) In a client-server architecture, a computer that is dedicated for running services used by Client computers. The services may include, for example, file storage, e-mail, or web pages.

Server PoolA Network Element representing a group of Servers. Used for inbound traffic management.

ServiceAn Element that is used for matching traffic to an application level protocol, for example, FTP, HTTP or SMTP. The TCP and UDP Services also determine the port number. Service elements are used in policies to make the rule match only a particular protocol, to enable Protocol Agents, and select traffic to be matched against Inspection Rules.

Session StealingSee IP Splicing (or Hijacking), on page 544.

SHA-1A cryptographic algorithm used for hash functions. It generates a 160-bit signature from an input of any length. See also Hash Signature, on page 541.

Single FirewallA firewall that has only one Firewall Engine.

Single Point of FailureThe point at which the failure of a single device or component of a system will lead to either the failure of the entire system, or the inability to use services normally provided by that system. Redundant systems, using high availability technologies, eliminate single points of failure.

SiteA set of resources protected by StoneGate.

556

Situation1) An Element that identifies and describes detected events in the traffic or in the operation of the system. Situations contain the Context information, i.e., a pattern that the system is to look for in the inspected traffic.2) An Inspection Rule cell where Situation elements are inserted.

Situation TypeA category of Tags for Situations. Meant for indicating what kind of events the associated Situations detect (for example, Attacks, Suspicious Traffic).

SnifferA device or program that captures data traveling over a network. Sniffers are often used for troubleshooting network problems, as they can show the packet flow taking place. They can also be used maliciously to steal data off a network.

SNMP AgentA software component that sends SNMP traps when specific events are encountered.

SPI (Security Parameter Index)See Security Parameter Index (SPI), on page 555.

SSH (Secure Shell)A program to log into another computer over a network, to execute commands in a remote machine, and to move files from one machine to another. It provides strong authentication and secure communications over insecure channels. Often used as a replacement for insecure programs such as telnet or rsh. In StoneGate, SSH can be used for remotely accessing the engine command line.

Standby Management ServerSee Secondary Management Server, on page 555.

Standby ModeAn operating state of a StoneGate cluster that keeps one node online and the rest in standby, so that State Synchronization is done, but node does not process the traffic. If the online node is taken offline or fails, one of the standby nodes takes over the existing connections.

State OverviewA tab in the Status/Statistics view that provides a general summary view of the current status of the monitored elements according to the component type.

557

State SynchronizationThe communication of connection tracking information between several firewall nodes in a cluster. Can be either a full synchronization, where all connection tracking information is transferred to the other nodes of a cluster, or an incremental synchronization, where only the information on connections changed after the last synchronization are transferred. See also Connection Tracking, on page 536.

Static IP addressIP address that is typed in by a user or an administrator, and which does not change without their action.

Static NATNAT (Network Address Translation) where for each original address, there is a single, predefined translated address.

Static RoutingA form of routing that has permanent routes between networks programmed into every Routing Table.

Sub-PolicyA set of rules that are separated from the main policy, based on some common category, such as the service or the destination IP address. In this way, related rules can be grouped together to make the entire policy easier to understand. Because subrules are only processed if the general rule in the main policy matches, the overall processing time is improved.

SubtunnelThe actual tunnels that are combined logically within a multi-route VPN tunnel in a StoneGate Multi-Link environment. They represent all possible routes that connect the end-points of the security gateways between which a Virtual Private Network (VPN) is formed. The individual subtunnels may connect the two gateways through different network links.

Symmetric EncryptionAn Encryption mechanism that uses the same shared secret key for encrypting and decrypting messages. It is often referred to as symmetric bulk encryption since it processes large amounts of data rather quickly. Also known as conventional or secret key cryptography. There are two main types of symmetric encryption algorithms, bulk and stream encryption (also known as block ciphers and stream ciphers). Common symmetric algorithms are DES and 3DES. See also Asymmetric Encryption, on page 532.

558

T

TagAn Element for organizing Situations. Tags can also be used in Inspection Rules, in the Situation cell, to represent all Situations marked with that Tag.

Takeover PeriodThe time interval during which the active nodes in a firewall or sensor cluster collaborate to redistribute the work load of a failed node.

TaskAn Element that allows you to schedule commands to run automatically at a convenient time.

Template PolicyA combination of rules and Insert Points, which is used as a basis when creating policies or other template policies. Policies and template policies created from a particular template policy then inherit all the rules from that template policy and any of the template policies higher up in the inheritance hierarchy. The Inherited Rules cannot be edited within the inheriting policy. Used, for example, by high-privilege Administrators to restrict changes administrators with a lower Administrator Role can make to rules.

Temporary FilterA log filter that is created from details of entries in the Logs View or the Connections view, and which is only available until the view is closed.

Terminate ActionAn Inspection Rule parameter that stops or attempts to stop the connection matching to the rule according to the Rule Option selected and the whether the Engine where the rule matching occurs is capable of stopping the connection.

TesterA tool that can automatically run tests on StoneGate engines to check system or network operation and take action based on the results of those tests.

TimelineA tool in the Logs View that allows you to select and change the time range for the logs that are displayed.

559

ToS FlagA data field in IP packet headers that provides a number representing the type of the service the packet is a part of. The ToS flag is used for Traffic Prioritization and is also know as DSCP (DiffServ Code Point).

Traffic HandlerThe set of Network Elements used for inbound and outbound traffic management. Includes NetLinks, Outbound Multi-links, and Server Pools.

Traffic ManagementThe control, definition, and management of how packets or connections should flow through firewalls, routers, network links, VPNs or other gateway objects, based on load balancing, clusters, availability of links and more.

Traffic PrioritizationThe process of assigning traffic a priority value, which is used to determine the order in which queued packets are sent forward, overriding the standard first-come-first-served operation of network devices. Used for assuring Quality of Service (QoS) for time-critical connections. Can be used together with Bandwidth Management or on its own. See also DSCP (DiffServ Code Point), on page 538, QoS Class, on page 552 and QoS Policy, on page 552.

Transparent Access Control ModeA Sensor configuration in which the Sensor examines Ethernet traffic according to the Ethernet Rules.

Transparent ProxyA technique whereby a connection is routed to a proxy server, which then establishes a second connection to the original destination host, but the entire transaction takes place without notifying the user, or requiring the user to perform any additional actions.

Transport ProtocolAny protocol that communicates and functions on the transport layer of the TCP/IP protocol stack. These protocols function above the network layer, and are usually responsible for error correction, quality of service, and other characteristics not handled by the network layer. TCP, UDP, and IPsec are common examples of transport protocols.

TunnelingA technology that enables one network to send its data through another, perhaps dissimilar, network. Tunneling works by encapsulating, or packaging, a network protocol within packets carried by the second network.

560

Tunnel (SS, HH, SH)HH (host-to-host) tunnels designate tunnels between two hosts. SS (subnet-to-subnet) tunnels are tunnels between subnets. SH (subnet-to-host) tunnels are tunnels between subnets and hosts. See Tunneling, on page 560.

U

UDP TrackingInformation maintained by the firewall engines to group together UDP requests and replies, handling them as a single virtual connection. See also Virtual Connection Tracking, on page 561.

Use VPN ActionA firewall Access Rule parameter that directs traffic matching to the rule to a VPN. Can be either an Apply VPN Action or an Enforce VPN Action.

UserAn Element that defines an end-user in your network. Used for defining Authentication with or without Client-to-Gateway VPN access. Confer to Administrator, on page 530.

UTMShort for unified threat management. Term used to refer to devices that combine different types of traffic filtering in one physical appliance. The features offered in a UTM device vary greatly from vendor to vendor. The StoneGate UTM comprises a firewall, deep packet inspection (IDS), and antivirus.

V

Virtual AdapterA component of the StoneGate VPN Client, or a third-party VPN client, that allows using a second, Virtual IP address for Virtual Private Network (VPN) traffic. Shown as a network adapter in the operating system.

Virtual Connection TrackingA superset of UDP tracking, ICMP tracking, etc. A technology that is used by the firewall engines for connectionless network protocols like UDP and ICMP. The firewall engines keep track of virtual connections by grouping together packets that are related, based on information in the packet headers. See also Related Connection, on page 553.

561

Virtual DefragmentationA procedure in which incoming packet fragments are collected. The packet is defragmented for processing by the firewall engine, and refragmented before it is transmitted again. See also Fragmentation, on page 540.

Virtual IP addressA second IP address that is given to a VPN Client that has a Virtual Adapter enabled, and that is connecting to a security gateway using Client-to-Gateway VPN. A virtual IP address enables the use of certain services that require the client to have an IP address belonging to a specific address range, while enabling it to retain its primary IP address for maintaining other connections. The Virtual IP address for StoneGate VPN Clients is always assigned by DHCP (Dynamic Host Configuration Protocol).

Virtual Local Area Network (VLAN)A local area network which is defined through software in a switch or other internetworking device, rather than by the more traditional hardware division.

Virtual Private Network (VPN)A set of devices connected to one or more public networks that encrypt communications amongst themselves. Effectively, the devices create a tunnel over the public network(s) as if they were connected by private lines instead.

VPN ClientSoftware that can be used to establish a Virtual Private Network (VPN) with a VPN gateway device to securely access remote resources over insecure networks.

VPN ProfileAn element that defines the IPsec (IP Security)-related settings for one or more VPNs.

VulnerabilityAn IPS element that contains information on a publicly known flaw that affects security of some system. Vulnerabilities are attached to Situations to provide you more information on what has happened when the Situation matches.

562

Index

Numerics

802.11 wireless connections, 106

A

access control lists, 87predefined, 88

access rules, 165–181action, 172authentication, 174comments, 175continue, 176–177destination, 171options, 173rule table, 168service, 171source, 171source VPN, 175time, 175users, 174

ACE/Server, 232action

in access rules, 172in inspection rules, 190

active directory server, 99active-active clustering, 123active-passive clustering, 124adding users, 230address range element, 96

administrator accounts, 85–93RADIUS authentication, 92

administrator roles, 87editor, 88operator, 88owner, 88

administratorsaccess control lists, 87, 89access control lists, predefined, 88administrator accounts, 85–93administrator elements, 91administrator roles, 87, 89administrator roles, predefined, 88log colors, 92monitoring user elements, 91superuser, 88

aggressive mode in IKE, 356AH (authentication header), 356alert chains, 325–330alert channels, 325–330alert entries, 310, 324alert escalation, 323–334

alert chains, 325–330alert channels, 325–330alert entries, 324alert policies, 325–329, 330custom alerts, 326custom scripts for, 331–332final actions, 327–328system alerts, 326

alert event traces, 319

Index 563

alert notification, 504alert policies, 325–329, 330alias element, 96aliases, 178, 423

system aliases, 425user aliases, system-defined, 424

allow action, 172antispoofing, 141–149anti-virus, 237

on clusters, 239overview to, 238

"any network" element, 98apply blacklist action, 173apply VPN action, 173, 370architecture, 41audit entries, 311authenticating users, 223–235authentication, 224

access rules, 174ACE/Server, 232external LDAP, 227firewall initiated, 231in VPNs, 357internal LDAP, 226one-time password, 232RADIUS, 92, 228RSA SecurID, 232simple password, 232TACACS+, 228user accounts, 230

authentication methods for VPNs, 375authentication rules, 231authentication server, 99authentication servers, 99, 229authentication services, 228, 230authorization

client IP, 231current connection, 231

B

bandwidth management, 281limits, 286

priorities, 286BGP (border gateway protocol), 48blacklisting, 255–260

blacklist entries, 256blacklist requests, 257blacklists, 257whitelisting, 256

C

CA, see certificate authoritycategories, 389–392central gateways, 369central management, 37certificate authority, 59

internal, 46, 365certificate revocation lists (CRL), 365certificates, 46certificates for VPNs, 364, 368CIS (content inspection server), 35, 100

communications, 245defining NAT for, 245redirection, 244–248

client gateway, 366client-to-gateway VPN

use VPN action, 173client-to-gateway VPN, see VPNclient-to-gateway VPNs, 354cluster status icons, 74–75clustering firewalls, 98, 121, 122clustering modes, 123, 125combined category filters, 392command line tools, 407commands

engine, 416log server, 408management server, 408

comments in access rules, 175communications between components, 46connection monitoring, 455–456connection tracking, 162, 173connectivity status, 77contact addresses, 202–203

564 Index

contact information, 18content inspection

examples, 247content inspection server, see CIScontent screening, 35

see also CIScontexts, 251continue action, 172, 176–177, 191corporate SOHO interface, 105custom alerts, 326custom services, 102customer support, 18CVI (cluster virtual interface), 128

D

data for reports, 345default inspection rules, 158, 187default services, 102default template, 158, 169defined operation in filters, 303deploying firewalls, 55–59deploying management center, 59–61destination


destination port translation, 196DHCP

index, 112internal server, 115server element, 100

DHCP relay sub-policy, 158differentiated services code point, 289discard action, 172discard before storing filters, 313, 316DMZ (demilitarized zone), 499DNS server, 100documentation available, 17domains, 230drill-down top rate summaries, 339DSCP, 289

mark, 286match, 285

dynamic DNS (DDNS), 275dynamic IP addresses

distributing, 115for single firewall interfaces, 112

dynamic NetLinks, 264, 266dynamic source NAT, 195

E

editors, see administrator roleselements

context, 251firewall cluster, 98group, 98host elements, 98ips, 98ISP settings, 104Multi-Link, 265, 267NetLink, 100, 264NetLinks, 266network, 98outbound Multi-Link, 101router, 99server, 99server pool, 101services, 101single firewall, 97situations, 249SNMP agent, 117, 133tags, 250–251traffic handlers, 100vulnerability, 250–251

encryption algorithms for VPNs, 376endpoints in VPNs, 370end-user license agreement, 513enforce VPN action, 173enforce VPN rule action, 370engine status icons, 74–75engines, 45–46ESP (encapsulating security payload), 356examples

access rules, 178adding a node to a cluster, 139

Index 565

administrator accounts, 92alert escalation, 332archiving logs, 319bandwidth management, 291blacklisting, 259categories, 392content inspection, 247filters, 306firewall cluster setup, 137incident cases, 397inspection rules, 191log management, 319Multi-Link, 268multi-link routing, 148NAT rules, 204outbound traffic management, 268, 278policies, 163policy routing, 149pruning logs, 320QoS, 291reports, 349routing, 148single firewall setup, 117situation, 254SOHO firewalls, 109traffic prioritization, 291VPN configuration, 380–385

excluded server status, 277exporting reports, 345–348expressions, 97external administrator accounts, 92external gateways, 377external LDAP, 227

classes and attributes, 227schema files, 458

external security gateway, 362external SOHO interface, 105

F

facility log field, 442false positives, 191fields in filters, 300

filter expressions, see filtersfilters, 297–307

fields, 300operations, 301temporary filters, 298, 306types of, 300undefined values, 303

final actions, 327–328fingerprint of certificates, 413fingerprint syntax, 427FIPS 140-2 compliant VPNs, 377firewall policies, 153–164

packet inspection, 154types of, 156

firewall/VPN deployment, 53–61firewalls

advantages of, 27clusters, 98, 121

communications, 122CVIs, 128interfaces, 124modes for clustering, 125Multi-Link, 130synchronization settings, 134

content screening, 35deployment, 55–59engines, 45–46functions of, 33general architecture of, 41general principles of, 25management, 43multi-layer inspection, 31network element for, 97–98requirements for, 36routing configuration for, 142single, 97, 111

dynamic IP addresses for, 112interface IP addresses, 114interfaces for, 113tester, 116, 132with Multi-Link, 115

SOHO firewall engines, 46SOHO Firewalls, 103–110

566 Index

stateful inspection, 31status icons, 74–75technologies of, 28weaknesses of, 38

forward VPN action, 173forward VPN rule action, 370FTP protocol agent, 211–212full sync interval, 135

G

gateway default settings, 366gateway element, 367gateway profile element, 367gateway settings element, 367gateway-to-gateway VPN, see VPNgateway-to-gateway VPNs, 354general firewall principles, 25group element, 98guarantees for bandwidth, 285guest SOHO interface, 105guidelines for policy design, 501

H

H.323 protocol agent, 212–213hardware requirements, 18heartbeat, 122high availability, 36, 48, 501host element, 98HSRP (hot standby routing protocol), 48HTTP protocol agent, 213–214

I

ICMP protocol agent, 214IEEE 802.1Q VLAN tagging, 113, 127IGMP (internet group management protocol),

507IKE (internet key exchange), 355immediate discard filters, 312, 316incident cases, 393–397

example, 397journal, 395player list, 395tabs, 394

incremental sync interval, 135inherited rules, 157inspection rules, 183–192

action, 190comments, 191continue, 191continue rules, 191destination, 189options, 190protocol, 189rule table, 186situation, 188source, 189time, 191

instant messaging, 254interface ID, 113, 127interfaces

IDs, 113, 127in single firewalls, 113network interface cards, 113, 127of firewall clusters, 121of single firewalls, 111of SOHO firewalls, 105routing, 142speed setting for, 286

internal certificate authority, 46, 365internal DHCP server, 115internal LDAP, 226internal security gateway, 362intersection, 97IP address spoofing, 142IP spoofing, 142IPsec overview, 355–358ISP Settings, 104issues in VPNs, 370

J

jump action, 172

Index 567

L

LDAP (Lightweight Directory Access Protocol), 230

classes and attributes, 227schema updates, 458server element, 100

LDAP server, 100LDAP servers, 229legal information, 513licenses, 47limits for bandwidth, 286load balancing

in StoneGate, 48ratio, 265round trip time, 265

load-balanced clustering, 123locations, 201–203

contact addresses, 201log data, 310log entries, 310log files, 313, 318log levels, 314–315log management, 309–321

log files, 313log levels, 314–315log pruning, 315–316log spooling policy, 313–314log tasks, 316–317logging options, 314–315

log pruning, 312–316log server, 44, 99

configuration file, 459log spooling policy, 313–314log tasks, 316–317logging, 309–321, 504logging options, 314–315

for access rules, 173for inspection rules, 190

M

MAC address

for single firewall interfaces, 113main mode in IKE, 356management center, 43

deployment, 59–61Management Client, 45management client, 66–83management server, 43, 99managing users, 230message digest algorithms for VPNs, 374monitoring

NetLinks, 266monitoring agents, 272–275, 276monitoring connections, 455–456monitoring server, 44, 100MSRPC protocol agent, 214–215multicast routing, 147multi-layer inspection, 31, 154Multi-Link, 115, 130, 263–270

configuration, 264examples, 268for VPNs, 379–380routing, 145–147standby NetLink, 265technology overview, 48

Multi-Link monitoring, 76

N

NATstatic source translation, 267

NAT (network address translation), 33contact addresses, 201destination translation, 196dynamic source translation, 195examples, 204hide NAT, 195locations, 201outbound load balancing, 203protocol agents, 209rules

NAT method, 198service, 198source and destination, 198

568 Index

static source translation, 194–195NAT rules

outbound load balancing, 267negating expressions, 97NetBIOS protocol agent, 215NetLink, 266

standby, 265NetLink status icons, 76NetLinks, 100, 115, 146, 264

dynamic, 264, 266monitoring, 266static, 264, 266

Network Address Translation (NAT), 193–206network diagrams in monitoring, 72network element, 98network elements, 95–101

address range, 96alias, 96expressions, 97firewall, 97–98group, 98host, 98network, 98router, 99searching for, 67servers, 99–100services, 101–102SOHO firewall, 97traffic handlers, 100

network interfaces, 113, 127NIC (network interface card), 113, 127

O

online help, 69operations in filters, 301operators, see administrator rolesoptions


oracle protocol agent, 215–216outbound load balancing, 203

NAT rules, 267

outbound Multi-Linkelements, 101

outbound traffic management, 263–270examples, 268, 278using, 268

owners, see administrator roles

P

packet dispatch, 125packet inspection with firewall policy, 154PDF report files, 345period total summaries, 338permit action, 190PFS (perfect forward secrecy), 356phase 1 in IKE negotiations, 356phase 2 in IKE negotiations, 356policies

validating, 161policy design guidelines, 501policy refresh needs, 161policy routing, 147, 149policy snapshots, 162positioning firewalls, 55post-processing reports, 348pre-defined

aliases, 425pre-defined services, 102pre-shared key authentication, 357priorities for bandwidth, 286probing settings, 266progress summaries, 338protocol agents, 177–178, 204, 208–222

FTP, 211–212H.323, 212–213HTTP, 213–214ICMP, 214MSRPC, 214–215NAT, 209NetBIOS, 215oracle, 215–216remote shell, 216services in firewall, 217

Index 569

SIP, 217SMTP, 218SSH, 218SunRPC, 219TCP, 219–220TFTP, 220–221using with CIS, 247–248

protocol in inspection rules, 189proxy ARP, 203

Q

QoS, 281classes, 283, 285interface settings for, 286policies, 283, 285

designing, 288rule table, 285

quick mode in IKE, 356

R

RADIUS, 92, 228, 232RADIUS authentication, 92reading DCSP codes, 285refuse action, 172regular expression syntax, 427remote shell protocol agent, 216removing users, 230report designs, 337–345report items, 337–343report sections, 337–343report tasks, 338, 344–345reporting, see reportsreports, 335–349

bar charts, 338curve charts, 338drill-down top rate summaries, 339exporting, 345–348filters, 345log data, 336, 345monitoring statistics, 336PDF files, 345

period comparisons, 341period total summaries, 338pie charts, 338post-processing, 348progress summaries, 338report designs, 337–345report files, 345–348report items, 337–343report sections, 337–343report tasks, 338, 344–345static information summaries, 339style templates, 346summary types, 338–339system reports, 349tab-delimited text files, 346–348tables, 338top rate summaries, 338

requirements for hardware, 18round trip time, 265router element, 99routing, 141–149

Multi-Link, 145–147NetLinks, 115, 146policy routing, 147static IP multicast routing, 147

RSA SecurID, 232rules

continue action, 176, 191inheritance, 157NAT rules, 193–206protocol agents, 177–178tags, 161validating, 161, 178, 191, 204

S

SA (security association), 355satellite gateways, 369scalability, 37searching

network elements, 67services, 67

secure sockets layer, 59

570 Index

security policycorporate, 498main goals, 498risks, 502

server elements, 99active directory server, 99authentication server, 99content inspection server, 100DHCP server, 100DNS server, 100LDAP server, 100log server, 99management server, 99monitoring server, 100

server pools, 271element, 101excluded server status, 277

service (access rule field), 171service elements

custom services, 102services, 95–102

searching for, 67services in firewall protocol agent, 217single firewalls, 97, 111single point of failure, 122, 501SIP protocol agent, 217site element, 368situations, 249

context definition, 251example, 254in inspection rules, 188

SMTP protocol agent, 218SNMP agent, 117, 133SOHO firewall engines, 46SOHO Firewalls, 103–110SOHO firewalls

network element for, 97security mode, 107wireless use, 107

sourcein access rules, 171in inspection rules, 189

source VPN, 370source VPN (access rule field), 175

SPI (security parameter index), 355SSH protocol agent, 218SSL, 59standard services, 102standby clustering, 124standby NetLink, 265standby NetLinks

using, 265state overview, see system status viewstate synchronization, 134

security levels, 135–136synchronization intervals, 135

stateful inspection, 31static destination NAT, 196static information summaries, 339static IP multicast routing, 147static NetLinks, 264, 266static source NAT, 194–195, 267statistics monitoring, 70status icons, 74–76sub-policies, 156, 159summaries

drill-down top rate summaries, 339period total summaries, 338progress summaries, 338static information summaries, 339top rate summaries, 338

SunRPC protocol agent, 219support services, 18syslog servers, 319system alerts, 326system contexts, 252system design

communications, 46overview, 41

system elementsaliases, 425services, 102

system reports, 349system requirements, 18system services, 102system status view, 70

network diagrams in, 72statistics, 70

Index 571

system-defined user aliases, 424

T

tab-delimited text report files, 346–348TACACS+, 228, 233tags, 250–251TCP protocol agent, 219–220technical support, 18template policies, 156temporary filters, 298, 306terminate action, 190tester, 116, 132, 277TFTP protocol agent, 220–221time


timed synchronization settings, 134TLS, 59top rate summaries, 338topologies for VPNs, 358traffic handlers, 100

NetLinks, 100outbound Multi-Link, 101server pool, 101

traffic prioritization, 281transport layer security, 59transport mode, 358tunnel mode, 358tunnels in VPNs, 355, 370type field, 443typographical conventions, 16

U

undefined optionsin access rules, 173in inspection rules, 190

undefined value policy, 303unified threat management (UTM), 35union, 97use VPN action, 173use VPN rule action, 370

user aliases, system-defined, 424user authentication, 223–235, 501user database

external, 227internal, 226

user databases, 229user-defined service elements, 102users

accounts, 230authenticating, 223–235domains, 230groups, 230managing, 230

users (access rule field), 174UTM, 237

V

virus scanning, 237on clusters, 239overview to, 238

VLAN (virtual local area network), 113, 127, 131VPN (virtual private network), 361–385

access rules for, 370apply action, 173authentication in, 357authentication methods, 375central gateways, 369certificates, 364, 368clustering, 379default elements, 366dynamic IP addresses, as endpoints for, 372encryption algorithms, 376endpoints, 370enforce VPN, 173examples, 380–385FIPS 140-2 mode, 377forward action, 173gateway, 367gateway profile, 367gateway settings, 367IKE, 355internal certificate authority, 365

572 Index

issues, 370logs, 372message digest algorithms, 374Multi-Link, 379–380NAT addresses, as endpoints for, 373overview, 354packet types, 356PFS, 356SAs, 355satellite gateways, 369security gateway types, 362site, 368source VPN, 370third-party gateway devices, 377topologies, 358tunnels, 355, 370

use VPN action, 173user aliases, 424VPN element, 369VPN profile, 369

VPN-A suite, 366vulnerabilities, 250–251

W

WEP (wired equivalent privacy), 107whitelisting, 256wi-fi, 106WLAN, 106WPA (wi-fi protected access), 107writing DSCP codes, 286

Index 573

574 Index

Available StoneGate Guides:

Administrator Documentation• Administrator’s Guide• Installation Guides• Reference Guides• IPsec VPN Client Administrator’s Guide

End-User Documentation• Monitoring Client User’s Guide• IPsec VPN Client User’s Guide

For PDF versions of the guides and the StoneGate technical knowledge base, visitwww.stonesoft.com/support

Stonesoft CorporationItälahdenkatu 22 AFI-00210 HelsinkiFinlandTel. +358 9 476 711Fax +358 9 4767 1234Business ID: 0837548-0Domicile: Helsinki

Stonesoft Inc.1050 Crown Pointe ParkwaySuite 900Atlanta, GA 30338USATel. +1 770 668 1125Fax +1 770 668 1131

Copyright 2008 Stonesoft Corporation. All rights reserved. All specifications are subject to change.
