StoneGate IPS Reference Guide 4.3

StoneGate Reference Guide

SMC 4.3 and IPS 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.

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: SGIRG_20080605

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 13

How to Use This Guide 14

Typographical Conventions 14

Documentation Available 15

Product Documentation 15Support Documentation 16System Requirements 16

Contact Information 16

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

CHAPTER 2 What’s New? 17

New Features in SMC 4.3 18

New Features in IPS 4.3 21

CHAPTER 3 Introduction to Intrusion Detection and Prevention 23

The Role of IDS and IPS 24

IDS and IPS Technologies 24

Host IDS 24Network IDS 24Intrusion Prevention Systems 24

IDS and IPS Functions 25

Misuse Detection 25Anomaly Detection 25Protocol Validation 25

Requirements for Modern IDS/IPS 26

High Availability 26

Performance 26Centralized Management 26Accuracy 27

IDS/IPS Weaknesses 27

Limitations of Protocol Validation 27False Positives 27False Negatives 28Denial of Service 28

CHAPTER 4 StoneGate IPS System Architecture 29

StoneGate Security Platform Overview 30

Accuracy 30Manageability 31Scalability 31Built-in High Availability 31

StoneGate Components 32

StoneGate Management Center 34Management Server 34Management Client 34Log Server 35Monitoring Server 35

Sensors 36IDS Installation 36IPS Installation 36Transparent Access Control Mode 36

Analyzer 36Certificates 37Licenses 37

Traffic Inspection Methods 37

Misuse Detection 38Anomaly Detection With Protocol Analysis 38Anomaly Detection With Statistics 39Event Correlation in the Analyzer 39

Response Mechanisms 39

Keeping StoneGate IPS Up-to-Date 40

3

CHAPTER 5 StoneGate IPS Deployment 41

Deployment Overview 42

Sensor and Analyzer Deployment 43

Positioning Sensors 44Internal Network 45DMZ Network 47External Network 49

Positioning Analyzers 51StoneGate IPS Connections and Bandwidth 51

Management Center Deployment 52

Positioning the Management Server 53Positioning Log Servers 53Positioning Management Clients 54

Example Deployment Scenario 54

SETTING UP STONEGATE

CHAPTER 6 Management Client Basics 61

Introduction 62

General Tools 62

Main Toolbar 62Status Bar 63Element Search 63Bookmarks 64Online Help 65

System Status View 66

System Summary 66Status Tree 67Info Panel 67Graphical Monitoring 68

Overview 69

Status Icons and Colors 70

Configuration View 73

Logs View 74

Policy Editing View 77

CHAPTER 7 Administrator Accounts 79

Overview to Administrator Accounts 80

Configuration of Administrator Accounts 81

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

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

Using Administrator Accounts 86

Customizing Log Color Settings 86RADIUS Authentication 86

Examples of Administrator Accounts 87

Creating Accounts with Predefined Administrator Roles 87

Creating Accounts with a New Access Control List 87

CHAPTER 8 Network Elements and Services 89

Introduction to Network Elements and Services 90

Network Element Types 90

Address Range Elements 90Alias Elements 90Expression Elements 91Firewall Elements 91SOHO Firewall Elements 91Group Elements 91Host Elements 91IPS Elements 92SSL VPN Elements 92Network Elements 92Router Elements 92Server Elements 92

Management Server Element 92

4

Log Server Elements 92Authentication Server Elements 93Active Directory Server Elements 93LDAP Server Elements 93Content Inspection Server (CIS) Elements 93DNS Server Elements 93DHCP Server element 93Monitoring Server element 93

StoneGate IPS Elements 93

Single Sensor Elements 94Sensor Cluster Elements 94Analyzer Elements 94Combined Sensor-Analyzer Elements 94

Services 94

CHAPTER 9 Sensor and Analyzer Configuration 97

Overview to Sensor and Analyzer Configuration 98

Communication Between the Nodes 98Load Balancing 99

Configuration of Sensors and Analyzers 99

Network Interfaces 99Configuration Workflow 101

Task 1: Create an Analyzer Element 101Task 2: Create a Sensor Element 102Task 3: Define VLAN Interfaces 102Task 4: Define NDIs 102Task 5: Define Logical Interfaces 103Task 6: Define Capture Interfaces 103Task 7: Define Inline Interfaces 104Task 8: Install the Sensor and Analyzer Engines 104Task 9: Install an IPS Policy 104

Using Sensors and Analyzers 105

Running Automatic Tests 105Sending SNMP Traps 106Contact Addresses for NATed

Communications 106Using Inline Sensors 107Using Inline Serial Clustering 107Using Sensors in Transparent Access Control

Mode 108

Capturing Traffic From VLANs 108

Examples of Sensor and Analyzer Configuration 109

Setting up an Inline Sensor 109Setting up a Sensor Cluster 110

CHAPTER 10 Routing 113

Overview to Routing 114

Configuration of Routing 114

Default Elements 114Configuration Workflow 114

Task 1: Add Router 114Task 2: Add Network(s) 114Task 3: Refresh IPS Policy 114

TRAFFIC INSPECTION

CHAPTER 11 Situations 117

Overview to Situations 118

Configuration of Situations 118

Situation Contexts 119Correlation Contexts 119Protocol-Specific Contexts 120The Scan Detection Context 120System Contexts 121Website Access Control Contexts 121


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

Using Situations 122

Examples of Custom Situations 123

Detecting the Use of Forbidden Software 123Counting Events 124Preventing Access to Forbidden Websites 124

CHAPTER 12 IPS Policies 125

Overview to IPS Policies 126

5

Policy Hierarchy 126How StoneGate Examines the Packets 126

Configuration of Policy Elements 129


Task 1: Create a Template Policy 131Task 2: Create a Policy 132Task 3: Create a Sub-Policy 132Task 4: Add Rules 133Task 5: Validate the Policy 133Task 5: Install the Policy 134

Using Policy Elements 134

Continue Rules 134Policy Snapshots 134

Example of Policy Element Use 135

Restricting Administrator Editing Rights 135

CHAPTER 13 Ethernet Rules 137

Overview to Ethernet Rules 138

Configuration of Ethernet Rules 138

Considerations for Designing Ethernet Rules 140Default Elements 140Configuration Workflow 141

Task 1: Define the Source and Destination 141Task 2: Define the Service 141Task 3: Select the Action 141Task 4: Select Rule Options 141

Using Ethernet Rules 142

Adding Comments to Rules 142Validating Rules 142

Examples of Ethernet Rules 142

Logging Ethernet Protocol Use 142Restricting the Use of Ethernet Protocols 143

CHAPTER 14 Access Rules 145

Overview to IPS Access Rules 146

Configuration of IPS Access Rules 146

Considerations for Designing Access Rules 148Default Elements 148

Configuration Workflow 150Task 1: Define the Source and Destination 150Task 2: Define the Service 150Task 3: Select the Action 151Task 4: Select Rule Options 151Task 5: Restrict the Time When the Rule Is En-forced 152

Using IPS Access Rules 152

Adding Comments to Rules 152Allowing System Communications 152Configuring Default Settings for Several Rules 153

Using Continue Rules to Set the Protocol 153Rematching Tunneled Packets 154Using Aliases in Access Rules 154Validating Rules 155

Examples of IPS Access Rules 155

Exempting Traffic from Inspection 155Filtering Traffic on an Inline Sensor 156

CHAPTER 15 IPv6 Access Rules 159

Overview to IPv6 Access Rules 160

Configuration of IPv6 Access Rules 160

Considerations for Designing IPv6 Access Rules 162


Task 1: Define the Source and Destination 163Task 2: Define the Service 164Task 3: Select the Action 164Task 4: Select Rule Options 165Task 5: Restrict the Time When the Rule Is En-forced 165

Using IPv6 Access Rules 166

Adding Comments to Rules 166Configuring Default Settings for Several Rules 166

Using Continue Rules to Set the Protocol 166Rematching Tunneled Packets 167Using Aliases in IPv6 Access Rules 167Validating Rules 167

CHAPTER 16 Inspection Rules 169

Overview to Inspection Rules 170

6

Configuration of Inspection Rules 170

Considerations for Designing Inspection Rules 173


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

Using Inspection Rules 177

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

Rules 177Validating Rules 177

Example of Inspection Rules 178

Eliminating a False Positive 178

CHAPTER 17 Protocol Agents 179

Overview to Protocol Agents 180

Connection Handling 180Protocol Validation 180

Configuration of Protocol Agents 181

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

Using Protocol Agents 182

FTP Agent 184GRE Agent 185H.323 Agent 185HTTP Agents 185ICMP Agent 186IPv4 Agent 186IPv4 Encapsulation Agent 186IPv6 Agent 187IPv6 Encapsulation Agent 187

MSRPC Agent 187NetBIOS Agent 187Oracle Agent 187Remote Shell (RSH) Agent 188Services in Firewall Agent 188SIP Agent 188SMTP Agent 189SSH Agent 189SunRPC Agents 189TCP Proxy Agent 189TFTP Agent 190

Examples of Protocol Agent Use 190

Preventing Active Mode FTP 190Logging URLs Accessed by Internal Users 190

CHAPTER 18 Blacklisting 193

Overview to Blacklisting 194

Risks of Blacklisting 194Whitelisting 194

Configuration of Blacklisting 195

Configuration Workflow 195Task 1: Define Blacklisting in the Access Rules 196Task 2: Define Analyzer-to-Firewall or Analyzer-to-Sensor Connections 196Task 3: Define Inspection Rules in the IPS Policy 196

Using Blacklisting 196

Manual Blacklisting 197Monitoring Blacklisting 197

Examples of Blacklisting 197

Blacklisting Traffic from a Specific IP Address Manually 197

Automatic Blacklisting with IPS 198

LOGS, ALERTS, AND REPORTS

CHAPTER 19 Filters 201

Overview to Filters 202

7

Configuration of Filters 202

Matching Log Data with Filters 203Default Elements 203Configuration Workflow 204

Task 1: Create a New Filter 204Task 2: Select Fields 204Task 3: Select Operations 205Task 4: Add Field Values 207Task 5: Define Handling of Missing Fields 207Task 6: Define A Type for the Filter 209

Using Filters 210

Temporary Filters and Browsing Logs Interactively 210

Examples of Filters 210

Creating a Temporary Filter in the Logs View for Viewing Logs with a Certain IP Address 210

Creating a Filter for Logs from Servers in Internal Network Excluding a Server 211

CHAPTER 20 Log Management 213

Overview to Log Management 214

Logs View 214Log Entries 214Alert Entries 214Audit Entries 215

Configuration of Log Management 215


Task 1: Set Logging Options 218Task 2: Configure Log Pruning 219Task 3: Define Log Tasks 220

Using Log Management 221

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

Examples of Log Management 222

Archiving Old Logs 222

Filtering Out Irrelevant Logs 223

CHAPTER 21 Alert Escalation 225

Overview to Alert Escalation 226

Configuration of Alert Escalation 226

Default Elements 227System Situations 228

Configuration Workflow 228Task 1: Define Custom Alerts 228Task 2: Define Alert Chains 228Task 3: Define Alert Policies 229Task 4: Configure Alert Channels 230

Using Alert Escalation 232

Designing Alert Policies and Alert Chains 232Using a Custom Script for Alert Escalation 233

Example of Alert Escalation 234

Escalating Alerts Based on Responsibilities 234

CHAPTER 22 Reports 237

Overview to Reports 238

Configuration of Reports 239


Task 1: Create a New Report Design 242Task 2: Define the Report Design’s Properties 242Task 3: Select Report Sections 244Task 4: Select Report Items 245

Using Reports 246

Generating Reports 246Using Filters with Reports 247Exporting Reports 247

PDF Report Files 247Tab-Delimited Text Report Files 248Post-Processing Report Files 250

Using the System Report 251

Examples of Reports 251

Creating a New Report Design from Predefined Report Designs 251

Creating a Report of VPN Users 251

8

ADMINISTRATION

CHAPTER 23 Categories 255

Overview to Categories 256

Configuration of Categories 256


Task1: Create Categories 256Task 2: Associate Elements with Categories 256Task 3: Select a Category to filter the displayed el-ements 257

Using Categories 257

Examples of Categories 257

Managing a Large Enterprise 257Combining Categories 258

CHAPTER 24 Incident Cases 259

Overview to Incident Cases 260

Configuration of Incident Cases 260

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

Using Incident Cases 262

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

Example of an Incident Case 262

APPENDICES

APPENDIX A StoneGate IPS Ports 267

APPENDIX B Command Line Tools 271

APPENDIX C Predefined Aliases 285

APPENDIX D Situation Context Parameters 289

APPENDIX E Regular Expression Syntax 295

APPENDIX F Log Field Values 307

APPENDIX G Advanced Log Server Configuration 343

APPENDIX H SNMP Traps and MIBs 349

APPENDIX I TCP/IP Protocol Headers 363

APPENDIX J ASCII Character Codes 367

Legal Information 373

Glossary 389

Index 423

9

10

Introduction

CHAPTER 1 Using StoneGate Documentation

Welcome to StoneGate™ IPS Intrusion Detection and Response System for Intelligent Analysis. This chapter describes how to use this Guide and related documentation. It also provides directions for obtaining technical support, and how to give feedback about the documentation.

The following sections are included:

How to Use This Guide, on page 14 Documentation Available, on page 15 Contact Information, on page 16

13

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 sections, which each include one to several chapters. The first section provides 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 15.

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.

14 Chapter 1: Using StoneGate Documentation

Documentation Avai lableStoneGate IPS 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.

Documentation Available 15

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/ips/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].

16 Chapter 1: Using StoneGate Documentation


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

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

http://www.stonesoft.com

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

mailto:[email protected]





CHAPTER 2 What’s New?

This chapter lists the major changes since the previous release. Most new or enhanced features in the software are listed here. For a full list of changes in the software, read the Release Notes.


New Features in SMC 4.3, on page 18 New Features in IPS 4.3, on page 21

17

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 79.

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.

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.

18 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 61.

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 19

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 61.

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 237.


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 IPS 4.3

IPv6 Inspection SupportStoneGate IPS now supports the inspection of IPv6, the next-generation Internet protocol. There is a new tab in the IPS policy for the IPv6 Access Rules. IPv4 rules remain as they are and also the tab name remains simply “Access Rules”. Inspection Rules also remain as they are, although there are new Situation elements to detect IPv6-specific threats.• For more details, see IPv6 Access Rules, on page 159.

Tunneled Traffic InspectionStoneGate IPS can now inspect IP-in-IP tunneled (cleartext) traffic. The main application is to inspect IPv6 traffic that is tunneled inside IPv4 for transport across IPv4 networks, but other combinations of IP-in-IP tunneling are also supported. If the tunneling involves encryption, the IPS cannot inspect the traffic.• For more details, see Access Rules, on page 145 and IPv6 Access Rules, on

page 159.

New Features in IPS 4.3 21


CHAPTER 3 Introduction to Intrusion Detection and Prevention

This chapter introduces and discusses the underlying security principles of Intrusion Detection Systems (IDS) and Intrusion Prevention Systems (IPS) in general. In this chapter we will discuss what IDS and IPS are, how they are used, what they are capable of, as well as what their possible weaknesses are.


The Role of IDS and IPS, on page 24 IDS and IPS Technologies, on page 24 IDS and IPS Functions, on page 25 Requirements for Modern IDS/IPS, on page 26 IDS/IPS Weaknesses, on page 27

23

The Role of IDS and IPSA firewall is an essential part of network security, but a firewall alone is not a complete security solution. Used together with the firewall, the Intrusion Detection System (IDS) or inline Intrusion Protection System (IPS) completes the security solution. The role of an IDS or IPS is to defend against attacks within the protected network, providing defense in depth. An IDS or IPS provides additional layers of defense by inspecting traffic that has already been allowed into the protected network, to detect and react to attacks.Unlike a firewall, an IDS or IPS allows everything except traffic that it deems to be malicious. An IDS triggers an alarm whenever something defined as anomalous is detected on the monitored network. An IPS can additionally trigger another response, such as blocking unwanted traffic, when malicious traffic is detected.

IDS and IPS TechnologiesGenerally speaking, there are two different classes of IDS: host-based and network-based. In this chapter we will focus on the network-based systems.

Host IDSHost IDS devices, such as Windows Defender, keep track of the system state changes on the hosts, alerting whenever something suspicious is detected. Host IDS devices must be installed on each monitored host and they must be actively kept up-to-date with constantly emerging new threats.

Network IDSNetwork-based IDS devices passively monitor network segments, keeping track of all the traffic going through the network. In StoneGate, the monitoring is performed by sensors, which are dedicated engines that are able to listen to and capture the traffic passing by. The sensors send the data to analyzers, which inspect and correlate the data from several sensors before sending the relevant data to the StoneGate Management Center. IDS is good for monitoring the traffic within network segments.

Intrusion Prevention SystemsThe main difference between a network IDS and a network IPS is that an IPS is located in the traffic path. When the sensor functions in inline mode, it can actively respond to malicious traffic. IPS can respond to malicious traffic by sending an alert, terminating the connection, and/or sending a blacklisting request to a firewall or inline sensor.IPS is good for blocking attacks when you can identify a clear threat path. For example, IPS could be deployed in the path from the Internet to the DMZ segment, from anywhere to an important application server, or from internal networks to the Internet.StoneGate sensors can also be used in hybrid mode. A sensor in hybrid mode operates simultaneously in both IDS and Inline IPS configuration.

24 Chapter 3: Introduction to Intrusion Detection and Prevention

IDS and IPS Functions

Misuse DetectionMisuse detection is based on signatures, also known as fingerprints, of well-known attacks. The monitored traffic is compared to these fingerprints and whenever a matching pattern is found, an alert or another response is triggered. Regular expressions are a powerful and flexible way to define fingerprints. Properly defined, a single regular expression fingerprint may cover several different variations of a given attack, thereby reducing the number of required fingerprints. For more information, see Regular Expression Syntax, on page 295.

Anomaly DetectionAnomaly detection triggers an alarm when something that is not defined to be statistically normal network behavior is detected. The inherent problem with this approach is that it can be very hard to define just what is normal and what is exceptional. Anomaly detection is highly prone to false positives. The concept of statistical anomaly, however, is valid in detecting, for example, denial-of-service (DoS) attacks or any other events that generate unusual volumes of certain type of traffic. In StoneGate IPS, the analyzer uses event correlation to detect these statistical anomalies.

Protocol ValidationProtocol validation checks whether traffic conforms to the protocol standards defined in the relevant Request for Comments (RFC). Any deviation from the defined protocol could be considered malicious. Because a majority of current attacks are based on some sort of a protocol violation, the detection accuracy of this model is quite high. Moreover, this approach is capable of detecting new types of attacks, also known as zero-day attacks when those attacks deviate from a protocol. This type of protocol validation can also take the different states of connections into account, adding the principle of stateful inspection to the IDS/IPS. For example, what is normal—by the protocol standards—for an opening SYN packet of a connection is not necessarily acceptable in an ACK packet within a TCP exchange.As an enhancement to protocol validation, protocol anomaly detection is a technique that is able to take into account the fact that often attacks do not actually violate the protocol specifications as such, but explicitly take advantage of the inaccuracies in the standards. For example, a standard may not specify any limitations for the size of a given protocol field, but still an exceptionally large value in the field constitutes a protocol anomaly. In other words, such an exceptional value quite likely signifies an attempt to exploit a vulnerability. By adding protocol anomaly detection to the arsenal, the IDS/IPS become quite well armed against any attempts to exploit vulnerabilities either by breaching a protocol or by bending the concepts of “normal” protocol behavior.

IDS and IPS Functions 25

Requirements for Modern IDS/IPS

High AvailabilityAvailability of network services is crucial to user satisfaction and employee productivity. Clustering sensors prevents the individual sensors from being bottlenecks or single points of failure. Sensors are clustered when two or more sensor nodes function as a single, virtual entity and enforce identical security policies. Traffic from a failed node is redistributed to the other nodes in the cluster. StoneGate has built-in clustering, so there is no need to set up and maintain additional hardware or software.

PerformanceIPS should let the legitimate traffic through with as little added latency or bandwidth limitation as possible. StoneGate IPS addresses performance issues in several ways, including:• Clustering: The performance of each node in a cluster contributes to the total

throughput and improves performance in environments with high volumes of traffic. • Architecture: StoneGate IPS architecture consists of sensors, which monitor and

optionally react to network traffic, and analyzers, to which the sensors send event data. Sensors only compress and forward relevant event data to the analyzer, reducing the volume of captured network traffic and providing better performance.

• Policy Processing: Traditional fingerprints require the system to review all signatures against the current connection, even if they are not all related. This slows down policy processing. StoneGate IPS uses a combination of protocol-specific, context-sensitive fingerprints and intelligent correlation, allowing it to process possible attacks much faster.

Centralized ManagementAn IDS/IPS needs to be kept up to date 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 IDS/IPS allows the administrator to do multiple tasks using the same interface, making it easier to combine information from different systems.The implementation of corporate-wide, complicated security policies requires a great deal of flexibility from the management system. Company-wide Firewall and IPS policies often co-exist with site-specific rules to provide the required degree of granularity in the implementation of a network security policy.Centralized and efficient management of administrator rights minimizes the possibility of human error. To avoid unintentional confusion or harm, access to IPS configuration and policies must be carefully planned according to the administrators’ responsibilities.


AccuracyThe IDS/IPS should let the legitimate traffic through as efficiently as possible while blocking the clearly harmful traffic. False positives occur when legitimate traffic is incorrectly identified as malicious. The IDS/IPS should minimize the number of false positives, while accurately stopping malicious traffic.Misuse detection is effective in catching well-known and non-modified attacks. The problem with traditional misuse detection is that the number of new threats and required fingerprints can be overwhelming. Furthermore, the fact that known attacks can also be purposefully modified so that the fingerprints no longer match the known pattern, adds another layer of complexity to the picture. Polymorphic exploits that are capable of mutating the attack signature may evade traditional misuse detection.StoneGate IPS combines intelligent event correlation on the analyzer with regular expressions that do not require individual signatures for every variation of an attack. StoneGate IPS also combines inspection technology based on signatures with protocol analysis using regular expressions that can be defined specifically in the IPS policy for context-specific matching to further reduce the number of false alarms.

IDS/IPS Weaknesses

Limitations of Protocol ValidationProtocol validation is prone to false positives. For example, if an IPS starts dropping traffic that deviates from the protocol standards but is still perfectly normal for a given environment, it loses its main benefit and turns into a nuisance. Therefore, the IPS must only be used to drop traffic that can unambiguously be identified as malicious; if there is any doubt whether the traffic actually is malicious or not, instead of blocking it, the IPS must either raise an alarm or do nothing.Protocol validation alone can also result in false negatives when certain types of exploits comply with protocols. Systems that combine signature and anomaly detection are better equipped to catch the whole variety of network exploits.

False PositivesIPS can be used to block traffic but only when there is absolute certainty that the traffic really is malicious. Especially when automatic responses, such as discarding traffic or blacklisting are used, false positives can cause business-critical traffic to be blocked or slowed down, resulting in a self-inflicted denial of service (DoS).Sometimes perfectly legitimate network traffic can trigger an alarm if the fingerprints are not context-sensitive and sufficiently specific. For example, if the system has a fingerprint for a known e-mail based exploit and it tries to match it indiscriminately to any traffic using SMTP (Simple Mail Transfer Protocol), the likelihood of false alarms is very high.

IDS/IPS Weaknesses 27

False NegativesFalse negatives occur when the IDS/IPS fails to react to malicious traffic. There are certain attack techniques that are used to confuse the IDS/PS so that they do not detect attacks. The IDS/IPS must always receive exactly the same traffic as the hosts on the monitored network. Sometimes, however, this may not be the case and the sensor either captures more packets than the target hosts or fewer packets. In either case, the sensor’s view of the traffic on the network is distorted and that can be exploited to get malicious packets to a target without the IDS/IPS detecting them.

Denial of ServiceIDS and IPS may be vulnerable to Denial of Service (DoS) attacks. If the sensors are busy processing a flood of packets, the attacker may succeed in slipping in some malicious traffic without the IDS/IPS being able to detect it.In addition, an IDS/IPS configured with responses such as connection resetting or IP address blacklisting could be turned into an effective DoS tool by an attacker. If such responses are not carefully considered, an attacker could generate malicious traffic with a spoofed IP address that actually belongs to a legitimate network resource and force a DoS condition against that network, using the IDS/IPS as an attack tool.


CHAPTER 4 StoneGate IPS System Architecture

This chapter gives you an overview of the StoneGate IPS system architecture. It describes the main components of the system, their interoperation, and the main features of each component.


StoneGate Security Platform Overview, on page 30 StoneGate Components, on page 32 Traffic Inspection Methods, on page 37 Keeping StoneGate IPS Up-to-Date, on page 40.

29

StoneGate Security Platform OverviewStoneGate IPS is a distributed intrusion detection system that can actively respond to the detected intrusion attempts. The system architecture is especially well-suited to complex and distributed network environments.

Illustration 4.1 Unified StoneGate Security Platform

StoneGate IPS is a part of the StoneGate Security Platform that also provides clustered high availability firewalls and Virtual Private Networking (VPNs). The whole system can be managed through a single user interface. Interoperation between the system includes common remote upgrades, unified logging and alerting system, and extensive reporting features, to mention a few.StoneGate IPS aims at accuracy, manageability, scalability, and high availability as described below.

AccuracyThe primary function of a network intrusion detection and response system is to detect anomalous events in the network traffic and respond to them as needed. This requires effective detection of many kinds of possible threats. Another major concern is the number of false alarms, as the system administrator does not want to go through thousands of alerts to ensure that none of them is an actual intrusion.To increase the number of detected intrusion attempts while still minimizing the number of false alarms, StoneGate IPS provides multiple detection methods that complement each other. This way, threats can be thwarted more quickly and less manual work is wasted on analyzing false alarms.Accurate intrusion detection allows quick response to incidents, as you can use active response mechanisms based on the intrusion detection. StoneGate IPS provides a wide range of configurable, automatic response mechanisms ranging from sending out alerts to administrators to stopping traffic from the offending host.

30 Chapter 4: StoneGate IPS System Architecture

ManageabilitySecurity solutions and technologies are used for implementing corporate security policies. Therefore, it is necessary that security solutions are flexible and comprehensive to allow efficient enforcement of the corporate security policy. StoneGate IPS provides centralized management using the StoneGate Management Center, a high degree of configurability, integration with the StoneGate Firewall/VPN system, and data analysis tools.The Sensors and Analyzers are the traffic inspection engines of StoneGate IPS. They use an integrated and hardened Linux operating system, thus reducing the complexity of system upgrades. As the Sensors and Analyzer machines can be upgraded remotely from the Management Client.

ScalabilityIt is important that intrusion detection can keep up with the high speed of network traffic as intrusion attempts must also be detected during traffic peaks. Therefore, it is crucial that the system is scalable and able to handle traffic even in the gigabit network environments.The possibility to cluster StoneGate IPS Sensors means that new Sensor nodes can be added flexibly as traffic volumes grow. Clustering of StoneGate IPS Sensor nodes also contributes to better performance by balancing the load intelligently between the Sensors. Additionally, the distributed architecture benefits StoneGate IPS system scalability as the Sensors, Analyzers, and the StoneGate Management Center components can be located on separate machines and in different networks, even in different countries and continents.With Stonesoft’s proven clustering technology, also used in the StoneGate Firewall/VPN product, the sensor nodes can be scaled from a single node to a powerful 16-node cluster.

Built-in High AvailabilityThe clustering technologies of StoneGate IPS prevent a system component from being a single point of failure. The StoneGate IPS Sensor nodes are clustered as a single virtual entity, where the performance of each node contributes to the total throughput. This eliminates bottlenecks and provides a fault tolerant and reliable system.High availability means that traffic from a failed Sensor node can be switched over to the other remaining nodes transparently. This also allows for online maintenance of Sensor nodes without disturbing the system’s operation. Additionally, it is possible to define a backup Analyzer, which is activated if the primary Analyzer fails.High availability measures are also available for the StoneGate Management Center allowing you to keep configuring and monitoring your system even when disaster strikes.

StoneGate Security Platform Overview 31

StoneGate ComponentsStoneGate IPS is an integral part of the StoneGate Security Platform that provides clustered high availability firewalls, advanced Virtual Private Networking (VPNs), and the intrusion detection and response features. The whole system can be managed through a single user interface. The StoneGate components are illustrated in Illustration 4.2.

Illustration 4.2 StoneGate Security Platform Components

The StoneGate Management Center can manage both the StoneGate Firewall/VPN and StoneGate IPS products. 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

Sensor and Analyzer engines (one or more of each)

The StoneGate IPS Sensors and Analyzers provide intrusion detection and prevention measures:- Sensors are used for picking up network traffic and inspecting it for misuses and anomalies. Inline installation and transparent access control operating mode allow the Sensor to stop any traffic.- Analyzer correlates, processes, and inspects the event information received from the Sensors.


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 location of the Sensors and the Analyzers.The Sensors and Analyzers work independently according to their installed configuration, so if the connections to the Management Server or the Log Server are cut, the IPS system continues its operation.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. The Sensor and Analyzer engines feature an integrated operating system, specifically designed to be secure and easily manageable. There is no need for separate operating system patches or upgrades; all software on the engines is upgraded during the IPS 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 analyzers, 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 log data for 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 browsing through the Monitoring Server. It provides no other access.

TABLE 4.1 StoneGate System Components



StoneGate Management CenterThe StoneGate Management Center is composed of the following components:• Management Server• Management Clients• Log Server• (Optionally) Monitoring Server and Monitoring Clients.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 communicates that information to the firewall engines. In turn, monitoring and log data from the firewalls is filtered through the Management Server and the Log Server and sent to the Management Client for display.

Management ServerThe Management Server is the central point of administration: it stores all configuration information, controls the Sensors and Analyzers, and runs the monitoring system that handles performance statistics and status information for each individual Sensor and Analyzer.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. If the Management Server data is lost, the engines continue to operate, but all of the configuration information must be manually reproduced on the Management Server.Optionally, one or more secondary Management Servers can be installed (special license required) to ensure the configuration information is backed up. A secondary Management Server allows controlling the sensors and analyzers without delays and without loss of configuration information if the primary Management Server is physically damaged, loses power, or becomes otherwise unusable without the need to manually transfer the information through backup files.

Management ClientThe Management Client is the tool for all day-to-day configuration and management tasks, including:• Configuring Sensors and Analyzers.• Designing and modifying IPS policies.• Monitoring security events and system operation.• Upgrading the Sensors and the Analyzers remotely.Management Clients can be deployed anywhere in the network. The administrators use the Management Clients to connect to the Management Server for all system monitoring and configuration tasks. Efficient permissions checking ensure several administrators can be logged in at the same time without accidentally overriding each others work.


Administrators can use the same Management Client to manage and monitor both the StoneGate IPS and the StoneGate Firewall/VPN products, and to monitor the StoneGate SSL VPN. Thus, the entire network security infrastructure can be managed via the same user interface with shared element definitions.StoneGate Management Center is also well-suited for the special requirements of very large systems, such as those of managed service providers (MSPs) who offer networking and network security services to several customers. By utilizing the category filtering feature, the administrators can easily control issues relating to each site separately by quickly filtering all unrelated elements out of their own view. Customers can be given limited access to just their environment’s logs through the separate Monitoring Client, and you can schedule periodic, customizable reports to be automatically e-mailed to the customer to keep them up-to-date on their network activity.

Log ServerLog Servers manage and store the log and alert entries, and they provide this information directly to the Management Clients as requested by the administrator viewing the logs, or through the Monitoring Server if the Monitoring Client is used. The log and alert entries can be queried, sorted, and exported flexibly with predefined and your own custom filters. Log entries can also be pruned to dismiss some of the log entries at the Log Server. For more information on log data management, see Chapter 20, Log Management.Log and Alert entries from StoneGate IPS, StoneGate Firewall/VPN engines, and StoneGate SSL VPN can be handled by the same Log Server. Multiple Log Servers may be deployed if there are several components in the system. This is particularly useful in geographically distributed systems, and it improves the performance and robustness of the logging system. However, individual nodes within a cluster must log to the same Log Server.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 Log Server 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 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 displayed logs can be further restricted with filtering.


SensorsA StoneGate IPS Sensor examines packets and connections according to the IPS policy. The Sensor sends its event data to an Analyzer, which processes the data further.Up to 16 Sensor nodes can be clustered together. The cluster functions as a single virtual sensor, providing high availability and load balancing which give reliability and high performance to the system. Sensors can also be clustered in an Inline Serial cluster, so that traffic passes through the sensors. Single Sensors may be deployed as well, although this is reasonable mainly in low-volume network segments.Sensors can be installed in three basic ways: IDS Installation, IPS Installation, and Transparent Access Control mode. All of these can both be used simultaneously in the same Sensor.

IDS InstallationIn the first setup, the Sensors work as an IDS (intrusion detection system). Sensors capture and inspect all traffic in the connected network segment, but do not, by default, interrupt the flow of traffic in any way. They just listen to all traffic within their network segment, and you can make all decisions regarding actions to take yourself. If you so choose, the Sensors can respond to selected threats even in this setup by sending TCP resets directly to the communicating parties or by giving a blacklisting command to a StoneGate firewall or some sensor that is installed inline or in transparent access control mode.

IPS InstallationIn the second setup, Sensors work as an IPS (intrusion protection system). Sensors are installed inline, so that all traffic that is to be inspected flows through the Sensor. In this setup, the Sensor itself can also be used to automatically block selected traffic according to how you configure it. Fail-open network cards (standard on some StoneGate appliances) can be used to ensure traffic flow is not disrupted when the Sensor is offline. Sensor Clusters do not support inline operation.

Transparent Access Control ModeInline sensors in transparent access control mode provide transparent access control and logging for any Ethernet traffic (layer 2) in addition to the IDS and IPS capabilities for IP (Internet Protocol) traffic.

AnalyzerThe StoneGate IPS analyzer correlates, processes, and analyses the event information received from the Sensors. A single Sensor may see only parts of a possible intrusion attempt, so it is the role of the Analyzer to gather an overall picture of the connections in your network and to analyze them for possible threats. Analyzers detect groups and sequences of events, compress excessive similar events, and so


on. The Analyzers send the processed events to the Log Server for logging and alerting.It is also possible to have the analyzer with a sensor in the same device. A combined sensor-analyzer works generally in the same way as separate components, but it is not possible to send event data from other sensors to the analyzer component in a combined sensor-analyzer. Combined sensor-analyzers are especially well-suited as one-box IPS solutions for isolated, small network environments, such as remote branch offices.Optionally, one or more secondary Analyzers can be installed to ensure that event information from the sensors is processed. A secondary Analyzer allows event data to be processed and send to the Log Server if the primary Analyzer is physically damaged, loses power, or becomes otherwise unusable.

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 provides 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 that authenticate the components during communication.Certificates are always created with an expiration date. StoneGate internal certificates are, by default, valid for three years. The engine certificates are automatically renewed before they expire, although this can be disabled in the properties of the engine.

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.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 a restricted period of time. Purchased licenses do not expire.

Traffic Inspection MethodsStoneGate IPS uses two primary intrusion detection methods: misuse detection and anomaly detection. These two methods complement each other, allowing efficient intrusion detection while at the same time minimizing the number of false positives.


Illustration 4.3 StoneGate IPS Traffic Inspection

Illustration 4.3 shows the traffic inspection process in StoneGate IPS. First, the Sensor inspects the network traffic for possible attacks or other anomalies. Then, the Sensor informs the Analyzer on the events of interest. Finally, the Analyzer sends the events to the StoneGate Management Center for logging and alerting. The different StoneGate IPS inspection methods are described below.

Misuse DetectionKnown attacks are detected in StoneGate IPS by using context-sensitive fingerprinting defined with regular expressions. Regular expressions allow the necessary flexibility in the definition, whereas context sensitivity decreases the number of false positives as the pattern matching is made in the correct context. As an example of context sensitivity, an attack that uses an HTTP connection has a certain pattern that can be used to raise an alert whenever encountered in HTTP traffic, but a match on that pattern will not generate a false alarm if the match is found in an e-mail message header in SMTP.Stonesoft provides ready-made Situation elements for detecting known exploits in dynamic update packages. You can select which ones are used for matching which type of traffic. You can also create customized Situation elements for detecting patterns in traffic.

Anomaly Detection With Protocol AnalysisWhile fingerprinting accurately detects known attacks, it does not detect attacks that are not yet known. StoneGate IPS provides two types of anomaly detection to complement fingerprinting: protocol analysis and statistical anomaly detection. Anomaly detection also helps detecting new and unknown attacks. Protocol analysis is important for intrusion detection as many of the attacks rely on misusing protocols. StoneGate IPS protocol analysis identifies violations in network communications, such as unexpected data, wrong connection states, and additional or invalid characters. StoneGate IPS is capable of analyzing the traffic on the different


protocol layers, from the link layer up to the application layer, and notifies the administrator of any traffic that does not comply with the defined configuration.

Anomaly Detection With StatisticsStoneGate IPS incorporates ways to detect anomalous traffic based on statistics. Traffic statistics provide information for detecting anomalous events such as unknown attacks, slow scans, unusual number of connections and so on. StoneGate IPS can collect statistical data for inspection with two different types of statistics:• connection statistics that use a counter for detecting certain types of connections.

When the counter hits a user-defined limit, a specified response or alert is triggered.

• timeslot statistics that collect connection data over a specified time window. If a user-defined statistic limit is exceeded within that time interval, a specified response or alert is triggered.

Event Correlation in the AnalyzerThe StoneGate IPS Analyzer offers further analysis on the event information. The Analyzer correlates and processes event information received from the Sensors. For example, the Analyzer can be configured to inspect the events for certain sequences or sets of occurrences that might indicate an intrusion attempt.

Response MechanismsWhen detecting anomalous traffic, StoneGate IPS can be configured to trigger a response for the event in addition to logging it. There are several response mechanisms available: different alerting channels, traffic recording, TCP connection termination, traffic blacklisting with a StoneGate Firewall, and with inline IPS and IPS in transparent access control mode, traffic blocking.

Note – Storing or viewing the packets’ payload may be illegal in some jurisdictions due to laws related to the privacy of communications.

As the least invasive response to an event, the Log Server is used for informing the administrators, which can be done through multiple, extensively configurable alert channels including e-mail, mobile phone text messaging (SMS), and SNMP. Connection recording can be configured to store the connection information with the full packet headers and data payload for further analysis.There are also several more active responses available:• A TCP connection can be terminated by sending a TCP Reset to both communicating

hosts.• Connection blacklisting can also be used to stop selected traffic for a certain time

period (requires a StoneGate firewall).• Inline Sensors and Sensors in transparent access control mode can also actively

block unwanted traffic attempting to pass through the inline interfaces.


Keeping StoneGate IPS Up-to-DateStoneGate IPS provides automatic update management to keep up with the latest security issues. Dynamic updates provide the latest elements that add to the detection capabilities of the system, along with possible updates to other elements and pre-defined inspection policies. Stonesoft provides the dynamic updates as file packages authenticated with digital signatures. The Management Server can be configured to check for, download, and activate these dynamic updates automatically, or you can manually handle all or some of these activities.Software upgrade of the StoneGate IPS Sensors and Analyzers can also be downloaded automatically and then installed remotely using the Management Client. This allows easy deployment of the latest software versions even in large, geographically distributed network environments.Upgrading the StoneGate Management Center does not interfere with the operation of the Sensors and the Analyzers. When a Log Server is temporarily unavailable during the upgrade, Sensors and Analyzers store the event information locally until the Log Server becomes available again, or (after a delay) send it to a backup Log Server, if you have one. Temporarily stored events are automatically forwarded when the Log Server returns online. The Sensors and Analyzers do not need a connection to the Management Server for their normal operation, so they continue to process traffic indefinitely with their currently installed configuration whether the Management Server is available or not.


CHAPTER 5 StoneGate IPS Deployment

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


Deployment Overview, on page 42 Sensor and Analyzer Deployment, on page 43 Management Center Deployment, on page 52 Example Deployment Scenario, on page 54.

41

Deployment OverviewStoneGate IPS system consists of Sensors, Analyzers, 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 to five optional secondary Management Servers. The system components are listed in Table 5.1.

Illustration 5.1 shows the general principle for positioning the different StoneGate IPS and StoneGate Management Center components.

TABLE 5.1 System Components


SensorPicks up network traffic, inspects it, and creates event data for further processing by the Analyzer. If the sensor has inline interfaces, it can also actively filter traffic.

AnalyzerFurther processes, correlates, and inspects event data received from the Sensors.

Management Server

Stores the configuration data and manages the StoneGate IPS system.

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

Management Client

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

42 Chapter 5: StoneGate IPS Deployment

Illustration 5.1 Positioning StoneGate IPS Components

Sensor and Analyzer DeploymentThe StoneGate IPS Sensors and Analyzers can be installed as follows:• As a sensor cluster that consists of 2 to 16 engine machines installed as cluster

nodes.• As a single-node sensor.• As a single-node analyzer.• As a combined sensor and analyzer on a single machine.The sensors and analyzers 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/ips/Certified_Servers/index.html.The general Sensor and Analyzer deployment steps are as follows:1. Determine the critical assets to be protected and the potential attack paths.2. Determine the most suitable locations for detecting and responding to attack

attempts in order to protect the assets.3. Determine the traffic volume that needs to be inspected on each location.4. Decide whether the Sensors are placed inline and which traffic must go through

the Inline interface(s).5. Position Sensors to inspect the traffic in the selected locations.6. Position Analyzers on each site to process the events from Sensors.Sensor and Analyzer deployment considerations are described next.


http://www.stonesoft.com/en/products_and_solutions/products/ips/Certified_Servers/index.html



Positioning SensorsEach Sensor can inspect the network traffic of one or more network segments. In a non-inline configuration, traffic is captured through port mirroring (switch SPAN ports) or through special-purpose wire TAP devices. Hubs can also be used, although this is not recommended for production environments because of network performance reasons.In inline mode and Transparent Access Control mode, the Sensor is connected as a “smart cable” between two network devices, such as routers. This requires setting up an inline interface with two ports. Some StoneGate appliances have dedicated inline ports with fail-open operation. In an Inline interface, traffic comes in through one port, is inspected, and is then sent onwards through the other port, if allowed to proceed. The inline operation makes it possible to actively stop traffic at the sensor.The same sensor can have both Inline and Capture interfaces. For example, a sensor can be deployed inline between two networks, so that malicious traffic can be stopped from traversing from one network to the other. Additionally, the sensor could use Capture interfaces to pick up traffic within the internal networks to look for harmful traffic between the hosts there.Sensors inspect the network traffic according to the IPS policy and send the relevant event information to the analyzer. As only the event data of the traffic inspection is forwarded to the analyzer, the event data volume is significantly smaller than the volume of the captured network traffic.Sensors can be clustered up to 16 nodes where the cluster functions as a single high-performance sensor. Clustering provides high availability and load balancing that results in reliability and high performance of the system. This way, a single point of failure is avoided as the Sensor cluster continues operation even if some of the Sensor nodes fail or are taken offline for maintenance. Sensors with inline interfaces can optionally be clustered in an Inline Serial Cluster configuration to improve throughput. When Inline Serial Clustering is used, only one sensor inspects the connection. The other sensors only pass the traffic through their interfaces.Sensor clusters can handle gigabit network traffic with load balancing. Single sensors and combined sensor-analyzers can be used for lower-volume network traffic. They do not provide high availability or load balancing. Illustration 5.2 illustrates different options for the sensor deployment, differing in the volume and type of network traffic as well as on the security needs. These different network environments are discussed below.


Illustration 5.2 Network Segments for Positioning the Sensors

Internal NetworkInternal 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, although traffic within the network is often not secured.Traffic coming in and going out of internal networks is readily available for the sensor located just inside the firewall perimeter. On this location, most of the traffic is controlled by the firewall and therefore less diverse than the traffic within the internal networks.A sensor in a local area network gets a detailed view of the traffic on that specific network segment. For example, it is possible to inspect the LAN traffic between desktop machines and servers, the applications and protocols used in the network, and so on. Access rules in sensors can also be used for basic traffic filtering between


internal networks, if the internal networks have similar security levels and there is no need for more advanced firewall features, such as authentication.

TABLE 5.2 Internal Network Considerations for Sensors

Description Implications on Sensors

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. Traffic inspection adds to the security provided by the firewalls that control the traffic in and out of the network.

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. Sensor policies can be fine-tuned based on the communicating hosts and applications for improved inspection accuracy.

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). This must be taken into account when designing traffic inspection and analyzing the detected events.

Traffic volume

High volume traffic up to Gbit/s LAN throughputs.

High volume traffic is best handled with sensor cluster load balancing and high availability. If inline interfaces are needed, this must be taken into consideration when selecting the hardware (high-performance with fail-open network cards to ensure traffic is not stopped when sensor is offline), since clustering is not available.


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 control the inbound and outbound traffic on the network perimeter, and the traffic may be encrypted.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. We recommend placing Sensors in DMZs, especially to protect the publicly available hosts and services from potential threats.

Traffic type

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

Inspection of the diverse traffic can be fine-tuned by configuring different inspection in the IPS policy based on the communicating hosts and/or applications.The Access rules that control traffic going in and out of the network must be taken into account when designing inspection for the traffic that crosses the network boundary.

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.

TABLE 5.3 DMZ Considerations for Sensors


Main purpose

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

DMZ networks are often more strict with the network communications than the internal networks. Traffic inspection adds to the security provided by the firewalls that control the traffic in and out of the network.

TABLE 5.2 Internal Network Considerations for Sensors (Continued)



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. IPS policies can be fine-tuned based on the communicating hosts and applications for improved inspection accuracy.

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 Sensor policies for traffic inspection.

Traffic volume

As DMZs often provide services for public use, the Internet bandwidth sets limitations to the traffic volume in/out of the network.Traffic volume within the network, and to internal network clients and back-end servers, can be up to Gbit/s LAN throughputs.

High volume traffic is best handled with Sensor cluster load balancing and high availability. If inline interfaces are needed, this must be taken into consideration when selecting the hardware (high-performance with fail-open network cards to ensure traffic is not stopped when sensor is offline), since clustering is not available.

Traffic type

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

Inspection of the rather uniform traffic can be further controlled by configuring different inspection in the IPS policy based on different communicating hosts and applications.The firewall policy that controls traffic going in and out of the network must be taken into account when designing inspection for the traffic that crosses the network boundary.

TABLE 5.3 DMZ Considerations for Sensors (Continued)



External NetworkExternal networks provide the infrastructure to connect the “trusted” internal networks to the “untrusted” public networks. Only a limited number of hosts are located in this network, including firewalls and possibly some secured hosts that need to 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.A Sensor can be located in the external network. Here, the Sensor also receives the traffic that is filtered out or blocked by a firewall, thus indicating events outside of the company’s protected network environment. Often, there are also encrypted connections in and out of the company’s network, such as VPNs, for which the data payload cannot be inspected in detail on this network.

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.

TABLE 5.4 External Network Considerations for Sensors


Main purpose

Connectivity between the protected and public networks.

External networks are often rather open to connections from the public network. A Sensor in this network serves mainly research purposes indicating events that take place outside of the corporate security perimeter.

Hosts

Often only hosts that need to 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. Although these systems are usually highly secured, the traffic can be inspected for potential attacks and other suspicious attempts originating from the public network.

TABLE 5.3 DMZ Considerations for Sensors (Continued)



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 Sensor policies for traffic inspection.

Traffic volume

The bandwidth to the public network sets limitations to the traffic volume in/out of the network.

High volume traffic is best handled with Sensor cluster load balancing and high availability. Sensors in the external network typically have only capture interfaces. If inline interfaces are needed, this must be taken into consideration when selecting the hardware (high-performance with fail-open network cards to ensure traffic is not stopped when sensor is offline), since clustering is not available.

Traffic type

Traffic going in and out through the firewall is often rather uniform and possibly encrypted (e.g., in VPNs). However, interfering connection attempts and attacks can reach this network as there is only limited filtering between the external and the public networks.

Sensor in the external network sees all the traffic that traverses through the router from the public network, even the traffic that is rejected by the firewall for entering the protected networks. This allows inspecting the traffic as it is seen outside of the corporate security perimeter.However, much of the legitimate traffic cannot be fully inspected because it is often encrypted (e.g., in VPNs), NATed, or otherwise modified.

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 and 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. Traffic inspection provides information mainly on the attack attempts originating from the public network.

TABLE 5.4 External Network Considerations for Sensors (Continued)



Positioning AnalyzersThe StoneGate IPS sensors and analyzers cooperate closely to inspect the captured network traffic. Thus, we recommend positioning the analyzer on the same geographical site as the sensors that send the event data. The sensors capture the raw network traffic, perform pattern matching on it. The analyzer then compresses and correlates the event data according to the correlation rules in the IPS policy and finally sends it to the Log Server.Each analyzer can receive data from one or more single sensors or sensor clusters. In a combined sensor-analyzer, the analyzer is located on the same machine as the sensor. However, note that a combined sensor-analyzer cannot receive events from other sensors.

StoneGate IPS Connections and BandwidthTo 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 IPS System Architecture, on page 29. Event data transfers are the only connections that may require more than minimal bandwidth. The Management Center communications require only minimal bandwidth (less than 1 Kbit/s on the average).The event data volume varies considerably based on the network environment, different types of traffic, the sensor location, the rules in the policy, and many other factors. As a rule of thumb, an average size of a StoneGate IPS event entry is approximately 750 bytes. An analyzer with a typical configuration is able to compress the event data volume down to 1/10th or even 1/20th of the event volume received from the sensors. As always, efficient traffic inspection requires fine-tuning to better match the characteristics of any specific network environment. Table 5.5 lists some rough estimates on the average transferred event data in a sensor-to-analyzer connection and an analyzer-to-Log Server connection based on different levels of traffic on the sensor.


Caution – The event data transfer rates may differ considerably in different networks with different types of traffic. Transfer rates may also differ considerably during peak traffic load.

Some examples for the traffic volumes are provided in Example Deployment Scenario, on page 54.In addition to alerting and logging events, the traffic itself can be recorded on specific events detected by the sensor. The recorded traffic is stored in files and transferred from the sensor 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 primary Management Server and optionally a secondary Management Server, Log Servers, and Management Clients. Sensors and analyzers are managed through the Management Server, so the Management Client does not ever connect directly to the sensors or analyzers. Communications between the StoneGate IPS system components are described in StoneGate IPS System Architecture, on page 29.It is possible to run the Management Server and the Log Server on the same machine for small environments. For larger environments, the components can be distributed geographically to different locations, and several Log Servers can be added as needed. The Management Clients can be installed where needed. The Management

TABLE 5.5 Some Estimated Average Rates of Event Data Transfer with the IPS System Policy

Captured Traffic

Average Event Transfer from Sensor to Analyzer

Average Event Transfer from Analyzer to Log Server

less than 2 Mbits/s

From ~1 Kbit/s for a protected office network to ~15 Kbit/s for an open Internet network.

Usually less than 1 Kbit/s.

2 – 10 Mbit/s

From less than 10 Kbit/s for a protected office network to ~60 Kbit/s for an open Internet network.

From less than 1 Kbit/s for a protected office network to less than 5 Kbit/s for an open Internet network.

10 – 100 Mbit/s



100 – 1000 Mbit/s




Clients connect to the Management Server for configuring and monitoring the 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/products/Intel_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.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 the StoneGate IPS system (as well as the firewall system, if you have one). Is is usually positioned on a central site at the corporate headquarters or data center, from where it can reach all the sensors, analyzers, 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.We recommend using the same Management Server 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 event data received from the sensors and analyzers. As the event 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 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.

Management Center Deployment 53

http://www.stonesoft.com/products/Intel_Servers/

http://www.stonesoft.com/products/Intel_Servers/

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 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 and the individual Management Client installations are then automatically upgraded without user intervention.

Example Deployment ScenarioThis section explains a typical StoneGate IPS deployment outlined in Illustration 5.3.

Illustration 5.3 StoneGate IPS Deployment Scenario


This scenario consists of five geographically separate sites, and each has one or more network segments. The sites are described in Table 5.6.

The StoneGate Management Center components are deployed as follows:• Management Server is located at the corporate headquarters in London. The same

server manages the StoneGate Firewall/VPN engines in the company.• Log Server located in London is used also for logging from Frankfurt, Paris and

Rome as these sites do not generate so much log data that they would need a dedicated local server. The Boston site has its own Log Server, as it is more efficient to store the higher volume of log data locally than to transfer the data to the Log Server in London.

TABLE 5.6 Network Sites in the Scenario

Site Description Traffic Volume

London: headquarters

The corporate headquarters in London is the largest network environment with a large number of servers and services.The corporate administrators are positioned primarily on this site.

The Sensors handle over 100 Mbit/s of traffic on the average.

Boston: large branch office

The Boston branch office is the second largest network environment with a moderate number of servers and services.This site has its own local administrators in addition to the corporate staff located at the headquarters.

The Sensors handle over 100 Mbit/s of traffic on the average.

Frankfurt: large branch office

The Frankfurt branch office is not as large as the Boston branch office. There are some servers and services on this site.This site has a few local administrators in addition to the corporate staff located at the headquarters.

The Sensors handle 10 – 100 Mbit/s of traffic on the average.

Paris: small branch office

The Paris branch office is small with only few local servers or services.The StoneGate IPS system is managed remotely from the headquarters as only minimal administrative staff is positioned here.

The Sensor handle less than 10 Mbit/s of traffic on the average.

Rome: small branch office

The Rome branch office is small with only few local servers or services.The StoneGate IPS system is managed remotely from the headquarters as only minimal administrative staff is positioned here.

The Sensor handle less than 10 Mbit/s of traffic on the average.


• Management Clients are used by the corporate administrators in London to manage all the system components throughout the company. The administrators in Boston and Frankfurt operate only their local Sensors and Analyzers.

Sensors are positioned in the different network segments of each site. The Sensors are deployed so that the network traffic in all network segments can be monitored. Each site has an Analyzer to correlate and compress the event data received from the local Sensors. The Analyzers on the smaller sites then send the event data to the headquarters’ Log Server. Table 5.7 summarizes the key deployment guidelines for this scenario.

TABLE 5.7 Guidelines for StoneGate IPS Deployment

System Component Guidelines Example Scenario

Management Server

Position on a central site where the server can access all the Sensors, Analyzers, Log Servers, and the StoneGate Firewall/VPNs (if any). Also, the Management Clients need a network access to the Management Server.

Located at the corporate headquarters in London for centralized administrative access.

Log Servers

Centralize the Log Servers at key locations and/or locally on sites as needed based on log data volume, administrative responsibilities, etc.

Located centrally at the headquarters in London for most of the Sensors, Analyzers and StoneGate Firewall/VPNs in the company. A separate Log Server is positioned in Boston because of large event data volume.

Management Clients

Management Clients can be located where the administrators use the system, as long as there is a network access from the Management Client to the Management Server and the Log Servers used.

StoneGate IPS administrators access the system at the headquarters in London and locally in Boston and Frankfurt. StoneGate IPS engines in Paris and Rome are managed remotely from the headquarters.


Sensors

Position Sensors at least to the critical network segments and use Sensor clusters for load balancing and high availability.

Sensor clusters are deployed to inspect traffic on most of the network segments.Single Sensors and combined Sensor-Analyzers are used in smaller network segments.The same Sensors are used both inline to inspect traffic into each network and to capture traffic within the internal network.

AnalyzersPosition an Analyzer on the same site with the Sensor(s).

Analyzers are deployed to correlate and compress the event data already locally on the site before sending the data through slower network connections.

TABLE 5.7 Guidelines for StoneGate IPS Deployment (Continued)

System Component Guidelines Example Scenario



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 62 General Tools, on page 62 System Status View, on page 66 Overview, on page 69 Status Icons and Colors, on page 70 Configuration View, on page 73 Logs View, on page 74 Policy Editing View, on page 77

61

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.

Switch to Configuration view.

Shortcuts to policies.

Switch to System Status view.

Switch to Logs view.

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

Shortcuts to Overviews.

62 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 63

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 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.

Create new bookmarks.

Open a panel for viewing and organizing bookmarks.

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 65

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 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. 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 68).

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 and 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 67

Illustration 6.10 Engine Status Information

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

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, for example, element state information, tables consisting of traffic and counter data, reports, and different types of charts (pie/curve/bar).

Illustration 6.12 Example Overview

The Sections are placed into a Grid, the resolution of which is freely user-definable.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 sections

You 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.You can adjust the size of the Sections, by dragging the Section by its outer edge with the mouse pointer and moving it to change the Section size.

Toolbar

Grid

Section

Overview 69

You can also change the order of the Sections in a Grid, by dragging and dropping them into new positions.You can select an Overview by clicking the Overviews button in the toolbar and selecting from the menu that opens the Overview you want to see.

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 follows 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.

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

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.

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.

Status Icons and Colors 71

The VPN status icons alert you to problems in VPNs.

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.

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.

White icon, not configured

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

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.

TABLE 6.3 NetLink Status Icons (Continued)

Color Status Description


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

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

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.

TABLE 6.5 Connectivity Status (Continued)

Color Status Explanation

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.

Configuration View 73

Logs ViewThe Logs view allows you to either view 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

Field previewFields panelTimeline for browsing

Log entry table


Illustration 6.15 Logs Toolbar

The Logs view, by default, shows logs stored on 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 toolbar buttons, keyboard, or the Timeline.• If you switch to the Sorting mode, you can sort the logs within the selected time

range according to any of the column in the table.• If you switch to 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.

The time range and other criteria for filtering the log display are set in the Query panel.

Acknowledge one alert (stops alert escalation)

Current Logs mode on/off

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

Logs View 75

Illustration 6.16 Query Panel

You can also generate simple reports of the log data displayed in the Logs view. Click the Statistics button in the toolbar and select which statistical data you want to include in the report.

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.

General type for logs to view.

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.


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 IPS Policy

The policy view has four tabs for the different types of rules you can add to the policy: Ethernet Rules, Access Rules, IPv6 Access Rules, and Inspection 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. With policy-specific tools you can validate the rules you have created, compare the policy you have modified to the engine’s current policy, see the rules that have been

Rule table.

Policy toolbar.

Save policy and install it on engine.

Save changes. Policy-specific tools

Policy Editing View 77

inherited from higher-level templates, see the network details, and search for any specific rules.

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.


CHAPTER 7 Administrator Accounts

Administrator accounts define administrator rights within the Management Client.


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

79

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.

80 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 StoneGate Elements All elements in StoneGate.


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.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

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 Simple ElementsAll elements except Firewalls, SOHO Firewalls, IPS engines, Firewall Policies, IPS Policies, and Incident Cases.

TABLE 7.2 Predefined Access Control Lists (Continued)

Access Control List Description


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:

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.

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.


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 86).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 84. 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

TABLE 7.4 Permission Levels for Administrators

Permission Level Description

Unrestricted Permissions (Superuser)

Right to manage all elements.

Restricted PermissionsAccess only to selected elements. The administrator’s rights depend on the permissions defined in the Administrator Role(s).


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 201 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.

Examples of Administrator Accounts 87

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.


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 IPS policies.


Introduction to Network Elements and Services, on page 90 Network Element Types, on page 90 StoneGate IPS Elements, on page 93 Services, on page 94

89

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 IPS policy, the rule matches TCP traffic on port 80. The Service also refers to a Protocol element for HTTP, which ensures that the traffic is inspected according to the standards of HTTP and TCP when the inspection process proceeds to the inspection rules.Network elements and services are managed in the Configuration view.

Note – The protocols and services are used for traffic matching purposes. They contain no information on traffic inspection.

Network Element TypesMost network elements can be defined by simply giving them a unique, descriptive name and an IP address in their Properties dialog. You can also add descriptive comments to help identifying elements or their purpose.For certain elements (hosts, routers, and servers) it is possible to define secondary IP addresses. 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 IPS engine 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.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 285.

90 Chapter 8: Network Elements and Services

Expression ElementsExpression is a special element that allows network elements to be combined with logical operators to create simple objects that can represent complex sets of network resources. 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 representing the StoneGate firewall engines administered by the StoneGate Management Center. For more information, see the Firewall/VPN Reference Guide and the online help system of the Management Client.

SOHO Firewall ElementsSOHO Firewalls represent SOHO Firewall engines administered by the StoneGate Management Center. For more information, see the Firewall/VPN Reference Guide and the online help system of the Management Client.

Group ElementsGroup is a combined element that allows other network elements to be collected together into a single object for convenience. The Group properties contain an embedded resource view from which elements can be added to the Group.

Host ElementsThe Host element can be used to represent any single IP address. Typically, it represents a single PC or Server such as a personal computer or a server.

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.

Network Element Types 91

IPS ElementsThe IPS network elements are the elements that represent your physical IPS engines. For more information, see IPS Elements, on page 92.

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. Network elements make rule creation easier, as rules that apply to an entire network do not require the creation and use of an element for each address on that network.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 IPS elements.

Router ElementsThe Router elements are used for defining routing, defining a next-hop gateway. For more information about routing, see Routing, on page 113.

Server ElementsThere are several specific server types available in StoneGate, each with a special role and additional parameters that must be configured for specific cases.

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 can perform authentication services. RADIUS servers can be used for authenticating administrator logins. Further authentication features are offered with StoneGate Firewall/VPN systems.

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 Firewall/VPN systems.

LDAP Server ElementsThe LDAP Server element is used for external LDAP directory servers with StoneGate Firewall/VPN.

Content Inspection Server (CIS) ElementsContent Inspection Servers (CIS) define servers that perform virus-scanning, Web filtering, or other actions based on the content of the packets with StoneGate Firewall/VPN.

DNS Server ElementsThe DNS Server element is used to define DNS servers for inbound traffic management when Dynamic DNS updates are used with StoneGate Firewall/VPN.

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

Monitoring Server elementThe Monitoring Server element is used as a gateway by the StoneGate Monitoring Client to contact the Management Center for log monitoring purposes.

StoneGate IPS ElementsThe StoneGate IPS engines are a special class of elements representing the StoneGate IPS Sensor and Analyzer engines administered by the StoneGate Management Center. You must define an initial configuration for a Sensor or Analyzer in the Management Client to be able to complete the installation on these engines. Later, you can always modify these elements as needed.

StoneGate IPS Elements 93

Single Sensor ElementsA single Sensor engine is used to capture network traffic for inspection according to its IPS policy. Single sensors can be installed in an inline configuration that allows the sensor to actively block traffic offending the IPS policy. Single Sensors can be used in Transparent Access Control mode to examine Ethernet protocol traffic. A single Sensor cannot provide load balancing or high availability for the Sensor functions like a cluster does. A single Sensor is suitable for low to medium traffic network segments.

Sensor Cluster ElementsA cluster of 2–16 Sensor engines balances the traffic inspection load and provides high availability for the Sensor operation. The nodes of the cluster function together as one Sensor. A Sensor cluster is better suited for normal LAN traffic in busy networks than a single Sensor. You can also cluster Sensors with inline interfaces as an Inline Serial Cluster, which improves the throughput of the traffic that traverses the inline interfaces of the Sensors.

Analyzer ElementsThe Analyzer has a configurable policy for correlating, processing, and analyzing the event information received from the Sensor nodes and optionally from other Analyzers. You can also define a backup Analyzer for an Analyzer. The backup Analyzer is used if the primary Analyzer no longer accepts connections from Sensors.

Combined Sensor-Analyzer ElementsSensor and Analyzer can run on the same machine as a combined Sensor-Analyzer. It can be used for smaller network environments with a lower level of network traffic.

Services Service elements are used in Access rules to match the rule to a certain port and to define the Protocol that is used for matching the traffic to the correct Situations in Inspection rules. Ethernet Services elements are used in Ethernet rules to define the Ethernet frame type that the rules match.Ethernet Services elements are found in the IPS Configuration branch of the All Elements tree.


Service elements have their own branch in the All Elements tree. The Services are organized according to service families, such as TCP and UDP. There are also Service Groups that combine similar single Services together.

The Services and Ethernet Services elements 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 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.) and pre-define Ethernet Services for well-known Ethernet protocols. 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.

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.

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.

Services 95


CHAPTER 9 Sensor and Analyzer Configuration

A Sensor Cluster is a group of sensor 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. A Single Sensor is a sensor that only has one sensor engine.


Overview to Sensor and Analyzer Configuration, on page 98 Configuration of Sensors and Analyzers, on page 99 Using Sensors and Analyzers, on page 105 Examples of Sensor and Analyzer Configuration, on page 109

97

Overview to Sensor and Analyzer Configuration

A Single Sensor can be deployed at sites where the performance benefits and high availability provided by a sensor cluster are not essential. Single Sensors and combined Sensor-Analyzers can optionally be used in Inline Sensor mode or Transparent Access Control mode.However, a single machine can be a single point of failure, which creates a threat to system operation. This risk can be significantly reduced by clustering sensor nodes. The StoneGate IPS solution uses built-in clustering technology technology, for which no additional software or hardware is needed to cluster several nodes. A Sensor cluster consists of up to 16 Sensor nodes that function as a single entity.In a clustered Sensor 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.Sensors in inline mode can optionally be clustered as in an inline chain to improve throughput. Optionally, you can 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 sensors.In case a Sensor node in a cluster fails or is taken offline for maintenance, traffic can be automatically redistributed between the other nodes in both clustering modes. The whole cluster can function normally even if a number of nodes are offline. This way maintenance work can be conducted even during business hours without compromising the intrusion detection.This chapter concentrates on configuration of network interfaces and clustering, which are the only parts of the configuration where there are major differences between a single sensor and a clustered installation. The section Using Sensors and Analyzers, on page 105 addresses other configuration tasks that you may do in the Sensor elements’ properties.

Communication Between the NodesThe nodes exchange status information constantly so that connections do not get lost. If a sensor node becomes unavailable, the other nodes of the cluster immediately notice this, and traffic is reallocated appropriately. The exchange of information between clustered StoneGate nodes is synchronized through selected interfaces via a heartbeat network using multicast transmissions.The frequent heartbeat transactions between nodes exchange data that is crucial for the correct functioning of the cluster. A dedicated network is recommended for these time-critical communications. The heartbeat messages are authenticated, and can also be encrypted if necessary. The nodes also use the heartbeat network to

98 Chapter 9: Sensor and Analyzer Configuration

exchange state synchronization information. When an Access rule has connection tracking enabled, all packets that belong to the same connection are handled by the same node. The nodes exchange information about the connections handled by each one so that another node can take over handling of the connection in the case of a failure.

Caution – Although it is possible to have the heartbeat interface in the same network with other traffic, it is recommended to run at least the Primary heartbeat on a dedicated network. Other traffic may interfere with the time-critical heartbeat communications and severely disrupt the operation of the cluster. Always take special care to ensure that the heartbeat interfaces operate correctly and reliably.

Load BalancingIf load-balanced clustering is used, the traffic arriving at the Sensor cluster is balanced across the nodes by means of a load balancing filter. This filtering process distributes packets between the sensor nodes and keeps track of packet distribution. The Sensor determines the packet ownership of the nodes by comparing the incoming packet with node-specific values based on the packet headers.The Sensor 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.

Configuration of Sensors and AnalyzersStoneGate Sensors and Analyzers are configured and managed centrally through the Management Server. The Single Sensor, Sensor Cluster, Sensor-Analyzer and Analyzer elements represent the sensor and analyzer configuration on the Management Server. The main configuration options in the Sensor elements include the settings related to network interfaces and clustering. This chapter concentrates on those settings.

Network InterfacesThe network interfaces of a StoneGate Sensor are identified by Interface IDs. The Interface IDs are assigned to the physical network interfaces during Sensor engine installation. During the Sensor configuration in the Management Client, you define the network interfaces of the Single Sensor. During the engine configuration on the command line, the Interface IDs are mapped to the engine’s physical interfaces. For each physical network interface, a unique Interface ID must be specified.


Depending on whether you are configuring a Single Sensor, a Sensor Cluster, a combined Sensor-Analyzer, or an Analyzer, you can configure the following types of interfaces for each Interface ID in use:

TABLE 9.1 Sensor and Analyzer Interface Types

Interface Type Available on Description

Capture InterfaceSingle Sensors, Sensor Clusters, Sensor-Analyzers

Capture Interfaces are used for listening to traffic that is not routed through the sensor. They are dedicated for capturing network traffic, and cannot be used for other purposes.

Inline InterfaceSingle SensorsSensor-AnalyzersInline Serial Clusters

Inline interfaces handle traffic that is routed through a Sensor in inline Sensor mode or Transparent Access Control mode, or Sensors in an Inline Serial Cluster. These Inline interfaces cannot be simultaneously used for other purposes.

Node Dedicated Interface (NDI)

Single Sensors, Sensor Clusters, Sensor-Analyzers, Analyzers

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. NDIs are used for management communications, sending event information to the Analyzer and triggering TCP Reset responses.


Illustration 9.1 Network Interfaces in a Sensor Cluster

Illustration 9.1 shows how capture interfaces and NDIs are used on a Sensor Cluster. In this example, the Sensor cluster consists of two nodes with three physical interfaces in each. Interface ID 0 in each node is used for the cluster heartbeat. Interface ID 1 is a capture interface used for capturing network traffic for inspection. Interface ID 2 is configured for management connections, sending event information to the Analyzer, and sending TCP Reset responses.

Configuration WorkflowThe following sections provide an overview of the configuration tasks related to configuring and customizing Single Sensors. 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 an Analyzer ElementDuring the Sensor element definition, you select the Analyzer to which the Sensor sends its event information. For this reason, you must define an Analyzer element before you begin defining Sensor elements. The only exception to this is when you are creating a combined Sensor-Analyzer. In that case, the Analyzer and the Sensor are defined at the same time.


Optionally, it is possible to configure a secondary Analyzer for single Sensors. When the primary Analyzer becomes unavailable, the Sensors start using the backup Analyzer. They automatically switch back to the primary Analyzer when the connectivity returns. No state synchronization information is sent between the primary and backup Analyzers, so connections may be interrupted during the transition.

Task 2: Create a Sensor ElementTo introduce a new Single Sensor, Sensor Cluster or combined Sensor-Analyzer to the Management Center, you must define a Sensor element that stores the configuration information related to the sensor engines.

Task 3: Define VLAN InterfacesA Virtual Local Area Network (VLAN) is a logical grouping of hosts and network devices that appear as a single network segment regardless of its physical topology. StoneGate supports VLAN tagging as defined in the IEEE 802.1q standard. One network interface can support up to 4094 VLANs.StoneGate IPS Sensors support VLAN tagging so that the Sensor’s network interface can use and interpret VLAN tags. VLAN tagging can be used to:• inspect VLAN tagged traffic (no VLAN interface configuration required on the Sensor)• define different inspection rules for different VLANs (requires defining VLAN

interfaces for the Sensor)• Sensor’s own management and event logging communications when the network

interface is connected to a VLAN trunk.You only need to configure VLAN interfaces for the Sensor capture interfaces if you want to customize traffic inspection for the different VLANs. By default, all captured VLAN traffic is inspected in the same way as non-VLAN traffic.When VLAN is used with inline interfaces, the interface numbers must be different and the VLAN identifier must be identical in both of the inline interfaces. For example, 3.101 and 4.101 would be a valid pair of VLAN inline interfaces. Also, when a VLAN interface is used for an inline interface, it cannot be simultaneously used for any other type of interfaces.

Task 4: Define NDIsIn a Single Sensor, NDIs are used for communication between the sensor and the Management Server, for sending event information to Analyzers, and for sending traffic recordings to Log Servers. Each single sensor must have at least one NDI defined. Multiple NDIs can be configured for the same physical network interface.In a Sensor Cluster, the NDIs handle all traffic for which the end-point of the communication is a node itself. The NDIs are used for node-to-node communications, for traffic between each individual node and the Management Server and Log Server, and any other traffic between the node itself and some other host. Multiple NDIs can be configured for the same physical network interface. There must be at least one NDI per Sensor node.


The NDIs are defined in two stages: common properties for the Cluster, such as the the Interface ID, and node-specific properties for each node, such as the IP address. All nodes must have the same netmask value for the IP address of their respective NDIs. The IP addresses specified in the node-specific properties are used whenever the nodes need to be contacted individually.The NDI MAC addresses do not need to be modified unless you want to override the MAC address on the physical interface. Because of the limitation of only one unicast MAC address per physical interface, all the NDIs defined on the same physical interface use the same MAC address. Make sure that the NDIs on different physical interfaces do not have duplicate MAC addresses.

Task 5: Define Logical InterfacesA Logical Interface is used in the IPS policies and the traffic inspection process to represent a network segment. A Logical interface can represent any number or combination of physical interfaces or VLAN interfaces, except that the same Logical interface cannot be used to represent both Capture interfaces and Inline interfaces on the same Sensor.Logical interfaces have one option, View interface as one LAN, which can be turned on or off. By selecting the option, you avoid the sensor seeing a single connection as multiple connections when a switch passes traffic between different VLANs and all traffic is mirrored to the sensor through a SPAN port.

Task 6: Define Capture InterfacesYou must define Capture interfaces if you want to use the Sensor to listen to traffic that is not routed through the Sensor. Capture Interfaces can be connected to a Switched Port Analyzer (SPAN) port (also known as port mirroring), wire Test Access Port (TAP), or even to a hub (for network performance reasons, using a hub might not be a suitable solution). Capture Interfaces have two operating modes: SPAN mode and wire TAP mode. The SPAN mode simply captures all traffic received by the physical interface. This mode can be used with switch SPAN ports as well as any other connection method that uses one physical interface for receiving the network traffic for capturing. The wire TAP mode combines traffic received through two Capture Interfaces. This is necessary, for example, when using a wire TAP that transmits the traffic going in different directions to different wires. StoneGate IPS is connected to a wire TAP using the TAP mode on two Capture Interfaces that are connected to the wire TAP.In addition to the Capture Interface mode, the Capture Interfaces have definitions for the corresponding Logical Interface that this interface belongs to. The Logical Interface represents one or more network interfaces which capture the traffic for inspection: • for a SPAN mode Capture Interface, there is one corresponding Logical Interface

used in the Sensor rule base representing this traffic source.• for a wire TAP mode, there are two Capture Interfaces bound to the same Logical

Interface as the monitored traffic going to different directions is captured through


these two related network interfaces and is then combined into a complete traffic flow on the Logical Interface.

You cannot select the same Logical interface for a Capture and an Inline interface on the same Sensor.A Reset Interface can be defined for a Capture Interface to send TCP Reset responses for the traffic captured from this interface. The Reset Interface is an NDI that can reach the communicating machines with the TCP Reset, for example, an NDI connected to the monitored network.

Task 7: Define Inline InterfacesYou must define Inline interfaces if you want to place a Single Sensor, Sensor-Analyzer, or Inline Serial Cluster directly in the traffic path so that any traffic that is to be inspected goes through the Sensor. An Inline interface is configured with two Interface IDs, representing two physical interfaces or two VLANs. Some StoneGate appliances use a fail-open network card, so the Inline interfaces must be configured for those specific ports. Inline interfaces do not have an IP address.In addition to the Interface IDs, Inline interfaces also have definitions for the corresponding Logical Interface that this interface belongs to. A single Logical interface can represent one or more pairs of Inline interfaces. The Logical Interface element can be used to represent the interfaces in the IPS policy. You cannot select the same Logical Interface for a Capture and an Inline interface on the same Sensor.

Task 8: Install the Sensor and Analyzer EnginesDuring the engine installation, you map the physical interfaces to the interface IDs you define 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, interface IDs are automatically mapped to physical interfaces in sequential order. For example, 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.You also activate a basic IPS Policy and routing (the initial configuration) that allows you to establish contact between the Management Server and the engine. After contacting the Management Server, the engine receives a certificate from the Management Center for identification, and a trust relationship between the engine and the Management Server is established.

Task 9: Install an IPS PolicyAfter the Sensor or Analyzer engine makes initial contact with the Management Server, only the primary control interface with the Management Server is configured. You must install an IPS Policy using the Management Client to transfer the complete interface configuration to the Sensor or Analyzer.


Before policy installation, StoneGate validates the IPS policy to be installed, and lists possible misconfigurations and errors in the Issues window, if the Validate Before Upload option has been ticked when defining the policy installation task properties.

Using Sensors and AnalyzersThe main points of Sensor and Analyzer configuration are explained in the preceding sections of this chapter, but this section illustrates some additional concepts that are useful when working with Sensors and Analyzers.

Running Automatic TestsThe Sensors and Analyzers have a test system, which runs on the engines. You can configure the Sensors and Analyzers to run different tests depending on their 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 Sensors and Analyzers. 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 9.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.

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

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.

Inline Pair Link SpeedChecks if the network settings (speed/duplex) match on the two ports that form the inline pair and can force both ports to use the same setting.


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 Sensors and Analyzers can send SNMP traps on events such as test failures and changes in operating state. The SNMP Agent element contains the settings according to which the Sensor or Analyzer sends SNMP trap messages to compatible external software. A single SNMP Agent can be created once and used on multiple Sensors and Analyzers by selecting the correct SNMP Agent in the element properties.The SNMP agent supports SNMPv1 (RFC1157), SNMPv2c (RFCs 1901 and 3416), and SNMPv3 (RFC 3414).

Contact Addresses for NATed CommunicationsIn a situation where a device performs network address translation (NAT) between the communicating StoneGate components, you must specify contact addresses for the components. The contact address is the NATed address of the component that is contacted instead of the interface’s real IP address. The contact addresses for the system components on each “site” behind NAT are grouped into a Location element. The contact address for each component is defined in the element’s properties based on the Location of the contacting component. For example, when a Management Server contacts a Sensor node through NAT, the Management Server uses the NATed contact address, not the Sensor node’s real IP

TABLE 9.3 Test Entry Display of Selected Actions and States

Types Table display Description

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


address. The NAT device in between performs the address translation from the NATed address to the Sensor’s real IP address as usual.You create the Locations and add elements in the Locations based on how your network is set up. Then you define the Contact Addresses for each element for each Location in the properties of the elements. All Management components in other Locations then use the addresses defined for their Location for contact.

Using Inline SensorsInline interfaces enable the placement of a Single Sensor directly in the traffic path. Traffic enters the Sensor through one interface, is inspected according to the installed IPS Policy, and all traffic not deemed harmful is then passed through the other interface.

Illustration 9.2 Inline Interfaces in a Single Sensor

Illustration 9.2 shows how Inline interfaces and NDIs are used on a Single Sensor. In this example, the Single Sensor has three physical interfaces. Interface ID 0 is used for management connections, sending event information to the Analyzer, and sending TCP Reset responses. Interface ID 1 is an inline interface that receives network traffic for inspection and passes all traffic not deemed harmful through Interface ID 2 to the internal network.

Using Inline Serial ClusteringYou can optionally cluster sensors with Inline interfaces as an Inline Serial Cluster to improve throughput for traffic that traverses the inline interfaces of the sensors.


Illustration 9.3 Inline Serial Clustering

Traffic passes through all the nodes, but only one node processes the connection. The other nodes simply forward the traffic. Connections are distributed between the nodes based on IP addresses. There is no state synchronization information shared between nodes in an Inline Serial Cluster. Inline Serial Clustering only improves performance, and does not provide high availability.

Using Sensors in Transparent Access Control ModeA Sensor or combined Sensor-Analyzer in Transparent Access Control mode examines Ethernet protocol traffic and allows or blocks it according to the Ethernet rules in the IPS policy. Sensors in Transparent Access Control mode can be configured with inline interfaces or capture interfaces. When capture interfaces are used, the Sensor can only examine the Ethernet protocol traffic. Inline interfaces are required to block traffic. Any Ethernet protocol traffic that is not deemed harmful is allowed through.

Capturing Traffic From VLANsA Sensor’s capture interfaces can be used to capture VLAN tagged traffic automatically without any additional configuration. The VLAN traffic can be identified by the VLAN ID that is included in the logged events. The installed IPS policy inspects the traffic, no matter if it is VLAN tagged or normal LAN traffic.


Illustration 9.4 VLAN Traffic Capturing

You must define VLAN tagged capture interfaces in the Sensor element if you want to customize the traffic inspection based on the VLAN tagged traffic. The VLAN tagged Capture interfaces handle only the traffic of the defined VLAN. The traffic inspection is customized for the VLANs by defining different Logical Interfaces for the different VLAN capture interfaces. The Logical Interface elements are then used in the IPS policy rules to define which rules are used for which VLANs.The network interface used for resetting connections is defined in the Capture interface’s properties. The reset is automatically tagged for the same VLAN that triggers a reset. The reset interface must be connected to the correct VLAN trunk to reach the communicating hosts.

Examples of Sensor and Analyzer Configuration

The examples in this section illustrate some common uses for Sensor and Analyzer configuration in StoneGate and general steps on how each scenario is configured.

Setting up an Inline SensorThe administrator at a branch office of Company A wants to set up an inline sensor. Illustration 9.5 shows the interfaces of the branch office inline sensor.


Illustration 9.5 Branch Office Inline Sensor

The administrator does the following:1. Defines an Analyzer element (Branch Office Analyzer).2. Creates a Single Sensor element (Branch Office Sensor), defines Branch Office

Analyzer as the Analyzer to which event data is sent, and Branch Office Log Server as the Log Server to which traffic recordings are sent.

3. Defines the interfaces as shown inTable 9.4:

4. Saves the initial configuration of the engine in the Management Client.5. Maps the interface IDs to the physical interfaces in the engine Configuration

Wizard on the engine’s command line and makes initial contact with the Management Server.

6. Installs an IPS policy in the Management Client to transfer the configuration to the engine.

Setting up a Sensor ClusterThe administrators at the headquarters of Company A want to set up a Sensor Cluster. The cluster consists of two cluster nodes: Node1 and Node2. The cluster has a dedicated heartbeat network, and has one capture interface per node.Illustration 9.6 shows Company A’s headquarters network.

TABLE 9.4 Inline Sensor Interfaces

Type Interface ID Mode

NDI 0 Management Interface

Inline Interface 1 Inline

Inline Interface 2 Inline


Illustration 9.6 Headquarters Network

The administrators:1. Define an Analyzer element (HQ Analyzer).2. Create a Sensor Cluster element (HQ Sensor Cluster), define HQ Analyzer as the

Analyzer to which event data is sent, and HQ Log Server as the Log Server to which traffic recordings are sent.

3. Define the Interfaces for each node as shown inTable 9.5.

4. Save the initial configuration of the engines in the Management Client.5. Map the interface IDs to the physical interfaces in the engine Configuration

Wizard on each engine’s command line and make initial contact with the Management Server.

6. Install an IPS policy on Node1 and Node2 in the Management Client to transfer the configuration to the engines. The nodes exchange authentication information and begin to work as a cluster.

TABLE 9.5 Sensor Interfaces

Type Interface ID Mode

NDI 0 Heartbeat

Capture Interface 1 Capture

NDI 2 Management Interface



CHAPTER 10 Routing

Routing defines which network interface StoneGate selects to reach a particular destination address. Routes are only needed for the communications the engines initiate with other system components. StoneGate IPS components do not route other traffic.


Overview to Routing, on page 114 Configuration of Routing, on page 114

113

Overview to RoutingRouting information is used for deciding which network interface is used to reach any given destination address. The Sensors and Analyzers need modifications in their routing configuration only if they are connecting to some other network than the directly connected networks. The Sensors and Analyzers do not function as gateways. They do not forward traffic from one network to another.

Configuration of RoutingEach Sensor and Analyzer element has a list of network interfaces with the directly connected networks in the Routing view. The routes for the Sensors and Analyzers are defined in the Management Client using Network elements. Usually, only a default route is needed for the Sensors and Analyzers. These are used when the sensors and analyzers need to open connections to some network other than the directly connected networks. No routes need to be defined if a sensor or an analyzer communicates only in its local IP network.

Default ElementsThe system includes a default network element called Any network, which is needed to define the default route for sensors and analyzers.

Configuration WorkflowThe following sections provide an overview of the configuration tasks related to routing in Sensors and Analyzers. 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 RouterA Router element represents the next-hop gateway device that forwards packets to the network(s) you define next.

Task 2: Add Network(s)The Network element represents the IP addresses to which the Router forwards the traffic.• To add a default route, add the default Any network element to the Router you just

created.• If you need to forward traffic to a network that is not directly connected and it

cannot be reached through the default gateway, you must define a Network element for this network and add it under the Router.

Task 3: Refresh IPS PolicyTo transfer the routing changes, upload the policy on the sensor. The Management Server sends all necessary configuration information when uploading a policy.

114 Chapter 10: Routing

Traffic Inspection

CHAPTER 11 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, i.e., a pattern that the system is to look for in the inspected traffic.


Overview to Situations, on page 118 Configuration of Situations, on page 118 Using Situations, on page 122 Examples of Custom Situations, on page 123

117

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 inspection rules in the IPS and the firewall. 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 IPS and firewall policies 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. Correlation Situations are Situations that IPS Analyzers use to find patterns in and group together event data sent by the Sensors.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 11.1 A Situation and the Associated Elements

As you can see in the illustration, the Situation element uses different elements in the system to form a representation of the traffic that you want to detect in your IPS Policy.• 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

118 Chapter 11: Situations

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 up to four references to public vulnerability databases (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 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 Situations that detect some publicly known issue.

Situation ContextsThe 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.

Correlation ContextsCorrelation Situations define the patterns the Analyzers look for in traffic. There are five types of Correlation Situations:• Event Compress Situations combine repeated similar events into the same log

entry, reducing clutter in the Logs view. For example, you could have a custom Situation for detecting suspicious access to a file server holding confidential data. An attacker is likely to browse through many files, triggering an alert entry for each file. An Event Compress Situation can be used to combine Situations together when the suspect’s IP address is the same.

• Event Count Situations find recurring patterns in traffic by counting the times certain Situations occur within the defined period, so that action can be taken if the threshold values you set are exceeded. For example, a Custom Situation that detects access to a system could normally trigger just a log entry, but the Event Count Situation could be used to blacklist connections for a while when access by any single host is too frequent.

• Event Group Situations find event patterns in traffic by keeping track of whether all events in the defined set of Situations match at least once in any order within the defined time period. For example, individual attempts to exploit different vulnerabilities in a software product in use on your server may not be too alarming if


you know that your system is patched against those vulnerabilities. However, when several such events are found in a short period of time, it becomes more likely that someone is trying to systematically attack the server and already knows that the server is running that particular piece of software. An Event Group Situation can detect this.

• Event Match Situations allow you to use filter expressions to filter event data produced by specific Situations.

• Event Sequence Situations find event patterns in traffic by keeping track of whether all events in the defined set of Situations match in a specific order within the defined time period. For example, on a file server, clients may use a certain type of request to fetch a file (e.g., “give file X”). On the same server, the administrators may enter into privileged mode, and successful administrator login can be seen in the traffic as a certain type of response (e.g., “full access granted”). However, a vulnerability in the server software allows an attacker to send a specially crafted file fetch request that looks like a valid “give file x” command, but actually causes the server to give the attacker administrator access. This is seen as a normal-looking “full access granted” response from the server. Individual Situations detecting “give file X” and “full access granted” both individually match to legitimate traffic as well, but the Event Sequence Situation can detect when a “give file X” Situation match is followed by a “full access granted” Situation match, which cannot be any legitimate traffic.

Detailed descriptions of the parameters for each of the Correlation Contexts can be found in Situation Context Parameters, on page 289.

Protocol-Specific ContextsThe protocol-specific contexts are used by Sensors to detect a particular characteristic in the network traffic. For example, you can detect a certain option number used in IP packets or set the maximum length for particular arguments in FTP commands. For those 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 to these values is considered a match for the Situation. So in other words, you may define what the Situation does not match.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, but 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.

The Scan Detection ContextThe Scan Detection Context provides parameters for adjusting what is considered an attempt to scan which IP addresses are in use or which ports are open in your systems.


Detailed descriptions of the parameters for the Scan Detection Context can be found in Situation Context Parameters, on page 289.

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.

Website Access Control ContextsThe Website Access Control Contexts are used for blocking access to the specified websites. As a parameter, you simply enter the websites you want to block.

Default ElementsWhen you have your IPS up and running, there are many pre-defined Contexts, Situations, Tags, and Vulnerabilities available, but these elements are imported and updated from dynamic update packages, so the set of elements available in your system changes in some part whenever you update your system with new definitions. The Situations and related elements contain comments that you can view in the Management Client to see what they are 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 website, 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 of 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 Situations in addition to the predefined ones. You can create a Situation element for Sensors or a Correlation Situation for Analyzers. The Custom Situation sets the severity value for the Situation, which can be used for matching in IPS Policies 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 attach information about the 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.


First, you select a Context, which then gives you a set of options or a field for entering a regular expression that you can use to 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 295. The context parameters for Port and Host Scan detection and the Correlation Situation parameters are explained in Situation Context Parameters, on page 289.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 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 IPS policies with less work. You can drag and drop the Tags into the Situations cell in 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 IPS policy, the new Situation is automatically included in the policy when you save the Situation, and the IPS components start 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.Only one reference per reference system is allowed for custom Vulnerabilities. System vulnerabilities can have an unlimited number of references to any reference system, and can have multiple references to the same reference system.

Using SituationsSituations are used for adding something that you want to detect into the Inspection rules. Situations are generally used for:• Detecting malicious patterns in traffic. The Situations supplied by Stonesoft in

dynamic update packages concentrate on such known vulnerabilities and exploits.• Reducing the number of alert and log entries you receive from the system (using

Correlation Situations).


• Detecting patterns in traffic that you do not want inspected. Sometimes you may want to allow a particular type of traffic to pass without inspection. Most of the time, you can use simple matching criteria such as IP addresses for this, but for some types of traffic, it may be possible to describe what is allowed using one or more Situations.

Although the general workflow requires ensuring that a Situation you want to use is included in the IPS 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 an IPS policy to a Situation, the Situation is included in the IPS policy without any further action, and is used by the Sensors or Analyzers after a policy refresh.

Examples of Custom SituationsThe examples in this section illustrate some common uses for Situations in StoneGate and the general steps on how each scenario is configured.

Detecting the Use of Forbidden SoftwareCompany A has a Sensor deployed in between their internal network and the Internet. The Sensor uses a policy that is based on the System Template policy.The administrators find out that some of the internal users have installed a piece of software on their computers that the company’s security policy forbids. They consider this software a security risk.The administrators decide that they would like to detect the use of the software so that they can find out which users have installed it. 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 295).

3. Add the default system Tag Possibly Unwanted Software to the Situation.4. Refresh the IPS policy of the Sensor.

• The system policy contains a rule for Possibly Unwanted Software, which is set to create a log entry.

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 based on which IP addresses are shown in the logs.

Examples of Custom Situations 123

Counting EventsCompany B has a StoneGate firewall and a sensor that monitor traffic to a DMZ network. The DMZ contains a server that provides information to Company B’s partners. A while ago, users started complaining that the service had slowed down.Upon investigation, they found out that the traffic had grown dramatically even though the number of users and the data on offer had stayed the same. They were puzzled, but soon they found out that one of the partners had made a misconfigured script that would frequently copy several large catalogs from Company B’s server to their own server and had given the script to a few other partners as well. As a first step, the administrators decide to immediately stop excessive queries to the server. The administrators:1. Create a custom Situation for detecting access to the catalog files.2. Create a custom Correlation Situation and attach the Event Count context to it

to catch the situations when there are more than 5 requests to any of the files per minute from the same source address.

3. Insert the Correlation Situation to the IPS policy with blacklisting as the option. The traffic from the offending hosts will be stopped at the StoneGate firewall.

4. Refresh the IPS policy on the Sensor.

Preventing Access to Forbidden WebsitesThe Administrators at Company C have noticed that employees frequently visit certain websites that are not related to their work. They want to block access to these websites to prevent employees from accessing them at work. To do this, they:1. Create a new Situation element.2. Add the Website Access Control context to the Situation.3. Specify the addresses they want to prevent access to. Access to the specified

addresses will be blocked.4. Refresh the IPS policy on the Sensor.

Field Option

Correlated Situations Custom Situation

Time Window 60

Alarm Threshold 5

Log Fields Enabled Select

Lognames Src Addr


CHAPTER 12 IPS Policies

IPS policy elements are containers for the lists of rules that determine how the sensors and analyzers inspect traffic. The policy elements include IPS Template Policies, IPS Policies, and IPS Sub-Policies.


Overview to IPS Policies, on page 126 Configuration of Policy Elements, on page 129 Using Policy Elements, on page 134 Example of Policy Element Use, on page 135

125

Overview to IPS PoliciesThe policy elements store rules according to which the sensors and analyzers examine the traffic. This chapter introduces you to how these elements are used by the sensors and analyzers and explains how you can 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 (Ethernet Rules, Access Rules, IPv6 Access Rules, and Inspection Rules) are discussed in the four chapters that follow.

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 sensors.• Make policies easier to read.The template and policy hierarchy is flattened when the IPS Policy is transferred to the sensors and analyzers, so the policy will look the same to the IPS components regardless of how it is organized on the Management Server (as long as the rules are in the same order). You can also create sections of conditional Access rules that you can insert into the other policy elements. The sensor 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 IPS Policy which you can build, for example, on the provided IPS System Template (a single policy may be used even if you have several sensors and analyzers).

How StoneGate Examines the PacketsThe IPS system matches traffic to different protocols and then checks the definitions for known vulnerabilities and other threats for that protocol. The protocol is assigned first, before the deep inspection. The protocol assignment is done using Services, which match ports and protocol numbers to Protocol elements. Depending on the rules in the policy used, some traffic may be discarded (on inline sensors) or allowed without deep inspection based just on IP address, port, and protocol information (simple packet filtering).

126 Chapter 12: IPS Policies

The packet handling process is shown in Illustration 12.1.

Illustration 12.1 Packet/Connection Handling in an IPS Sensor

The illustration above shows how the policies are used:1. (If Transparent Access Control is used) An inline sensor or sensor-analyzer in

Transparent Access Control mode checks Ethernet protocol packets against the Ethernet rules installed in the IPS policy (requires that the sensor or sensor-analyzer is licensed for the Transparent Access Control feature). The packet is processed until it matches an Ethernet rule that tells the inline sensor or sensor-analyzer to allow or to discard the packet.

2. The sensor or sensor-analyzer 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). If it is part of an established connection, it can either let the packet to pass through or continue processing the packet in the Inspection rules.

1.

2.

3.

4.

Overview to IPS Policies 127

3. If the packet is not part of an existing connection, the packet is compared with the Access rules or IPv6 Access rules according to traffic type (IPv4 traffic is checked against Access rules and IPv6 traffic is checked against IPv6 Access rules). • If the traffic is tunneled (IP over IP or Generic Routing Encapsulation is used),

the traffic can be checked against the Access rules and/or IPv6 Access rules several times according to the number and type of layers in the tunnel. See Access Rules, on page 145, IPv6 Access Rules, on page 159 for more information.

• The processing of the packet continues until the packet matches an Access rule or IPV6 Access rule that tells the sensor or sensor-analyzer to allow or discard the packet. Only inline sensors or sensor-analyzers in Transparent Access Control mode can drop packets at this point (requires that the sensor or sensor-analyzer is licensed for the Transparent Access Control feature). The packet may also match a rule that sends it for further inspection in the Inspection rules.

4. The sensor or sensor-analyzer applies Inspection rules for the connections that are selected for deep packet inspection in the Access rules or IPv6 Access rules.• The Inspection rules are used to look for interesting patterns that are a part of

allowed connections. The patterns may indicate potential attacks, exploits, or other possible threats. Alternatively, they can be any other patterns that might be of interest to the administrator (such as multiple login attempts, use of peer-to-peer or instant messaging software, or protocol violations in the traffic).

• The packet is processed until a pattern that matches a rule is found. If there is no rule match (no pattern of interest is found), the packet is allowed to pass through.


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

other IPS Template Policies. The IPS 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.

• IPS Policies can be based on an IPS Template Policy. The IPS Policies are the only policy elements that can be installed on the IPS components.

• IPS Sub-Policies are sections of rules that you can insert into IPS Policies and IPS 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 12.2.

Illustration 12.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. Then, our example IPS Policy inherits all rules from Template B, so the IPS Policy includes all the rules from Template A, Template B, and the Sub-Policy, as well as any rules the administrators add to the IPS Policy directly. The only rules that can be edited from within the IPS 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 IPS Policies are installed on IPS


components, the new rule is used on all those components without anyone directly modifying each individual IPS Policy.

• Restrict the editing rights of administrators. For example, administrators who are granted rights to only the inheriting IPS 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 IPS 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 IPS 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 improved throughput if the processor load is constantly very high.

Default ElementsThe system has a ready-made IPS System Template and a System Policy that you can install on your IPS system. The IPS System Template contains a set of rules for detecting common threats, and provides an easy starting point when you first start using the system and start determining what kind of rules your system needs. The System Policy does not add any rules to those defined in the template, but it exists by default so that you can install the pre-defined rules right after installation (since templates cannot be installed on the IPS engines).New IPS policies and templates can be added freely to the system without basing them on any existing policy, so you are not required to use the IPS System Template or the System policy. In most cases, the IPS System Template (or a copy of it) is still the easiest starting point for your own customized templates and policies.

Note – Updated versions of the IPS System Template are included in dynamic update packages. Policies that inherit rules from the IPS System Template are automatically updated when you activate a new dynamic update in your system and refresh the IPS Policy. Policies based on copies of the IPS System Template are not automatically updated. For this reason, it is recommended to base your policies on the IPS System Template.

Situations are the central element in Inspection rules. The dynamic updates from Stonesoft contain the Situations for detecting exploit attempts against known vulnerabilities and other commonly known security threats. Because the dynamic


updates include new and updated Situations, new patterns in traffic may begin to match when a new dynamic update is activated in your system and you refresh the IPS policy.

Configuration WorkflowThe following sections provide an overview of the configuration tasks related to configuring and customizing IPS 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 PolicyIPS Template Policies are used as a basis for other IPS Policies and IPS Template Policies. IPS Policies and IPS Template Policies are usually based on a template. It is recommended to base your policies on the IPS System Template. However, you can optionally create custom templates or even create a policy without using any IPS Template Policy.When editing the policies, the main difference between IPS Template Policies and IPS Policies are the special rows called Insert Points. Insert points are shown in both IPS Template Policies and IPS Policies, but you can add them only to IPS Template Policies. The Insert Points added to templates mark the place where new rules can be added in the lower-level IPS Template Policies and IPS Policies. When creating an IPS Template Policy, you must add an insert point separately for the Ethernet rules, Access rules, IPv6 Access rules, and Inspection rules. If you want to override rules inherited from the IPS System Template, it is advisable to add insert points to your policy and create specific rules to override the inherited rules.

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

Illustration 12.3 shows what the same insert point looks like in an IPS 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 IPS 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 IPS 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 sensors and analyzers read 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. Naturally, any rules below the insert point in the template may be overridden by rules placed in the Insert Point in lower-level policy elements.

Task 2: Create a PolicyThe IPS Policy is the only policy element that you can transfer to the IPS components, so the IPS Policy is the element that gathers together all the rules from the different policy elements. The IPS Policy is usually based on an IPS Template Policy, often the IPS System Template that is provided in the system and updated through dynamic updates.

Task 3: Create a Sub-PolicyIPS Sub-Policies are sections of Access rules that you can insert into IPS Policies, Template Policies, and even other Sub-Policies to make the sensors process traffic faster and to organize the rules. The Sub-Policies are not based on any template. IPv6 Access rules, Inspection rules and Ethernet rules cannot be inserted into Sub-Policies, which is also why analyzers do not use them.The Sub-Policies may make reading the policies and assigning administrator editing rights easier. If you so choose, you can give some administrators the rights to edit only certain Sub-Policies without giving editing rights to the IPS Policy.A Sub-Policy is inserted into some other policy element by adding a Jump rule. The Jump rule directs those connections that match the criteria defined in the Jump rule for inspection against the Sub-Policy. When you have already added rules to the policy, one way to insert a Sub-Policy is to select the rules for the Sub-Policy and then an action for creating the Sub-Policy directly in the policy. In that case, the system automatically adds a Jump rule into the policy.


Illustration 12.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 IPS Policy that uses the rules.For example, you could create a Sub-Policy for checking 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 to checking 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 Access rule processing faster, because the sensor 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 IPS Policy, the sensor would have to compare all connections to all those rules individually (since that is then 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 sensor is to begin with. Therefore, Sub-Policies are mainly useful in the policies of inline sensors that are used extensively for packet filtering.

Task 4: Add RulesAs stated before, the policy 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 Ethernet Rules, on page 137, Access Rules, on page 145, IPv6 Access Rules, on page 159, and Inspection Rules, on page 169).

Task 5: Validate the PolicyThe number of rules in an IPS policy may grow quite large over time. It may become quite difficult, for example, to spot duplicate and therefore unnecessarily rules in a policy. To make policy management easier and make sure that the policy does not contain misconfigured rules, you can optionally validate the policy before you install or refresh it on an engine. You can select different criteria for validating the policy. You

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


can, for example, check the policy for duplicate and empty rules or check if there are rules that are in fact never matched against traffic.

Task 5: Install the PolicyAfter creating or modifying an IPS Policy, you must transfer the changes to the sensors 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 sensor already uses from the Management Server to the engine). You can install the same IPS Policy simultaneously on several sensors under your administration.The rules for analyzers are automatically transferred in the same process. Each analyzer typically receives events from more than one sensor, so the analyzer configuration can contain rules from several IPS policies. The rules are applied to correct traffic based on the sensor that sends the information.Policy installation transfers more information than just the IPS Policy. Whenever you update the sensor or analyzer configuration or the properties of an element used in the configuration, you must reload the IPS Policy to the sensor engine to make the changes effective. This includes, for example, changes in the routing configuration, the Situation elements, and the elements representing the IPS components, even if the changes are not directly related to the rules in the IPS Policy.

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

If the installation of a policy fails for some reason, the system will automatically roll back to the previously installed configuration.

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.

Continue RulesThe Continue action for a rule sets default options (such as logging options) 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 153.

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 check the IPS Policies and other


configuration information that were uploaded and when they were uploaded. You can also compare any two policy snapshots or a policy snapshot and the currently saved policy version which has not yet been installed on any engine.

Example of Policy Element UseThe example in this section illustrates a common use for the different policy elements in StoneGate and general steps on how the scenario is configured.

Restricting Administrator Editing RightsCompany A 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 sensors at any of the other sites. The administrators:1. Create a new IPS Template Policy based on the IPS System Template.2. Add rules using Alias elements to the template to cover their customizations at

all sites with just one policy.• Using a common template for all the branch offices eliminates the need to

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

sites.• Although a single 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. Attach each IPS Policy to the correct Sensor elements.• After this, only the correct policy can be installed on each Sensor. No other

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

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

can install it on the correct Sensor.• The branch office administrators are not allowed to edit the template the IPS

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

Example of Policy Element Use 135


CHAPTER 13 Ethernet Rules

Ethernet rules are lists of matching criteria and actions that define whether Ethernet protocol traffic is allowed or discarded.


Overview to Ethernet Rules, on page 138 Configuration of Ethernet Rules, on page 138 Using Ethernet Rules, on page 142 Examples of Ethernet Rules, on page 142

137

Overview to Ethernet RulesEthernet rules are used only by Inline Sensors or Inline Sensor-Analyzers in Transparent Access Control mode. The role of the Ethernet rules in IPS is to define which Ethernet protocol packets sensors stop, and which packets are allowed through. Ethernet rules can also be used by Sensors in capture mode to define how Ethernet protocol traffic is logged. The Ethernet rules are stored in policy elements, which are discussed in IPS Policies, on page 125.The traffic matching in Ethernet rules is based on the Source and Destination MAC Address in the packets. Any Ethernet network traffic, such as ARP, RARP, IPv6, Cisco Discovery Protocol (CDP), and Spanning Tree Protocol (SPT), can be checked against the Ethernet rules. When some traffic is found to match an Ethernet rule, the traffic can be allowed or discarded. For sensors in Capture mode, only the Allow action is available.Regardless of the action taken, a matching rule can also create a log or alert entry if you wish.

Configuration of Ethernet RulesEthernet rules are configured on the Ethernet Rules tab inside IPS Policy and Template Policy elements. Sub-policies cannot contain Ethernet rules.

Illustration 13.1 Newly Inserted Ethernet Rule - Main Cells

Illustration 13.1 displays an Ethernet rule that has just been inserted into the policy. The Source, Destination, and Service cells are set to NONE, so this rule never matches until they are changed to ANY or some more specific value. The Logical Inteface cell is also matched against traffic, but it is not mandatory to change it if you want the rule to apply regardless of the interface. The other editable cells specify further conditions and options for handling connections that match the cells that are used for traffic matching. It is not necessary to modify all cells in each rule.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 Ethernet rules.

Logging is configured in the Options cell

Sensor applies Action when it finds a match

138 Chapter 13: Ethernet Rules

Illustration 13.2 Elements in Ethernet Rules

The table below explains briefly what each Ethernet rule cell does and which elements you can use in the rules. More information on each cell is included in the task flow 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 13.1 Ethernet 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.

Source Elements containing the MAC 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 MAC Address elements.

Destination

ServiceThe Services match an Ethernet frame type. The Service cell accepts Ethernet Services elements.

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

Options The options for logging.

CommentYour optional free-form comment for this rule. Note that you can also add separate comment rows in between rules.

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, @20.1). 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.


Considerations for Designing Ethernet RulesLike Access and Inspection rules, Ethernet rules are read from the top down, and more specific rules must be placed above more general rules that match the same traffic. The actions Allow and Discard stop the processing from continuing down the rule table for any packet 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. If the traffic does not match any of the Ethernet rules by the end of the policy, it is allowed by default.

Default ElementsThe System Template Policy contains some pre-defined Ethernet rules that allow the most common types of Ethernet traffic. Because the System Template is added in the system and updated through dynamic update packages, the policy you currently have in your system may look slightly different from the one that is presented in this section. Newer versions of the policy work in the same way as described below. Any changes are documented in the Release Notes document for each dynamic update package.

Illustration 13.3 System Template Policy - Ethernet Rules

In the illustration above, you can see a yellow insert point at the top of the rule table, three default rules below it, and then another insert point below them.• The first rule contains common Ethernet protocols and allows the matching traffic

to pass through.• The second rule contains the IPv4 protocol and allows IPv4 traffic.• The third rule contains the IPv6 protocol and allows IPv6 traffic.The two insert points indicate where you can add Ethernet rules to a Policy that uses the System Template. The first insert point above the default rules allows you to modify and make exceptions to the way traffic matching the three default rules is checked. For example, you could add a rule defining that IPv4 or IPv6 traffic between certain MAC addresses is not allowed.The second insert point below the default rules allows you to define how traffic matching other protocols is checked. The final rule in the System Template Policy allows all traffic.


Configuration WorkflowThe following sections provide an overview of the configuration tasks related to configuring and customizing Ethernet 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 MAC addresses specified in a rule are compared to the MAC 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 MAC address elements. You can set these cells to ANY to make the rule match all possible source or destination MAC addresses. Also, you can add more than one element in each cell to make the rule match multiple MAC 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 Ethernet Services elements. You can set the Service to ANY to make the rule match all protocols. For more information on Services, see Chapter 8, Network Elements and Services.

Task 3: Select the ActionThe Action cell defines what happens when a packet matches the rule. The following actions are available in the Ethernet rules:• Allow: the traffic is let through the Sensor.• Discard: the traffic is silently dropped if going through an inline interface.

Note – When the Allow action is used for IPv4 traffic in the Ethernet rules, the traffic is then checked against the Access rules. The final action for the IPv4 traffic is determined by the Access rules.

Task 4: Select Rule OptionsBy default, the Logging options are set to Undefined, which means that no log entry is issued when the rule matches. In most cases, you can leave the setting as Undefined.The log levels are as follows:• None.• Alert.• Stored (saved on the Log Server).


Note – A log entry is generated for each packet that matches an Ethernet rule. You must use careful consideration when setting the logging options to avoid producing an excessive amount of log data.

Logging is discussed in greater detail in Log Management, on page 213.

Using Ethernet Rules

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

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 Ethernet RulesThe examples in this section illustrate some common modifications to the default Ethernet rules in StoneGate and general steps on how each scenario is configured.

Logging Ethernet Protocol UseThe administrators at Company A have installed a Sensor in Transparent Access Control mode and they want to create some custom Ethernet rules. The administrators know that the majority of traffic uses the IPv4 protocol, but they do not have a clear idea of which other Ethernet protocols are being used in the company’s network. They decide to temporarily log the usage of Ethernet protocols, excluding IPv4, to gather data for a report. To do this, the administrators:1. Create a new IPS policy based on the IPS System template to replace the

System policy that they have currently installed.2. Add a new rule in the Ethernet rules to exclude IPv4 traffic from logging:

TABLE 13.2 Ethernet Rule for Excluding IPv4 Traffic from Logging

Source Destination Service Action Options

ANY ANY IPv4 Allow Logging: None


3. Add a rule to log the use of other Ethernet protocols:

4. Save and install the policy on the Sensor.5. View the logs generated by the matches to the Ethernet rules in the Logs view.6. Create a report based on the log data to help them visualize the patterns of

Ethernet protocol use (see Reports, on page 237 for more information about Reports).

7. Disable the logging Ethernet rule to prevent excess log data from being generated.

Restricting the Use of Ethernet ProtocolsNow that the administrators at Company A from the previous example have a clear picture of which Ethernet protocols are being used in the company’s network, they want to restrict which protocols are allowed. The administrators determine that ARP and Spanning Tree Protocol (SPT) must be allowed. Since the majority of traffic will use these protocols, the administrators do not want to log matches to the rules that allow specific protocols.They decide to block the Cisco Discovery Protocol (CDP) on the logical interface named Inline interface because of the security problems it creates, and store log entries of detected CDP use.To do this, the administrators:1. Add a new rule in the Ethernet rules to allow ARP, Spanning Tree Protocol (SPT),

and IPv4 without producing any logs:

TABLE 13.3 Ethernet Rule for Logging Ethernet Protocol Use


ANY ANY ANY Allow Logging: Stored

TABLE 13.4 Ethernet Rule for Allowing ARP and SPT Use

Logical Interface Source Destination Service Action Options

ANY ANY ANYARPSPTIPv4

Allow Logging: None

Examples of Ethernet Rules 143

2. Add another rule to block the use of Cisco Discovery Protocol (CDP) on the Inline interface, and produce logs that will be stored:

3. Add a rule on the last line of the Ethernet rules to block the use of other Ethernet protocols without producing logs:

4. Save and install the policy on the Sensor.

TABLE 13.5 Ethernet Rule for Blocking CDP Use


Inline interface ANY ANY CDP Discard Logging: Stored

TABLE 13.6 Ethernet Rule for Blocking Other Ethernet Protocols


ANY ANY ANY ANY Discard Logging: None


CHAPTER 14 Access Rules

Access rules are lists of matching criteria and actions that define which IPv4 traffic is allowed or discarded or inspected against the Inspection rules. They also define which IPv4 traffic inline sensors stop or which IPv4 traffic passed through without inspection.


Overview to IPS Access Rules, on page 146 Configuration of IPS Access Rules, on page 146 Using IPS Access Rules, on page 152 Examples of IPS Access Rules, on page 155

145

Overview to IPS Access RulesThe IPS Access rules are used only by sensors. The role of the Access rules in the IPS is to define which traffic is inspected against the Inspection rules, which traffic inline sensors stop, and which traffic is passed through without inspection. The Access rules are stored in policy elements, which are discussed in IPS Policies, on page 125.In StoneGate IPS, the Access rules are simpler than in firewalls. The main visible differences between the firewall and IPS Access rules is that there is no connection tracking and no user authentication in IPS Access rules.The traffic matching in IPS Access rules is based on source IP address, destination IP address, and port information included in the packets. Additional matching criteria that is not based on information in the packets includes the day of the week and the time of day (allowing you to enforce rules during specific 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:• Allow the traffic with inspection against the Inspection rules.• Allow the traffic without IPS inspection.• Stop the traffic, if the traffic is traversing the inline interfaces of a sensor (requires

that the sensor is licensed for the Transparent Access Control feature).Regardless of which of the above actions is taken, a matching rule can also create a log or alert entry.

Configuration of IPS Access RulesAccess rules are configured on the Access Rules tab inside IPS 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 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 Service) must be set to some value other than NONE for the rule to be valid. The Logical Inteface cell is also matched against traffic, but it is not

Mandatory cells for matching traffic

Logging and further inspection is configured in the Options cell


146 Chapter 14: Access Rules

mandatory to change it if you want the rule to apply regardless of the interface. 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 IPS 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 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.

Logical Interface

Matches the rule based on which interface the traffic is picked up from. The same logical interface may be assigned to one or several interfaces as configured in the properties of the Sensor. This cell accepts only Logical Interface elements.

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


Considerations for Designing Access RulesOne of the crucial issues in designing any 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 stop the processing from continuing down the Access 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. At its simplest, this principle 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 Exempting Traffic from Inspection, on page 155 for a more detailed example.

Default ElementsThe IPS System Template Policy has pre-defined Access rules, Inspection rules, and Ethernet rules. Because the IPS System Template is added in the system and updated through dynamic update packages, the policy you currently have in your system may look slightly different from the one that is presented in this section. Newer versions of the policy work in the same way as described below. Any changes are documented in the Release Notes document for each dynamic update package.

ServiceThe Services match a certain port, but they can also contain a Protocol Agent that defines the protocol for the traffic when it is further inspected against the Inspection rules.

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

OptionsThe options for logging, deep packet inspection (whether traffic is matched against Inspection rules), and blacklisting.

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


Tag


TABLE 14.1 Access Rule Cells (Continued)

Cell Explanation


The pre-defined Access rules do not stop any traffic by default, but they direct all traffic to be checked against the Inspection rules.

Illustration 14.3 System Template Policy - Access Rules

In the illustration above, you can see several Access rules with various Services defined with Continue as the action, a yellow insert point indicating the place where a Policy that uses the System Template can be edited, and a rule below the insert point that is set to Allow all traffic.• The rules above the insert point do not determine if traffic is allowed to pass (the

action is Continue). These rules set parameters for further matching rules. Their task is to ensure that unless otherwise defined in rules added to the insert point, all traffic is inspected against the Inspection rules.

• The rule below the Insert point is the actual rule that picks up the parameters of the Continue rules above and, using the parameters set in the continue rules, directs the traffic to further examination against the Inspection rules.

The Access rules that you add at the insert point in custom policies based on this template are (in most cases) quite specific exceptions to the rules explained above. For example, you could insert a rule there that allows a connection between two


particular hosts to continue without any further inspection, or rules for inline sensors to always stop traffic between particular IP addresses and ports.

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, which also determines the protocol used in the Inspection rules for matching traffic (the protocol that is detected and selected for traffic by an Access rule is a matching criteria in the Inspection rules). 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 different types of traffic.Protocol Agent parameters are available for some Protocols in Service elements. The Protocol Agent parameters are primarily used with firewalls, as Sensors support only some of the Protocol Agents and only some of the parameters available for them.You can set the Service to ANY to make the rule match all protocols. A previous Continue rule may define a Protocol for traffic allowed by rules that use ANY as the Service (see Configuring Default Settings for Several Rules, on page 153). For more information on Services, see Chapter 8, Network Elements and Services.


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.

Task 4: Select Rule OptionsEach Access rule has three types of options: logging options, a deep packet inspection option, and blacklisting options.By default, the Logging options are set to Undefined, which means that no log entry is issued when the rule matches (note that this differs from firewall Access rules). If this is what you want, you can leave the setting as Undefined.The log levels are as follows:• None.• Alert.• Stored (saved on the Log Server).Logging is discussed in greater detail in Log Management, on page 213.

TABLE 14.2 Action field options

Action Explanation

Allow The traffic is let through the sensor.

Continue

Stores the contents of the Options cell and the Protocol Agent option (inside 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 153.

DiscardThe traffic is silently dropped if going through an Inline interface. This action requires a that the sensor is licensed for the Transparent Access Control feature.

Refuse

The traffic is dropped if going through an inline interface and an ICMP error message is sent in response to notify the packet’s sender. This action requires a that the sensor is licensed for the Transparent Access Control feature.

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.

Apply Blacklist

Checks the packet against the blacklist according to the options set for this rule. If the packet matches a blacklist entry and is going through an inline interface, the sensor discards the connection.


The Inspection option determines whether matching traffic is inspected against the Inspection rules (Deep Inspection).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 guarded by two different StoneGate components. The default setting is to take all blacklist entries into account from any other Firewall, Sensor, or Analyzer (that is managed by the same Management Server) regardless of the component that created the entry.

Task 5: 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 sensor’s local time zone. Also consider that UTC time does not adjust to daylight saving time (summer time).

Using IPS Access Rules

Adding Comments to RulesAccess rule tables can grow large, so comments are a good way to ensure that the rules are easy to read. You can add comments in 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 CommunicationsIf NAT is applied to StoneGate system communications, you must create Location elements and add Contact Addresses for the elements to define which translated addresses are necessary for making contact.If you have Inline Sensors, be careful that you do not define rules that would prevent other StoneGate components from communicating with each other through the sensor. The system communications are detailed in StoneGate IPS Ports, on page 267.There are predefined Service elements in the system for all system communications. You can use these in your Access rules as necessary (see Network Elements and Services, on page 89).


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.The options that can be set using Continue rules in IPS Access rules includes:• The Protocol option inside the Service used.• The Logging options.When a connection matches a rule with Continue as the action, 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. A Continue rule can be overridden by some subsequent Continue rule that has an identical scope (Source, Destination, and Service), 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.Continue rules are defined in the same way as other rules. However, you must keep in mind that many or even all rules below may be affected. The Continue rule options are used by the rules below, provided that the Source, Destination, and Service 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.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 the ProtocolDefault Protocol Agents are set using the Continue action. This way, the correct Protocol is used also for traffic that is allowed by rules that match any Service (and therefore have no particular Service element that would set the correct protocol). The Protocol element is needed to associate the traffic with the correct protocol for further inspection and to handle some types of traffic, such as FTP, correctly. The System template includes several Continue rules that associate all traffic with Protocols according to standard ports.If you have TCP and UDP services set up in your network under non-standard ports, the traffic may not be associated correctly to the correct protocol and be therefore inspected at a more general (TCP or UDP) level. In this case, you can create your own custom Situation for the traffic and add it in your policy to have the traffic inspected

Using IPS Access Rules 153

with the correct protocol information. Only some protocols and some of their parameters are supported in the services that are used in IPS policies.You can also add your own rules for the opposite purpose: to have some traffic not inspected as a particular protocol, but more generally as TCP or UDP traffic. In this case, you add a rule in your policy that includes the general TCP or UDP Service element from the IP-proto branch of the Services tree.

Rematching Tunneled PacketsIf a Sensor inspects tunneled traffic (IP in IP tunneling or Generic Routing Encapsulation is used), the traffic can be checked against Access rules and/or IPv6 Access rules several times according to the number and type of layers in the tunnel. For example, when an IPv4 datagram contains an IPv6 datagram, the IPv4 datagram is first matched according to Access rules. If the tunneling Service in the Access rule specifies that the encapsulated IPv6 datagram should be matched again, the contents are then matched against the IPv6 Access rules.To limit the number of encapsulating layers, the Sensor engine properties define the maximum rematch count. By default, the maximum rematch count is 1. If this count is exceeded, the packet is discarded and a log or an alert is generated.

Using Aliases in Access RulesAliases are one of the most useful tools for reducing the complexity of a policy. In a sense, Aliases are like variables in a mathematical equation—their value changes depending on the component on which they are installed. Because Aliases are able to change their meaning to adapt to local contexts, they can be used to create a single rule that changes in meaning depending on where it is installed. Thanks to Aliases, you can use a single rule to replace multiple, near duplicate rules created separately for each sensor.To better understand this concept, let us consider an example company, which has its headquarters in Helsinki and branch offices in Atlanta, Munich, Tokyo, and Montreal. Each of these offices has its own Web server. In this scenario, it seems we would require a separate rule or set of rules for each location’s Web server.By using aliases, however, we can create a single rule or set of rules that is still valid in all parts when applied on different components.The administrator of the example company can create a Web server alias, $WebServers. In the Alias’s properties, the administrator defines what $WebServers means for each component. For the sensor in Helsinki, the Web server would be defined as 192.168.1.101, for the sensor in Tokyo as 192.168.2.101, and so on.When the administrator installs a policy containing the Web server rules with the Alias, the addresses are translated to the correct address on that component. Therefore, when the policy is installed on the Helsinki sensor, the Alias translates to an IP address of 192.168.1.101. The other addresses are not included in the policy that is transferred to that particular engine.


Validating RulesYou can validate the rules in the IPS 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 IPS Access RulesThe examples in this section illustrate some common uses for IPS Access rules in StoneGate and general steps on how each scenario is configured.

Exempting Traffic from InspectionAt Company A, there is a sensor deployed between the general office network and a subnetwork.

Illustration 14.4 Company A’s Networks

In the subnetwork, there are several servers that provide services to the general office network as well as the StoneGate Management Server and Log Server. There is also a StoneGate firewall deployed between the internal and external networks. There is heavy traffic to the subnetwork where the internal servers are, so the administrators decide to exempt the log transmissions between the StoneGate firewall and the Log Server from being inspected against the IPS Inspection rules to reduce the Sensor’s workload. The administrators:1. Create a new IPS policy based on the IPS System template to replace the

System policy that they have currently installed.2. Add a new rule in the Access rules for their sensor:

TABLE 14.3 Access Rule for Exempting Traffic from Inspection Against the Inspection Rules


Firewall Log ServerSG Engine to Log

AllowDeep inspection: Off


Filtering Traffic on an Inline SensorAdministrators at company B decide that they want more control over which hosts and ports can be used between two networks.

Illustration 14.5

Hosts in the two networks must be able to communicate between each other using certain specific ports. Additionally, one of the administrators has a workstation connected to Network A. The administrator’s workstation must have unrestricted access to Network B. The administrators decide that the inline sensor provides an acceptable level of security at this point between two internal networks. They:1. Create elements for network A, network B, and administration host.2. Add new Access rules for their inline sensor:

• Each of the first two rules allows traffic between the Source and the Destination in both directions. The order of the elements within the Source, Destination, and Service cells makes no difference to the outcome of the matching process.

• The order of the rules is important. The rules above proceed correctly from most specific to the least specific. The two first rules must be in this order, because the administrators want all connections from the Administrator host (which is in Network A) to always match the first rule and never the second one, since the rules have different logging options.

TABLE 14.4 Access Rules for Filtering Traffic


AdministratorNetwork B

AdministratorNetwork B

ANY AllowLogging: UndefinedDeep inspection: On

Network ANetwork B

Network ANetwork B

Service elements for allowed services

AllowLogging: StoredDeep inspection: On

ANY ANY ANY Refuse

Logging: StoredDeep inspection: (irrelevant, because dropped traffic is never inspected further)


• The last of the added rules stops all traffic that is not allowed in the rules above to prevent unauthorized traffic from passing.

Note – If the inline interfaces are on a fail-open network card, traffic passes freely whenever the sensor is offline regardless of what the Access rules state.



CHAPTER 15 IPv6 Access Rules

IPv6 Access rules are lists of matching criteria and actions that define whether IPv6 traffic is allowed or discarded.


Overview to IPv6 Access Rules, on page 160 Configuration of IPv6 Access Rules, on page 160 Using IPv6 Access Rules, on page 166

159

Overview to IPv6 Access RulesIPv6 Access rules are used only by sensors. The role of the IPv6 Access rules is to define which IPv6 traffic is inspected against the Inspection rules, which traffic inline sensors stop, and which traffic is passed through without inspection. The IPv6 Access rules are stored in policy elements, which are discussed in IPS Policies, on page 125.The traffic matching in IPv6 Access rules is based on source IP address, destination IP address, and port information included in the packets. Additional matching criteria that is not based on information in the packets includes the day of the week and the time of day. This allows you to enforce rules during specific times, such as during working hours.The IPv6 Access rules in policies provide several different ways to react when some traffic is found to match a rule. You can:• Allow the traffic with inspection against the Inspection rules.• Allow the traffic without IPS inspection.• Stop the traffic if the traffic is traversing the inline interfaces of a sensor (requires

that the sensor is licensed for the Transparent Access Control feature).Regardless of which of the above actions is taken, a matching rule can also create a log or alert entry.

Configuration of IPv6 Access RulesIPv6 Access rules are configured on the IPv6 Access Rules tab inside IPS Policy and Template Policy elements.

Illustration 15.1 Newly Inserted IPv6 Access Rule - Main Cells

Illustration 15.1 displays an IPv6 Access rule that has just been inserted into the policy. The Source, Destination, and Service cells are set to NONE, so this rule never matches traffic until they are changed to ANY or to some more specific value. The Logical Inteface cell is also matched against traffic, but it is not mandatory to change it if you want the rule to apply regardless of the interface. The other editable cells specify further conditions and options for handling connections that match the cells that are used for traffic matching. It is not necessary to modify all cells in each rule.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

Mandatory cells for matching traffic


Logging and further inspection is configured in the Options cell

160 Chapter 15: IPv6 Access Rules

use in IPv6 Access rules. Network elements used in IPv6 Access rules must contain IPv6 addresses.

Illustration 15.2 Elements in IPv6 Access Rules

The table below explains briefly what each IPv6 Access rule cell does and which elements you can use in the rules. 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 15.1 IPv6 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.

Logical Interface


Source Elements containing the IPv6 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 that contain an IPv6 address.

Destination

ServiceThe Services match a certain port, but they can also contain a Protocol Agent that defines the protocol for the traffic when it is further inspected against the Inspection rules.

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

OptionsThe options for logging and deep packet inspection (whether traffic is matched against Inspection rules).


Considerations for Designing IPv6 Access RulesLike Access and Inspection rules, IPv6 Access rules are read from the top down, and more specific rules must be placed above more general rules that match the same traffic. The actions Allow and Discard stop the processing from continuing down the rule table for any packet 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. If the traffic does not match any of the IPv6 Access rules by the end of the policy, it is allowed by default.

Default ElementsThe IPS System Template Policy has pre-defined Access rules, Inspection rules, Ethernet rules, and IPv6 Access rules. Because the IPS System Template is added in the system and updated through dynamic update packages, the policy you currently have in your system may look slightly different from the one that is presented in this section. Newer versions of the policy work in the same way as described below. Any changes are documented in the Release Notes document for each dynamic update package.The pre-defined IPv6 Access rules do not stop any traffic by default, but they direct all traffic to be checked against the Inspection rules.



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. 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 IPv6 Access Rule Cells (Continued)

Cell Explanation


Illustration 15.3 System Template Policy - IPv6 Access Rules

In the illustration above, you can see several IPv6 Access rules with various Services defined with Continue as the action, a yellow insert point indicating the place where a Policy that uses the System Template can be edited, and a rule below the insert point that is set to Allow all traffic.• The rules immediately above the insert point do not determine if traffic is allowed to

pass (the action is Continue). These rules set parameters for further matching rules. Their task is to ensure that unless otherwise defined in rules added to the insert point, all traffic is inspected against the Inspection rules.

• The rule below the Insert point is the actual rule that picks up the parameters of the Continue rules above and, using the parameters set in the continue rules, directs the traffic to further examination against the Inspection rules.

The IPv6 Access rules that you add at the insert point in custom policies based on this template are (in most cases) quite specific exceptions to the rules explained above. For example, you could insert a rule there that allows a connection between two particular hosts to continue without any further inspection, or rules for inline sensors to always stop traffic between particular IP addresses and ports.

Configuration WorkflowThe following sections provide an overview of the configuration tasks related to configuring and customizing IPv6 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 IPS 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 that have IPv6 addresses can be used to represent IPv6 addresses in the Source and Destination cells. Aliases, Groups, Address Ranges, and Expressions are especially useful for defining IPv6 addresses in complex scenarios. You can set these cells to ANY to make the rule match all possible source or destination IPv6 addresses. Also, you can add more than one element in each cell to make the rule match several IPv6 addresses.

Task 2: Define the ServiceThe Service cell defines which protocol(s) the rule you design applies to. It also determines the protocol used in the Inspection rules for matching traffic (the protocol that is detected and selected for traffic by an IPv6 Access rule is one of the matching criteria in the Inspection rules). 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 different types of traffic.Protocol Agent parameters are available for some Protocols in Service elements. The Protocol Agent parameters are primarily used with firewalls, as Sensors support only some of the Protocol Agents and only some of the parameters available for them.You can set the Service to ANY to make the rule match all protocols. A previous Continue rule may define a Protocol for traffic allowed by rules that use ANY as the Service (see Configuring Default Settings for Several Rules, on page 166). For more information on Services, see Chapter 8, Network Elements and Services.

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

TABLE 15.2 Action Field Options

Action Explanation

Allow The traffic is let through the sensor.

Continue

Stores the contents of the Options cell and the Protocol Agent option (inside 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 166.


Task 4: Select Rule OptionsEach IPv6 Access rule has two types of options: logging options and a deep packet inspection option.By default, the Logging options are set to Undefined, which means that no log entry is issued when the rule matches (note that this differs from firewall Access rules). If this is what you want, you can leave the setting as Undefined.The log levels are as follows:• None.• Alert.• Stored (saved on the Log Server).Logging is discussed in greater detail in Log Management, on page 213.The Inspection option determines whether matching traffic is inspected against the Inspection rules (Deep Inspection).

Task 5: 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 sensor’s local time zone. Also consider that UTC time does not adjust to daylight saving time (summer time).

DiscardThe traffic is silently dropped if going through an Inline interface. This action requires a that the sensor is licensed for the Transparent Access Control feature.

Refuse

The traffic is dropped if going through an inline interface and an ICMP error message is sent in response to notify the packet’s sender. This action requires a that the sensor is licensed for the Transparent Access Control feature.

TABLE 15.2 Action Field Options (Continued)

Action Explanation


Using IPv6 Access Rules

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

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.The options that can be set using Continue rules in IPv6 Access rules includes:• The Protocol option inside the Service used.• The Logging options.When a connection matches a rule with Continue as the action, the rule’s settings are written to memory, and 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. A Continue rule can be overridden by some subsequent Continue rule that has an identical scope (Source, Destination, and Service), 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.Continue rules are defined in the same way as other rules. However, you must keep in mind that many or even all rules below may be affected. The Continue rule options are used by the rules below, provided that the Source, Destination, and Service 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.

Using Continue Rules to Set the ProtocolDefault Protocol Agents are set using the Continue action. This way, the correct Protocol is also used for traffic that is allowed by rules that match any Service (and therefore have no particular Service element that would set the correct protocol). The Protocol element is needed to associate the traffic with the correct protocol for further inspection and to handle some types of traffic, such as FTP, correctly. The System template includes several Continue rules that associate all traffic with Protocols according to standard ports.


If you have TCP and UDP services set up in your network under non-standard ports, the traffic may not be associated with the correct protocol, and may be inspected at a more general (TCP or UDP) level. In this case, you can create your own custom Situation for the traffic and add it in your policy to have the traffic inspected with the correct protocol information. Only some protocols and some of their parameters are supported in the services that are used in IPS policies.You can also add your own rules for the opposite purpose: to have some traffic not inspected as a particular protocol, but more generally as TCP or UDP traffic. In this case, you add a rule in your policy that includes the general TCP or UDP Service element from the IP-proto branch of the Services tree.

Rematching Tunneled PacketsIf a Sensor inspects traffic that is tunneled using IP-in-IP tunneling or Generic Routing Encapsulation (GRE), the traffic can be checked against IPv6 Access rules and/or Access rules several times according to the number and type of layers in the tunnel. For example, when an IPv4 datagram contains an IPv6 datagram, the IPv4 datagram is first matched according to the Access rules. If the tunneling Service in the Access rule specifies that the encapsulated IPv6 datagram should be matched again, the contents are then matched against the IPv6 Access rules.To limit the number of encapsulating layers, the Sensor engine properties define the maximum rematch count. By default, the maximum rematch count is 1. If this count is exceeded, the packet is allowed or discarded according to the settings specified in the Sensor properties, and a log or an alert may be generated.

Using Aliases in IPv6 Access RulesAliases are one of the most useful tools for reducing the complexity of a policy. Their value changes depending on the component on which they are installed. Because Aliases are able to change their meaning to adapt to local contexts, they can be used to create a single rule that changes in meaning depending on where it is installed. Thanks to Aliases, you can use a single rule to replace multiple, near duplicate rules created separately for each sensor.

Validating RulesYou can validate the rules in the IPS policy while you are editing it, or 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.

Using IPv6 Access Rules 167


CHAPTER 16 Inspection Rules

Inspection Rules are lists of matching criteria and actions. They define how the sensors and analyzers look 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 170 Configuration of Inspection Rules, on page 170 Using Inspection Rules, on page 177 Example of Inspection Rules, on page 178

169

Overview to Inspection RulesInspection rules define how the actual traffic analysis is done after the traffic has been allowed through the simple filtering in Access rules. The Inspection rules look inside the packets after the Access rules have allowed them and throughout a connection or several connections to see if the data being transferred contains a malicious pattern. The Inspection rules are stored in policy elements, which are discussed in IPS Policies, on page 125.There are three general cases where Inspection rules help:• You can detect attempts to exploit known vulnerabilities in one of your systems.

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 sequences 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.

• You can detect patterns in traffic, which alone do not cause alarm, but together present real threats. For example, you can detect if someone in your network is secretly scanning the network structure.

Inspection rules work by comparing traffic to patterns of known security threats. The 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.The Inspection rules provide several different ways to react when some traffic is found to match a rule. You can:• Allow the traffic without further inspection (for example, to eliminate a false

positive).• Stop the traffic, if it is going through an inline sensor.• Reset the connection.• Blacklist the connection on a StoneGate firewall or sensor.Regardless of which of the above actions is taken, you can also create:• A log entry with or without recording some of the detected traffic.• An alert with or without recording some of the detected traffic.

Configuration of Inspection RulesThe sensors inspect traffic based on Situation elements, which contain the information about known vulnerabilities and attacks. The same Situation elements can be used in Inspection rules of both firewalls and sensors. (However, only HTTP and SIP situations can be used in a Firewall Policy, as these are the two protocols the firewall currently supports for deep packet inspection). Analyzers use Correlation Situations, which contain the parameters according to which the Analyzer compresses and further analyzers the traffic already inspected by sensors.

170 Chapter 16: Inspection Rules

Inspection rules are configured on the Inspection Rules tab inside IPS Policy and IPS Template Policy elements. Sub-Policies cannot contain Inspection rules.

Illustration 16.1 Newly Inserted Inspection Rule - Main Cells

Illustration 16.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 traffic identified as malicious. However, only Sensors use the Source and Destination information. Analyzers ignore the Source and Destination matches, so Correlation Situations cannot be limited by Source or Destination.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 117. The illustration below shows the types of elements you can use in Inspection rules.

Illustration 16.2 Elements in Inspection Rules

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

Situation cell defines which traffic patterns the rule matches

Severity can make the rule match only a subset of the selected Situations

Sensor or analyzer applies Action when it finds a match


the default order, but you can drag and drop them to your preferred order in your own Management Client.

TABLE 16.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. Correlation Situations are for use with analyzers.

Logical Interface


SeverityLimits the scope of the rule to those matching Situations that have a severity value within a range you define. This is useful with rules that include many or even all Situations in the Situation cell.

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 for traffic in the Access rules, in the Service cell of the rule that allows the traffic. The Protocol cell allows you to limit the scope of an Inspection rule based on the protocol that an Access rule has assigned.

ActionCommand for the sensor or analyzer to carry out when a connection matches the rule.

Options Options for logging, connection resetting and termination, and blacklisting.


CommentYour free-form comment for this rule. Note that you can also add separate comment rows in between rules.


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. Only Sensors use the Source and Destination information. Analyzers ignore the Source and Destination matches, so Correlation Situations cannot be limited by Source or Destination.

Default ElementsThe Inspection rules contain the actual traffic inspection parameters. By default, traffic that does not match any of the Inspection rules is allowed.

Illustration 16.3 System Template Policy - Inspection Rules

In the illustration above, you can see a yellow insert point at the top of the rule table and then only two rules below.

Tag


TABLE 16.1 Inspection Rule Cells (Continued)

Cell Explanation


• The first rule contains Situations that are tagged as Attacks or Successful attacks. This rule terminates (stops) matching traffic and triggers an alert entry, as you can see in the Options cell. This rule creates a warning during the policy installation if you install the policy on a sensor that has no inline interfaces. This is just to notify you that matching connections cannot be terminated as stated in the rule and does not prevent the system from carrying out the other parts of the rule (matching traffic creates an alert).

• The second rule picks up the less severe Situations and a match found in traffic creates a log entry.

Although the rules look brief, they both include a large number of Situation elements. Right-click a rule and select “Show Matching Situations” from the menu that opens to see which Situations the rule will match. This operation uses the values both in the Situation and the Severity cells no matter which cell you right-click.The Inspection rules you add at the insert point in your custom policies most often define:• The Situations that are not of interest in your environment, and thus do not need to

trigger even a log or alert entry.• The Situations that match to harmful traffic in your environment and trigger a

blacklisting response.

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.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, most of the Situations you add to the policy are those that you consider to be producing false positives in your environment (for example, Situations for exploit attempts against an operating system that is not used on any of your computers).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 118.

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 only a subset of the Situations that are included in the Situation cell based on their severity value. Restricting the scope using Severity is most useful when you use Tags in the Situations cell, or if the Situation cell is set to ANY.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 DestinationOnly Sensors use the Source and Destination information. Analyzers ignore the Source and Destination matches, so Correlation Situations cannot be limited by Source or Destination.The Source and Destination cells are used for limiting the scope of inspection on Sensors 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 exempt 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, 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). Each individual Situation matches only one protocol in any case.


Note – The Access rules determine the Protocol for the traffic. Inspection rules use the protocol information in the inspection process, and if no specific protocol is assigned to traffic in the Access rules, only more generic-level (TCP or UDP) Situations may be applied to the traffic.

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 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 stores the rule’s options (in the Options cell) in memory while the matching process continues. The options are used by later matching rules, unless overridden. See Setting Default Options for Several Inspection Rules, on page 177.

• Terminate stops the matching connection according to options set for the rule.

Task 6: Set the Options for the RuleEach rule has four types of options: for logging, for the Terminate action, for connection resets, and for blacklisting.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. By default, 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 some 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.

The log levels are the same as in Access rules. Logging is discussed in greater detail in Log Management, on page 213.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).The blacklisting options define how the blacklist entry is generated and to which inline sensor or firewall it is sent. Blacklisting is explained in more detail in Blacklisting, on page 193

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 engines’ 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, all settings in the Options cell can be set using Continue rules. Otherwise, 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 153.

Validating RulesYou can validate the rules in the IPS 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.

Using Inspection Rules 177

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 installed a new IPS system with the pre-defined System Policy. When they command the Sensor online, they soon start receiving alerts.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 few specific servers in the internal network, so they decide to modify the IPS policy so that they no longer receive notifications if this exploit is detected in communications between those servers. The administrators:1. Create Host elements to represent the servers.2. Create a Group element that includes the Host elements.

• The administrators name the Group so that it is immediately clear from the name that the Group contains the servers that run their custom-built application. This makes the new rule easier to read than if they included the hosts directly in the rule.

3. Create a new custom policy based on the IPS System template.4. Add the following rule in the Inspection rules in their policy:

• The IPS System template is designed so that the insert point is above the rule that defines an alert to be sent for detected attacks. This rule can therefore override the rule that triggers the alerts.

• If the Situation matches traffic between any other hosts than those included in the Group, the IP address does not match the ones defined in the new rule. The processing will continue to the next rule, which will trigger 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.

5. Install the new policy on the Sensors.

TABLE 16.2 Rule for Excluding

Situation Source Destination Action Options

The Situation element that is mentioned in the alerts in the Logs view.

The Group defining the internal servers.

The Group defining the internal servers.

Permit Logging: None


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 180 Configuration of Protocol Agents, on page 181 Using Protocol Agents, on page 182 Examples of Protocol Agent Use, on page 190

179

Overview to Protocol AgentsProtocol Agents are IPS modules for advanced processing of some protocols that require such handling. They can be used to extend the sensor’s Access rules with proxy-like application layer features. Protocol Agents are also used to associate traffic with a certain protocol for inspection against the Inspection rules.Protocol Agents can be used for:• Validating application-level protocol use (e.g. FTP command syntax).• Opening related connections when required (e.g. FTP data connections).Some protocols always require the use of the correct Protocol Agent to pass the IPS inspection.

Connection HandlingSome protocols require special handling on the sensor due to their complexity, address information in the data payload, related connections, and so on. Protocol Agents are provided to handle related connections for the following protocols:• FTP with the related active and passive data connections.• Microsoft RPC (MSRPC) for Microsoft Exchange and Outlook communications.• Oracle TNS protocol communications.• Remote Shell (RSH) protocol communications.• Session Initiation protocol (SIP) 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).

Protocol ValidationProtocol Agents can be used to validate communications against standards of specific protocols. How this exactly works depends on the protocol in question. The following Protocol Agents provide protocol validation:• FTP• HTTP and HTTP Proxy• ICMP• IPv4• IPv6• MSRPC• SIP• SMTP• SSH

180 Chapter 17: Protocol Agents

Configuration of Protocol AgentsThe Protocol Agents are represented in the Management Client by Protocol elements. Those Protocols that have an associated Protocol Agent state “Protocol Agent” as their type. Other Protocol elements are of the type “Protocol Tag”. The Protocol Agent elements represent software modules on the sensor that you activate by using a corresponding Protocol element in your configuration.

Illustration 17.1 Using Protocol Agents

As seen in Illustration 17.1, Protocol Agents are not placed directly in IPS policies. They are used inside custom Service elements that you create and which can then be used in Access rules. Whenever a rule that contains a Service with an associated Protocol Agent matches, the Agent is automatically activated.All Protocol Agents in the system are default elements and you cannot change them or add any new ones. To customize Protocol Agents for specific needs, you must use the Protocol Agent in a custom Service element you create and set parameters for the Protocol Agent in the properties of the Service. The Protocol Agent parameters can be accessed in the properties of Services that you have associated with a Protocol Agent that has configurable parameters.

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 those Protocol Agents that have configurable parameters, so if you want to modify how a Protocol Agent behaves, you must create a new custom Service of your own and attach the correct Protocol Agent to that Service.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.

Configuration of Protocol Agents 181

Task 2: Set Parameters for the Protocol AgentIf you create your own custom Service that uses a Protocol Agent, 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 Table 17.1.

Task 3: Put 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 IPS 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 is set to ANY. A more specific definition is in effect an override, as all Service elements either specify some particular Protocol Agent or that no Protocol Agent is used at all. Some protocols may require a Protocol Agent to be used if Connection Tracking is on for the rule, so those protocols may not be passed by a rule that allows any service without a matching Continue rule.If some of your network services are configured so that the identifying information is identical for two different types of services, for example, if two different TCP services have been set to use the same port, you must ensure that the Service with a Protocol Agent is not applied to traffic that does not use that protocol by ensuring that the different types of traffic do not match the same Access rule (whether a Continue rule or some ‘normal’ rule that sets a specific Protocol Agent).

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 sensor. 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).


The following Protocol Agents and parameters are available on Sensors:

TABLE 17.1 Protocol Agents Used by Sensors

Name Protocol Validation

Deep Inspection

Allow Related Connections

Protocol Agent Parameters

FTP (see FTP Agent, on page 184)

yes yes yesAllow Active Mode Allow Passive Mode

GRE (see GRE Agent, on page 185)

yes yes n/aApply Tunnel RematchTunnel IPv4 ProtocolTunnel IPv6 Protocol

H.323 (see H.323 Agent, on page 185)

no yes no no

HTTP and HTTP Proxy (see HTTP Agents, on page 185)

yes yes n/a Logging of Accessed URLs

ICMP (see ICMP Agent, on page 186)

yes no n/a n/a

IPv4 (see IPv4 Agent, on page 186)

yes no n/a n/a

IPv4 Encapsulation (see IPv4 Encapsulation Agent, on page 186)

yes yes n/a Apply Tunnel Rematch

IPv6 (see IPv6 Agent, on page 187)

yes no n/a n/a

IPv6 Encapsulation (see IPv6 Encapsulation Agent, on page 187)

yes yes n/a Apply Tunnel Rematch

MSRPC (see MSRPC Agent, on page 187)

yes yes yes no

NetBIOS (see NetBIOS Agent, on page 187)

no yes n/a no

Oracle (see Oracle Agent, on page 187)

no yes yes no

Remote Shell (RSH) (see Remote Shell (RSH) Agent, on page 188)

no yes yes no


FTP AgentOne of the most common ways to transfer files across networks is using the File Transfer Protocol (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 the actual ports used 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 is platform-independent.Table 17.2 lists the parameters that the FTP Protocol Agent adds to Service elements that use it:

Services in Firewall (see Services in Firewall Agent, on page 188)

n/a n/a n/a no

SIP (see SIP Agent, on page 188)

yes yes yes n/a

SMTP (see SMTP Agent, on page 189)

yes yes n/a no

SSH (see SSH Agent, on page 189)

yes yes n/a no

SunRPC (see SunRPC Agents, on page 189)

no yes no no

TCP (see TCP Proxy Agent, on page 189)

no yes no no

TFTP (see TFTP Agent, on page 190)

no yes yes no

TABLE 17.1 Protocol Agents Used by Sensors

Name Protocol Validation

Deep Inspection

Allow Related Connections

Protocol Agent Parameters

TABLE 17.2 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


GRE AgentThe Generic Routing Encapsulation (GRE) protocol is a tunneling protocol that allows the encapsulation of network layer packets inside IP tunneling packets.Table 17.3 lists the parameters that the GRE 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.There are no configurable parameters for this Protocol Agent.

HTTP AgentsThere are two Hypertext Transfer Protocol (HTTP) Protocol Agents available on sensors:

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

TABLE 17.3 GRE Protocol Agent Parameters


Apply Tunnel Rematch

Rematches the encapsulated payload inside the tunneling packet until the maximum rematch count defined in the Sensor Properties is reached.Options: On (default)/Off

Tunnel IPv4 ProtocolSpecifies that IPv4 traffic is encapsulated in the tunneling packet.Options: On (default)/Off

Tunnel IPv6 ProtocolSpecifies that IPv6 traffic is encapsulated in the tunneling packet.Options: On (default)/Off

TABLE 17.2 FTP Protocol Agent Parameters (Continued)



• The HTTP agent can be used to log the URLs from HTTP requests. This agent has parameters you can set in the Service properties.

• The HTTP Proxy 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.4 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.

IPv4 AgentThe IPv4 Agent provides protocol inspection for IPv4 traffic. This Protocol Agent is available only on Sensors. There are no configurable parameters for this Protocol Agent.

IPv4 Encapsulation AgentThe IPv4 Encapsulation Agent provides protocol inspection for tunneled IPv4 traffic. This Protocol Agent specifies rematching parameters for IPv4 packets encapsulated in IPv6 packets.Table 17.5 lists the parameters that the IPv4 Encapsulation Protocol Agent adds to Service elements that use it.

TABLE 17.4 HTTP Protocol Agent Parameters


Logging of Accessed URLsDefines whether the URL address used in the communications is logged or not.

TABLE 17.5 IPv4 Encapsulation Protocol Agent Parameters



Rematches the encapsulated payload inside the tunneling packet until the maximum rematch count defined in the Sensor Properties is reached.

Options: On (default)/Off


IPv6 AgentThe IPv6 Agent provides protocol inspection for IPv6 traffic. This Protocol Agent is available only on Sensors. There are no configurable parameters for this Protocol Agent.

IPv6 Encapsulation AgentThe IPv6 Encapsulation Agent provides protocol inspection for tunneled IPv6 traffic. This Protocol Agent specifies rematching parameters for IPv64 packets encapsulated in IPv4 packets.Table 17.6 lists the parameters that the IPv6 Encapsulation Protocol Agent adds to Service elements that use it.

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. The 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. There are no configurable parameters for this Protocol Agent.

NetBIOS AgentThis Protocol Agent provides deep inspection for Windows NetBIOS Datagram Service connections. 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.

TABLE 17.6 IPv6 Encapsulation Protocol Agent Parameters



Rematches the encapsulated payload inside the tunneling packet until the maximum rematch count defined in the Sensor Properties is reached.

Options: On (default)/Off


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.7 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.8 lists the parameters that the Remote Shell (RSH) Protocol Agent adds to Service elements that use it:

Services in Firewall AgentThis Protocol Agent is intended for services running on firewall nodes. 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. 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 range of dynamic ports does not need to be allowed in the policy.

TABLE 17.7 Oracle Protocol Agent Parameters


Allow Related ConnectionsAllows/disallows database connection based on information in the listener connection.Options: True (default)/False

TABLE 17.8 Remote Shell (RSH) Protocol Agent Parameters


Allow Related ConnectionsAllows standard error (stderr) stream as a response to an RSH command.Options: True (default)/False


Table 17.9 lists the parameters that the SIP Protocol Agent adds to Service elements that use it:

SMTP AgentThe Simple Mail Transfer Protocol (SMTP) Protocol Agent provides protocol validation and deep inspection. There are no configurable parameters for this Protocol Agent.

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. There are no configurable parameters for this Protocol Agent.

SunRPC AgentsStoneGate provides both UDP and TCP based Protocol Agents for Sun Remote Procedure Call (RPC) protocol. These protocol agents provide deep inspection.The Portmapper Protocol Agents collect information about RPC services by interpreting the GET PORT and DUMP PORTS requests and their respective answers. All information they collect 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 information received is stored in cache.There are no configurable parameters for these Protocol Agents.

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 closing of the connection does not complete in a specified period of time.There are no configurable parameters for this Protocol Agent.

TABLE 17.9 SIP Protocol Agent Parameters


Allow Related ConnectionsAllows the SIP media connections based on the signalling connection.Options: True (default)/False


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).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” of “write” command to the server. The server opens a data connection from a dynamic source port to the client’s destination port, which is same as the one used as the source port of the control connection.Table 17.10 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 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 has made a decision to keep track of which web pages the employees visit. In addition to logging the connections, the administrators also want to 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 Protocol Agent in a Continue rule.

TABLE 17.10 TFTP Protocol Agent Parameters


Allow Related ConnectionsAllows replies to TFTP requests. Options: True (default)/False.


The administrators:1. Add the Continue rule above the existing Access rule like this:

2. Refresh the policy on the sensor.

TABLE 17.11 Example Rules for Company B

Source Destination Service Action

Internal Networks ANY “HTTP (with URL Logging)” default Service. Continue

Internal Networks ANY ANY Allow

Examples of Protocol Agent Use 191


CHAPTER 18 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 194 Configuration of Blacklisting, on page 195 Using Blacklisting, on page 196 Examples of Blacklisting, on page 197

193

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. 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 18.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.

194 Chapter 18: 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 18.1 Blacklisting Configuration

In Illustration 18.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 195

Task 1: Define Blacklisting in the 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 PolicyBlacklist 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 Sensors and Analyzers. 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 IPS policy. The Access rule applies blacklisting

and allows the Management Server to send blacklist requests to the Sensor(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 Sensor(s) that will receive the blacklist request.

Examples of Blacklisting 197

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.


Logs, Alerts, And Reports

CHAPTER 19 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 202 Configuration of Filters, on page 202 Using Filters, on page 210 Examples of Filters, on page 210

201

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 19.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.

202 Chapter 19: Filters

In addition to permanent Filters, you can also create temporary Filters in the Logs view (see Temporary Filters and Browsing Logs Interactively, on page 210).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 19.2 Matching Events with a Filter

Illustration 19.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 Table 19.1.

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 210.

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 19.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 19.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 19.3 for details.• Logical operations are used for the AND, OR, NOT types of logical operations. See

Table 19.4 for details.You can use different operation types in the same Filter. The operation types are explained in detail below.

TABLE 19.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 19.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 19.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.

smaller thanMatches when the value on the left-hand side of this operation is smaller than the value on the right-hand side.

smaller than or equal

Matches 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 19.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 19.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 19.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.

Illustration 19.3 Using the Defined Operation in a 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 19.5.

TABLE 19.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 Analyzer handles the undefined result as True by filter, which means that the log data matches the Filter.


These four different Undefined value policy settings are compared below with an example.

Illustration 19.4 Undefined Values When Matching an Event

The example Filter in Illustration 19.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 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 213)• archiving, exporting and deleting logs, alerts and audit data (see Log Management,

on page 213)• creating reports (see Reports, on page 237). • selecting data for Correlation Situations (see Situations, on page 117).

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 View for Viewing Logs with a Certain IP AddressThe 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 from Servers in Internal Network Excluding a ServerStoneGate IPS has detected and stopped an attack connected to an application X in Company B’s network. Application X is used on all the servers in the network except on HOST2. Company B’s administrator decides to investigate the attack and wants to create a report of all the logs from the servers excluding HOST2. The administrator needs a new Filter for creating the report. The administrator: 1. Creates a new Filter in which the source IP and destination IP address fields in log

data are compared to the internal network’s addresses.2. Adds a condition that the IP source or destination address in the log data may

not belong to HOST2.

Illustration 19.5 Filter Excluding A Server

Examples of Filters 211


CHAPTER 20 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 214 Configuration of Log Management, on page 215 Using Log Management, on page 221 Examples of Log Management, on page 222

213

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 therefore 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 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 only logging 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.

214 Chapter 20: 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 225.

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 333.

Configuration of Log ManagementThe following illustrations demonstrate how different log data is logged and stored in StoneGate.Illustration 20.1 shows the processing of log entries.

Illustration 20.1 Log Entry Processing


Events on Analyzers produce log entries, which are sent to the Log Server and stored there. Events on Sensors produce log entries that are sent to the Analyzer, and the Analyzer sends them to the Log Server. You can view the log entries in the Management Client’s Logs view. The Log Server delivers the log data to the Management Client based on the users’ requests. You can also create reports based on the entries saved on the Log Server. In this case the log data goes through the Management Server.Illustration 20.2 shows the processing of alert entries.

Illustration 20.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 also 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 20.3 shows the pruning of log entries.


Illustration 20.3 Pruning Log Entries

Illustration 20.3 shows the pruning of log entries. The IPS policy defines the important events to be sent to the Log Server for logging and alerting. The Log Server receives the event data from the Analyzers, and the events are logged and alert notifications are sent according to the Alert policy. In addition, Sensors send traffic recording files to the Analyzers, which forward them to the Log Server.All log entries that the administrators consider irrelevant can be discarded automatically using the Immediate Discard filters. The Immediate Discard deletes 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 in the Current Logs mode (if the 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 stored 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 237.


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 Filters, on page 201.

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 Logs, Alerts, and Reports.

Task 1: Set Logging OptionsBefore log data of traffic handled by the IPS engines can be viewed or used in any meaningful way, the logging options must first be configured in the IPS Policy.By default, an access rule’s logging option 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 20.1 explains the logging levels

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.

TABLE 20.1 Log Levels

Log Level Explanation

Alert An alert entry is generated.

Stored A log entry is generated and stored on the Log Server.

None The rule does not produce any log entries.


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 Field Values, on page 307.

Task 2: 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.

Illustration 20.4 Log Pruning

Illustration 20.4 shows the two pruning options available for the IPS 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 20.4 on page 219. 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 3: 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 tasks and run them manually as necessary or automatically according to a schedule. The task properties define what each task does when executed. Table 20.2 explains the different types of log tasks and the operation types for the export task.

TABLE 20.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: 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.


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.

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, e.g., “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 343 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

Using Log Management 221

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, 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, i.e., 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 225.

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 343 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 20.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

TABLE 20.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.

Examples of Log Management 223

“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: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 21 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 226 Configuration of Alert Escalation, on page 226 Using Alert Escalation, on page 232 Example of Alert Escalation, on page 234

225

Overview to Alert EscalationAlert entries inform the administrators that there is a problem with the StoneGate system, that a test or a task has failed, or that 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. If you so wish, you can configure StoneGate to be much more active than that. You can send alert notifications out from the system as e-mail, SMS text messages or 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 the Alert Configuration branch of the tree in the Configuration view.

Illustration 21.1 Alert Handling Process

1. A Sensor sends alert entries to an Analyzer when a matching Access or Inspection rule contains an Alert element in its rule options or when a failure is detected when running a test that is correctly configured. The Analyzer may also detect a test failure or a match to an Inspection rule and generate an alert entry based on that. The Analyzer forwards the alert entries to the Log Server. Depending on the engine version and hardware, the Sensors and Analyzers may also send alert entries about changes in their status (for example, changes in interface or hard disk status). The Management Server sends alerts to the Log

1

3

2

4

226 Chapter 21: Alert Escalation

Server if a task (for example, a policy installation or backup task) fails or critical system events occur. When a secondary Management Server is configured in the system, only the currently active Management Server sends alerts.

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. If you have installed the System Policy or a custom policy based on the System Template Policy, you will receive alerts on some of the detected Situations. Apart from these alerts, the only other 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 problems in

the operation of StoneGate, including tasks (for example, policy installation or backup tasks) that fail.

• Default Alert element: the Default Alert is used by default in the System Template Policy for Situations with the Tag “Attacks” or “Successful Attacks”. 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).

• System Situations: the System Situations contain definitions for problems in the system that trigger a System Alert. There are no configurable parameters for System Situations and there is never any need to have them in any policy.

System SituationsStoneGate has predefined System Situations for both firewalls and IPS to represent certain critical system events. These Situations trigger a System Alert. The System Situations are not configurable and they are not used in security 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 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 21.2 Alert Chain

Alert Chains contain a list of actions that are executed from top to bottom. Each row in the Alert Chain defines a Channel and a Destination address for the notification:• The Custom Script channel executes a script stored on the Log Server. The

Destination cell must contain the name of the script.• The DELAY channel is not a way to send notifications. 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 add a delay at the top of the Alert Chain before any action.

• The SMS channel sends 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.

• The SMTP channel sends an e-mail. The Destination cell must contain one or more e-mail addresses in a form that your SMTP server is able to use.

• The SNMP channel sends an SNMP trap. The Destination cell is not used with this channel.

• The USER NOTIFICATION channel 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.

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 Final Action option below the Alert Chain table defines what is done if the Alert Chain is completed without any administrator acknowledging the alert.

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.

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.

TABLE 21.1 Alert Policy Fields

Field Explanation

SenderAllows you to limit the rule to match alert 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.

Severity

Allows you to limit the rule to match alert entries that have a Severity value from within a certain range. 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 21.2 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.


As the different Alert Channels have varying possibilities for relaying information, the amount of information the alert notification gives regarding the Situation depends on the Alert Channel used. The information included in alert notifications is detailed by Alert Channel in the table below.

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 acknowledging the alert entry in the Logs view. The Final Actions are explained in the table below.

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 21.3 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 233.

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.

TABLE 21.4 Final Actions

Final Action Explanation

None Stops the escalation of this alert entry.

TABLE 21.2 Configurable Alert Channels (Continued)

Alert Channel Configuration


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 security 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.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). You must also 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.

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 from the next rule below the rule that redirected the processing to this Alert Chain.

TABLE 21.4 Final Actions (Continued)

Final Action Explanation


Using a Custom Script for Alert EscalationFor the 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 Table 21.5.

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.

TABLE 21.5 Arguments Passed to the Custom Scripts

Argument number Content Description

1 Alert ID Identifies the alert uniquely in the Log Server.

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 233

The Linux/Unix script in Illustration 21.3 is an example on how to create an operating system log entry using the custom script alert notification.

Example of Alert EscalationThe example in this section illustrates a common use for Alert Escalation in StoneGate and the general steps on how the scenario is configured.

Escalating Alerts Based on ResponsibilitiesIn this example, a company has two sites, a branch office (BO) and a headquarters (HQ) site, which both have their own administrators. Both sites have an Analyzer 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:

Illustration 21.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 21.6 “HQ Important Alerts” Alert Chain

Channel Destination Delay

SMS [Phone number for HQ shared mobile phone] 15 min


• 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.

• “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.

SMS [Phone number for BO shared mobile phone]

TABLE 21.7 “HQ Minor Alerts” Alert Chain


USER NOTIFICATIONHQ Administrator AHQ Administrator B[etc.]

60 min

SMS [Phone number for HQ shared mobile phone]

TABLE 21.8 Example Alert Policy

Sender Alert and Situation Severity Chain

HQ Analyzer HQ Log ServerManagement Server

ANY 5...10 HQ Important Alerts

HQ AnalyzerHQ Log ServerManagement Server

ANY 1...4 HQ Minor Alerts

BO Analyzer BO Log Server

ANY 5...10 BO Important Alerts

BO AnalyzerBO Log Server

ANY 1...4 BO Minor Alerts

TABLE 21.6 “HQ Important Alerts” Alert Chain (Continued)


Example of Alert Escalation 235

4. Define the SMS channel in the BO Log Server’s properties.5. Install the new Alert Policy on both Log Servers.


CHAPTER 22 Reports

Reports are summaries of logged firewall and IPS events as well as monitoring statistics.


Overview to Reports, on page 238 Configuration of Reports, on page 239 Using Reports, on page 246 Examples of Reports, on page 251

237

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 61.

Illustration 22.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.

238 Chapter 22: 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 22.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 22.3 shows how the report designs, report sections and report items are displayed in the Management Client.

Illustration 22.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 22.1 describes the summary types.

TABLE 22.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 22.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 22.2 Predefined Report Item Types

Report Item Type Explanation

Common General items that count log data from any StoneGate component.

TABLE 22.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 reports 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.

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.

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 22.2 Predefined Report Item Types (Continued)

Report Item Type Explanation


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 22.3.

TABLE 22.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.

Log Data TypesAllows you to select the type of logs from which the data is selected for the report.


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 22.4 explains in detail the different properties you can set for a report section.

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 22.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 22.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.

Log Data TypesAllows you to select the type of logs from which the data is selected for the report.

TABLE 22.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 IPS 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.

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 22.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 22.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 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 247

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 reports contain the statistics in tabulated tables. The Tab characters and the operating environment specific line endings delimit the text.

TABLE 22.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 22.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.

Illustration 22.5 Example of a Plain Text Report File

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 22.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 249

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 22.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 22.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. The administrator: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. The administrator: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 251


Administration

CHAPTER 23 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 256 Configuration of Categories, on page 256 Using Categories, on page 257 Examples of Categories, on page 257

255

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.The Not Categorized Category contains all elements that do not belong to any specific Category. This can be useful for cases where the same elements would belong to all of the categories. Rather than adding the elements to each category, you can leave them in the Not Categorized Category and select it as part of a combined Category Filter.

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.

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

256 Chapter 23: Categories

are existing elements and a new Category, it may be more convenient to assign the elements to the Category when you create it. 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• Incident Cases• Locations• Monitoring Users• Updates• Authentication Services• Users• IPS Inspection Protocols• IPS Logical Interfaces• 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 258 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.

Examples of CategoriesThe examples in this section illustrate some common uses for Categories in StoneGate and general steps on how each scenario is configured.

Managing a Large EnterpriseCompany 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

Using Categories 257

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 23.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.

258 Chapter 23: Categories

CHAPTER 24 Incident Cases

The Incident Case element is a tool for investigating incidents of suspicious activity.


Overview to Incident Cases, on page 260 Configuration of Incident Cases, on page 260 Using Incident Cases, on page 262 Example of an Incident Case, on page 262

259

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 Elements.

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 24.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 shows all the log and audit entries that track actions performed in this incident case window

260 Chapter 24: Incident Cases

Task 2: Attach DataThe following types of data can be attached:

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 24.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 261

Using Incident CasesThere are many ways an administrator could 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 263


Appendices

APPENDIX A StoneGate IPS Ports

StoneGate IPS uses SSL/TLS-secured TCP connections between the system components. The connections and the TCP ports used are illustrated below.

Illustration A.1 TCP Connections Between the StoneGate IPS Components

267

In Illustration A.1, the listening TCP ports are indicated in the boxes next to each system component. The connections are established in the direction of the arrows. The dashed arrows indicate the one-time connections during the initial configuration of the system components when they establish a trust relationship with the Management Server. After a successful initial connection, all the communications between the components take place as indicated by the arrows with the solid lines.The following table lists the ports used in communication between the StoneGate IPS components.

TABLE A.1 StoneGate IPS Ports

Listening hosts Port/Protocol Contacting

Hosts Service Description Service Element Name

Analyzer 18889/TCPManagement Server

Control connections, status monitoring, and policy upload

SG Commands (Analyzer)

Analyzer 18890/TCP Sensor Event data sent from the Sensors. SG Event Transfer

Analyzer 4950/TCPManagement Server

Remote upgrade from the Management Server

SG Remote-Upgrade

Analyzer 514/UDP syslogSyslog messages forwarded to Analyzer

Syslog (UDP)

Log Server 3020/TCPAnalyzer, Sensor

Log and alert messages from Analyzers and recording file transfers from Sensors

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)

Management Server

3021/TCPSensor, Analyzer

Initial contact from Sensor or Analyzer during installation

SG Initial Contact

Management Server

5936/TCP Log ServerInitial contact from Log Server during installation

SG Log Initial Contact

Management Server

8902-8913/TCP

Management Client, Log Server

Management Client and Log Server connections to the Management Server

SG Control

Monitoring Server

8919-8921/TCP

Monitoring Client

Monitoring Client connection to Monitoring Server.

SG Control (Monitoring Client)

268 Appendix A: StoneGate IPS Ports

Sensor 18888/TCPManagement Server

Control connections, status monitoring, and policy upload

SG Commands (Sensor)

Sensor

3000-3001/UDP3002,3003, 3010/TCP

SensorHeartbeat and state synchronization between the cluster nodes.

SG State Sync (Multicast), SG State Sync (Unicast), SG Data Sync

Sensor 4950/TCPManagement Server

Remote upgrade from the Management Server

SG Remote Upgrade

StoneGate firewall

15000/TCPManagement Server, Analyzer

Blacklist entries sent to firewall SG Blacklisting

TABLE A.1 StoneGate IPS Ports (Continued)

Listening hosts Port/Protocol Contacting

Hosts Service Description Service Element Name

269

270 Appendix A: StoneGate IPS Ports

APPENDIX B Command Line Tools

This appendix describes the command line tools for StoneGate Management Center and the engines.


Management Center Commands, on page 272 Engine Commands, on page 280

271

Management Center CommandsThe Management Server and the 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.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.

Note – Using the Management Client is the recommended configuration method, as most of the same tasks can be done through it.

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 option 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 option 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 option is not defined, the username root is used.o=OUTPUT_FILE parameter defines the destination file where the logs will be exported. If this option 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.

272 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.

sgCertifyMonitoringServerCertifies the Monitoring Server on the Management Server. The certificate is required to allow secure communication between the Monitoring Server and the Management Server.

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.

TABLE B.1 Management Center Command Line Tools (Continued)

Command Description

Management Center Commands 273

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 option 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 option 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 option is not defined, the username root is used.o=OUTPUT_FILE parameter defines the destination file where the logs will be exported. If this option 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 analyzer or the sensor.

TABLE B.2 StoneGate-specific Command Line Tools on Engines

Command Description

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

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

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.

sg-contact-mgmt

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]

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]

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]

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-status [-l] [-h] Displays information on the engine’s status.-l option displays all available information on engine status.-h option displays usage information.

TABLE B.2 StoneGate-specific Command Line Tools on Engines (Continued)

Command Description

Engine Commands 281

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.

sg-toggle-active SHA1 SIZE |--force [--debug]

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-version Displays the software version and build number for the node.

sginfo [-f] [-d] [-s] [-p] [--] [--help]

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.2 StoneGate-specific Command Line Tools on Engines (Continued)

Command Description

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.

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

Engine Commands 283


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 286 System Aliases, on page 287

285

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.

286 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.

287

288 Appendix C: Predefined Aliases

APPENDIX D Situation Context Parameters

This appendix describes the parameters you can define for Situation Contexts.

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.


Port/Host Scan Detection Parameters, on page 290 Correlation Context Parameters, on page 291 Regular Expression Parameter, on page 294 Other Context Parameters, on page 294

289

Port/Host Scan Detection ParametersThe table below explains the parameters for the Scan Started Event Context.

TABLE D.1 Scan Detection Parameters


Port scan start period (seconds)Port scan is reported if any of the thresholds is exceeded within this time limit.

Port scan idle timeout (seconds)Port scan is assumed finished if the originator makes no scan attempts within this time limit.

Port scan status delay (seconds) Defines how often an interim status of ongoing port scan is reported.

Maximum normal TCP connectionsDefines how many TCP connections that proceed normally according to the protocol definitions are allowed before action is taken.

Maximum allowed open TCP portsNumber of SYN+ACK replies allowed during the tracking before action is taken.

Maximum unreplied TCP connections

Number of unreplied TCP connections during the tracking before action is taken.

Maximum allowed closed TCP portsNumber of RST replies allowed during the tracking before action is taken.

Maximum TCP segments with no SYN or ACK

Number of TCP segments with no SYN or ACK flag before action is taken.

Wait time for TCP connectionsSeconds waited before considering TCP connection as successful port scan or unreplied connection attempt.

Maximum UDP packet destinationsNumber of UDP destinations allowed per host during the tracking before action is taken.

Maximum bidirectional UDP transfers

Number of bidirectional UDP transfers allowed per host during the tracking before action is taken.

Maximum unidirectional UDP transfers

Allowed number of UDP destinations that have not replied or have replied with ICMP error during the tracking period before action is taken.

Maximum allowed closed UDP portsNumber of ICMP Port Unreachable replies allowed per host during the tracking before action is taken.

Maximum ICMP requests per hostNumber of ICMP request destinations allowed per host during the tracking before action is taken.

Maximum unreplied ICMP request destinations

Number of ICMP request destinations that have not replied during the tracking allowed per host before action is taken.

290 Appendix D: Situation Context Parameters

Correlation Context Parameters

Event CompressEvent Compress combines repeated similar events into the same log entry, reducing clutter in the Logs view.

Maximum ICMP Echo Request destinations

Number of ICMP Echo Request (ping) destinations allowed per host during the tracking before action is taken.

Maximum unreplied ICMP Echo Requests

Number of ICMP Echo Request (ping) destinations that have not replied during the tracking allowed per host before action is taken.

Maximum ICMP Timestamp Request destinations

Number of ICMP Timestamp Request destinations allowed per host during the tracking before action is taken.

Maximum unreplied ICMP Timestamp Requests

Number of ICMP Timestamp Request destinations that have not replied during the tracking allowed per host before action is taken.

Maximum ICMP Netmask Request destinations

Number of ICMP Netmask Request destinations allowed per host during the tracking before action is taken.

Maximum unreplied ICMP Netmask Requests

Number of ICMP Netmask Request destinations that have not replied during the tracking allowed per host before action is taken.

TABLE D.1 Scan Detection Parameters (Continued)


TABLE D.2 Event Compress Parameters

Field Option (if any) Explanation

Correlated Situations Situation(s) you want to compress.

Time WindowAll the matches to the Situation(s) selected are combined to a common log entry when they are triggered within the defined time from each other.

Log Fields Enabled

SelectEvents triggered by the selected Situations are considered the same when the values those entries have in the Log Fields you place in Lognames are identical.

IgnoreEvents triggered by the selected Situations are considered the same, except when the values those entries have in the Log Fields you place in Lognames are identical.

LognamesThe selected log fields are used by the matching option you selected in the previous step.

291

Event CountEvent Count finds recurring patterns in traffic by counting the times certain Situations occur within the defined period, so that action can be taken if the threshold values you set are exceeded.

Location

Very Early The execution order of the Compress operation in relation to other operations. Compress operations that share the same Location are executed in parallel; each compress operation receives the same events as the other compress operations in the same Location. “Very Early” and “Early” locations may effect the operation of other Correlations.

Early

Late

Very Late

Compress Filter Filters in data for the compression.

TABLE D.2 Event Compress Parameters (Continued)




Correlated Situations Situation(s) you want to count.

Time WindowThe period of time within which the matches to the Situation must occur the specified number of times.

Alarm ThresholdThe number of times that the selected Situation(s) must occur for the Correlation Situation to match.

Log Fields Enabled

SelectEvents triggered by the selected Situations are considered the same when the values those entries have in the Log Fields you place in Lognames are identical.

IgnoreEvents triggered by the selected Situations are considered the same, except when the values those entries have in the Log Fields you place in Lognames are identical.

LognamesThe selected log fields are used by the matching option you selected in the previous step.


Event GroupEvent Group finds event patterns in traffic by following if all events in the defined set of Situations match at least once in any order within the defined time period.

Event MatchEvent Match allows filtering event data produced by specific Situations using Filter expressions.



Member (column)

Event Match Filter for grouping.

Needed NumberHow many occurrences of the Event selected for this Member are required for them to be included in the grouping.

Binding Log field used for the grouping.

Correlated Situations Situation(s) you want to group.

Keep and Forward Events

Yes

Makes the Correlation Situation examine the events and trigger the desired response defined in the Inspection rule but does not actually group the matching events into one. All the individual events are still available for further inspection, event though they have already triggered a response.

No

Makes the Correlation Situation group the matching events together, so that only the response defined for the inspection rule is triggered, and no further processing is done on the individual events.

Time Window SizeThe period of time within which the Situation must occur for them to be grouped.

Continuous Responses

YesMakes the Analyzer respond as defined in the Inspection rule to each occurrence of the defined event within the selected Time Window.

NoMakes the Analyzer respond only to the first occurrence of the defined event within the selected Time Window.


Field Explanation

Correlated Situations Situation(s) you want the Correlation Situation to match.

293

Event SequenceEvent Sequence finds event patterns in traffic by following if all events in the defined set of Situations match in a specific order within the defined time period.

Regular Expression ParameterSee Regular Expression Syntax, on page 295.

Other Context ParametersSee the properties dialog of the Context in question (the Contexts are shown as branches/sub-branches in the Situations→By Context tree in the Configuration view).

Filter Filter for finding a pattern in the event data.

TABLE D.5 Event Compress Parameters (Continued)

Field Explanation



Entry to/Exit from (columns)

Event Match Filter for selecting data for the sequencing.

Binding Log field that the Correlation Situation traces to find a sequence.

Correlated Situations Situation(s) from which you want to find sequences.

Keep and Forward Events

Yes

Makes the Correlation Situation examine the events and trigger the desired response defined in the Inspection rule but does not actually group the matching events into one. All the individual events are still available for further inspection, event though they have already triggered a response.

No

Makes the Correlation Situation group the matching events together, so that only the response defined for the inspection rule is triggered, and no further processing is done on the individual events.

Time Window SizeThe period of time within which the Situation must occur for them to be considered a sequence.


APPENDIX E 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 296 Special Character Sequences, on page 299 Pattern-Matching Modifiers, on page 300 Variable Extensions, on page 302 Parallel Matching Groups, on page 305

295

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 E.1.

TABLE E.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.

296 Appendix E: Regular Expression Syntax

It is also possible to indicate repeated, consecutive regular expressions by using quantifiers as described in Table E.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 E.1 StoneGate Regular Expression Syntax (Continued)

Sequence Description Example

TABLE E.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.

297

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 302.Illustration E.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 E.2 StoneGate Regular Expression Quantifiers (Continued)

Quantifier Description Example

Illustration E.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 E.3.

TABLE E.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”.

299

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 E.4.

TABLE E.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 E.4 Pattern-Matching Modifiers (Continued)


301

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 E.5.

TABLE E.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 E.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 E.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 E.5 Variable Extensions (Continued)


Illustration E.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})

303

$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 E.5), except that the variable’s value is not user-changeable.

Illustration E.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 E.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 E.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 E.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 E.4 Setting a parallel Matching Group

#!!GROUP(1)This heavy regular expression is matched in parallel matching group 1.#!!#

#Insert regular expression below

305


APPENDIX F Log Field Values


Log Entry Table, on page 308 Facility Field Values, on page 325 Type Field Values, on page 327 Action and Event Occurrences, on page 328 VPN-Related Information Messages, on page 329 Audit Entry Types, on page 333 Syslog Entries, on page 339 Log Fields Controlled by the Additional Payload Option, on page 340 Connection States, on page 341

307

Log Entry TableThe following table lists all fields of the log entry table. The rights of the administrator who views the logs and the log type(s) that the administrator has selected for viewing determine which fields are displayed.

TABLE F.1 Fields of the Log Entry Table

Field Description

Acknowledged Acknowledged Alert

ActionConnection action. The action values are Allow, Discard, Refuse, Terminate, Wait for further actions, and Wait for authentication.

Administrator Administrator who triggered the event

Alert Type Type of alert

Attacker IP IPv4 address of the attacking host

Auth. User Username of authorized user

Blacklist executor Target firewall or sensor

Blacklist response Firewall blacklist response

Blacklist response.Blacklist duration

Duration of blacklisting in seconds

Blacklist response.Blacklist executor

Target firewall or sensor

Blacklist response.Endpoint1 addr

Blacklisted IP addresses for Endpoint1.

Blacklist response.Endpoint1 mask

Netmask for blacklisted Endpoint1 IP address (32 = host address)

Blacklist response.Endpoint1 port

Blacklisted Endpoint1 port (empty = all ports)

Blacklist response.Endpoint1 port range

Blacklisted Enpoint1 port range.

308 Appendix F: Log Field Values

Blacklist response.Endpoint2 addr

Blacklisted IP addresses for Endpoint2

Blacklist response.Endpoint2 mask

Netmask for blacklisted Endpoint2 IP address (32 = host address)

Blacklist response.Endpoint2 port

Blacklisted Endpoint2 port (empty = all ports)

Blacklist response.Endpoint2 port range

Blacklisted Endpoint2 port range.

Blacklist response.Firewall ID

The ID number of firewall node for which the blacklist request is assigned (this must match the Firewall ID given to the blacklist Analyzer module).

Blacklist response.IP Protocol

IP protocol

Blacklist response.Value missing in

Blacklist Response field for which value resolving failed.

Bytes Rcvd Number of bytes received during connection

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.

Client IP address Address of the client who triggered the event

Connection analysis end

Application could not continue analyzing the traffic stream after this event

Content type of message body

Content type of the message body

Correlation begin time

Ntp stamp of beginning of time frame

Correlation base component ID

Indicates the policy which decides the response after successful correlation

TABLE F.1 Fields of the Log Entry Table (Continued)

Field Description

309

Correlation end time

Ntp stamp of end of time frame

Creation Time Entry creation time

Destination port TCP or UDP destination port in a packet header

DNS class DNS resource record class

DNS hdr ancount DNS answers count

DNS hdr arcount DNS additional section count

DNS hdr flag tc DNS header flag TC

DNS hdr id DNS message ID

DNS hdr is request DNS message is a request

DNS hdr nscount DNS authority section count

DNS hdr opcode DNS operation code

DNS hdr dqcount DNS questions count

DNS hdr rcode DNS return code

DNS name length Length of DNS name in a message

DNS offset DNS message offset where the situation occurs

DNS pointer Name pointer in a DNS message

DNS qclass Query resource record class in a DNS message

DNS qname First queried name in a DNS message

DNS qtype Query type in a DNS message

DNS section Section name in a DNS message

DNS type DNS resource record type

DNS UDP payload UDP payload size of a DNS message

DNS UDP payload by opt

UDP payload advertised in a DNS OPT record

Dst Addr Packet destination IP address


Field Description


Dst Port Packet destination protocol port

Elapsed TimeElapsed time of connection in seconds. It is only indicated when accounting entries are created, that is, when a connection is closed.

Element name Name of the element

Error id Identifier of the occurred error

Eth frame length Length of the Ethernet frame

Eth min frame length

Minimum length for Ethernet frame

Ethernet main type Ethernet frame main type (Ethernet 2, IPX, LLC, SNAP)

Ethernet type Type field in Ethernet frame

EventLogged event, e.g., New connection, Connection closed, Connection discarded

Event count Event count in the defined time frame

Event ID Event identifier, unique within one sender

Event type Description of the event

Event update Event id for which this event is update

Excerpt data Recording of the application level data stream of the attack

Excerpt position Position in the attached short recording

FacilityFirewall subsystem. For more information on facility values, see Table F.2

From address From address

FTP account len Length of the FTP account string

FTP adat argument len

Length of ADAT command argument

FTP allocate size Size of FTP allocate

FTP arg len Length of FTP command argument

FTP auth arg len Length of AUTH argument length


Field Description

311

FTP client state name

Detected FTP client state

FTP clnt arg len FTP CLNT argument length

FTP cmd name Name of the detected FTP command (no arguments)

FTP command The name of the FTP command

FTP conf arg len Length of CONF command argument

FTP enc arg len Length of ENC command argument

FTP eprt arg len Length of EPRT command argument

FTP estp arg len Length of ESTP command argument

FTP help arg len Length of HELP command argument

FTP lang arg len Length of LANG command argument

FTP lprt arg len Length of LPRT command argument

FTP marker len Length of REST command argument

FTP mic arg len Length of MIC command argument

FTP opts arg len Length of OPTS command argument

FTP password len Length of detected FTP password

FTP pathname len Length of detected FTP pathname

FTP protection buffer size

Detected PBSZ protection buffer size

FTP reply Detected FTP server reply

FTP reply code Detected FTP server reply code

FTP reply len Length of an FTP server reply that is too long

FTP reply line len Length of an FTP server reply line that is too long

FTP server action Server action after a suspicious client command

FTP server banner Detected FTP server banner

FTP server state name

Detected FTP server state


Field Description


FTP site arg len Length of SITE command argument

FTP state name Detected FTP session state

FTP username len Length of detected FTP username

HTTP header Detected HTTP header field.

HTTP header name Detected HTTP header field name

HTTP no request Response could not be associated to any request

HTTP request line HTTP request line

HTTP request message field name length

Length of HTTP request header field name

HTTP request message field value length

Length of HTTP request header field value

HTTP request method

Detected HTTP request method

HTTP request URI Detected HTTP request URI

HTTP request version

Detected HTTP request version

HTTP requests not stored

Number of requests not stored due to HTTP pipeline overflow

HTTP response code

Detected HTTP response code

HTTP response message field name length

Length of HTTP response header field name

HTTP response message field value length

Length of HTTP response header field value

HTTP URI length Length of HTTP request URI


Field Description

313

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 expected message length

Expected length of ICMP message

ICMP field addr entry size

Value of detected ICMP address entry size field

ICMP field address mask

Value of detected ICMP address mask field

ICMP field code ICMP code field value

ICMP field domain name

Value of detected ICMP domain name field

ICMP field gateway IP addr

Value of detected ICMP gateway address field

ICMP field lifetime Value of ICMP lifetime field

ICMP field num addrs

Value of ICMP number of addresses field

ICMP field originate timestamp

Value of ICMP originate timestamp field

ICMP field outbound hop count

Value of ICMP outbound hop count field

ICMP field output link mtu

Value of ICMP output link MTU field

ICMP field output link speed

Value of ICMP output link speed field

ICMP field pointer Offset where the situation occurred in the related datagram

ICMP field preference level

Value of ICMP preference level field

ICMP field receive timestamp

Value of ICMP receive timestamp field


Field Description


ICMP field return hop count

Value of ICMP return hop count field

ICMP field router addr

Value of ICMP router address field

ICMP field sequence num

Value of ICMP sequence number field

ICMP field traceroute id

Value of ICMP traceroute ID field

ICMP field transmit timestamp

Value of ICMP transmit timestamp field

ICMP field type Value of ICMP type field

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.

ICMP message length

Length of the ICMP message

ICMP referenced destination IP addr

Destination IP address of the datagram related to the ICMP message

ICMP referenced destination port

Destination port of the datagram related to the ICMP message

ICMP referenced IP proto

IP Protocol field of the datagram related to the ICMP message

ICMP referenced source IP addr

Source IP address of the datagram related to the ICMP message

ICMP referenced source port

Source port of IP datagram related to ICMP message


Field Description

315

ICMP Type

ICMP type attribute. 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.

IKE Cookie IKE Cookie

Imf encoded word Encoded word token related to this event

Imf header fieldContents (possibly partial) of the mail header field related to this event

Imf header field name

Name of the mail header field related to this event

Imf header field position

The number of characters processed in this header field when this event was generated

Imf token Syntactical token in mail body related to this event

Imf token length Length of the syntactical token in mail body related to this event

Incident case Incident case

Information message

Informative message to further explain the entry

IP checksum Value of IP header checksum

IP datagram length Length of an IP datagram

IP datagram new length

IP datagram suggested new length

IP destination Destination IP address in a packet header

IP frag conflict range

Conflicting byte range in a fragments

IP frag conflict range.IP frag different bytes

Total number of conflicting bytes

IP frag conflict range.IP frag different bytes first

First conflicting byte in the IP fragment


Field Description


IP frag conflict range.IP frag different bytes last

Last conflicting byte in the IP fragment

IP frag conflict range.IP frag different new first

Value of first conflicting byte in the latest fragment

IP frag conflict range.IP frag different new last

Value of last conflicting byte in the latest fragment

IP frag conflict range.IP frag different old first

Value of first conflicting byte in an earlier fragment.

IP frag conflict range.IP frag different old last

Value of last conflicting byte in an earlier fragment.

IP fragment offset Fragment offset in an IP header

IP header length Length of an IP header

IP identification Identification field in an IP header

IP offset Start offset of IP from the beginning of the ethernet frame

IP option length Length of IP option that triggered the response

IP option number IP option number that triggered the response

IP protocol IP protocol number in packet header

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.

IP source Source IP address in a packet header

IP total length Total length of an IP datagram

IP version Version field value in an IP header

Length of message body

Length of message body


Field Description

317

LLC DSAP Logical Link Control Destination Service Access Point

LLC SSAP Logical Link Control Source Service Access Point

Logical interface Logical interface for a packet

MAC destination Destination MAC address in a packet header

MAC source Source MAC address in a packet header

NAT Dst Translated packet destination IP address

NAT Dst Port Translated packet destination protocol port

NAT Src Translated packet source IP address

NAT Src Port Translated packet source protocol port

Node configuration Current configuration

Node dynup Uodate package level

Node version Node version

Normalized URI normalization was used to find the match

Not final value Entry is not final

One LANThe “View interface as one LAN” option was enabled on the logical interface through which the packet was received.

Origin name Name of the component that triggered the event

Original Alert Type Type of alert in the referred event

Original correlation begin time

Ntp stamp of the beginning of the time frame in the referred event

Original correlation end time

Ntp stamp of the end of the time frame in the referred event

Original event count

Number of events in the time frame of the referred event

Original severity Severity of the referred event

Original situation Identifier of the situation that triggered the referred event

Original time Time of creating the referred event


Field Description


Packet analysis end

Module could not continue analyzing packet or datagram after this event

Packet not seen Flag indicating that the related packet was not seen

Physical interface Physical interface for a packet

Priority The priority assigned to the traffic according to the QoS policy.

Protocol Connection IP protocol

Protocol Agent Protocol Agent numerical code.

QoS ClassThe Quality of Service class assigned to the traffic according to the QoS policy.

Reception time Time when the entry was received by the log server

Record ID Identifier of the traffic recording

Reference event ID Reference to a related event

Reference event ID.Ref Comp Id

Sender identifier of the referred event

Reference event ID.Ref Creation Time

The creation time of the referred event

Reference event ID.Ref Event ID

Identifier of the referred event

Result Result state

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.

Rule TagRule tag value of acceptance rule. When you click the Rule Tag cell, a Rule definition dialog opens. It shows the name of the policy, sub-policy, or template that generated the log record.

Scan ICMP echo no reply cnt

Number of ICMP Echo Request destinations with no reply

Scan ICMP echo request cnt

Number of ICMP Echo Request destinations detected


Field Description

319

Scan ICMP echo targets

List of the detected ICMP Echo Request destinations

Scan ICMP mask no reply cnt

Number of ICMP Netmask Request destinations with no reply

Scan ICMP mask request cnt

Number of distinct ICMP Netmask Request destinations detected

Scan ICMP mask targets

List of the detected ICMP Netmask Request destinations

Scan ICMP no reply cnt

Number of ICMP Echo, Timestamp, and Netmask Request destinations with no reply

Scan ICMP request cnt

Number of ICMP Echo, Timestamp, and Netmask Request destinations

Scan ICMP time no reply cnt

Number of ICMP Timestamp Request destinations with no reply

Scan ICMP time request cnt

Number of the distinct ICMP Timestamp Request destinations detected

Scan ICMP time targets

List of detected ICMP Timestamp Request destinations

Scan start time Detected starting time of this port scanning activity

Scan TCP negative cnt

Number of TCP destinations that replied with TCP Reset

Scan TCP no ack cnt

Number of TCP destinations targeted for illegal TCP segments

Scan TCP no ack targets

List of TCP destinations targeted for illegal TCP segments

Scan TCP no reply cnt

Number of TCP destinations with no reply to connection attempts

Scan TCP normal cnt

Number of TCP destinations with handshake and two-directional data transfer

Scan TCP positive cnt

Number of TCP destinations with handshake but no data sent by client

Scan TCP targets List of the detected TCP port scan destinations


Field Description


Scan UDP negative cnt

Number of destinations that replied with ICMP Port Unreachable

Scan UDP positive cnt

Number of two-directional UDP conversations detected

Scan UDP probe cnt

Number of destinations that did not reply using UDP

Scan UDP target cnt

Total number of UDP destinations detected

Scan UDP targets List of the detected UDP destinations

Sender Firewall or server node IP address that passes this information

Sender module version

Version of the module that generated the event.

Sender module version.Sender build

Build number of the engine that generated the event.

Sender module version.Sender module major

Major version of the module that generated the event.

Sender module version.Sender module minor

Minor version of the module that generated the event.

Sender module version.Sender module pl

Patch version of the module that generated the event.

Sender type Sender type

Severity Severity of a situation

SIP call ID SIP call ID

SIP contact address

SIP contact address

SIP header field contents

SIP header field contents


Field Description

321

SIP header field name

SIP header field name

SIP request method

method of a SIP request

SIP request URI URI of a SIP request

SIP request version version of a SIP request

SIP response reason-phrase

SIP response reason-phrase

SIP response status code

status code of a SIP response

SIP VIA address SIP VIA address

Situation The identifier of the situation that caused this event to be sent

SMTP command Suspicious SMTP command sent by the client

SMTP misplaced command

Command given in wrong place in the command sequence

SMTP recipient Recipient forward path in RCPT command parameter

SMTP reply Suspicious SMTP reply message sent by the server

SMTP reverse path SMTP reverse path in MAIL FROM command parameter

SMTP server action Suspicious server action after a suspicious client command

SMTP server banner

Banner sent by the SMTP server in the beginning of a connection

SMTP transaction state

Session state of the SMTP transaction

SNAP Organization Code

Subnetwork Access Protocol Organization Code

Source file Name of the source file

Source file line Line number in the source file

Source port TCP or UDP source port in a packet header

Src Addr Packet source IP address


Field Description


Src IF Defined source interface number for the firewall cluster

Src Port Packet source protocol port

Src VLAN Source VLAN ID number (up to 4095)

SSH calc client crypto bit ratio

Calculated SSH client crypto bit ratio

SSH calc server crypto bit ratio

Calculated SSH server crypto bit ratio

SSH1 host key bits Bit length of the SSHv1 host key

SSH1 server key bits

Bit length of the SSHv1 server key

State Connection state in connection monitoring

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 a UNIX server environment. For more information on syslog and syslog types, refer to RFC 3164.

Target IP IPv4 address of the target host

TCP connection start time

Start time of the TCP connection

TCP handshake seen

Initial handshake of the TCP connection detected

TCP option kind Type of the TCP option

TCP option length Length of the TCP option that caused the response

To address To address

TypeLog entry severity type. For more information on type values, see Table F.3

UDP datagram size Size of the UDP datagram

User and Group Information

User and Group Information

Username Username


Field Description

323

Whole session seen

True, if no data of this session has been missed up to this point


Field Description


Facil ity Field ValuesThe following table lists the possible values for the Facility field in the log table.

TABLE F.2 Facility Field Values

Value

Accounting

Authentication

Blacklisting

Cluster Daemon

Cluster Protocol

Connection Tracking

Data Synchronization

DHCP Client

DHCP Relay

Invalid

IPsec

License

Load balancing filter

Log Server

Logging System

Management

Monitoring

NetLink Incoming HA

Network Address Translation

Packet Filter

Protocol Agent

Server Pool

SNMP Monitoring

325

State Synchronization

Syslog

System

Tester

Undefined

User Defined

TABLE F.2 Facility Field Values (Continued)

Value


Type Field ValuesThe following table lists the possible values for the Type field in the log table.

TABLE F.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

327

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 F.4 Action and Event Occurrences

Action Event Description

Allow New connection A new connection is allowed through the engine.

Allow Related ConnectionA related connection is allowed through the engine. For example, an FTP data connection.

Allow Related PacketA related packet is allowed through the engine. 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 engine.

Discard Packet Discarded A packet is discarded by the engine.

Refused Connection Refused A connection is refused by the engine.

Terminate Connection Terminated A connection is terminated by the engine.

Went Online Indicates engine startup.

Went Offline Indicates that engine went offline.

New configuration successfully installed

New configuration is installed on the engine.

Security Policy reload New security policy is loaded on the engine.


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.

TABLE F.5 Common VPN-related Log Messages

Information/Error Message Description

[...] No proposal chosen

IKE negotiations failed. Usually, this message appears 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. If settings seem to match, activate IPsec diagnostics to see more verbose logs (produces more log entries).

[...] 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.

[...] SA install failedA negotiated SA could not be stored in memory. May indicate that the memory has run out.

[...] traffic selector mismatchThere is 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.

Authentication method mismatch

The authentication method used by the other gateway is not allowed in the configuration of this gateway. Check your VPN Profile.

Can not get policy [...] No matching connection

May indicate that the gateway has no valid VPN certificate.

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.

Dead peer detection failedIKE peer was found dead [...]

Dead peer detection checks the other gateway periodically when the VPN is established. If no response is received, the VPN tunnel is closed. Indicates that the other gateway is down, unreachable, or considers the VPN tunnel already closed.

ESP [...]AH [...]

Traffic going through the VPN tunnel. When you enable IPsec diagnostics you may see more of these messages.

329

IKE negotiation rate-limit reached, discard connection

This message is visible only when IPsec diagnostics are enabled.There is an excessive number of new VPN connection attempts within a short period of time. This mechanism is meant to protect the firewall from certain types of denial-of-service attacks.

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.

Invalid argumentVarious reasons. See the other log entries for more information. Activate IPsec diagnostics to see more verbose logs.

Invalid syntaxVarious reasons. See the other log entries for more information. Activate IPsec diagnostics to see more verbose logs.

NAT-T is not allowed for this peer

This message is visible only when IPsec diagnostics are enabled.NAT-T was requested by the other gateway but it is not allowed in the configuration of the gateway that sends this message.

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.

Proposal did not match policyThere is 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.

TABLE F.5 Common VPN-related Log Messages (Continued)



Remote address not allowed

A VPN client is trying to use an IP address that is out of the allowed address range. Check why the VPN client is assigned an illegal IP address and make sure all valid IP addresses are actually included in the range of allowed addresses in the Internal VPN Gateway properties.

Remote ID mismatch

The end-point identifies itself differently from what you have defined as the identity in the External VPN Gateway properties. Note that if an IP address is used as identity, the IP address used as the identity may be different from the IP address used for communications.

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.

Tunnel policy mismatch [...]

This message is visible only when IPsec diagnostics are enabled.Usually indicates 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.

Tunnel selection failed

An Access rule matched this connection, but the traffic could not be sent across the VPN. Most likely, this is due to the (possibly NATed) source or destination IP address not being included in the local or remote gateway’s Site as required or a connection that is not intended for the VPN matching the VPN rule.

Tunnel type mismatchUsually appears because a VPN client tried to connect, but VPN client access is not configured (correctly) on the gateway.



331

Unknown IKE cookie

This message is visible only when IPsec diagnostics are enabled.The other gateway identified an SA that does not exist on this node. If this is a cluster, this message is normal when the SA has been negotiated with a different node and the correct SA is then queried from the other nodes, allowing the connection to continue. This message can also appear if the SA has been deleted, for example, because of a timeout or dead peer detection having deleted the SA due to a non-responsive peer.




Audit Entry TypesThe following table explains the audit entry types.

TABLE F.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

333

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 F.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

335

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

337

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 F.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

339

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 F.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 F.9 lists the possible states.

TABLE F.9 Connection States

State Description

CP established StoneGate cluster protocol packet is recognized.

ICMP echo Ping reply is expected.

ICMP reply wait Other ICMP request/reply types.

Invalid The communication has violated the protocol.

IPsec established IPsec tunnel packet is recognized.

New New connection is being opened.

Related New connection related to an existing one is expected soon.

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.

TCP close waitOne end of the connection waits for the FIN packet (passive close).

TCP close wait ackWaiting ACK for the FIN before going to close wait status (passive close).

TCP closingClosing packet (FIN) sent by one end of the connection (simultaneous).

TCP closing ackWaiting ACK for the FIN before going to closing status (active close).

TCP established Normal status of TCP connections for data transfer.

TCP fin wait 1One end of the connection waits for sending the FIN packet (active close).

TCP fin wait 2 One end of the connection waits for receiving ACK packet.

341

TCP last ack One end of the connection sent a FIN packet (passive close).

TCP last ack wait Waiting for the FIN packet to be acknowledged.

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 syn fin seen T/TCP (Transactional TCP) connection, RFC 1644.

TCP syn returnReceived simultaneous SYN from the other end (simultaneous open).

TCP syn seen Very first packet sent by one end of the connection.

TCP time wait One end of the connection acknowledged closing packet (FIN).

TCP time wait ackWaiting ACK for the FIN status before going to time wait status (active close).

UDP established UDP connection is recognized.

Unknown established Connection from other transport level protocol.

TABLE F.9 Connection States (Continued)

State Description


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.

343

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)


344 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.



345

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.



347


APPENDIX H SNMP Traps and MIBs

StoneGate IPS 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 H.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-IPS-MIB (Table H.2)• STONESOFT-NETNODE-MIB (Table H.3).

TABLE H.1 SNMP Traps for StoneGate IPS

Trap name Objects Included Description

ipsPolicyInstall ipsSecurityPolicy Policy was installed on the IPS engine.

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.

349

The StoneGate IPS MIB files can be downloaded from the Stonesoft website at http://www.stonesoft.com/. The StoneGate IPS also supports objects in the following standard MIBs:• IF-MIB (RFC 2863) (Table H.4)• IP-MIB (RFC 2011) (Table H.5)• SNMP-USER-BASED-SM-MIB (RFC 3414) (Table H.6).• SNMPv2 MIB (RFC 3418) (Table H.7)

TABLE H.2 STONESOFT-IPS-MIB Objects

Object Name Object Description in MIB

ipsPolicyTime The time when the security policy was installed to the IPS engine

ipsSecurityPolicy Name of the current security policy on the IPS engine

ipsSoftwareVersion Version string of the IPS software

TABLE H.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

350 Appendix H: SNMP Traps and MIBs



TABLE H.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.

351

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 H.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.



353

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 H.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 H.5 IP-MIB Supported Objects (Continued)


355

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.



357

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 H.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 H.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 H.6 SNMP-USER-BASED-SM-MIB Objects (Continued)


359

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 H.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 H.7 SNMPv2-MIB Supported Objects (Continued)


361


APPENDIX I TCP/IP Protocol Headers

This appendix is a brief overview of the common TCP/IP protocol headers.


Internet Protocol (IP), on page 364 Internet Control Message Protocol (ICMP), on page 364 Transmission Control Protocol (TCP), on page 365 User Datagram Protocol (UDP), on page 365

363

Internet Protocol (IP)For the Internet Protocol (IP) specification, please refer to RFC791 available at http://www.rfc-editor.org/.

Internet Control Message Protocol (ICMP)For the Internet Control Message Protocol (ICMP) specification, please refer to RFC792 available at http://www.rfc-editor.org/.

TABLE I.1 IP Datagram

bits 0 - 7 bits 8 - 15 bits 16 - 23 bits 24 - 31

Version(4 bits)

IP Header Length (4 bits)

Type of Service(8 bits)

Total Length (in number of bytes)(16 bits)

IP Identification Number(16 bits)

Flags(3 bits)

Fragment Offset(13 bits)

Time to Live(8 bits)

Protocol Number(8 bits)

Header Checksum(16 bits)

Source IP Address(32 bits)

Destination IP Address(32 bits)

Options (if any) + Padding (matching to 32-bit boundary)

( data . . . )

TABLE I.2 ICMP Message


Type(8 bits)

Code(8 bits)

Checksum(16 bits)

( data . . . )

364 Appendix I: TCP/IP Protocol Headers

http://www.rfc-editor.org/



Transmission Control Protocol (TCP)For the Transmission Control Protocol (TCP) specification, please refer to RFC793 available at http://www.rfc-editor.org/.

User Datagram Protocol (UDP)For the User Datagram Protocol (UDP) specification, please refer to RFC768 available at http://www.rfc-editor.org/.

TABLE I.3 TCP Segment

bits 0 - 7 bits 8- 15 bits 16 - 23 bits 24 - 31

Source Port Number(16 bits)

Destination Port Number(16 bits)

Sequence Number(32 bits)

Acknowledgement Number(32 bits)

TCP Header Length (4 bits)

reserved(6 bits)

URG

ACK

PSH

RST

SYN

FIN

Window Size(16 bits)

Checksum(16 bits)

Urgent Pointer(16 bits)

Options (if any) + Padding (matching to 32-bit boundary)

( data . . . )

TABLE I.4 UDP Datagram


Source Port Number(16 bits)

Destination Port Number(16 bits)

User Datagram Length(16 bits)

Checksum(16 bits)

( data . . . )

365





366 Appendix I: TCP/IP Protocol Headers

APPENDIX J ASCII Character Codes

The decimal and hexadecimal values of the ASCII characters are presented for interpreting traffic captures and pre-defined Situation Contexts.


ASCII Character Codes, on page 368 ASCII Control Codes, on page 370

367

TABLE J.1 ASCII Character Codes

ASCII Dec Hex ASCII Dec Hex ASCII Dec Hex ASCII Dec Hex

NUL 0 0x00 SPACE 32 0x20 @ 64 0x40 ` 96 0x60

SOH 1 0x01 ! 33 0x21 A 65 0x41 a 97 0x61

STX 2 0x02 " 34 0x22 B 66 0x42 b 98 0x62

ETX 3 0x03 # 35 0x23 C 67 0x43 c 99 0x63

EOT 4 0x04 $ 36 0x24 D 68 0x44 d 100 0x64

ENQ 5 0x05 % 37 0x25 E 69 0x45 e 101 0x65

ACK 6 0x06 & 38 0x26 F 70 0x46 f 102 0x66

BEL 7 0x07 ' 39 0x27 G 71 0x47 g 103 0x67

BS 8 0x08 ( 40 0x28 H 72 0x48 h 104 0x68

HT 9 0x09 ) 41 0x29 I 73 0x49 i 105 0x69

LF 10 0x0A * 42 0x2A J 74 0x4A j 106 0x6A

VT 11 0x0B + 43 0x2B K 75 0x4B k 107 0x6B

FF 12 0x0C , 44 0x2C L 76 0x4C l 108 0x6C

CR 13 0x0D - 45 0x2D M 77 0x4D m 109 0x6D

SO 14 0x0E . 46 0x2E N 78 0x4E n 110 0x6E

SI 15 0x0F / 47 0x2F O 79 0x4F o 111 0x6F

DLE 16 0x10 0 48 0x30 P 80 0x50 p 112 0x70

DC1 17 0x11 1 49 0x31 Q 81 0x51 q 113 0x71

DC2 18 0x12 2 50 0x32 R 82 0x52 r 114 0x72

DC3 19 0x13 3 51 0x33 S 83 0x53 s 115 0x73

DC4 20 0x14 4 52 0x34 T 84 0x54 t 116 0x74

NAK 21 0x15 5 53 0x35 U 85 0x55 u 117 0x75

SYN 22 0x16 6 54 0x36 V 86 0x56 v 118 0x76

ETB 23 0x17 7 55 0x37 W 87 0x57 w 119 0x77

CAN 24 0x18 8 56 0x38 X 88 0x58 x 120 0x78

368 Appendix J: ASCII Character Codes

EM 25 0x19 9 57 0x39 Y 89 0x59 y 121 0x79

SUB 26 0x1A : 58 0x3A Z 90 0x5A z 122 0x7A

ESC 27 0x1B ; 59 0x3B [ 91 0x5B { 123 0x7B

FS 28 0x1C < 60 0x3C \ 92 0x5C | 124 0x7C

GS 29 0x1D = 61 0x3D ] 93 0x5D } 125 0x7D

RS 30 0x1E > 62 0x3E ^ 94 0x5E ~ 126 0x7E

US 31 0x1F ? 63 0x3F _ 95 0x5F DELETE 127 0x7F

TABLE J.1 ASCII Character Codes (Continued)

ASCII Dec Hex ASCII Dec Hex ASCII Dec Hex ASCII Dec Hex

369

TABLE J.2 ASCII Control Codes

ASCII Dec Hex Description

NUL 0 0x00 Null

SOH 1 0x01 Start of Heading

STX 2 0x02 Start of Text

ETX 3 0x03 End of Text

EOT 4 0x04 End of Transmission

ENQ 5 0x05 Enquiry

ACK 6 0x06 Acknowledge

BEL 7 0x07 Bell

BS 8 0x08 Backspace

HT 9 0x09 Horizontal Tabulation

LF 10 0x0A Line Feed

VT 11 0x0B Vertical Tabulation

FF 12 0x0C Form Feed

CR 13 0x0D Carrier Return

SO 14 0x0E Shift Out

SI 15 0x0F Shift In

DLE 16 0x10 Data Line Escape

DC1 17 0x11 Device Control 1




NAK 21 0x15 Negative Acknowledge

SYN 22 0x16 Synchronous Idle

ETB 23 0x17 End of Transmission Block

CAN 24 0x18 Cancel


EM 25 0x19 End of Medium

SUB 26 0x1A Substitute

ESC 27 0x1B Escape

FS 28 0x1C File Separator

GS 29 0x1D Group Separator

RS 30 0x1E Record Separator

US 31 0x1F Unit Separator

TABLE J.2 ASCII Control Codes (Continued)

ASCII Dec Hex Description

371


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 373

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.

374 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 375

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 405.

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 411.

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).

389

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 407. See also Security Association (SA), on page 415.

AH (Authentication Header)See Authentication Header (AH), on page 392.

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.

390

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 404.

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.

391

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 389.

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 418 and Public-key Cryptography, on page 412.

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 415.

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.

392

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 417.

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 412 and QoS Policy, on page 412.

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.

393

C

CASee Certificate Authority (CA), on page 394.

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.

394

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 396.

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.

395

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 395.

396

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 394.

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 413.

Dispatch ClusteringSee Packet Dispatch, on page 410.

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.

397

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.

398

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 409.

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 392.

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.

399

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.

400

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 395, and SHA-1, on page 416.

401

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 403 and Security Association (SA), on page 415.

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.

402

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 389.

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).

403

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 407.

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.

404

IPsec ProposalSuggested encryption algorithms, hash algorithms, authentication methods, etc. to be used for an IPsec (IP Security) tunnel. See also IKE Proposal, on page 402.

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 389.

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 415.

ISP (Internet Service Provider)See Internet Service Provider (ISP), on page 404.

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.

405

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.

406

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 390 and Perfect Forward Secrecy (PFS), on page 410.

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 404.

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.

407

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 410.

408

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 409.

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.

409

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 417.

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 403.

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.

410

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 409.

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.

411

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 396.

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 389.

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.

412

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 422.

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 397.

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).

413

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 415.

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.

414

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 418.

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 392.

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 392.

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 391).

Sensor ClusterGroup of two or more IPS Sensor nodes that work together as if they were a single Sensor.

415

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 404.

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 401.

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.

416

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 415.

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 415.

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.

417

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 396.

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 392.

418

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.

419

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 398, QoS Class, on page 412 and QoS Policy, on page 412.

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.

420

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 420.

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 421.

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 390.

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 413.

421

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 400.

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.

422

Index

A

access control lists, 81predefined, 82

access rules, 145–157action, 151comment, 152continue, 153–154destination, 150options, 151rematching tunneled packets, 154rule table, 147service, 150source, 150time, 152

actionin access rules, 151in ethernet rules, 141in inspection rules, 176in IPv6 access rules, 164

active directory server, 93address range element, 90administrator accounts

RADIUS authentication, 86administrator roles, 81administrators, 79–88

access control lists, 81, 83administrator accounts, 79–88administrator elements, 84administrator roles, 81, 83

editor, 82log colors, 86monitoring user elements, 84operator, 82owner, 82permission levels, 85predefined access control lists, 82superuser, 82

alert chains, 227–232alert channels, 227–232alert entries, 214, 226alert escalation, 225–236

alert chains, 227–232alert channels, 227–232alert entries, 226alert policies, 227, 232custom alerts, 228custom scripts for, 233–234final actions, 231system alerts, 228

alert policies, 227, 229–230, 232alerts

alert policies, 229–230event traces, 222

aliases, 154, 167, 285alias element, 90system aliases, 287user aliases, system-defined, 286

allow action, 141, 151, 164analyzer, 36

correlation situations, 119

423

deployment, 43–52element, 94

analyzers, 97–111tester, 105

anomaly detection, 25, 37"any network" element, 92apply blacklist action, 151architecture, 30auditing, audit entries, 215authentication

authentication server, 93RADIUS, 86

B

blacklisting, 193–198blacklist entries, 194blacklist requests, 195blacklists, 195whitelisting, 194

C

CA (certificate authority), internal, 37CA, see certificate authoritycapture interfaces, 100

SPAN mode, 103wire TAP mode, 103

categories, 255–258configuration, 256–257examples, 257not categorized, 256

central management, 26certificate authority, 51certificates, 37CIS (content inspection server), 93cluster status icons, 70–72clustering

architecture, 98sensors, 97–111

command line tools, 271commands

engine, 280

log server, 272management server, 272

comments in IPv6 access rules, 166comments in rules, 142, 152communications between components, 37components of the system, 32compress situation context, 119Configuration, 73configuration view, 73connection tracking, 151connectivity diagrams, 68contact addresses, 106contact information, 16contexts, 119continue action, 151, 153–154, 164, 166–167, 177correlation situations, 119count situation context, 119custom alerts, 228custom services, 95customer support, 16

D

data for reports, 247default services, 95default system policy, 140, 148, 162defense in depth, 24deploying sensors and analyzers, 43–52destination

in access rules, 150in ethernet rules, 141in inspection rules, 175in IPv6 access rules, 163

detectionanomaly, 25misuse, 25

DHCP server, 93diagrams in system status view, 68discard action, 141, 151, 165discard before storing filters, 217, 219DNS server, 93documentation available, 15drill-down top rate summaries, 241

424

E

editors, see predefined administrator roleselements

active directory server, 93analyzers, 36authentication server, 93CIS (content inspection server), 93context, 119DHCP server, 93DNS server, 93LDAP server, 93log server, 35, 92management server, 34monitoring server, 35, 93network elements, 89–95searching for, 63sensors, 36services, 94situations, 117SNMP agent, 106tags, 118vulnerabilities, 118–119

encapsulated packets, 154, 167end-user license agreement, 373engine status icons, 70–72ethernet rules, 137–144

action, 141comment, 142destination, 141examples, 142options, 141rule table, 139service, 141source, 141

event compress, 119event correlation, 119event count, 119event group, 119event match, 120event sequence, 120examples

access rules, 155

administrator accounts, 87alert escalation, 234archiving logs, 222blacklisting, 197categories, 257ethernet rules, 142filters, 210incident case, 262inspection rules, 178IPS deployment, 54log management, 222policies, 135pruning logs, 223reports, 251situation, 123

exporting reports, 247–251style templates, 248

expressions, 91intersection, 91negation, 91union, 91

external administrator accounts, 86

F

facility field, 325filters, 201–211

fields, 202, 204log data, 202operation types, 205–206operations, 202–209temporary filters, 203, 210types of, 204undefined values, 207–209

final actions, 231fingerprint of certificates, 277fingerprint syntax, 295firewall element, 91firewalls

network element for, 91FTP protocol agent, 184–185

425

G

GRE protocol agent, 185group element, 91group situation context, 119

H

H.323 protocol agent, 185hardware requirements, 16heartbeat, 98HIDS, 24high availability, 26, 31, 98host elements, 91HTTP protocol agent, 185–186

I

ICMP protocol agent, 186IDS

host-based, 24network-based, 24

IEEE 802.1Q VLAN tagging, 102immediate discard filters, 217, 219incident cases, 259–263

data collection, 260–261example, 262history, 260journal, 260–261player list, 260–261

inherited rules, 129inline interfaces, 100, 104

inline serial clustering, 107inline mode, 24inline serial cluster, 107inspection rules, 169–178

action, 176comments, 177continue, 177continue rules, 177destination, 175options, 176protocol, 175

rule table, 172severity, 175situation, 174source, 175time, 177

interface ID, 99interfaces

network interface cards, 99internal certificate authority, 37IP diagrams, 68IP in IP tunneling, 154, 167IPS deployment, 41–56

example, 54IPS policies, 125–135

packet inspection, 126types of, 129

IPS, inline, 24IPv4 Encapsulation protocol agent, 186IPv4 protocol agent, 186IPv6 access rules, 159–167

action, 164comment, 166continue, 166–167destination, 163options, 165rematching tunneled packets, 167rule table, 161service, 164source, 163time, 165

IPv6 Encapsulation protocol agent, 187IPv6 protocol agent, 187

J

jump action, 151

L

LDAP server, 93legal information, 373location, for NATed communications, 106log data, 214

426

log entries, 214log files, 217, 221log levels, 218–219log management, 213–224

log files, 217log levels, 218–219log pruning, 219log tasks, 220logging options, 218–219

log pruning, 217, 219log server, 35, 92

configuration file, 343log tasks, 220logging, 213–224

accounting, 218logging options, 218–219

for access rules, 151for ethernet rules, 141for inspection rules, 176for IPv6 access rules, 165

logical interfaces, 103–104logs view, 74–76

M

MAC addressfor cluster NDIs, 102

management center, 34deployment, 52–54

management client, 34, 61–78management server, 34match situation context, 120misuse detection, 25, 37monitoring server, 35, 93MSP (managed service provider), 35MSRPC protocol agent, 187Multi-Link monitoring, 71–72

N

NATed addresses, 106NDI, 102NDI (node dedicated interface), 100

in clusters, 102netBIOS protocol agent, 187NetLink status icons, 71–72network elements, 89–95

address range, 90alias, 90analyzer, 94combined sensor-analyzer, 94expressions, 91firewall, 91group, 91host, 91network, 92router, 92sensor cluster, 94servers, 92services, 94–95single sensor, 94SOHO firewall, 91

network interfaces, 99NIC (network interface card), 99NIDS, 24node dedicated interface, see NDInot categorized, 256

O

online help, 65operators, see predefined administrator

rolesoptions


oracle protocol agent, 187–188overviews

system statistics, 69–70owners, see predefined administrator roles

P

packet inspection with IPS policy, 126

427

PDF report files, 247period total summaries, 240permit action, 176policies

alerts, 229–230validating, 133

policypre-defined, 140, 148, 162system, 140, 148, 162

policy editing view, 77–78policy refresh needs, 134policy snapshots, 134port mirroring, 103positioning sensors, 44post-processing reports, 250pre-defined

aliases, 287policy, 140, 148, 162services, 95

progress summaries, 240protocol

in inspection rules, 175validation, 25

protocol agents, 150, 164, 180–191FTP, 184–185GRE, 185H.323, 185HTTP, 185–186ICMP, 186IPv4, 186IPv4 Encapsulation, 186IPv6, 187IPv6 Encapsulation, 187MSRPC, 187netBIOS, 187oracle, 187–188remote shell, 188services in firewall, 188SIP, 188–189SMTP, 189SSH, 189SunRPC, 189TCP proxy, 189TFTP, 190

R

RADIUS authentication, 86refuse action, 151, 165regular expression syntax, 295rematching

tunneled packets, 154, 167tunneled traffic, 154, 167

remote shell protocol agent, 188report designs, 239–247report files, 247–251report items, 239–245report sections, 239–245report tasks, 240, 246–247reports, 237–251

bar charts, 240curve charts, 240drill-down top rate summaries, 241exporting, 247–251filters, 247log data, 238, 247monitoring statistics, 238PDF files, 247period comparison, 243period total summaries, 240pie charts, 240post-processing, 250progress summaries, 240report designs, 239–247report files, 247–251report items, 239–245report sections, 239–245report tasks, 240, 246–247static information summaries, 241style templates, 248summary types, 240–241system reports, 251tab-delimited text files, 247–251tables, 240top rate summaries, 240

requirements for hardware, 16reset interfaces, 104router element, 92routing, 113–114

428

analyzer, 114sensor, 114

rulescontinue action, 153, 166, 177inheritance, 129protocol agents, 150, 164validating, 133, 142, 155, 167, 177

S

scan detection situation context, 120searching

elements, 63services, 63

secure sockets layer, 51sensor cluster

communications, 98inline serial clustering, 107interfaces, 99

sensor-analyzer element, 94sensors, 36

capture interfaces, 100clustering, 97–111clusters, 94

NDIs, 102deployment, 43–52inline interfaces, 100, 104logical interfaces, 103–104NDIs, 100, 102reset interfaces, 104tester, 105transparent access control mode for, 36

sequence situation context, 120service (access rule field), 150service (ethernet rule field), 141service (IPv6 access rule field), 164services, 95

custom services, 95searching for, 63

services in firewall protocol agent, 188severity, in inspection rules, 175single point of failure, 26, 98single sensor element, 94

SIP protocol agent, 188–189situation contexts

correlationevent compress, 119event count, 119event group, 119event match, 120event sequence, 120

scan detection, 120system, 121website access control, 121

situations, 117context definition, 119examples, 123in inspection rules, 174

SMC, see management centerSMTP protocol agent, 189SNMP agent, 106SOHO firewall element, 91SOHO firewalls

network element for, 91source


SPAN, 103SSH protocol agent, 189SSL, 51standard services, 95static information summaries, 241status icons, 70–72stonegate management center, see manage-

ment centersub-policies, 129, 132summaries

drill-down top rate summaries, 241period total summaries, 240progress summaries, 240static information summaries, 241top rate summaries, 240

SunRPC protocol agent, 189support services, 16

429

switched port analyzer port, 103syslog servers, 222system alerts, 228system architecture, 30system components, 32

analyzer, 36log server, 35management client, 34management server, 34monitoring server, 35sensor, 36

system designcommunications, 37

system elementsaliases, 287services, 95

system policy, 140, 148, 162system reports, 251system requirements, 16system services, 95system situation context, 121system statistics views, 69–70system status view, 66–68

diagrams in, 68system summary, 66system-defined user aliases, 286

T

tab-delimited text report files, 247–251tags, 118TAP, 103TCP proxy protocol agent, 189technical support, 16template policies, 129temporary filters, 203, 210terminate action, 176test access port, 103tester, 105

TFTP protocol agent, 190time

in access rules, 152in inspection rules, 177in IPv6 access rules, 165

TLS, 51top rate summaries, 240transparent access control, 36transport layer security, 51tunneled packets

rematching, 154, 167tunneled traffic

rematching, 154, 167type field, 327typographical conventions, 14

U

undefined optionsin access rules, 151in ethernet rules, 141in inspection rules, 176in IPv6 access rules, 165

user aliases, system-defined, 286user-defined service elements, 95

V

VLAN (virtual local area network), 102VPN (virtual private network)

user aliases, 286vulnerabilities, 118–119

W

website access control situation context, 121whitelisting, 194wire TAP, 103

430

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.


Documents

StoneGate IPS Reference Guide 4.3