StoneGate Reference Guide

SMC 4.3 and IPS 4.3

Legal Information
End-User License Agreement
The 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 Services
The 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 Service
The instructions for replacement service can be found at the Stonesoft website: www.stonesoft.com/en/support/view_support_offering/return_material_authorization/

Hardware Warranty
The 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 Patents
The 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.

Disclaimer
Although 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

Table of Contents
I NTRODUCTION
CHAPTER 1 Using StoneGate Documentation 13
How to Use This Guide 14 Typographical Conventions 14 Documentation Available 15 Product Documentation 15 Support Documentation 16 System Requirements 16 Contact Information 16 Licensing Issues 16 Technical Support 16 Your Comments 16 Other Queries 16 Performance 26 Centralized Management 26 Accuracy 27 IDS/IPS Weaknesses 27 Limitations of Protocol Validation 27 False Positives 27 False Negatives 28 Denial of Service 28

CHAPTER 4 StoneGate IPS System Architecture 29
StoneGate Security Platform Overview 30 Accuracy 30 Manageability 31 Scalability 31 Built-in High Availability 31 StoneGate Components 32 StoneGate Management Center 34 Management Server 34 Management Client 34 Log Server 35 Monitoring Server 35 Sensors 36 IDS Installation 36 IPS Installation 36 Transparent Access Control Mode 36 Analyzer 36 Certificates 37 Licenses 37 Traffic Inspection Methods 37 Misuse Detection 38 Anomaly Detection With Protocol Analysis 38 Anomaly Detection With Statistics 39 Event Correlation in the Analyzer 39 Response Mechanisms 39 Keeping StoneGate IPS Up-to-Date 40

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 24 Network IDS 24 Intrusion Prevention Systems 24 IDS and IPS Functions 25 Misuse Detection 25 Anomaly Detection 25 Protocol Validation 25 Requirements for Modern IDS/IPS 26 High Availability 26

3

CHAPTER 5 StoneGate IPS Deployment 41
Deployment Overview 42 Sensor and Analyzer Deployment 43 Positioning Sensors 44 Internal Network 45 DMZ Network 47 External Network 49 Positioning Analyzers 51 StoneGate IPS Connections and Bandwidth 51 Management Center Deployment 52 Positioning the Management Server 53 Positioning Log Servers 53 Positioning Management Clients 54 Example Deployment Scenario 54

CHAPTER 7 Administrator Accounts 79
Overview to Administrator Accounts 80 Configuration of Administrator Accounts 81 Default Elements 82 Predefined Account with Unrestricted Permissions 82 Predefined Administrator Roles 82 Predefined Access Control Lists 82 Configuration Workflow 83 Task 1: Create a New Administrator Role 83 Task 2: Create a New Access Control List 83 Task 3: Configure Administrator Password Policy 84 Task 4: Create a New Administrator Element or Monitoring User Element 84 Using Administrator Accounts 86 Customizing Log Color Settings 86 RADIUS Authentication 86 Examples of Administrator Accounts 87 Creating Accounts with Predefined Administrator Roles 87 Creating Accounts with a New Access Control List 87

S ETTING U P S TONE G ATE
CHAPTER 6 Management Client Basics 61
Introduction 62 General Tools 62 Main Toolbar 62 Status Bar 63 Element Search 63 Bookmarks 64 Online Help 65 System Status View 66 System Summary 66 Status Tree 67 Info Panel 67 Graphical Monitoring 68 Overview 69 Status Icons and Colors 70 Configuration View 73 Logs View 74 Policy Editing View 77

CHAPTER 8 Network Elements and Services 89
Introduction to Network Elements and Services 90 Network Element Types 90 Address Range Elements 90 Alias Elements 90 Expression Elements 91 Firewall Elements 91 SOHO Firewall Elements 91 Group Elements 91 Host Elements 91 IPS Elements 92 SSL VPN Elements 92 Network Elements 92 Router Elements 92 Server Elements 92 Management Server Element 92

4

Log Server Elements 92 Authentication Server Elements 93 Active Directory Server Elements 93 LDAP Server Elements 93 Content Inspection Server (CIS) Elements 93 DNS Server Elements 93 DHCP Server element 93 Monitoring Server element 93 StoneGate IPS Elements 93 Single Sensor Elements 94 Sensor Cluster Elements 94 Analyzer Elements 94 Combined Sensor-Analyzer Elements 94 Services 94

Capturing Traffic From VLANs 108 Examples of Sensor and Analyzer Configuration 109 Setting up an Inline Sensor 109 Setting up a Sensor Cluster 110

CHAPTER 10 Routing 113
Overview to Routing 114 Configuration of Routing 114 Default Elements 114 Configuration Workflow 114 Task 1: Add Router 114 Task 2: Add Network(s) 114 Task 3: Refresh IPS Policy 114

CHAPTER 9 Sensor and Analyzer Configuration 97
Overview to Sensor and Analyzer Configuration 98 Communication Between the Nodes 98 Load Balancing 99 Configuration of Sensors and Analyzers 99 Network Interfaces 99 Configuration Workflow 101 Task 1: Create an Analyzer Element 101 Task 2: Create a Sensor Element 102 Task 3: Define VLAN Interfaces 102 Task 4: Define NDIs 102 Task 5: Define Logical Interfaces 103 Task 6: Define Capture Interfaces 103 Task 7: Define Inline Interfaces 104 Task 8: Install the Sensor and Analyzer Engines 104 Task 9: Install an IPS Policy 104 Using Sensors and Analyzers 105 Running Automatic Tests 105 Sending SNMP Traps 106 Contact Addresses for NATed Communications 106 Using Inline Sensors 107 Using Inline Serial Clustering 107 Using Sensors in Transparent Access Control Mode 108

T RAFFIC I NSPECTION
CHAPTER 11 Situations 117
Overview to Situations 118 Configuration of Situations 118 Situation Contexts 119 Correlation Contexts 119 Protocol-Specific Contexts 120 The Scan Detection Context 120 System Contexts 121 Website Access Control Contexts 121 Default Elements 121 Configuration Workflow 121 Task 1: Create a Custom Situation Element 121 Task 2: Add a Context for the Situation 121 Task 3: Associate Tags with the Situation 122 Task 4: Associate the Situation with a Vulnerability 122 Using Situations 122 Examples of Custom Situations 123 Detecting the Use of Forbidden Software 123 Counting Events 124 Preventing Access to Forbidden Websites 124

CHAPTER 12 IPS Policies 125
Overview to IPS Policies 126

5

Policy Hierarchy 126 How StoneGate Examines the Packets 126 Configuration of Policy Elements 129 Default Elements 130 Configuration Workflow 131 Task 1: Create a Template Policy 131 Task 2: Create a Policy 132 Task 3: Create a Sub-Policy 132 Task 4: Add Rules 133 Task 5: Validate the Policy 133 Task 5: Install the Policy 134 Using Policy Elements 134 Continue Rules 134 Policy Snapshots 134 Example of Policy Element Use 135 Restricting Administrator Editing Rights 135

Configuration Workflow 150 Task 1: Define the Source and Destination 150 Task 2: Define the Service 150 Task 3: Select the Action 151 Task 4: Select Rule Options 151 Task 5: Restrict the Time When the Rule Is Enforced 152 Using IPS Access Rules 152 Adding Comments to Rules 152 Allowing System Communications 152 Configuring Default Settings for Several Rules 153 Using Continue Rules to Set the Protocol 153 Rematching Tunneled Packets 154 Using Aliases in Access Rules 154 Validating Rules 155 Examples of IPS Access Rules 155 Exempting Traffic from Inspection 155 Filtering Traffic on an Inline Sensor 156

CHAPTER 13 Ethernet Rules 137
Overview to Ethernet Rules 138 Configuration of Ethernet Rules 138 Considerations for Designing Ethernet Rules 140 Default Elements 140 Configuration Workflow 141 Task 1: Define the Source and Destination 141 Task 2: Define the Service 141 Task 3: Select the Action 141 Task 4: Select Rule Options 141 Using Ethernet Rules 142 Adding Comments to Rules 142 Validating Rules 142 Examples of Ethernet Rules 142 Logging Ethernet Protocol Use 142 Restricting the Use of Ethernet Protocols 143

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 Default Elements 162 Configuration Workflow 163 Task 1: Define the Source and Destination 163 Task 2: Define the Service 164 Task 3: Select the Action 164 Task 4: Select Rule Options 165 Task 5: Restrict the Time When the Rule Is Enforced 165 Using IPv6 Access Rules 166 Adding Comments to Rules 166 Configuring Default Settings for Several Rules 166 Using Continue Rules to Set the Protocol 166 Rematching Tunneled Packets 167 Using Aliases in IPv6 Access Rules 167 Validating Rules 167

CHAPTER 14 Access Rules 145
Overview to IPS Access Rules 146 Configuration of IPS Access Rules 146 Considerations for Designing Access Rules 148 Default Elements 148

CHAPTER 16 Inspection Rules 169
Overview to Inspection Rules 170

6

Configuration of Inspection Rules 170 Considerations for Designing Inspection Rules 173 Default Elements 173 Configuration Workflow 174 Task 1: Add Situations 174 Task 2: Limit the Situations by Severity 175 Task 3: Define the Source and Destination 175 Task 4: Define the Protocol 175 Task 5: Select the Action 176 Task 6: Set the Options for the Rule 176 Task 7: Restrict the Time When the Rule is Enforced 177 Using Inspection Rules 177 Adding Comments to Inspection Rules 177 Setting Default Options for Several Inspection Rules 177 Validating Rules 177 Example of Inspection Rules 178 Eliminating a False Positive 178

MSRPC Agent 187 NetBIOS Agent 187 Oracle Agent 187 Remote Shell (RSH) Agent 188 Services in Firewall Agent 188 SIP Agent 188 SMTP Agent 189 SSH Agent 189 SunRPC Agents 189 TCP Proxy Agent 189 TFTP Agent 190 Examples of Protocol Agent Use 190 Preventing Active Mode FTP 190 Logging URLs Accessed by Internal Users 190

CHAPTER 18 Blacklisting 193
Overview to Blacklisting 194 Risks of Blacklisting 194 Whitelisting 194 Configuration of Blacklisting 195 Configuration Workflow 195 Task 1: Define Blacklisting in the Access Rules 196 Task 2: Define Analyzer-to-Firewall or Analyzer-toSensor Connections 196 Task 3: Define Inspection Rules in the IPS Policy 196 Using Blacklisting 196 Manual Blacklisting 197 Monitoring Blacklisting 197 Examples of Blacklisting 197 Blacklisting Traffic from a Specific IP Address Manually 197 Automatic Blacklisting with IPS 198

CHAPTER 17 Protocol Agents 179
Overview to Protocol Agents 180 Connection Handling 180 Protocol Validation 180 Configuration of Protocol Agents 181 Configuration Workflow 181 Task 1: Create a Custom Service with a Protocol Agent 181 Task 2: Set Parameters for the Protocol Agent 182 Task 3: Put the Service in Access Rules 182 Using Protocol Agents 182 FTP Agent 184 GRE Agent 185 H.323 Agent 185 HTTP Agents 185 ICMP Agent 186 IPv4 Agent 186 IPv4 Encapsulation Agent 186 IPv6 Agent 187 IPv6 Encapsulation Agent 187

L OGS , A LERTS , A ND R EPORTS
CHAPTER 19 Filters 201
Overview to Filters 202

7

Configuration of Filters 202 Matching Log Data with Filters 203 Default Elements 203 Configuration Workflow 204 Task 1: Create a New Filter 204 Task 2: Select Fields 204 Task 3: Select Operations 205 Task 4: Add Field Values 207 Task 5: Define Handling of Missing Fields 207 Task 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

Filtering Out Irrelevant Logs 223

CHAPTER 21 Alert Escalation 225
Overview to Alert Escalation 226 Configuration of Alert Escalation 226 Default Elements 227 System Situations 228 Configuration Workflow 228 Task 1: Define Custom Alerts 228 Task 2: Define Alert Chains 228 Task 3: Define Alert Policies 229 Task 4: Configure Alert Channels 230 Using Alert Escalation 232 Designing Alert Policies and Alert Chains 232 Using a Custom Script for Alert Escalation 233 Example of Alert Escalation 234 Escalating Alerts Based on Responsibilities 234

CHAPTER 20 Log Management 213
Overview to Log Management 214 Logs View 214 Log Entries 214 Alert Entries 214 Audit Entries 215 Configuration of Log Management 215 Default Elements 218 Configuration Workflow 218 Task 1: Set Logging Options 218 Task 2: Configure Log Pruning 219 Task 3: Define Log Tasks 220 Using Log Management 221 Log Files 221 Additional Archive Directories 221 Enabling/Disabling Diagnostics 221 Acknowledging Alerts 222 Alert Escalation 222 Exporting Log Data to Syslog Servers 222 Examples of Log Management 222 Archiving Old Logs 222

CHAPTER 22 Reports 237
Overview to Reports 238 Configuration of Reports 239 Default Elements 241 Configuration Workflow 242 Task 1: Create a New Report Design 242 Task 2: Define the Report Design’s Properties 242 Task 3: Select Report Sections 244 Task 4: Select Report Items 245 Using Reports 246 Generating Reports 246 Using Filters with Reports 247 Exporting Reports 247 PDF Report Files 247 Tab-Delimited Text Report Files 248 Post-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

A DMINISTRATION
CHAPTER 23 Categories 255
Overview to Categories 256 Configuration of Categories 256 Default Elements 256 Configuration Workflow 256 Task1: Create Categories 256 Task 2: Associate Elements with Categories 256 Task 3: Select a Category to filter the displayed elements 257 Using Categories 257 Examples of Categories 257 Managing a Large Enterprise 257 Combining Categories 258

A PPENDICES
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

CHAPTER 24 Incident Cases 259
Overview to Incident Cases 260 Configuration of Incident Cases 260 Configuration Workflow 260 Task 1: Create an Incident Case 260 Task 2: Attach Data 261 Task 3: Attach Players 261 Task 4: Write Journal Entries 261 Task 5: Close the Incident Case 261 Using Incident Cases 262 Investigation by One Administrator 262 Investigation by More Than One Administrator 262 Investigation of a False Positive 262 Example of an Incident Case 262

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 Guide
This 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 Conventions
The following typographical conventions are used throughout the guide:
TABLE 1.1 Typographical Conventions

Formatting
Normal text This is normal text.

Informative Uses

User Interface text
References, terms Command line User input Command parameters

Text you see in the User Interface (buttons, menus, etc.) and any other interaction with the user interface are in boldface. Cross-references and first use of acronyms and terms are in italics. File names, directories, and text displayed on the screen are monospaced. User input on screen is monospaced bold-face. Command parameter names are in monospaced italics.

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.

14

Chapter 1: Using StoneGate Documentation

Documentation Available
StoneGate 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 Documentation
The table below lists the available product documentation.
TABLE 1.2 Product Documentation

Guide

Description
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. Instructions for planning, installing, and upgrading a StoneGate system. Available for StoneGate Firewall/VPN and StoneGate IPS. 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. 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. Instructions for end-users. Available for the StoneGate IPsec VPN Client and the StoneGate Monitoring Client. Instructions for physically installing and maintaining StoneGate appliances (rack mounting, cabling etc.). Available for all StoneGate hardware appliances.

Reference Guide

Installation Guide

Online Help

Administrator’s Guide

User’s Guide

Appliance Installation Guide

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

Documentation Available

15

Support Documentation
The 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 Requirements
The 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 Information
For street addresses, phone numbers, and general information about StoneGate and Stonesoft Corporation, visit our website at http://www.stonesoft.com/.

Licensing Issues
You 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 order@stonesoft.com.

Technical Support
Stonesoft 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 Comments
We 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 feedback@stonesoft.com. • To comment on the documentation, e-mail documentation@stonesoft.com.

Other Queries
For queries regarding other matters, e-mail info@stonesoft.com.

16

Chapter 1: Using StoneGate Documentation

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. The following sections are included: 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 Improvements
You 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 Upgrade
StoneGate 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 Allocation
Due 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 Improvements
You 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 Improvements
There 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 Appliances
You 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 Improvements
There 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 Improvements
Usefulness 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 SubPolicy 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 Validation
You 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 Changes
Direct 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 Elements
There 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 Improvements
New 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 Integration
You 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 Report
A 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.

20

Chapter 2: What’s New?

Tools Icon Menu
Many 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 Support
StoneGate 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 Inspection
StoneGate 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

22

Chapter 2: What’s New?

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 following sections are included: 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

T h e R o le o f I D S a n d I P S
A 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 Technologies
Generally speaking, there are two different classes of IDS: host-based and networkbased. In this chapter we will focus on the network-based systems.

Host IDS
Host 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 IDS
Network-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 Systems
The 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 Detection
Misuse 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 Detection
Anomaly 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 Validation
Protocol 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 Availability
Availability 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.

Performance
IPS 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 protocolspecific, context-sensitive fingerprints and intelligent correlation, allowing it to process possible attacks much faster.

Centralized Management
An 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.

26

Chapter 3: Introduction to Intrusion Detection and Prevention

Accuracy
The 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 Validation
Protocol 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 Positives
IPS 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 Negatives
False 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 Service
IDS 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.

28

Chapter 3: Introduction to Intrusion Detection and Prevention

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. The following sections are included: 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 Overview
StoneGate 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.

Accuracy
The 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

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

Scalability
It 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 16node cluster.

Built-in High Availability
The 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 Components
StoneGate 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
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.

Sensor and Analyzer engines (one or more of each)

32

Chapter 4: StoneGate IPS System Architecture

TABLE 4.1 StoneGate System Components

Component

Description 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

StoneGate Management Center (SMC)

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) Monitoring Client (several) Graphical tool used for configuring, managing and monitoring the entire StoneGate system. The Monitoring Client provides restricted log browsing through the Monitoring Server. It provides no other access.

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 Components

33

StoneGate Management Center
The 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 Server
The 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 Client
The 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.

34

Chapter 4: StoneGate IPS System Architecture

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 Server
Log 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 Server
The 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.

StoneGate Components

35

Sensors
A 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 Installation
In 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 Installation
In 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 Mode
Inline 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.

Analyzer
The 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

36

Chapter 4: StoneGate IPS System Architecture

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.

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

Licenses
Licenses 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 Methods
StoneGate 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.

Traffic Inspection Methods

37

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 Detection
Known 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 Analysis
While 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

38

Chapter 4: StoneGate IPS System Architecture

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 Statistics
StoneGate 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 Analyzer
The 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 Mechanisms
When 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.

Traffic Inspection Methods

39

K e e p i n g S t o n e G a t e I P S U p - t o- D a t e
StoneGate 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.

40

Chapter 4: StoneGate IPS System Architecture

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. The following sections are included: 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 Overview
StoneGate 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.
TABLE 5.1 System Components

Component
Sensor

Description
Picks 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. Further processes, correlates, and inspects event data received from the Sensors. Stores the configuration data and manages the StoneGate IPS system. Stores the received event data and alerts the administrators when critical events occur. Provides a graphical user interface for managing and monitoring the system.

Analyzer Management Server Log Server Management Client

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

42

Chapter 5: StoneGate IPS Deployment

Illustration 5.1 Positioning StoneGate IPS Components

Sensor and Analyzer Deployment
The 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.

Sensor and Analyzer Deployment

43

Positioning Sensors
Each 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 highperformance 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.

44

Chapter 5: StoneGate IPS Deployment

Illustration 5.2 Network Segments for Positioning the Sensors

Internal Network
Internal 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

Sensor and Analyzer Deployment

45

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
Network services and connectivity for the authorized end users. Possibly also back-end servers that serve other networks and user groups.

Implications on Sensors
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. 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. 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. 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 failopen network cards to ensure traffic is not stopped when sensor is offline), since clustering is not available.

Main purpose

Hosts

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

Users

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

Traffic volume

High volume traffic up to Gbit/s LAN throughputs.

46

Chapter 5: StoneGate IPS Deployment

TABLE 5.2 Internal Network Considerations for Sensors (Continued)

Description

Implications on Sensors
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. 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.

Traffic type

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

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.

DMZ Network
DMZ 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.
TABLE 5.3 DMZ Considerations for Sensors

Description

Implications on Sensors
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.

Main purpose

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

Sensor and Analyzer Deployment

47

TABLE 5.3 DMZ Considerations for Sensors (Continued)

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

Implications on Sensors
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. 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. 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 failopen network cards to ensure traffic is not stopped when sensor is offline), since clustering is not available. 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.

Hosts

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

Traffic volume

Traffic type

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

48

Chapter 5: StoneGate IPS Deployment

TABLE 5.3 DMZ Considerations for Sensors (Continued)

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

Implications on Sensors
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.

Network security

External Network
External 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.
TABLE 5.4 External Network Considerations for Sensors

Description

Implications on Sensors
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. 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.

Main purpose

Connectivity between the protected and public networks.

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.

Sensor and Analyzer Deployment

49

TABLE 5.4 External Network Considerations for Sensors (Continued)

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

Implications on Sensors
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. 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 failopen network cards to ensure traffic is not stopped when sensor is offline), since clustering is not available. 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. 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.

Users

Traffic volume

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

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.

Network security

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

50

Chapter 5: StoneGate IPS Deployment

Positioning Analyzers
The 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 Bandwidth
To 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.

Sensor and Analyzer Deployment

51

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.
TABLE 5.5 Some Estimated Average Rates of Event Data Transfer with the IPS System Policy

Captured Traffic
less than 2 Mbits/s

Average Event Transfer from Sensor to Analyzer
From ~1 Kbit/s for a protected office network to ~15 Kbit/s for an open Internet network. From less than 10 Kbit/s for a protected office network to ~60 Kbit/s for an open Internet network. From ~60 Kbit/s for a protected office network to ~600 Kbit/s for an open Internet network. From ~600 Kbit/s for a protected office network to ~3000 Kbit/s for an open Internet network.

Average Event Transfer from Analyzer to Log Server
Usually less than 1 Kbit/s. From less than 1 Kbit/s for a protected office network to less than 5 Kbit/s for an open Internet network. From ~5 Kbit/s for a protected office network to ~30 Kbit/s for an open Internet network. From ~50 Kbit/s for a protected office network to ~150 Kbit/s for an open Internet network.

2 – 10 Mbit/s

10 – 100 Mbit/s 100 – 1000 Mbit/s

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 Deployment
The 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

52

Chapter 5: StoneGate IPS Deployment

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 Server
The 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 Servers
Log 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

Positioning Management Clients
The 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 Scenario
This section explains a typical StoneGate IPS deployment outlined in Illustration 5.3.
Illustration 5.3 StoneGate IPS Deployment Scenario

54

Chapter 5: StoneGate IPS Deployment

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

Site

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

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

London: headquarters

Boston: large branch office

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

Frankfurt: large branch office

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

Paris: small branch office

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

Rome: small branch office

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

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.

Example Deployment Scenario

55

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

Example Scenario

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

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.

56

Chapter 5: StoneGate IPS Deployment

TABLE 5.7 Guidelines for StoneGate IPS Deployment (Continued)

System Component

Guidelines

Example Scenario
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. Analyzers are deployed to correlate and compress the event data already locally on the site before sending the data through slower network connections.

Sensors

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

Analyzers

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

Example Deployment Scenario

57

58

Chapter 5: StoneGate IPS Deployment

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. The following sections are included: 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

Introduction
The 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 Toolbar
The following buttons are present on the toolbar in all windows.
Illustration 6.1 General Toolbar Buttons

Back and forward buttons. Click and hold to see history. Switch to Configuration view. Shortcuts to policies.

Switch to Logs view. Shortcuts to Overviews. Switch to System Status view.

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

62

Chapter 6: Management Client Basics

Status Bar
The status bar at the bottom of the StoneGate windows displays system messages.
Illustration 6.2 Status Bar

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.

Element Search
The Management Client has a general search for quickly finding elements.
Illustration 6.3 The Search Panel

Search term. Options to restrict the search. Search results.

General Tools

63

Bookmarks
You 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

Create new bookmarks. Bookmark a view that opens each time you log in.

Open a panel for viewing and organizing bookmarks. Shared Bookmarks group is shown for all administrators.

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.

64

Chapter 6: Management Client Basics

Online Help
The 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

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

General Tools

65

System Status View
The 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

Tree of those elements that can be monitored. Element status is shown with colors. Details of the selected element (Not visible in the Monitored Elements view, if no element has been selected).

Summary of the system’s status.

System Summary
The 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

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.

66

Chapter 6: Management Client Basics

Status Tree
The 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 rightclick 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 Panel
The 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 Monitoring
There 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

68

Chapter 6: Management Client Basics

Overview
An 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

Toolbar

Section

Grid

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.

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 Colors
The 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
Green icon, all OK

Description
All nodes have a normal status (online or standby). Some of the nodes have an abnormal status or have been commanded offline by administrator command, but are still sending status updates normally. All 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. No policy has been installed on any of the nodes in the cluster.

Yellow icon, warning

Red icon, alert

Grey icon, unknown status White icon, not monitored

Administrator has set the cluster not to be monitored.

70

Chapter 6: Management Client Basics

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

Icon

Node Status
Green icon, node or server online

Description
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. The node is in standby mode. A standby node goes online when the cluster has no other online node.

Cyan icon, standby mode

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. The management system does not know the status of the node.

Grey icon, timeout or unknown status

White framed icon, not monitored

The node is not monitored.

The color of the NetLink icons shows the status of the NetLinks in the Multi-Link configuration.
TABLE 6.3 NetLink Status Icons

Color
Green Grey OK

Status
The NetLink is up.

Description

Unknown status

The status of the NetLink is unknown.

Status Icons and Colors

71

TABLE 6.3 NetLink Status Icons (Continued)

Color
White

Status
Not monitored

Description
The NetLink is not monitored.

The VPN status icons alert you to problems in VPNs.
TABLE 6.4 VPN Status Icons

Icon

Cluster Status
Green icon, tunnels up

Description
All tunnels have a normal status (online or standby). Some error has been detected, at least for some traffic, but the tunnels are usable in principle, and some other traffic may be getting through. Some or all tunnels are down.

Yellow icon, warning

Red icon, error

Blue icon, idle

The tunnels are valid, but not up because there has not been traffic going through them in a while. The VPN has no valid tunnels, because the VPN configuration is not complete or does not allow any valid tunnels.

White icon, not configured

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

Color
Green Red

Status
OK Error

Explanation
The connection is active (there have been communications within the last 2 minutes) and no problems have been reported. The Management Server has received a report that connection attempts have failed.

72

Chapter 6: Management Client Basics

TABLE 6.5 Connectivity Status (Continued)

Color
Cyan Blue Grey

Status
Idle Closed Timeout, Unknown

Explanation
Connection between components is still open, but no traffic passes between them. The connection was closed by one of the components. The Management Server does not know the status of the connection. The connection may or may not be working.

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

Full tree of all elements and objects in the system. Tree or list of selected type of elements; showing firewall policy tree. Information on selected element; switched to show modification history for the selected policy.

Configuration View

73

L o gs V i ew
The 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

Logs toolbar

Log entry table

Query panel

Timeline for browsing

Fields panel

Field preview

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.

74

Chapter 6: Management Client Basics

Illustration 6.15 Logs Toolbar

Current Logs mode on/off

Go to the last log record.

Statistics view

Show the details of a Log entry

Refresh statistics

Zoom (in/out)

Acknowledge one alert (stops alert escalation) Acknowledge all alerts (stops alert escalation) 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.

Logs View

75

Illustration 6.16 Query Panel

General type for logs to view. Show logs from a subset of engines or servers that send and store the data. 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. Focuses the view to the beginning/ end of the time range. Time range. Apply filters the logs according to your selections. 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

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

76

Chapter 6: Management Client Basics

Policy Editing View
You 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

Policy toolbar. Rule table.

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

Save policy and install it on engine. Save changes.

Policyspecific tools

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

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

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

Validate the policy you have created. Compare the policy you have modified to the engine’s current policy. Find and highlight the rules that match the criteria you define. Toggle between element names and IP addresses.

78

Chapter 6: Management Client Basics

CHAPTER 7

Administrator Accounts

Administrator accounts define administrator rights within the Management Client. The following sections are included: 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 Accounts
You 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 Accounts
Two 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.

Configuration of Administrator Accounts

81

Default Elements
There 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 Permissions
A 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 Roles
There are three predefined Administrator Roles: Owner, Operator, and Editor. You cannot modify them.
TABLE 7.1 Predefined Administrator Roles

Administrator Role
Owner

Description
Owners are administrators who can edit and delete a limited set of elements that they or other administrators have created. Operators 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. Editors 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.

Operator

Editor

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

Access Control List
ALL StoneGate Elements

Description
All elements in StoneGate.

82

Chapter 7: Administrator Accounts

TABLE 7.2 Predefined Access Control Lists (Continued)

Access Control List
ALL Firewall Policies ALL Firewalls ALL Incident Cases ALL IPS Policies ALL Sensors and Analyzers ALL SOHO Firewalls ALL Simple Elements

Description

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

All elements except Firewalls, SOHO Firewalls, IPS engines, Firewall Policies, IPS Policies, and Incident Cases.

Configuration Workflow
The 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 Role
Administrator 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 List
Access 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

Configuration of Administrator Accounts

83

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 Policy
The Administrator password policy defines the settings for password strength, password expiration, and failed logins. You can optionally configure the administrator password policy in <installation directory>/data/SGConfiguration.txt on the Management Server. The following settings can be configured:
TABLE 7.3 Administrator Password Policy Settings

Parameter Name
FAILED_AUTH_ATTEMPT_MAX

Description
The maximum number of failed login attempts before the administrator account is 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. Prevents the reuse of the defined number of previous passwords. Defines whether administrator passwords must contain both letters and numbers. When the value is true, both letters and numbers are required. The minimum number of characters administrator passwords must contain. The number of days after which the administrator password expires and must be changed.

TIME_LOGIN_LOCKED

OBSOLETE_PASSWORD_QUEUE_LENGTH

PASSWORD_BOTH_LETTER_AND_NUM_ REQUIRED

PASSWORD_CHARACTER_NUMBER_ MINIMUM

PASSWORD_EXPIRATION

Task 4: Create a New Administrator Element or Monitoring User Element
We 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.

84

Chapter 7: Administrator Accounts

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.
TABLE 7.4 Permission Levels for Administrators

Permission Level
Unrestricted Permissions (Superuser) Restricted Permissions

Description
Right to manage all elements. Access only to selected elements. The administrator’s rights depend on the permissions defined in the Administrator Role(s).

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

Configuration of Administrator Accounts

85

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 Accounts
You 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 Settings
Different 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 Authentication
You 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.

86

Chapter 7: Administrator Accounts

Examples of Administrator Accounts
The 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 Roles
In 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 List
Company 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.

88

Chapter 7: Administrator Accounts

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. The following sections are included: 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 S e r v i c es
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 Types
Most 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 Elements
Address 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 Elements
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 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 Elements
Expression 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.
TABLE 8.1 Network Element Expressions

Expression
A A A B B

Description
The union of sets A and B. Unites two sets and forms a new set that includes every element of set A and set B. The intersection of sets A and B. Creates a new set that includes every element shared in common between sets A and B. The negation of set A. Creates a new set that includes every possible element except the ones in set A.

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 Elements
Firewalls 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 Elements
SOHO 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 Elements
Group 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 Elements
The 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.

Network Element Types

91

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

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

Network Elements
The 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 Elements
The Router elements are used for defining routing, defining a next-hop gateway. For more information about routing, see Routing, on page 113.

Server Elements
There 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 Element
The 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 Elements
The 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.

92

Chapter 8: Network Elements and Services

Authentication Server Elements
Authentication 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 Elements
The 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 Elements
The LDAP Server element is used for external LDAP directory servers with StoneGate Firewall/VPN.

Content Inspection Server (CIS) Elements
Content 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 Elements
The 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 element
The 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 element
The Monitoring Server element is used as a gateway by the StoneGate Monitoring Client to contact the Management Center for log monitoring purposes.

StoneGate IPS Elements
The 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 Elements
A 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 Elements
A 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 Elements
The 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 Elements
Sensor 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.

S e r v i c es
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.

94

Chapter 8: Network Elements and Services

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

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 wellknown 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 predefined services to change the port to a non-standard one or change any of the other options that the Services have.

Services

95

96

Chapter 8: Network Elements and Services

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. The following sections are included: 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 Nodes
The 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 Balancing
If 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 Analyzers
StoneGate 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 Interfaces
The 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.

Configuration of Sensors and Analyzers

99

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

Capture Interface

Single Sensors, Sensor Clusters, Sensor-Analyzers

Inline Interface

Single Sensors Sensor-Analyzers Inline Serial Clusters

Node Dedicated Interface (NDI)

Single Sensors, Sensor Clusters, Sensor-Analyzers, Analyzers

100

Chapter 9: Sensor and Analyzer Configuration

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 Workflow
The 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 Element
During 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.

Configuration of Sensors and Analyzers

101

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 Element
To 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 Interfaces
A 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 NDIs
In 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.

102

Chapter 9: Sensor and Analyzer Configuration

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 Interfaces
A 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 Interfaces
You 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

Configuration of Sensors and Analyzers

103

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 Interfaces
You 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 Engines
During 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 Policy
After 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.

104

Chapter 9: Sensor and Analyzer Configuration

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 Analyzers
The 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 Tests
The 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
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. Checks whether the available free hard disk space on the specified partition is above the specified minimum amount (in kilobytes). Checks whether the free hard disk swap space is above the specified minimum value (in kilobytes). Checks whether a network port is enabled or disabled. Tests whether a network port reports the link as up or down. Sends out a series of ping requests to determine whether there is connectivity through a network link. Checks 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.

External

File System Space

Free Swap Space Interface Up Link Status Multiping

Inline Pair Link Speed

Using Sensors and Analyzers

105

All entries that you have configured with the tester are displayed in the Test Entries table. The selected states and actions are indicated on that table with letters as summarized in table below.
TABLE 9.3 Test Entry Display of Selected Actions and States

Types
N States to test O S A O+A Action on failure FO+A A+S O+A+S

Table display
Online Offline

Description

Standby Alert Offline + Alert Force Offline + Alert Alert + SNMP Offline + Alert + SNMP Force Offline + Alert + SNMP

FO+A+S

Sending SNMP Traps
The 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 Communications
In 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

106

Chapter 9: Sensor and Analyzer Configuration

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 Sensors
Inline 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 Clustering
You 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.

Using Sensors and Analyzers

107

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 Mode
A 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 VLANs
A 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.

108

Chapter 9: Sensor and Analyzer Configuration

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

Examples of Sensor and Analyzer Configuration

109

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:
TABLE 9.4 Inline Sensor Interfaces

Type
NDI Inline Interface Inline Interface

Interface ID
0 1 2

Mode
Management Interface Inline Inline

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

110

Chapter 9: Sensor and Analyzer Configuration

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.
TABLE 9.5 Sensor Interfaces

Type
NDI Capture Interface NDI

Interface ID
0 1 2 Heartbeat Capture

Mode

Management Interface

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.

Examples of Sensor and Analyzer Configuration

111

112

Chapter 9: Sensor and Analyzer Configuration

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. The following sections are included: Overview to Routing, on page 114 Configuration of Routing, on page 114

113

Overview to Routing
Routing 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 Routing
Each 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 Elements
The system includes a default network element called Any network, which is needed to define the default route for sensors and analyzers.

Configuration Workflow
The 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 Router
A 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 Policy
To 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. The following sections are included: 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 Situations
Situations 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 Situations
The 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 Contexts
The sections below explain the types of Context elements available and how they can be configured. Note – The details related to the Contexts in your system may be different from what is described here, because the Contexts may have been updated through dynamic update packages after this guide was published. Read the release notes of each update package you import to see which elements are affected.

Correlation Contexts
Correlation 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

Configuration of Situations

119

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 Contexts
The 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 Context
The 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.

120

Chapter 11: Situations

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

System Contexts
The 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 Contexts
The 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 Elements
When 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 Workflow
The 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 Element
You 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 Situation
Adding 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.

Configuration of Situations

121

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 Situation
Tag 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 Vulnerability
Vulnerabilities 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 Situations
Situations 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).

122

Chapter 11: 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 Situations
The 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 Software
Company 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 Events
Company 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. Field
Correlated Situations Time Window Alarm Threshold Log Fields Enabled Lognames

Option
Custom Situation 60 5 Select Src Addr

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

124

Chapter 11: Situations

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. The following sections are included: 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 Policies
The 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 Hierarchy
The 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 Packets
The 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

1.

2.

3.

4.

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

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

128

Chapter 12: IPS Policies

Configuration of Policy Elements
The 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 SubPolicies 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

Configuration of Policy Elements

129

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 lowerlevel 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 Elements
The 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

130

Chapter 12: IPS Policies

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 Workflow
The 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 Policy
IPS 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 lowerlevel 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.

Configuration of Policy Elements

131

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 higherlevel 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 Policy
The 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-Policy
IPS 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 SubPolicies, 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.

132

Chapter 12: IPS Policies

Illustration 12.4 A Sub-Policy in Use

A Jump rule inserts the SubPolicy, which is shown as an expandable section.

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 SubPolicy. 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 Rules
As 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 Policy
The 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

Configuration of Policy Elements

133

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 Policy
After 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 Elements
The 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 Rules
The 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 Snapshots
A 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

134

Chapter 12: IPS Policies

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 Use
The 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 Rights
Company 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

136

Chapter 12: IPS Policies

CHAPTER 13

Ethernet Rules

Ethernet rules are lists of matching criteria and actions that define whether Ethernet protocol traffic is allowed or discarded. The following sections are included: 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 Rules
Ethernet 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 Rules
Ethernet 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

Sensor applies Action when it finds a match

Logging is configured in the Options cell

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.

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
ID Source Destination Service Action Options Comment

Explanation
(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. 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. The Services match an Ethernet frame type. The Service cell accepts Ethernet Services elements. Command for the Sensor to carry out when a connection matches the rule. The options for logging. Your optional free-form comment for this rule. Note that you can also add separate comment rows in between rules. (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.

Tag

Configuration of Ethernet Rules

139

Considerations for Designing Ethernet Rules
Like 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 Elements
The 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.

140

Chapter 13: Ethernet Rules

Configuration Workflow
The 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 Destination
The 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 Service
The 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 Action
The 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 Options
By 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).

Configuration of Ethernet Rules

141

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 Rules
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 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 Rules
You 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 Rules
The 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 Use
The 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
ANY

Destination
ANY

Service
IPv4

Action
Allow

Options
Logging: None

142

Chapter 13: Ethernet Rules

3. Add a rule to log the use of other Ethernet protocols:
TABLE 13.3 Ethernet Rule for Logging Ethernet Protocol Use

Source
ANY

Destination
ANY

Service
ANY

Action
Allow

Options
Logging: Stored

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 Protocols
Now 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.4 Ethernet Rule for Allowing ARP and SPT Use

Logical Interface
ANY

Source
ANY

Destination
ANY

Service
ARP SPT IPv4

Action
Allow

Options
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:
TABLE 13.5 Ethernet Rule for Blocking CDP Use

Logical Interface
Inline interface

Source
ANY

Destination
ANY

Service
CDP

Action
Discard

Options
Logging: Stored

3. Add a rule on the last line of the Ethernet rules to block the use of other Ethernet protocols without producing logs:
TABLE 13.6 Ethernet Rule for Blocking Other Ethernet Protocols

Logical Interface
ANY

Source
ANY

Destination
ANY

Service
ANY

Action
Discard

Options
Logging: None

4. Save and install the policy on the Sensor.

144

Chapter 13: Ethernet Rules

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. The following sections are included: 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 Rules
The 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 Rules
Access 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

Mandatory cells for matching traffic

Sensor applies Action when it finds a match

Logging and further inspection is configured in the Options cell

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

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

ID

Logical Interface Source Destination

Configuration of IPS Access Rules

147

TABLE 14.1 Access Rule Cells (Continued)

Cell
Service Action Options Time Comment

Explanation
The 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. Command for the sensor to carry out when a connection matches the rule. The options for logging, deep packet inspection (whether traffic is matched against Inspection rules), and blacklisting. The time period when the rule is applied. If this cell is left empty, the rule applies at all times. Your optional free-form comment for this rule. Note that you can also add separate comment rows in between rules. (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.

Tag

Considerations for Designing Access Rules
One 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 SubPolicies 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 Elements
The 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.

148

Chapter 14: Access Rules

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

Configuration of IPS Access Rules

149

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

Configuration Workflow
The 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 Destination
The 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 Service
The 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 readymade 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.

150

Chapter 14: Access Rules

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

Action
Allow

Explanation
The traffic is let through the sensor. 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. The 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. 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. Matching is continued in the specified sub-policy until a match is found. If there is no matching rule in the subpolicy, the process is resumed in the main policy. 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.

Continue

Discard

Refuse

Jump

Apply Blacklist

Task 4: Select Rule Options
Each 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.

Configuration of IPS Access Rules

151

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 Enforced
Optionally, 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 Rules
Access 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 Communications
If 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).

152

Chapter 14: Access Rules

Configuring Default Settings for Several Rules
You 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 SubPolicy 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 Protocol
Default 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 Packets
If 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 Rules
Aliases 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.

154

Chapter 14: Access Rules

Validating Rules
You 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 Rules
The 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 Inspection
At 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

Source
Firewall

Destination
Log Server

Service
SG Engine to Log

Action
Allow

Options
Deep inspection: Off

Examples of IPS Access Rules

155

Filtering Traffic on an Inline Sensor
Administrators 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:
TABLE 14.4 Access Rules for Filtering Traffic

Source
Administrator Network B Network A Network B

Destination
Administrator Network B Network A Network B ANY

Service

Action
Allow

Options
Logging: Undefined Deep inspection: On Logging: Stored Deep inspection: On Logging: Stored Deep inspection: (irrelevant, because dropped traffic is never inspected further)

Service elements for allowed services

Allow

ANY

ANY

ANY

Refuse

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

156

Chapter 14: Access Rules

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

Examples of IPS Access Rules

157

158

Chapter 14: Access Rules

CHAPTER 15

IPv6 Access Rules

IPv6 Access rules are lists of matching criteria and actions that define whether IPv6 traffic is allowed or discarded. The following sections are included: 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 Rules
IPv6 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 Rules
IPv6 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

Mandatory cells for Sensor applies Action Logging and further matching traffic when it finds a match inspection is configured in the Options cell 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

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
(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. 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. 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. The 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. Command for the sensor to carry out when a connection matches the rule. The options for logging and deep packet inspection (whether traffic is matched against Inspection rules).

ID

Logical Interface Source Destination

Service Action Options

Configuration of IPv6 Access Rules

161

TABLE 15.1 IPv6 Access Rule Cells (Continued)

Cell
Time Comment

Explanation
The time period when the rule is applied. If this cell is left empty, the rule applies at all times. Your optional free-form comment for this rule. Note that you can also add separate comment rows in between rules. (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.

Tag

Considerations for Designing IPv6 Access Rules
Like 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 Elements
The 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.

162

Chapter 15: IPv6 Access Rules

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 Workflow
The 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 Destination
The 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.

Configuration of IPv6 Access Rules

163

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 Service
The 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 readymade 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 Action
The 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
Allow

Explanation
The traffic is let through the sensor. 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.

Continue

164

Chapter 15: IPv6 Access Rules

TABLE 15.2 Action Field Options (Continued)

Action
Discard

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

Refuse

Task 4: Select Rule Options
Each 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 Enforced
Optionally, 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).

Configuration of IPv6 Access Rules

165

Using IPv6 Access Rules
Adding Comments to Rules
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 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 Rules
You 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 Protocol
Default 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.

166

Chapter 15: IPv6 Access Rules

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 Packets
If 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 Rules
Aliases 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 Rules
You 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

168

Chapter 15: IPv6 Access Rules

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. The following sections are included: 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 Rules
Inspection 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 Rules
The 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

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

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

Configuration of Inspection Rules

171

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
(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. 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. 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. Limits 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. 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. 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. Command for the sensor or analyzer to carry out when a connection matches the rule. Options for logging, connection resetting and termination, and blacklisting. The time period when the rule is applied. If this cell is left empty, the rule applies at all times. Your free-form comment for this rule. Note that you can also add separate comment rows in between rules.

ID

Situation

Logical Interface

Severity Source Destination

Protocol

Action Options Time Comment

172

Chapter 16: Inspection Rules

TABLE 16.1 Inspection Rule Cells (Continued)

Cell

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

Tag

Considerations for Designing Inspection Rules
The 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 Elements
The 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.

Configuration of Inspection Rules

173

• 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 Workflow
The 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 Situations
The 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.

174

Chapter 16: Inspection Rules

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 predefined 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 Severity
Situation 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 Destination
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. 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 Protocol
The 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.

Configuration of Inspection Rules

175

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 Action
Inspection 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 Rule
Each 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

176

Chapter 16: Inspection Rules

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 Enforced
Optionally, 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 Rules
Inspection 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 Rules
You 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 Rules
You 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 Rules
The 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 Positive
The 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:
TABLE 16.2 Rule for Excluding

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

Source
The Group defining the internal servers.

Destination
The Group defining the internal servers.

Action
Permit

Options
Logging: None

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

178

Chapter 16: Inspection Rules

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. The following sections are included: 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 Agents
Protocol 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 Handling
Some 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 Validation
Protocol 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 Agents
The 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 Workflow
The 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 Agent
There 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 Agent
If 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 Rules
Whether 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 Agents
There 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).

182

Chapter 17: Protocol Agents

The following Protocol Agents and parameters are available on Sensors:
TABLE 17.1 Protocol Agents Used by Sensors

Name
FTP (see FTP Agent, on page 184) GRE (see GRE Agent, on page 185) H.323 (see H.323 Agent, on page 185) HTTP and HTTP Proxy (see HTTP Agents, on page 185) ICMP (see ICMP Agent, on page 186) IPv4 (see IPv4 Agent, on page 186)

Protocol Validation
yes

Deep Inspection
yes

Allow Related Connections
yes

Protocol Agent Parameters
Allow Active Mode Allow Passive Mode Apply Tunnel Rematch Tunnel IPv4 Protocol Tunnel IPv6 Protocol no Logging of Accessed URLs n/a n/a

yes

yes

n/a

no yes yes yes

yes yes no no

no n/a n/a n/a

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

yes

yes

n/a

Apply Tunnel Rematch

yes

no

n/a

n/a

IPv6 Encapsulation (see IPv6 Encapsulation Agent, on page 187)
MSRPC (see MSRPC Agent, on page 187) NetBIOS (see NetBIOS Agent, on page 187) Oracle (see Oracle Agent, on page 187) Remote Shell (RSH) (see Remote Shell (RSH) Agent, on page 188)

yes

yes

n/a

Apply Tunnel Rematch

yes no no

yes yes yes

yes n/a yes

no no no

no

yes

yes

no

Using Protocol Agents

183

TABLE 17.1 Protocol Agents Used by Sensors

Name
Services in Firewall (see Services in Firewall Agent, on page 188) SIP (see SIP Agent, on page 188) SMTP (see SMTP Agent, on page 189) SSH (see SSH Agent, on page 189) SunRPC (see SunRPC Agents, on page 189) TCP (see TCP Proxy Agent, on page 189) TFTP (see TFTP Agent, on page 190)

Protocol Validation
n/a

Deep Inspection
n/a

Allow Related Connections
n/a no

Protocol Agent Parameters

yes yes yes no no no

yes yes yes yes yes yes

yes n/a n/a no no yes

n/a no no no no no

FTP Agent
One 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:
TABLE 17.2 FTP Protocol Agent Parameters

Parameter
Allow Active Mode

Description
Allows active mode FTP connections, where the server opens a data connection to the client. Options: Yes (default)/No

184

Chapter 17: Protocol Agents

TABLE 17.2 FTP Protocol Agent Parameters (Continued)

Parameter
Allow Passive Mode

Description
Allows passive mode FTP connections, where the client opens a data connection to the server. Options: Yes (default)/No Allows control connections to be opened with the data connection. Options: True (default)/False

Allow Related Connections

GRE Agent
The 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:
TABLE 17.3 GRE Protocol Agent Parameters

Parameter

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

Apply Tunnel Rematch

Tunnel IPv4 Protocol

Tunnel IPv6 Protocol

H.323 Agent
H.323 defines a set of protocols as well as the components and procedures for realtime 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 Agents
There are two Hypertext Transfer Protocol (HTTP) Protocol Agents available on sensors:

Using Protocol Agents

185

• 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.
TABLE 17.4 HTTP Protocol Agent Parameters

Parameter
Logging of Accessed URLs

Description
Defines whether the URL address used in the communications is logged or not.

ICMP Agent
The 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 Agent
The 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 Agent
The 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.5 IPv4 Encapsulation Protocol Agent Parameters

Parameter

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

Apply Tunnel Rematch

186

Chapter 17: Protocol Agents

IPv6 Agent
The 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 Agent
The 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.
TABLE 17.6 IPv6 Encapsulation Protocol Agent Parameters

Parameter

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

Apply Tunnel Rematch

MSRPC Agent
The 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 Agent
This Protocol Agent provides deep inspection for Windows NetBIOS Datagram Service connections. There are no configurable parameters for this Protocol Agent.

Oracle Agent
This Protocol Agent handles Oracle Transparent Network Substrate (TNS) protocolbased 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.

Using Protocol Agents

187

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:
TABLE 17.7 Oracle Protocol Agent Parameters

Parameter
Allow Related Connections

Description
Allows/disallows database connection based on information in the listener connection. Options: True (default)/False

Remote Shell (RSH) Agent
Remote 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:
TABLE 17.8 Remote Shell (RSH) Protocol Agent Parameters

Parameter
Allow Related Connections

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

Services in Firewall Agent
This 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 Agent
The 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.

188

Chapter 17: Protocol Agents

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

Parameter
Allow Related Connections

Description
Allows the SIP media connections based on the signalling connection. Options: True (default)/False

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

SSH Agent
Secure 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 Agents
StoneGate 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 Agent
The 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.

Using Protocol Agents

189

TFTP Agent
The 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.
TABLE 17.10 TFTP Protocol Agent Parameters

Parameter
Allow Related Connections

Description
Allows replies to TFTP requests. Options: True (default)/False.

Examples of Protocol Agent Use
The 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 FTP
Company 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 Users
Company 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.

190

Chapter 17: Protocol Agents

The administrators: 1. Add the Continue rule above the existing Access rule like this:
TABLE 17.11 Example Rules for Company B

Source
Internal Networks Internal Networks

Destination
ANY ANY

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

Action
Continue Allow

2. Refresh the policy on the sensor.

Examples of Protocol Agent Use

191

192

Chapter 17: Protocol Agents

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. The following sections are included: 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 Blacklisting
Blacklisting 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 Blacklisting
Blacklisting 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:
TABLE 18.1 Risks of Blacklisting

Risk
Blacklisting legitimate connections (false positive)

Explanation
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. 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 denialof-service on legitimate traffic.

Causing self-inflicted denial of service (DoS)

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.

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

194

Chapter 18: Blacklisting

Configuration of Blacklisting
Blacklisting 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 Workflow
The 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 Rules
Blacklisting 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 Connections
The 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 Policy
Blacklist scope options in IPS Inspection rules trigger blacklisting for the detected events. Blacklisting scope options can be defined for any type of IPS Inspection rules, including correlation rules. Blacklisting is defined using the detected event’s IP source and destination addresses, and optionally the TCP or UDP ports. If the event does not contain this information, a blacklist entry cannot be created. The source and destination addresses to be blacklisted can be determined from the IP addresses of the detected event. Netmasks can also be used to blacklist not just the detected event’s IP address but also its network.

Using Blacklisting
Blacklisting 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,

196

Chapter 18: Blacklisting

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 Blacklisting
You 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 Blacklisting
The 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 Blacklisting
The 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 Manually
Company 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 IPS
Company 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.

198

Chapter 18: Blacklisting

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. The following sections are included: 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 Filters
Network 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 Filters
You 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 Filters
StoneGate 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 Elements
Predefined 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

Configuration of Filters

203

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.
TABLE 19.1 Predefined Filters

Predefined Filters
Action Filters Alert Filters Protocol Filters Situation Filters General Filters

Explanation
Filters that match different actions (for example, Allow or Discard). Filters that match different alerts (for example, Active Alert or Not Alert). Filters that match different protocols (for example, FTP or IP) Filters that match different situations (for example, Aggressive Port Scan). Other Filters that match other criteria in network traffic (for example, Match All or Match None).

Configuration Workflow
The 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 Filter
In 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 Fields
When 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.

204

Chapter 19: Filters

Task 3: Select Operations
Operations 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
bitwise AND sum of

Description
Bitwise 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. Sums the values of the defined fields.

TABLE 19.3 Comparison Operations

Operation
between contains

Description
Matches when the value on the left-hand side of this operation is in the range of the right-hand side. Matches when the element on the left-hand side of this operation contains one of the elements on the right-hand side. 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. Matches when the value on the left-hand side of this operation is equal to the value on the right-hand side. Matches when the value on the left-hand side of this operation is larger than the value on the right-hand side.

defined

equal to greater than

Configuration of Filters

205

TABLE 19.3 Comparison Operations (Continued)

Operation
greater than or equal in is false is true like (case insensitive) like (case sensitive) map size exceeded require all occurrences of require any occurrence of smaller than smaller than or equal

Description
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. Matches when the element on the left-hand side of this operation belongs to the element on the right-hand side. Matches when the value of a Boolean type of field is false. Matches when the value of a Boolean type of field is true. Matches when the value on the left-hand side of this operation is equal to the right-hand side without considering character capitalization. Matches when the value on the left-hand side of this operation is equal to the right-hand side when considering character capitalization. Matches when the size of the selected map structure is exceeded. Matches only when all the values match. Matches when any of the values matches. Matches when the value on the left-hand side of this operation is smaller than the value on the right-hand side. 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

Operation
AND (Require all of) OR (Require any of) NOT

Description
Matches when all of the operations in the Filter are true. Matches when any of the operations in the Filter is true. Matches when all of the operations in the Filter are false.

206

Chapter 19: Filters

Task 4: Add Field Values
You 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 Fields
In 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.

Configuration of Filters

207

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

False by comparison

False by filter

True by filter

Undefined

208

Chapter 19: Filters

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

Configuration of Filters

209

Using Filters
Filters 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 Interactively
Logs 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 Filters
The 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 Address
The 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.

210

Chapter 19: Filters

Creating a Filter for Logs from Servers in Internal Network Excluding a Server
StoneGate 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

212

Chapter 19: Filters

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. The following sections are included: 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 Management
StoneGate 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 View
The 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 Entries
Log 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 Entries
Alert 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 Entries
Audit 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 Management
The 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

Configuration of Log Management

215

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.

216

Chapter 20: Log Management

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.

Configuration of Log Management

217

Default Elements
Filters 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 Workflow
The 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 Options
Before 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
TABLE 20.1 Log Levels

Log Level
Alert Stored None An alert entry is generated.

Explanation

A log entry is generated and stored on the Log Server. The rule does not produce any log entries.

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.

218

Chapter 20: Log Management

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 Pruning
You 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 newlygenerated 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.

Configuration of Log Management

219

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 Tasks
Log 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 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. 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. Deletes the selected data from the current log files on the Log Server.

Export Log Task

Archive Log Task

Delete Log Task

220

Chapter 20: Log Management

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 Management
There 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 Files
A 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 Directories
Log 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 Diagnostics
In 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 Alerts
New 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 Escalation
In 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 Servers
Log 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 Management
The examples in this section illustrate some common uses for Log Management in StoneGate and general steps on how each scenario is configured.

Archiving Old Logs
Last 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

222

Chapter 20: Log Management

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:
TABLE 20.3 Archive Log Task for Company A

Option
Time Range Filter for Copying Filter for Deletion Archive Target Directory Last Full Month

Setting

A custom filter which matches the important log data that the administrators want to archive. Match All to delete all last month’s logs from the Log Server. A network drive.

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

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.

224

Chapter 20: Log Management

CHAPTER 21

Alert Escalation

Alert Escalation means defining when and how the system notifies the administrators when an alert entry is created. The following sections are included: 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 Escalation
Alert 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 Escalation
Elements 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

2

3

4

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

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

Configuration of Alert Escalation

227

• 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 Situations
StoneGate 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 Workflow
The 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 Alerts
If 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 Chains
Alert Chains define how, in which order and to whom the notifications on alert entries are sent.

228

Chapter 21: Alert Escalation

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

Configuration of Alert Escalation

229

The fields in Alert Policy rules are explained in the table below.
TABLE 21.1 Alert Policy Fields

Field
Sender Alert and Situation

Explanation
Allows you to limit the rule to match alert entries generated by one or more particular StoneGate components. Allows you to limit the rule to match alert entries that are based on one or more particular Alert elements or Situation elements. Allows 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. 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. Defines the Alert Chain that is used for escalating matching alert entries. Your optional free-form comment for this rule.

Time

Severity

Chain Comment

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 Channels
To 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.2 Configurable Alert Channels

Alert Channel
Custom Script SMTP (E-mail)

Configuration
Define the absolute path to the script to be executed. 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.

230

Chapter 21: Alert Escalation

TABLE 21.2 Configurable Alert Channels (Continued)

Alert Channel
SMS (text message) SNMP

Configuration
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. Define the SNMP Gateways used.

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.
TABLE 21.3 Contents of Escalated Alerts

Alert Channel
Custom Script

Information Included in the Notification
Depends on the script you create. See Using a Custom Script for Alert Escalation, on page 233. 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. 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. 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.

SMTP (E-mail)

SMS (Text Message)

SNMP

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.
TABLE 21.4 Final Actions

Final Action
None

Explanation
Stops the escalation of this alert entry.

Configuration of Alert Escalation

231

TABLE 21.4 Final Actions (Continued)

Final Action

Explanation
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. Continues the alert escalation from the top of the Alert Chain you select in the second pull-down menu. Returns the processing to the Alert Policy from the next rule below the rule that redirected the processing to this Alert Chain.

Acknowledge

Redirect Return

Using Alert Escalation
Some 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 Chains
As 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.

232

Chapter 21: Alert Escalation

Using a Custom Script for Alert Escalation
For 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.
TABLE 21.5 Arguments Passed to the Custom Scripts

Argument number
1 2 3 4 5 6 7 8 9

Content
Alert ID Alert Name Alert Originator Alert Date Alert Message Alert Severity Alert Short Description Event ID Situation Description

Description
Identifies the alert uniquely in the Log Server. The name defined in the alert properties. The IP address of the Sensor, Analyzer, firewall, or other system component that generated this alert. The date when the alert was originally generated. A short alert description. The severity value of the alert The contents of the Comment field in the alert properties. IPS only: reference to the event ID that triggered the alert. Long description of the situation that triggered the alert.

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.

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

Example of Alert Escalation
The 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 Responsibilities
In 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:
TABLE 21.6 “HQ Important Alerts” Alert Chain

Channel
SMS

Destination
[Phone number for HQ shared mobile phone]

Delay
15 min

234

Chapter 21: Alert Escalation

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

Channel
SMS

Destination
[Phone number for BO shared mobile phone]

Delay

• 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:
TABLE 21.7 “HQ Minor Alerts” Alert Chain

Channel
USER NOTIFICATION SMS

Destination
HQ Administrator A HQ Administrator B [etc.] [Phone number for HQ shared mobile phone]

Delay
60 min

• 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:
TABLE 21.8 Example Alert Policy

Sender
HQ Analyzer HQ Log Server Management Server HQ Analyzer HQ Log Server Management Server BO Analyzer BO Log Server BO Analyzer BO Log Server

Alert and Situation
ANY

Severity
5...10

Chain
HQ Important Alerts

ANY

1...4

HQ Minor Alerts

ANY ANY

5...10 1...4

BO Important Alerts BO Minor Alerts

3. Define the SMS channel in the HQ Log Server’s properties.

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.

236

Chapter 21: Alert Escalation

CHAPTER 22

Reports

Reports are summaries of logged firewall and IPS events as well as monitoring statistics. The following sections are included: 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 Reports
StoneGate 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 Reports
Reports 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

Configuration of Reports

239

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

Chart Type

Progress Summary

A bart chart or a curve chart.

Top Rate Summary

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

240

Chapter 22: Reports

TABLE 22.1 Summary Types (Continued)

Type

Description
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). Illustrates current values for items in the database (for example, the number of administrators or the version of an engine).

Chart Type

Drill-down Top Rate Summary

A bar chart or a pie chart.

Static Information

A table.

Default Elements
The 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.
TABLE 22.2 Predefined Report Item Types

Report Item Type
Common

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

Configuration of Reports

241

TABLE 22.2 Predefined Report Item Types (Continued)

Report Item Type
Counters

Explanation
Items for statistical monitoring information and log data. 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. Items for IPS logs. Items for logs generated by the deep inspection option in rule properties. Items specific for SSL VPN logs. Items for audit logs.

Firewall and VPN

IPS Inspection SSL VPN Audit

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 Workflow
The 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 Design
There 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 Properties
The 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.

242

Chapter 22: Reports

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
Name

Explanation
A name for the report design. It is used in the Reports view and in the reports. An 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. 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. A time frame for the report. This affects the dates offered by default when you generate a report using this design. Allows you to enter a number and select a period to include the comparison data from a previous period of the same length. 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. Allows you to select whether StoneGate network elements and/or a DNS are used to resolve the IP addresses in the report. 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. Allows you to select the type of logs from which the data is selected for the report.

Category

Comment

Period Compare With

Time Resolution

Resolve IP Addresses Using

Report Expiration

Log Data Types

Configuration of Reports

243

TABLE 22.3 Report Design Properties (Continued)

Property

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

Filter

Task 3: Select Report Sections
A 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.
TABLE 22.4 Report Section Properties

Property
Name Comment

Explanation
A name for the report section. It is used in the Reports view and in the reports. An optional free-form comment that is shown above the section data in the report when you print or export the report. The 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. 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. The unit for data in tables and graphs. 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. Allows you to choose whether you want the export file of the finished reports to include a table, a chart, or both. Allows you to select the type of logs from which the data is selected for the report.

Section Type

Preferred Chart Type Unit for Traffic Rates Maximum Number of Top Items Print/Export Content Log Data Types

244

Chapter 22: Reports

TABLE 22.4 Report Section Properties (Continued)

Property

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

Filter

Related Element

Task 4: Select Report Items
A 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.

Configuration of Reports

245

Using Reports
This section explains how you can generate, export, and post-process reports.

Generating Reports
The 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

246

Chapter 22: Reports

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 Reports
You 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 Reports
You 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 Files
PDF 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 Files
Tab-delimited text files are designed to be used for further processing. The tabdelimited 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.
1 2 3

File Content
<Report Title>, <Start Time> <End Time> <empty line> <Section Content for each section>

Description
Start and End Time define the reporting period in format YYYY/MM/DD hh:mm:ss.

Each section of the report follows the format described below.

Line No.
1 2

Section Content
<Section Name>[; <Section Comment>] <empty line>

Description
Optional Section Comment with a leading semi-colon (;) may follow the Section Name.

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

248

Chapter 22: Reports

TABLE 22.5 Structure of a Tab-Delimited Text Report File (Continued) Tab delimited column labels. Some columns may not have a label, and labels may be padded with trailing spaces.

1

<Table Heading>

2 3Section data’s last line

<empty line> <Table rows> Tab delimited values. Value in any given column can be empty. The column values are not padded.

<empty line>

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

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 Files
You 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.
TABLE 22.6 Command Arguments for Post-Processing Reports

Command Argument
-report_name name -report_file_title title -report_categ name -creation_time YYYY/MM/ DD hh:mm:ss -period_begin YYYY/MM/DD hh:mm:ss -period_end YYYY/MM/DD hh:mm:ss -pdf_file filename -text_file filename -filter_name filter -filter_categ name

Explanation
The name of the report. The title of the report file. A category assigned to the report (and to the report file). The report creation time. The begin time of the reporting period. The end time of the reporting period. The name of the report file for PDF export. The name of the report file for export as plain text. The name of the filter assigned to the task. The category assigned to the task filter.

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

250

Chapter 22: Reports

Using the System Report
The 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 Reports
The 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 Designs
The 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 Users
Company 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

252

Chapter 22: Reports

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. The following sections are included: 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 Categories
In 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 Categories
Categories 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 Elements
The 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 Workflow
The 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 Categories
You 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 Categories
Elements 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 elements
Categories 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 Categories
Categories 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 Categories
The examples in this section illustrate some common uses for Categories in StoneGate and general steps on how each scenario is configured.

Managing a Large Enterprise
Company 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 Categories
Company 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. The following sections are included: 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 Cases
When 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 Cases
Incident 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.
TABLE 24.1 Incident Case tabs

Tab
Data Collection Player List Journal

Explanation
Allows you to attach information that is needed to provide context for investigating an incident. Lists the elements or IP addresses that were involved in the incident Allows you to record comments about administrator actions during the incident investigation Automatically gathers and shows all the log and audit entries that track actions performed in this incident case window

History

Configuration Workflow
The 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 Case
The 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.

260

Chapter 24: Incident Cases

Task 2: Attach Data
The following types of data can be attached:
TABLE 24.2 Data Collection

Data Item
Logs

Explanation
Log, alert, and audit entries from firewall or IPS engines and Log and Management servers A 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. A simple text file for attaching excerpts of text, for example, by copying and pasting from e-mail, IRC or instant messaging. Any type of file. For example, saved reports, text files, saved e-mail messages, packet capture files, or screenshot images

Policy Snapshot

Memo File

Task 3: Attach Players
A 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 Entries
The 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 Case
The 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.

Configuration of Incident Cases

261

Using Incident Cases
There 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 Administrator

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

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

1. 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 Case
The 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.

262

Chapter 24: Incident Cases

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

264

Chapter 24: Incident Cases

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

Port/Protocol
18889/TCP 18890/TCP 4950/TCP 514/UDP

Contacting Hosts
Management Server Sensor Management Server syslog Analyzer, Sensor Management Client, Monitoring Server Sensor, Analyzer Log Server Management Client, Log Server Monitoring Client

Service Description
Control connections, status monitoring, and policy upload Event data sent from the Sensors. Remote upgrade from the Management Server Syslog messages forwarded to Analyzer Log and alert messages from Analyzers and recording file transfers from Sensors Management Client and Monitoring Server connections to the Log Server. Initial contact from Sensor or Analyzer during installation Initial contact from Log Server during installation Management Client and Log Server connections to the Management Server Monitoring Client connection to Monitoring Server.

Service Element Name
SG Commands (Analyzer) SG Event Transfer SG RemoteUpgrade Syslog (UDP)

Log Server

3020/TCP

SG Log SG Data Browsing, SG Data Browsing (Monitoring Server) SG Initial Contact SG Log Initial Contact SG Control SG Control (Monitoring Client)

Log Server

8914-8918/ TCP

Management Server Management Server Management Server Monitoring Server

3021/TCP 5936/TCP 8902-8913/ TCP 8919-8921/ TCP

268

Appendix A: StoneGate IPS Ports

TABLE A.1 StoneGate IPS Ports (Continued)

Listening hosts
Sensor

Port/Protocol
18888/TCP 3000-3001/ UDP 3002,3003, 3010/TCP 4950/TCP

Contacting Hosts
Management Server

Service Description
Control connections, status monitoring, and policy upload Heartbeat and state synchronization between the cluster nodes. Remote upgrade from the Management Server Blacklist entries sent to firewall

Service Element Name
SG Commands (Sensor) SG State Sync (Multicast), SG State Sync (Unicast), SG Data Sync SG Remote Upgrade SG Blacklisting

Sensor

Sensor

Sensor StoneGate firewall

Management Server Management Server, Analyzer

15000/TCP

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. The following sections are included: Management Center Commands, on page 272 Engine Commands, on page 280

271

Management Center Commands
The 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
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.

sgArchiveExport i=INPUT_FILE pass=PASSWORD [ e=FILTER_EXPRESSION ] [ f=FILTER_FILE ] [ format=CSV|XML ] [ host=ADDRESS ] [ login=LOGIN_NAME ] [ o=OUTPUT_FILE ] [ -v ] [ -h ]

272

Appendix B: Command Line Tools

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

Command

Description
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. 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. 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. 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. Certifies the Monitoring Server on the Management Server. The certificate is required to allow secure communication between the Monitoring Server and the Management Server. 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.

sgBackupLogSrv

sgBackupMgtSrv

sgCertifyLogSrv

sgCertifyMgtSrv

sgCertifyMonitoringServer

sgChangeMgtIPOnLogSrv NEW_IP_ADDR

Management Center Commands

273

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

Command

Description
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 Starts the StoneGate Management Client. Creates a superuser administrator account. The Management Server needs to be stopped before running this command. 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.

sgChangeMgtIPOnMgtSrv NEW_IP_ADDR

sgClient sgCreateAdmin

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 ]

274

Appendix B: Command Line Tools

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

Command

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

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

sgHA [host=host] login=login name password=password [-h|--help] [-set-active] [-set-standby] [-force-active] [-sync]

Management Center Commands

275

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

Command

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

sgImport [host=host] login=login name password=password file=file path and name

sgImportExportUser [host=host] login=login name pass=password action=[import|export] file=file path and name

The user information in the export file is stored as plaintext. Handle the file securely.
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. Recreates the Log Server configuration if the configuration file has been lost.

sgInfo

sgReinitializeLogServer

276

Appendix B: Command Line Tools

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

Command

Description
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. 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. Restores the Certificate Authority (CA) or the Management Server certificate from a backup file in the <installation directory>/backups/ directory. Restores the Log Server (logs and/or configuration files) from a backup file in the <installation directory>/ backups/ directory. Restores the Management Server (database and/or configuration files) from a backup file in the <installation directory>/backups/ directory. Displays the CA certificate’s fingerprint on the Management Server. Starts the Log Server’s database. (The Log Server’s database is started and stopped automatically when starting/stopping the Log Server service.) Starts the Log Server and its database.

sgReplicate [-h|--help] [-nodiskcheck] [-backup backupname] -standby-server management-name

sgRestoreArchive ARCHIVE_DIR

sgRestoreCertificate

sgRestoreLogBackup

sgRestoreMgtBackup

sgShowFingerPrint

sgStartLogDatabase

sgStartLogSrv

Management Center Commands

277

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

Command
sgStartMgtDatabase

Description
Starts the Management Server’s database. (The Management Server’s database is started and stopped automatically when starting/stopping the Management Server service.) Starts the Management Server and its database. Starts the Monitoring Server used by the Monitoring Client. Stops the Log Server’s database. Stops the Management Server’s database. (The Management Server’s database is started and stopped automatically when starting/stopping the Management Server service.) Stops the Monitoring Server used by the Monitoring Client. 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.

sgStartMgtSrv sgStartMonitoringServer sgStopLogDatabase

sgStopMgtDatabase

sgStopMonitoringServer

sgStopRemoteMgtSrv [-host HOST] [-port PORTNUM] [-login LOGINNAME] [-pass PASSWORD]

278

Appendix B: Command Line Tools

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

Command

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

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 ]

Management Center Commands

279

Engine Commands
StoneGate 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
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-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

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

280

Appendix B: Command Line Tools

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

Command

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

sg-logger -f FACILITY_NUMBER -t TYPE_NUMBER [-e EVENT_NUMBER] [-i "INFO_STRING"] [-s] [-h]

sg-raid [-status] [-add] [-re-add] [-force] [-help]

sg-reconfigure [--boot] [--maybe-contact] [--no-shutdown]

sg-status [-l] [-h]

Engine Commands

281

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

Command

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

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

sg-version

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

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.
TABLE B.3 General Command Line Tools on Engines

Command
dmesg

Description
Shows system logs and other information. Use the -h option to see usage.

282

Appendix B: Command Line Tools

TABLE B.3 General Command Line Tools on Engines (Continued)

Command
halt Shuts down the system.

Description

ip

Displays IP-address related information. Type the command without options to see usage. Example: type ip addr for basic information on all interfaces. Tool for sending ICMP echo packages to test connectivity. Type the command without options to see usage. Reports status of running processes. Reboots 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. Secure copy. Type the command without options to see usage. Secure FTP (for transferring files securely). Type the command without options to see usage. SSH client (for opening a terminal connection to other hosts). Type the command without options to see usage. Gives information on network traffic. Use the -h option to see usage. Displays the top CPU processes taking most processor time. Use the -h option to see usage. Traces the route packets take to the specified destination. Type the command without options to see usage. Outputs various VPN related information. Type the command without options to see usage.

ping ps

reboot

scp sftp

ssh

tcpdump

top

traceroute

vpninfo

Engine Commands

283

284

Appendix B: Command Line Tools

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. The following sections are included: Pre-Defined User Aliases, on page 286 System Aliases, on page 287

285

Pre-Defined User Aliases
User Aliases are usually created by administrators, but there are also some predefined 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
$ Allowed ICMP Local Sources $ Allowed ICMP Remote Sources $ Allowed SSH Local Sources

Description
Defines source IP addresses, probably part of the $ Local Protected Sites, allowed to ping the local StoneGate VPN-only security gateway. 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. 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. 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. Addresses that can be allocated by DHCP server(s).

$ Allowed SSH Remote Sources $ DHCP address pools $ DHCP address pools for IPsec VPN Clients $ DHCP servers $ DHCP servers for IPsec VPN Clients

Address pools for assigning virtual IP addresses to VPN clients. DHCP servers. The DHCP servers defined for assigning virtual IP addresses to VPN clients.

286

Appendix C: Predefined Aliases

System Aliases
System 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
$$ DHCP Enabled Interface Addresses $$ DHCP Interface X.dns $$ DHCP Interface X.gateways $$ DHCP Interface X.ip $$ DHCP Interface X.net $$ Local Cluster $$ Local Cluster (CVI addresses only) $$ Local Cluster (DHCP Interface Addresses) $$ Local Cluster (NDI addresses only) $$ Local Cluster (NDI for heartbeat addresses only) $$ Local Cluster (NDI for management addresses only) $$ Log Servers $$ Management Servers $$ Valid DHCP Address Pools for IPsec VPN clients $$ Valid DHCP Servers $$ Valid DHCP Servers for IPsec VPN clients

Description
IP addresses of CVIs which have DHCP relay enabled. IP address of the DNS for interface number X. IP address of the default router for interface number X. Dynamic IP address allocated for interface number X. Network behind the dynamic IP interface number X. All addresses of the cluster. All CVI addresses of the cluster. Dynamic IP address of the engine itself. All NDI addresses of all nodes in the cluster. Heartbeat NDI addresses of all nodes in the cluster. Management NDI address(es) of all nodes in the cluster. IP addresses of all Log Servers. IP addresses of all Management Server. Address pools defined in the Internal VPN Gateway properties for assigning virtual IP addresses to VPN clients. All DHCP servers defined for the firewall. 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. The following sections are included: 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 Parameters
The table below explains the parameters for the Scan Started Event Context.
TABLE D.1 Scan Detection Parameters

Parameter
Port scan start period (seconds) Port scan idle timeout (seconds) Port scan status delay (seconds) Maximum normal TCP connections Maximum allowed open TCP ports Maximum unreplied TCP connections Maximum allowed closed TCP ports Maximum TCP segments with no SYN or ACK Wait time for TCP connections Maximum UDP packet destinations Maximum bidirectional UDP transfers Maximum unidirectional UDP transfers Maximum allowed closed UDP ports Maximum ICMP requests per host Maximum unreplied ICMP request destinations

Description
Port scan is reported if any of the thresholds is exceeded within this time limit. Port scan is assumed finished if the originator makes no scan attempts within this time limit. Defines how often an interim status of ongoing port scan is reported. Defines how many TCP connections that proceed normally according to the protocol definitions are allowed before action is taken. Number of SYN+ACK replies allowed during the tracking before action is taken. Number of unreplied TCP connections during the tracking before action is taken. Number of RST replies allowed during the tracking before action is taken. Number of TCP segments with no SYN or ACK flag before action is taken. Seconds waited before considering TCP connection as successful port scan or unreplied connection attempt. Number of UDP destinations allowed per host during the tracking before action is taken. Number of bidirectional UDP transfers allowed per host during the tracking before action is taken. Allowed number of UDP destinations that have not replied or have replied with ICMP error during the tracking period before action is taken. Number of ICMP Port Unreachable replies allowed per host during the tracking before action is taken. Number of ICMP request destinations allowed per host during the tracking before action is taken. 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

TABLE D.1 Scan Detection Parameters (Continued)

Parameter
Maximum ICMP Echo Request destinations Maximum unreplied ICMP Echo Requests Maximum ICMP Timestamp Request destinations Maximum unreplied ICMP Timestamp Requests Maximum ICMP Netmask Request destinations Maximum unreplied ICMP Netmask Requests

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

Correlation Context Parameters
Event Compress
Event Compress combines repeated similar events into the same log entry, reducing clutter in the Logs view.
TABLE D.2 Event Compress Parameters

Field
Correlated Situations Time Window

Option (if any)

Explanation
Situation(s) you want to compress. All 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.

Select Log Fields Enabled Ignore

Events 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. Events 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. The selected log fields are used by the matching option you selected in the previous step.

Lognames

291

TABLE D.2 Event Compress Parameters (Continued)

Field

Option (if any)
Very Early

Explanation
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. Filters in data for the compression.

Location

Early Late Very Late

Compress Filter

Event Count
Event 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.
TABLE D.3 Event Compress Parameters

Field
Correlated Situations Time Window Alarm Threshold

Option (if any)

Explanation
Situation(s) you want to count. The period of time within which the matches to the Situation must occur the specified number of times. The number of times that the selected Situation(s) must occur for the Correlation Situation to match.

Select Log Fields Enabled Ignore

Events 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. Events 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. The selected log fields are used by the matching option you selected in the previous step.

Lognames

292

Appendix D: Situation Context Parameters

Event Group
Event 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.
TABLE D.4 Event Compress Parameters

Field

Option (if any)
Event Match Filter for grouping.

Explanation

Member (column)

Needed Number Binding

How many occurrences of the Event selected for this Member are required for them to be included in the grouping. Log field used for the grouping. Situation(s) you want to group. 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. 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. The period of time within which the Situation must occur for them to be grouped.

Correlated Situations

Yes Keep and Forward Events No

Time Window Size

Continuous Responses

Yes

Makes the Analyzer respond as defined in the Inspection rule to each occurrence of the defined event within the selected Time Window. Makes the Analyzer respond only to the first occurrence of the defined event within the selected Time Window.

No

Event Match
Event Match allows filtering event data produced by specific Situations using Filter expressions.
TABLE D.5 Event Compress Parameters

Field
Correlated Situations

Explanation
Situation(s) you want the Correlation Situation to match.

293

TABLE D.5 Event Compress Parameters (Continued)

Field
Filter

Explanation
Filter for finding a pattern in the event data.

Event Sequence
Event 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.
TABLE D.6 Event Compress Parameters

Field
Entry to/Exit from (columns) Correlated Situations

Option (if any)
Event Match Binding

Explanation
Filter for selecting data for the sequencing. Log field that the Correlation Situation traces to find a sequence. Situation(s) from which you want to find sequences. 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. 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. The period of time within which the Situation must occur for them to be considered a sequence.

Yes Keep and Forward Events No

Time Window Size

Regular Expression Parameter
See Regular Expression Syntax, on page 295.

Other Context Parameters
See 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).

294

Appendix D: Situation Context Parameters

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. The following sections are included: 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 Expressions
StoneGate 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
<char>

Description
Matches only the defined characters. matches any character, including the null character \x00 and a missing character. Matches also other than printable characters, such as the linefeed. 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.

Example
‘2’, ‘A’, ‘foo’ match exactly to the defined characters: ‘2’, ‘A’, and ‘foo’ respectively.

. (dot)

‘.’ matches any single character or byte.

\x<hex>

‘\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

TABLE E.1 StoneGate Regular Expression Syntax (Continued)

Sequence

Description
Matches when none of the characters in the list is present. Matches all the characters ranging from <char1> to <char2>, these two characters included. 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 [09], 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]. Used for escaping special metacharacters to be interpreted as normal characters, in this case as <char>. The metacharacters are: \|)(][^-*+?.# 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. Matches if either the sub-expression <expr1> or <expr2> matches.

Example
‘[^aBc]’ matches if none of the characters ‘a’, ‘B’, or ‘c’ is present in the matching location of the inspected string. ‘[a–f]’ matches any character within the range from ‘a’ to ‘f’, with ‘a’ and ‘f’ included.

[^<char>]

[<char1>– <char2>]

[:<class>:]

‘[[:digit:]]’ matches any digit, e.g. 1, 5, or 7.

\<char>

‘\[’ matches the ‘[’ character instead of interpreting it as the regular expression class metacharacter.

#<text>

‘# my comment.’ is not used in the matching process.

(<expr1>| <expr2>)

‘a(bc|de)’ matches ‘abc’ and ‘ade’.

It is also possible to indicate repeated, consecutive regular expressions by using quantifiers as described in Table E.2.
TABLE E.2 StoneGate Regular Expression Quantifiers

Quantifier
<expr>*

Description
Matches if there are zero or more consecutive <expr> strings. Matches if there are one or more consecutive <expr> strings.

Example
‘a*’ matches ‘<empty>’, ‘a’, ‘aa’ and so on. ‘a+’ matches ‘a’, ‘aa’, ‘aaa’ and so on, but not the empty string.

<expr>+

297

TABLE E.2 StoneGate Regular Expression Quantifiers (Continued)

Quantifier
<expr>?

Description
Matches if there is zero or one <expr> string. {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.

Example
‘a?’ matches ‘<empty>’ and ‘a’. “a{5,}” matches five or more consecutive ‘a’. “a{5,7}” matches five, six, or seven consecutive ‘a’.

<expr>{n,m}

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

298

Appendix E: Regular Expression Syntax

Special Character Sequences
The 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
\a \t \n \f \r \e \OOO \xHH \c<char> \w \W \s \S \d \D \b Bell (BEL) = \x07 Horizontal tab (HT) = \x09 Linefeed (LF) = \x0A Formfeed (FF) = \x0C Carriage return (CR) = \x0D Escape (ESC) = \x1B

Description

Octal code OOO of the character. Hexadecimal code HH of the character. Control character that corresponds to Ctrl+<char> "word" class character = [A-Za-z0-9_] Non-"word" class character = [^A-Za-z0-9_] Whitespace character = [ \t\r\n\f] Non-whitespace character = [^ \t\r\n\f] Digit character = [0-9] Non-digit character = [^0-9] Backspace (BS) = \x08 Note: allowed only in bracket expressions. 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”.

\Q <expr> \E

299

Pattern-Matching Modifiers
The StoneGate regular expression syntax has Perl-like extensions. The patternmatching 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

Sequence

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

(?i)

(?s)

(?x)

(?C)

(?L)

300

Appendix E: Regular Expression Syntax

TABLE E.4 Pattern-Matching Modifiers (Continued)

Sequence

Description
“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. Applies the <modifiers> modifiers only to the subexpression <sub-expr>. These modifiers are not used in other parts of the regular expression.

(?S)

(?<modifiers> :<sub-expr>)

301

Variable Extensions
Variables 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

Sequence
(?{<var>=<value>})

Description
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 ‘,’. 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.

(?{<var>=<value>,ignore})

302

Appendix E: Regular Expression Syntax

TABLE E.5 Variable Extensions (Continued)

Sequence
(?{<var>==<value>})

Description
The expression matches only when the <var> variable’s value is <value>. Multiple conditional expressions can be defined by separating them with ‘&&’. 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>.

(?{<var1>==<value1>-> <var2>=<value>})

Variables are used in the two top-level branches that are separated by the logical OR symbol ‘|’.
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})

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.

303

$offset System Variable
The 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.
TABLE E.6 $offset Variable Comparison

Sequence

Description
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 ‘&&’.

(?{$offset==<value>})

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
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})

304

Appendix E: Regular Expression Syntax

Parallel Matching Groups
StoneGate 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
#!!GROUP(X) Comment #!!#

Description
'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

306

Appendix E: Regular Expression Syntax

APPENDIX F

Log Field Values

The following sections are included: 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

L o g E n t r y T a b le
The 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
Acknowledged Action Administrator Alert Type Attacker IP Auth. User Blacklist executor Blacklist response Blacklist response.Blacklist duration Blacklist response.Blacklist executor Blacklist response.Endpoint 1 addr Blacklist response.Endpoint 1 mask Blacklist response.Endpoint 1 port Blacklist response.Endpoint 1 port range Acknowledged Alert

Description

Connection action. The action values are Allow, Discard, Refuse, Terminate, Wait for further actions, and Wait for authentication. Administrator who triggered the event Type of alert IPv4 address of the attacking host Username of authorized user Target firewall or sensor Firewall blacklist response Duration of blacklisting in seconds

Target firewall or sensor

Blacklisted IP addresses for Endpoint1.

Netmask for blacklisted Endpoint1 IP address (32 = host address)

Blacklisted Endpoint1 port (empty = all ports)

Blacklisted Enpoint1 port range.

308

Appendix F: Log Field Values

TABLE F.1 Fields of the Log Entry Table (Continued)

Field
Blacklist response.Endpoint 2 addr Blacklist response.Endpoint 2 mask Blacklist response.Endpoint 2 port Blacklist response.Endpoint 2 port range Blacklist response.Firewall ID Blacklist response.IP Protocol Blacklist response.Value missing in Bytes Rcvd Bytes Sent Client IP address Connection analysis end Content type of message body Correlation begin time Correlation base component ID

Description
Blacklisted IP addresses for Endpoint2

Netmask for blacklisted Endpoint2 IP address (32 = host address)

Blacklisted Endpoint2 port (empty = all ports)

Blacklisted Endpoint2 port range. 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). IP protocol

Blacklist Response field for which value resolving failed. Number of bytes received during connection Number of bytes sent during connection. As it happens with the elapsed time, the bytes sent will be indicated just when accounting entries are created. Address of the client who triggered the event Application could not continue analyzing the traffic stream after this event Content type of the message body Ntp stamp of beginning of time frame Indicates the policy which decides the response after successful correlation

309

TABLE F.1 Fields of the Log Entry Table (Continued)

Field
Correlation end time Creation Time Destination port DNS class DNS hdr ancount DNS hdr arcount DNS hdr flag tc DNS hdr id DNS hdr is request DNS hdr nscount DNS hdr opcode DNS hdr dqcount DNS hdr rcode DNS name length DNS offset DNS pointer DNS qclass DNS qname DNS qtype DNS section DNS type DNS UDP payload DNS UDP payload by opt Dst Addr

Description
Ntp stamp of end of time frame Entry creation time TCP or UDP destination port in a packet header DNS resource record class DNS answers count DNS additional section count DNS header flag TC DNS message ID DNS message is a request DNS authority section count DNS operation code DNS questions count DNS return code Length of DNS name in a message DNS message offset where the situation occurs Name pointer in a DNS message Query resource record class in a DNS message First queried name in a DNS message Query type in a DNS message Section name in a DNS message DNS resource record type UDP payload size of a DNS message UDP payload advertised in a DNS OPT record Packet destination IP address

310

Appendix F: Log Field Values

TABLE F.1 Fields of the Log Entry Table (Continued)

Field
Dst Port Elapsed Time Element name Error id Eth frame length Eth min frame length Ethernet main type Ethernet type Event Event count Event ID Event type Event update Excerpt data Excerpt position Facility From address FTP account len FTP adat argument len FTP allocate size FTP arg len FTP auth arg len

Description
Packet destination protocol port Elapsed time of connection in seconds. It is only indicated when accounting entries are created, that is, when a connection is closed. Name of the element Identifier of the occurred error Length of the Ethernet frame Minimum length for Ethernet frame Ethernet frame main type (Ethernet 2, IPX, LLC, SNAP) Type field in Ethernet frame Logged event, e.g., New connection, Connection closed, Connection discarded Event count in the defined time frame Event identifier, unique within one sender Description of the event Event id for which this event is update Recording of the application level data stream of the attack Position in the attached short recording Firewall subsystem. For more information on facility values, see Table F.2 From address Length of the FTP account string Length of ADAT command argument Size of FTP allocate Length of FTP command argument Length of AUTH argument length

311

TABLE F.1 Fields of the Log Entry Table (Continued)

Field
FTP client state name FTP clnt arg len FTP cmd name FTP command FTP conf arg len FTP enc arg len FTP eprt arg len FTP estp arg len FTP help arg len FTP lang arg len FTP lprt arg len FTP marker len FTP mic arg len FTP opts arg len FTP password len FTP pathname len FTP protection buffer size FTP reply FTP reply code FTP reply len FTP reply line len FTP server action FTP server banner FTP server state name Detected FTP client state FTP CLNT argument length

Description

Name of the detected FTP command (no arguments) The name of the FTP command Length of CONF command argument Length of ENC command argument Length of EPRT command argument Length of ESTP command argument Length of HELP command argument Length of LANG command argument Length of LPRT command argument Length of REST command argument Length of MIC command argument Length of OPTS command argument Length of detected FTP password Length of detected FTP pathname Detected PBSZ protection buffer size Detected FTP server reply Detected FTP server reply code Length of an FTP server reply that is too long Length of an FTP server reply line that is too long Server action after a suspicious client command Detected FTP server banner Detected FTP server state

312

Appendix F: Log Field Values

TABLE F.1 Fields of the Log Entry Table (Continued)

Field
FTP site arg len FTP state name FTP username len HTTP header HTTP header name HTTP no request HTTP request line HTTP request message field name length HTTP request message field value length HTTP request method HTTP request URI HTTP request version HTTP requests not stored HTTP response code HTTP response message field name length HTTP response message field value length HTTP URI length

Description
Length of SITE command argument Detected FTP session state Length of detected FTP username Detected HTTP header field. Detected HTTP header field name Response could not be associated to any request HTTP request line Length of HTTP request header field name

Length of HTTP request header field value

Detected HTTP request method Detected HTTP request URI Detected HTTP request version Number of requests not stored due to HTTP pipeline overflow Detected HTTP response code

Length of HTTP response header field name

Length of HTTP response header field value Length of HTTP request URI

313

TABLE F.1 Fields of the Log Entry Table (Continued)

Field
ICMP code ICMP expected message length ICMP field addr entry size ICMP field address mask ICMP field code ICMP field domain name ICMP field gateway IP addr ICMP field lifetime ICMP field num addrs ICMP field originate timestamp ICMP field outbound hop count ICMP field output link mtu ICMP field output link speed ICMP field pointer ICMP field preference level ICMP field receive timestamp

Description
ICMP 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. Expected length of ICMP message Value of detected ICMP address entry size field Value of detected ICMP address mask field ICMP code field value Value of detected ICMP domain name field Value of detected ICMP gateway address field Value of ICMP lifetime field Value of ICMP number of addresses field Value of ICMP originate timestamp field

Value of ICMP outbound hop count field

Value of ICMP output link MTU field Value of ICMP output link speed field Offset where the situation occurred in the related datagram Value of ICMP preference level field Value of ICMP receive timestamp field

314

Appendix F: Log Field Values

TABLE F.1 Fields of the Log Entry Table (Continued)

Field
ICMP field return hop count ICMP field router addr ICMP field sequence num ICMP field traceroute id ICMP field transmit timestamp ICMP field type

Description
Value of ICMP return hop count field Value of ICMP router address field Value of ICMP sequence number field Value of ICMP traceroute ID field Value of ICMP transmit timestamp field Value of ICMP type field 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. Length of the ICMP message Destination IP address of the datagram related to the ICMP message Destination port of the datagram related to the ICMP message IP Protocol field of the datagram related to the ICMP message Source IP address of the datagram related to the ICMP message Source port of IP datagram related to ICMP message

ICMP ID

ICMP message length ICMP referenced destination IP addr ICMP referenced destination port ICMP referenced IP proto ICMP referenced source IP addr ICMP referenced source port

315

TABLE F.1 Fields of the Log Entry Table (Continued)

Field

Description
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 Encoded word token related to this event Contents (possibly partial) of the mail header field related to this event Name of the mail header field related to this event The number of characters processed in this header field when this event was generated Syntactical token in mail body related to this event Length of the syntactical token in mail body related to this event Incident case Informative message to further explain the entry Value of IP header checksum Length of an IP datagram IP datagram suggested new length Destination IP address in a packet header Conflicting byte range in a fragments

ICMP Type

IKE Cookie Imf encoded word Imf header field Imf header field name Imf header field position Imf token Imf token length Incident case Information message IP checksum IP datagram length IP datagram new length IP destination IP frag conflict range IP frag conflict range.IP frag different bytes IP frag conflict range.IP frag different bytes first

Total number of conflicting bytes

First conflicting byte in the IP fragment

316

Appendix F: Log Field Values

TABLE F.1 Fields of the Log Entry Table (Continued)

Field
IP frag conflict range.IP frag different bytes last IP frag conflict range.IP frag different new first IP frag conflict range.IP frag different new last IP frag conflict range.IP frag different old first IP frag conflict range.IP frag different old last IP fragment offset IP header length IP identification IP offset IP option length IP option number IP protocol

Description
Last conflicting byte in the IP fragment

Value of first conflicting byte in the latest fragment

Value of last conflicting byte in the latest fragment

Value of first conflicting byte in an earlier fragment.

Value of last conflicting byte in an earlier fragment. Fragment offset in an IP header Length of an IP header Identification field in an IP header Start offset of IP from the beginning of the ethernet frame Length of IP option that triggered the response IP option number that triggered the response IP protocol number in packet header 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. Source IP address in a packet header Total length of an IP datagram Version field value in an IP header Length of message body

IPsec SPI

IP source IP total length IP version Length of message body

317

TABLE F.1 Fields of the Log Entry Table (Continued)

Field
LLC DSAP LLC SSAP Logical interface MAC destination MAC source NAT Dst NAT Dst Port NAT Src NAT Src Port Node configuration Node dynup Node version Normalized Not final value One LAN Origin name Original Alert Type Original correlation begin time Original correlation end time Original event count Original severity Original situation Original time

Description
Logical Link Control Destination Service Access Point Logical Link Control Source Service Access Point Logical interface for a packet Destination MAC address in a packet header Source MAC address in a packet header Translated packet destination IP address Translated packet destination protocol port Translated packet source IP address Translated packet source protocol port Current configuration Uodate package level Node version URI normalization was used to find the match Entry is not final The “View interface as one LAN” option was enabled on the logical interface through which the packet was received. Name of the component that triggered the event Type of alert in the referred event Ntp stamp of the beginning of the time frame in the referred event Ntp stamp of the end of the time frame in the referred event Number of events in the time frame of the referred event Severity of the referred event Identifier of the situation that triggered the referred event Time of creating the referred event

318

Appendix F: Log Field Values

TABLE F.1 Fields of the Log Entry Table (Continued)

Field
Packet analysis end Packet not seen Physical interface Priority Protocol Protocol Agent QoS Class Reception time Record ID Reference event ID Reference event ID.Ref Comp Id Reference event ID.Ref Creation Time Reference event ID.Ref Event ID Result Round trip

Description
Module could not continue analyzing packet or datagram after this event Flag indicating that the related packet was not seen Physical interface for a packet The priority assigned to the traffic according to the QoS policy. Connection IP protocol Protocol Agent numerical code. The Quality of Service class assigned to the traffic according to the QoS policy. Time when the entry was received by the log server Identifier of the traffic recording Reference to a related event Sender identifier of the referred event

The creation time of the referred event

Identifier of the referred event Result state Round 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 tag value of acceptance rule. When you click the Rule Tag cell, a Rule definition dialog opens. It shows the name of the policy, subpolicy, or template that generated the log record. Number of ICMP Echo Request destinations with no reply Number of ICMP Echo Request destinations detected

Rule Tag Scan ICMP echo no reply cnt Scan ICMP echo request cnt

319

TABLE F.1 Fields of the Log Entry Table (Continued)

Field
Scan ICMP echo targets Scan ICMP mask no reply cnt Scan ICMP mask request cnt Scan ICMP mask targets Scan ICMP no reply cnt Scan ICMP request cnt Scan ICMP time no reply cnt Scan ICMP time request cnt Scan ICMP time targets Scan start time Scan TCP negative cnt Scan TCP no ack cnt Scan TCP no ack targets Scan TCP no reply cnt Scan TCP normal cnt Scan TCP positive cnt Scan TCP targets

Description
List of the detected ICMP Echo Request destinations Number of ICMP Netmask Request destinations with no reply Number of distinct ICMP Netmask Request destinations detected List of the detected ICMP Netmask Request destinations Number of ICMP Echo, Timestamp, and Netmask Request destinations with no reply Number of ICMP Echo, Timestamp, and Netmask Request destinations Number of ICMP Timestamp Request destinations with no reply Number of the distinct ICMP Timestamp Request destinations detected List of detected ICMP Timestamp Request destinations Detected starting time of this port scanning activity Number of TCP destinations that replied with TCP Reset Number of TCP destinations targeted for illegal TCP segments List of TCP destinations targeted for illegal TCP segments Number of TCP destinations with no reply to connection attempts Number of TCP destinations with handshake and two-directional data transfer Number of TCP destinations with handshake but no data sent by client List of the detected TCP port scan destinations

320

Appendix F: Log Field Values

TABLE F.1 Fields of the Log Entry Table (Continued)

Field
Scan UDP negative cnt Scan UDP positive cnt Scan UDP probe cnt Scan UDP target cnt Scan UDP targets Sender Sender module version Sender module version.Sender build Sender module version.Sender module major Sender module version.Sender module minor Sender module version.Sender module pl Sender type Severity SIP call ID SIP contact address SIP header field contents

Description
Number of destinations that replied with ICMP Port Unreachable Number of two-directional UDP conversations detected Number of destinations that did not reply using UDP Total number of UDP destinations detected List of the detected UDP destinations Firewall or server node IP address that passes this information Version of the module that generated the event.

Build number of the engine that generated the event.

Major version of the module that generated the event.

Minor version of the module that generated the event.

Patch version of the module that generated the event. Sender type Severity of a situation SIP call ID SIP contact address SIP header field contents

321

TABLE F.1 Fields of the Log Entry Table (Continued)

Field
SIP header field name SIP request method SIP request URI SIP request version SIP response reason-phrase SIP response status code SIP VIA address Situation SMTP command SMTP misplaced command SMTP recipient SMTP reply SMTP reverse path SMTP server action SMTP server banner SMTP transaction state SNAP Organization Code Source file Source file line Source port Src Addr SIP header field name method of a SIP request URI of a SIP request version of a SIP request SIP response reason-phrase

Description

status code of a SIP response SIP VIA address The identifier of the situation that caused this event to be sent Suspicious SMTP command sent by the client Command given in wrong place in the command sequence Recipient forward path in RCPT command parameter Suspicious SMTP reply message sent by the server SMTP reverse path in MAIL FROM command parameter Suspicious server action after a suspicious client command Banner sent by the SMTP server in the beginning of a connection Session state of the SMTP transaction Subnetwork Access Protocol Organization Code Name of the source file Line number in the source file TCP or UDP source port in a packet header Packet source IP address

322

Appendix F: Log Field Values

TABLE F.1 Fields of the Log Entry Table (Continued)

Field
Src IF Src Port Src VLAN SSH calc client crypto bit ratio SSH calc server crypto bit ratio SSH1 host key bits SSH1 server key bits State

Description
Defined source interface number for the firewall cluster Packet source protocol port Source VLAN ID number (up to 4095) Calculated SSH client crypto bit ratio Calculated SSH server crypto bit ratio Bit length of the SSHv1 host key Bit length of the SSHv1 server key Connection state in connection monitoring 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. IPv4 address of the target host Start time of the TCP connection Initial handshake of the TCP connection detected Type of the TCP option Length of the TCP option that caused the response To address Log entry severity type. For more information on type values, see Table F.3 Size of the UDP datagram User and Group Information Username

Syslog

Target IP TCP connection start time TCP handshake seen TCP option kind TCP option length To address Type UDP datagram size User and Group Information Username

323

TABLE F.1 Fields of the Log Entry Table (Continued)

Field
Whole session seen

Description
True, if no data of this session has been missed up to this point

324

Appendix F: Log Field Values

Facility Field Values
The 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

TABLE F.2 Facility Field Values (Continued)

Value
State Synchronization Syslog System Tester Undefined User Defined

326

Appendix F: Log Field Values

T y pe F i el d V a l u e s
The 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 Occurrences
The following table show the most common log occurrences for the Action and Event fields.
TABLE F.4 Action and Event Occurrences

Action
Allow Allow

Event
New connection Related Connection

Description
A new connection is allowed through the engine. A related connection is allowed through the engine. For example, an FTP data connection. A related packet is allowed through the engine. For instance, ICMP error messages related to an earlier TCP connection. A new VPN connection is allowed through the firewall. A connection is discarded by the engine. A packet is discarded by the engine. A connection is refused by the engine. A connection is terminated by the engine. Indicates engine startup. Indicates that engine went offline. New configuration is installed on the engine. New security policy is loaded on the engine.

Allow

Related Packet

Allow Discard Discard Refused Terminate

New VPN connection Connection Discarded Packet Discarded Connection Refused Connection Terminated Went Online Went Offline New configuration successfully installed Security Policy reload

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

328

Appendix F: Log Field Values

VPN-Related Information Messages
The 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
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). 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. A negotiated SA could not be stored in memory. May indicate that the memory has run out. There 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. The authentication method used by the other gateway is not allowed in the configuration of this gateway. Check your VPN Profile. May indicate that the gateway has no valid VPN certificate. 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 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. Traffic going through the VPN tunnel. When you enable IPsec diagnostics you may see more of these messages.

[...] No proposal chosen

[...] Payload malformed [...]

[...] SA install failed

[...] traffic selector mismatch

Authentication method mismatch Can not get policy [...] No matching connection

Can not get QM policy [...]

Dead peer detection failed IKE peer was found dead [...]

ESP [...] AH [...]

329

TABLE F.5 Common VPN-related Log Messages (Continued)

Information/Error Message

Description
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 denialof-service attacks. 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 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. Various reasons. See the other log entries for more information. Activate IPsec diagnostics to see more verbose logs. Various reasons. See the other log entries for more information. Activate IPsec diagnostics to see more verbose logs. 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. 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. There 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.

IKE negotiation rate-limit reached, discard connection

IKE Phase-1 initiator done IKE Phase-1 responder done

IKE Phase-2 initiator done IKE Phase-2 responder done

Invalid argument

Invalid syntax

NAT-T is not allowed for this peer

No IKE SA found [...]

Proposal did not match policy

330

Appendix F: Log Field Values

TABLE F.5 Common VPN-related Log Messages (Continued)

Information/Error Message

Description
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. 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. 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. 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. 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. 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. Usually appears because a VPN client tried to connect, but VPN client access is not configured (correctly) on the gateway.

Remote address not allowed

Remote ID mismatch

Remote identity [...] used in IKE negotiation doesn’t match to policy [...]

SPD doesn’t allow connection [...]

Tunnel policy mismatch [...]

Tunnel selection failed

Tunnel type mismatch

331

TABLE F.5 Common VPN-related Log Messages (Continued)

Information/Error Message

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

Unknown IKE cookie

332

Appendix F: Log Field Values

Audit Entry Types
The following table explains the audit entry types.
TABLE F.6 Audit Entry Types

Type
audit.info audit.start audit.stop stonegate.admin.changeIp.mgtserver stonegate.admin.changeMgtIp.logserver stonegate.admin.comment.change stonegate.admin.create stonegate.admin.delete stonegate.admin.login stonegate.admin.logout stonegate.admin.name.change stonegate.admin.password.change stonegate.admin.permission.change stonegate.admin.session stonegate.alert stonegate.alert.policy.upload stonegate.audit.archive.create stonegate.audit.archive.delete stonegate.audit.archive.restore stonegate.audit.purge

Definition
Internal messages of the audit system Start of an audit End of an audit Audited when management server IP address is changed Audited when log server management IP address is changed Audited when a comment is changed Creation of an administrator Deletion of an administrator Audited when the administrator logs in to the management server Audited when the administrator logs out from the management server Change of administrator name Change of password for an administrator Change of permissions for an administrator Audits administrator sessions Audited when management system sends an alert Uploading a policy to an alert server - success or failure Audited when audit data archive is created Audited when audit data archive is deleted Audited when audit data archive is restored Audited when audit data is purged

333

TABLE F.6 Audit Entry Types (Continued)

Type
stonegate.backup.create stonegate.backup.delete stonegate.backup.restore stonegate.database.migrate stonegate.database.password.change stonegate.directarchive.start stonegate.directarchive.stop stonegate.export.start stonegate.firewall.connections.terminate stonegate.firewall.diagnostic stonegate.firewall.disable.userdatabase stonegate.firewall.enable.userdatabase stonegate.firewall.initial.contact stonegate.firewall.initial.generate stonegate.firewall.monitor.off stonegate.firewall.monitor.on stonegate.firewall.policy.upload stonegate.firewall.reboot stonegate.firewall.reset.database

Definition
Audited when a backup is created in the origin server Audited when a backup is deleted in the origin server Audited when a backup is restored in the origin server Audited when the server database is migrated Audited when database password is changed Audited when the direct archive option is set to ON Audited when the direct archive option is set to OFF Audited when an export operation is started Audited when a connection is terminated Diagnostic mode selected for a firewall Audited when user database is disabled Audited when user database is enabled Firewall performed initial contact to management server Initial configuration generated for a firewall A firewall monitoring change by an administrator to deactivated A firewall monitoring change by an administrator to activated Uploading a policy to a single firewall - success or failure A firewall reboot by an administrator through the management system Audited when the user database is reset

334

Appendix F: Log Field Values

TABLE F.6 Audit Entry Types (Continued)

Type
stonegate.firewall.state.lockoffline stonegate.firewall.state.lockonline stonegate.firewall.state.offline stonegate.firewall.state.online stonegate.firewall.state.standby stonegate.firewall.time.adjust stonegate.firewall.upgrade.end stonegate.firewall.upgrade.start stonegate.import.start stonegate.ips.analyzer.diagnostic stonegate.ips.analyzer.monitor.off stonegate.ips.analyzer.monitor.on stonegate.ips.analyzer.policy.upload stonegate.ips.analyzer.reboot stonegate.ips.analyzer.state.lockoffline stonegate.ips.analyzer.state.lockonline stonegate.ips.analyzer.state.offline stonegate.ips.analyzer.state.online stonegate.ips.analyzer.state.standby stonegate.ips.analyzer.time.adjust

Definition
A firewall state change by an administrator to locked offline A firewall state change by an administrator to locked online A firewall state change by an administrator to offline A firewall state change by an administrator to online A firewall state change by an administrator to standby Firewall node time adjustment Firewall node upgrade end through management system Firewall node upgrade start through management system Audited when an import operation is started Diagnostic mode selected for an analyzer Monitoring mode offline for a sensor Monitoring mode online for a sensor Uploading a policy to an analyzer - single analyzer cluster success or failure Analyzer reboot through the management system Analyzer state changed to locked offline Analyzer state changed to locked online Analyzer state changed to offline Analyzer state changed to online Sensor state changed to standby Analyzer node time adjusted

335

TABLE F.6 Audit Entry Types (Continued)

Type
stonegate.ips.analyzer.upgrade.end stonegate.ips.analyzer.upgrade.start stonegate.ips.sensor.diagnostic stonegate.ips.sensor.monitor.off stonegate.ips.sensor.monitor.on stonegate.ips.sensor.policy.upload stonegate.ips.sensor.reboot stonegate.ips.sensor.state.lockoffline stonegate.ips.sensor.state.lockonline stonegate.ips.sensor.state.offline stonegate.ips.sensor.state.online stonegate.ips.sensor.state.standby stonegate.ips.sensor.time.adjust stonegate.ips.sensor.upgrade.end stonegate.ips.sensor.upgrade.start stonegate.license.activate stonegate.license.delete stonegate.license.import stonegate.license.inactivate stonegate.logdatamanager.abort

Definition
Analyzer node upgrade through management system ends Analyzer node upgrade through management system begins Diagnostic mode selected for a sensor Monitoring mode offline for a sensor Monitoring mode online for a sensor Uploading a policy to a sensor - single sensor success or failure Sensor rebooted through the management system Sensor state changed to locked offline Sensor state changed to locked online Sensor state changed to offline Sensor state change by an administrator to online Sensor state changed to standby Sensor node time adjusted Sensor node upgrade through management system ends Sensor node upgrade through management system begins Audited when a license file or a license component is activated Audited when a license component is deleted Audited when a license file is imported Audited when a license is deactivated Audited when a scheduled task is aborted in the log server

336

Appendix F: Log Field Values

TABLE F.6 Audit Entry Types (Continued)

Type
stonegate.logdatamanager.complete stonegate.logdatamanager.create stonegate.logdatamanager.delete stonegate.logdatamanager.modify stonegate.logdatamanager.start stonegate.logpruningfilter.apply stonegate.logpruningfilter.delete

Definition
Audited when a scheduled task is completed in the log server Audited when a scheduled task is created in the log server Audited when a scheduled task is deleted in the log server Audited when a scheduled task is modified in the log server Audited when the user manually starts a task Audited when a pruning filter is applied to the log server Audited when a pruning filter is deleted from the log server Audited when, following to a log server relogging to the management, all the pruning filters are retrieved at the management and reapplied Log reception process begins Log reception process ends Audited when the log server is certified Audited when the management server is certified Audited when an object is deleted Audited when a new object is added Audited when an object is updated Generate a policy for display Uploading a policy ends Uploading a policy starts Audited when the log server disk gets full Audited when the log server is started

stonegate.logpruningfilter.refresh

stonegate.logreception.start stonegate.logreception.stop stonegate.logserver.certify stonegate.mgtserver.certify stonegate.object.delete stonegate.object.insert stonegate.object.update stonegate.policy.display stonegate.policy.upload.end stonegate.policy.upload.start stonegate.server.diskfull stonegate.server.start

337

TABLE F.6 Audit Entry Types (Continued)

Type
stonegate.server.stop stonegate.vpn.certificate.download stonegate.vpn.certificate.request stonegate.vpn.certificate.sign stonegate.vpn.gateway.remove stonegate.vpn.site.remove stonegate.vpn.validity.check

Definition
Audited when the log server is stopped Audited when client downloaded a VPN certificate Audited when a VPN certificate is requested Audited when a VPN certificate is signed Audited when a VPN gateway is removed Audited when a VPN site is removed Audited when the VPN validity is checked

338

Appendix F: Log Field Values

Syslog Entries
The 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 Controlled 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

340

Appendix F: Log Field Values

Connection States
The 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
CP established ICMP echo ICMP reply wait Invalid IPsec established New Related Remove

Description
StoneGate cluster protocol packet is recognized. Ping reply is expected. Other ICMP request/reply types. The communication has violated the protocol. IPsec tunnel packet is recognized. New connection is being opened. New connection related to an existing one is expected soon. Connection cannot be physically removed yet. 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. One end of the connection waits for the FIN packet (passive close). Waiting ACK for the FIN before going to close wait status (passive close). Closing packet (FIN) sent by one end of the connection (simultaneous). Waiting ACK for the FIN before going to closing status (active close). Normal status of TCP connections for data transfer. One end of the connection waits for sending the FIN packet (active close). One end of the connection waits for receiving ACK packet.

Remove soon

TCP close wait TCP close wait ack TCP closing TCP closing ack TCP established TCP fin wait 1 TCP fin wait 2

341

TABLE F.9 Connection States (Continued)

State
TCP last ack TCP last ack wait TCP syn ack seen TCP syn fin seen TCP syn return TCP syn seen TCP time wait TCP time wait ack UDP established Unknown established

Description
One end of the connection sent a FIN packet (passive close). Waiting for the FIN packet to be acknowledged. Second phase of the TCP three-way handshake, the server has replied to client sent SYN with SYN+ACK, next status will be established. T/TCP (Transactional TCP) connection, RFC 1644. Received simultaneous SYN from the other end (simultaneous open). Very first packet sent by one end of the connection. One end of the connection acknowledged closing packet (FIN). Waiting ACK for the FIN status before going to time wait status (active close). UDP connection is recognized. Connection from other transport level protocol.

342

Appendix F: Log Field Values

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
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. Directory used for archiving audit logs. By default, ${SG_ROOT_DIR}/data/audit/ archive.

ARCHIVE_DIR_0

AUDIT_ARCHIVE_DIR

343

TABLE G.1 Log Server Configuration Parameters in LogServerConfiguration.txt file (Continued)

Parameter name

Description
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. Directory used for audit logs. By default, ${SG_ROOT_DIR}/data/audit/log. 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. 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). Root directory for the Alerts. By default, ${FILESTORAGE_DIR}/Alerts. Root directory for the Alert event traces. By default, ${FILESTORAGE_DIR}/AlertEvent. Root directory for the IPS logs. By default, ${FILESTORAGE_DIR}/IPS. Root directory for the StoneGate IPS event recording files. By default, ${FILESTORAGE_DIR}/IPS_Recordings. Root directory for the firewall logs. By default, ${FILESTORAGE_DIR}/Firewall. SNMP community string used for sending SNMP messages from the Log Server (public by default). SNMP Enterprise Object Identifier (OID) used for SNMP messages sent from the Log Server (.1.3.6.1.4.1.1369 by default).

AUDIT_DISK_LIMIT

AUDIT_LOG_DIR

AUTO_ACK_ALERT_NB

DISK_TRESHOLD_IN_KBYTES

FILESTORAGE_ALERT_DIR FILESTORAGE_ALERT_EVENT_TRACES_DIR FILESTORAGE_IPS_DIR

FILESTORAGE_IPS_RECORDINGS_DIR

FILESTORAGE_STONEGATE_DIR

SNMP_COMMUNITY

SNMP_ENTERPRISE_OID

344

Appendix G: Advanced Log Server Configuration

TABLE G.1 Log Server Configuration Parameters in LogServerConfiguration.txt file (Continued)

Parameter name

Description
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. Directory used for storing the files exported by the Log Data tasks. By default, ${SG_ROOT_DIR}/data/export. 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. Directory used for storing the logfile.txt that logs the task scheduler operations. By default, ${SG_ROOT_DIR}/data. Timeout (in milliseconds) for queries in the Logs view (30000 ms by default). Directory for the scripts used in Log Data tasks. By default, ${SG_ROOT_DIR}/data/ script. IP address of the Log Server. Changing this value requires reinstalling the Log Server software. Maximum number of active alerts. If there are more alerts, they are automatically acknowledged (50000 by default). IP address of the Management Server. Use the sgChangeMgtIPOnLogSrv.bat (or .sh) to change this value. The script used for starting the Log Server database. By default, bin\\sgStartLogDatabase.bat or bin/ sgStartLogDatabase.sh. Log Server database location. By default, ${SG_ROOT_DIR}/data/db/logserver.

LOG_BACKUP_DIR

LOG_EXPORT_DIR

LOG_FW_PORT

LOG_LOGFILE_DIR

LOG_QUERY_TIMEOUT

LOG_SCRIPT_DIR

LOG_SERVER_ADD

MAX_ACTIVE_ALERT_NB

MGT_SERVER_ADD

PHY_EXE

PHY_LOC

345

TABLE G.1 Log Server Configuration Parameters in LogServerConfiguration.txt file (Continued)

Parameter name
PHY_PORT

Description
Log Server database port that the Log Server connects to (1314 by default). 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. Defines the file format used for syslog exporting. Either CSV or XML. Defines whether to export StoneGate Alerts to syslog. Either YES or NO. Defines whether to export StoneGate Firewall/VPN logs to syslog. Either YES or NO. Defines whether to export StoneGate IPS logs to syslog. Either YES or NO. 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. 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. The priority (0–191) of the syslog message is included at the beginning of each UDP packet (the default is 6). See RFC 3164.

SYSLOG_CONF_FILE

SYSLOG_EXPORT_FORMAT SYSLOG_EXPORT_ALERT

SYSLOG_EXPORT_FW

SYSLOG_EXPORT_IPS

SYSLOG_FILTER_MATCH

SYSLOG_FILTER_TYPE

SYSLOG_MESSAGE_PRIORITY

346

Appendix G: Advanced Log Server Configuration

TABLE G.1 Log Server Configuration Parameters in LogServerConfiguration.txt file (Continued)

Parameter name
SYSLOG_PORT SYSLOG_SERVER_ADDRESS

Description
Port for syslog connections. The default port is 514 (UDP). The IP address of the syslog server used for sending log events to syslog. 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.

SYSLOG_USE_DELIMITER

347

348

Appendix G: Advanced Log Server Configuration

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.
TABLE H.1 SNMP Traps for StoneGate IPS

Trap name
ipsPolicyInstall nodeBoot nodeHwmon nodeOffline nodeOnline nodeShutdown nodeTestFailure nodeUserLogin

Objects Included
ipsSecurityPolicy nodeHwmonEvent nodeOperState nodeOperState nodeTestIdentity nodeLastLogin

Description
Policy was installed on the IPS engine. Node bootup complete. Hardware monitoring system has detected problems. Node changed to offline or standby state. Node changed to online state. Node is shutting down. Test subsystem reported a test failure on the node. Login initiated on the node’s console or through SSH.

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

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
ipsPolicyTime ipsSecurityPolicy ipsSoftwareVersion

Object Description in MIB
The time when the security policy was installed to the IPS engine Name of the current security policy on the IPS engine Version string of the IPS software

TABLE H.3 STONESOFT-NETNODE-MIB Objects

Object Name
nodeClusterId nodeCPULoad nodeHwmonEvent nodeLastLogin nodeLastLoginTime nodeMemberId nodeOperState nodeTestIdentity nodeTestResult nodeTestResultTime

Object Description in MIB
The identification number of the cluster this node belongs to The CPU load percentage on the node Reason for the hardware monitoring event The most recent login event on the node Timestamp of the most recent login event on the node Node's member identification within the cluster The operative (clustering) state of the node Identification string of a nodeTest The most recent result of the nodeTest The timestamp of the most recent result of the nodeTest

350

Appendix H: SNMP Traps and MIBs

TABLE H.4 IF-MIB Supported Objects

Object Name

Object Description in MIB
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). 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. A 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. 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. 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 managementsystemtothenextre-initialization. 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.

ifAdminStatus

ifAlias

ifDescr

ifHighSpeed

ifIndex

ifInDiscards

351

TABLE H.4 IF-MIB Supported Objects (Continued)

Object Name

Object Description in MIB
For packet-oriented interfaces, the number of inbound packets that contained errors preventing them from being deliverable to a higher-layer protocol. For characteroriented 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. 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 asindicatedbythevalueofifCounterDiscontinuityTime. 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. 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, andatothertimesasindicatedbythevalueofifCounterDiscontinuityTime. The 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. 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. The 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.

ifInErrors

ifInMulticastPkts

ifInOctets

ifInUcastPkts

ifLastChange

ifLinkUpDownTrapEnable

ifMtu

352

Appendix H: SNMP Traps and MIBs

TABLE H.4 IF-MIB Supported Objects (Continued)

Object Name

Object Description in MIB
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. The number of network interfaces (regardless of their current state) present on this system. 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)stateiftheinterfacehasmissing(typically,hardware)components. 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 othertimesasindicatedbythevalueofifCounterDiscontinuityTime. 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. 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.

ifName

ifNumber

ifOperStatus

ifOutDiscards

ifOutErrors

ifOutOctets

353

TABLE H.4 IF-MIB Supported Objects (Continued)

Object Name

Object Description in MIB
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 asindicatedbythevalueofifCounterDiscontinuityTime. 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. 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. 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. The 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.

ifOutUcastPkts

ifPhysAddress

ifPromiscuousMode

ifSpeed

ifType

TABLE H.5 IP-MIB Supported Objects

Object Name
icmpInAddrMaskReps icmpInAddrMasks icmpInDestUnreachs icmpInEchoReps icmpInEchos

Object Description in MIB
The number of ICMP Address Mask Reply messages received. The number of ICMP Address Mask Request messages received. The number of ICMP Destination Unreachable messages received. The number of ICMP Echo Reply messages received. The number of ICMP Echo (request) messages received.

354

Appendix H: SNMP Traps and MIBs

TABLE H.5 IP-MIB Supported Objects (Continued)

Object Name
icmpInErrors icmpInMsgs icmpInParmProbs icmpInRedirects icmpInSrcQuenchs icmpInTimeExcds icmpInTimestampReps icmpInTimestamps icmpOutAddrMaskReps icmpOutAddrMasks icmpOutDestUnreachs icmpOutEchoReps icmpOutEchos

Object Description in MIB
The number of ICMP messages which the entity received but determined as having ICMP-specific errors (bad ICMP checksums, bad length, etc.). The total number of ICMP messages which the entity received. Note that this counter includes all those counted by icmpInErrors. The number of ICMP Parameter Problem messages received. The number of ICMP Redirect messages received. The number of ICMP Source Quench messages received. The number of ICMP Time Exceeded messages received. The number of ICMP Timestamp Reply messages received. The number of ICMP Timestamp (request) messages received. The number of ICMP Address Mask Reply messages sent. The number of ICMP Address Mask Request messages sent. The number of ICMP Destination Unreachable messages sent. The number of ICMP Echo Reply messages sent. The number of ICMP Echo (request) messages sent. 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 whichcontributetothiscounter's value. The total number of ICMP messages which this entity attempted to send. Note that this counter includes all those counted by icmpOutErrors. The number of ICMP Parameter Problem messages sent. The number of ICMP Redirect messages sent. For a host, this object will always be zero, since hosts do not send redirects. The number of ICMP Source Quench messages sent. The number of ICMP Time Exceeded messages sent. The number of ICMP Timestamp Reply messages sent. The number of ICMP Timestamp (request) messages sent.

icmpOutErrors

icmpOutMsgs icmpOutParmProbs icmpOutRedirects icmpOutSrcQuenchs icmpOutTimeExcds icmpOutTimestampReps icmpOutTimestamps

355

TABLE H.5 IP-MIB Supported Objects (Continued)

Object Name
ipAdEntAddr

Object Description in MIB
The IP address to which this entry's addressing information pertains. 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 addressesusedbytheentityonthis(logical)interface. The 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. The 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. The size of the largest IP datagram which this entity can re-assemble from incoming IP fragmented datagrams received on this interface. The 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. The 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). 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, andtheSource-Routeoptionprocessingwassuccessful. The number of IP datagram fragments that have been generated as a result of fragmentation at this entity. The 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. The number of IP datagrams that have been successfully fragmented at this entity.

ipAdEntBcastAddr

ipAdEntIfIndex

ipAdEntNetMask

ipAdEntReasmMaxSize

ipDefaultTTL

ipForwarding

ipForwDatagrams

ipFragCreates

ipFragFails ipFragOKs

356

Appendix H: SNMP Traps and MIBs

TABLE H.5 IP-MIB Supported Objects (Continued)

Object Name

Object Description in MIB
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 becausethedestinationaddresswasnotalocaladdress. The total number of input datagrams successfully delivered to IP user-protocols (including ICMP). 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. The number of input datagrams discarded due to errors in their IP headers, including bad checksums, version number mismatch, other format errors, time-tolive exceeded, errors discovered in processing their IP options, etc. The total number of input datagrams received from interfaces, including those received in error. The number of locally-addressed datagrams received successfully but discarded because of an unknown or unsupported protocol. The 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. The IpAddress corresponding to the media-dependent `physical' address. The media-dependent `physical' address. 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 requiresexaminationoftherelevantipNetToMediaTypeobject. 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 ipForwDatagramsifanysuchpacketsmetthis(discretionary)discardcriterion.

ipInAddrErrors

ipInDelivers

ipInDiscards

ipInHdrErrors

ipInReceives ipInUnknownProtos

ipNetToMediaIfIndex ipNetToMediaNetAddress ipNetToMediaPhysAddress

ipNetToMediaType

ipOutDiscards

357

TABLE H.5 IP-MIB Supported Objects (Continued)

Object Name

Object Description in MIB
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. The 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. 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. The number of IP datagrams successfully re-assembled. The number of IP fragments received which needed to be reassembled at this entity. The maximum number of seconds which received fragments are held while they are awaiting reassembly at this entity.

ipOutNoRoutes

ipOutRequests

ipReasmFails

ipReasmOKs ipReasmReqds ipReasmTimeout

TABLE H.6 SNMP-USER-BASED-SM-MIB Objects

Object Name
usmStatsDecryptionErrors

Object Description in MIB
The total number of packets received by the SNMP engine which were dropped because they could not be decrypted. The total number of packets received by the SNMP engine which were dropped because they appeared outside of the authoritative SNMP engine's window. The 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. The 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. The 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.

usmStatsNotInTimeWindows

usmStatsUnknownEngineIDs

usmStatsUnknownUserNames

usmStatsUnsupportedSecLevels

358

Appendix H: SNMP Traps and MIBs

TABLE H.6 SNMP-USER-BASED-SM-MIB Objects (Continued)

Object Name
usmStatsWrongDigests

Object Description in MIB
The total number of packets received by the SNMP engine which were dropped because they didn't contain the expected digest value. An advisory lock used to allow several cooperating Command Generator Applications to coordinate their use of facilities to alter secrets in the usmUserTable. 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.

usmUserSpinLock

usmUserStatus

TABLE H.7 SNMPv2-MIB Supported Objects

Object Name

Object Description in MIB
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 reinitializationsofthenetworkmanagementsystem. The total number of ASN.1 or BER errors encountered by the SNMP entity when decoding received SNMP messages. The total number of SNMP messages delivered to the SNMP entity which used a SNMP community name not known to said entity. The 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. The total number of SNMP messages which were delivered to the SNMP entity and were for an unsupported SNMP version.

snmpEnableAuthenTraps

snmpInASNParseErrs snmpInBadCommunityNames

snmpInBadCommunityUses

snmpInBadVersions

359

TABLE H.7 SNMPv2-MIB Supported Objects (Continued)

Object Name
snmpInPkts

Object Description in MIB
The total number of messages delivered to the SNMP entity from the transport service. 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 thanatime-out)suchthatnoResponse-PDUcouldbereturned. 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. 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 associatedwiththeoriginatoroftherequest. The 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. A textual description of the entity. This value must include the full name and version identification of the system's hardware type, software operatingsystem, and networking software. The physical location of this node (e.g., `telephone closet, 3rd floor'). If the location is unknown, the value is the zero-length string. An 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. 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 assigntheidentifier1.3.6.1.4.1.4242.1.1toits`FredRouter'.

snmpProxyDrops

snmpSetSerialNo

snmpSilentDrops

sysContact

sysDescr

sysLocation

sysName

sysObjectID

360

Appendix H: SNMP Traps and MIBs

TABLE H.7 SNMPv2-MIB Supported Objects (Continued)

Object Name

Object Description in MIB
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-toend (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. The time (in hundredths of a second) since the network management portion of the system was last re-initialized.

sysServices

sysUpTime

361

362

Appendix H: SNMP Traps and MIBs

APPENDIX I

TCP/IP Protocol Headers

This appendix is a brief overview of the common TCP/IP protocol headers. The following sections are included: 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/.
TABLE I.1 IP Datagram

bits 0 - 7
Version (4 bits) IP Header Length (4 bits)

bits 8 - 15
Type of Service (8 bits)

bits 16 - 23

bits 24 - 31

Total Length (in number of bytes) (16 bits) Flags (3 bits) Fragment Offset (13 bits) Header Checksum (16 bits)

IP Identification Number (16 bits) Time to Live (8 bits) Protocol Number (8 bits)

Source IP Address (32 bits) Destination IP Address (32 bits) Options (if any) + Padding (matching to 32-bit boundary) ( data . . . )

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.2 ICMP Message

bits 0 - 7
Type (8 bits)

bits 8 - 15
Code (8 bits) ( data . . . )

bits 16 - 23
Checksum (16 bits)

bits 24 - 31

364

Appendix I: TCP/IP Protocol Headers

Transmission Control Protocol (TCP)
For the Transmission Control Protocol (TCP) specification, please refer to RFC793 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) Sequence Number (32 bits)

Destination Port Number (16 bits)

Acknowledgement Number (32 bits) TCP Header Length (4 bits) reserved (6 bits) Checksum (16 bits) U A P R S F R C S S Y I G K H T N N Window Size (16 bits) Urgent Pointer (16 bits)

Options (if any) + Padding (matching to 32-bit boundary) ( data . . . )

User Datagram Protocol (UDP)
For the User Datagram Protocol (UDP) specification, please refer to RFC768 available at http://www.rfc-editor.org/.
TABLE I.4 UDP Datagram

bits 0 - 7

bits 8 - 15

bits 16 - 23

bits 24 - 31

Source Port Number (16 bits) User Datagram Length (16 bits) ( data . . . )

Destination Port Number (16 bits) Checksum (16 bits)

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. The following sections are included: ASCII Character Codes, on page 368 ASCII Control Codes, on page 370

367

TABLE J.1 ASCII Character Codes

ASCII
NUL SOH STX ETX EOT ENQ ACK BEL BS HT LF VT FF CR SO SI DLE DC1 DC2 DC3 DC4 NAK SYN ETB CAN

Dec
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

Hex
0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0A 0x0B 0x0C 0x0D 0x0E 0x0F 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18

ASCII
SPACE ! " # $ % & ' ( ) * + , . / 0 1 2 3 4 5 6 7 8

Dec
32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56

Hex
0x20 0x21 0x22 0x23 0x24 0x25 0x26 0x27 0x28 0x29 0x2A 0x2B 0x2C 0x2D 0x2E 0x2F 0x30 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38

ASCII
@ A B C D E F G H I J K L M N O P Q R S T U V W X

Dec
64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88

Hex
0x40 0x41 0x42 0x43 0x44 0x45 0x46 0x47 0x48 0x49 0x4A 0x4B 0x4C 0x4D 0x4E 0x4F 0x50 0x51 0x52 0x53 0x54 0x55 0x56 0x57 0x58

ASCII
` a b c d e f g h i j k l m n o p q r s t u v w x

Dec
96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120

Hex
0x60 0x61 0x62 0x63 0x64 0x65 0x66 0x67 0x68 0x69 0x6A 0x6B 0x6C 0x6D 0x6E 0x6F 0x70 0x71 0x72 0x73 0x74 0x75 0x76 0x77 0x78

368

Appendix J: ASCII Character Codes

TABLE J.1 ASCII Character Codes (Continued)

ASCII
EM SUB ESC FS GS RS US

Dec
25 26 27 28 29 30 31

Hex
0x19 0x1A 0x1B 0x1C 0x1D 0x1E 0x1F

ASCII
9 : ; < = > ?

Dec
57 58 59 60 61 62 63

Hex
0x39 0x3A 0x3B 0x3C 0x3D 0x3E 0x3F

ASCII
Y Z [ \ ] ^ _

Dec
89 90 91 92 93 94 95

Hex
0x59 0x5A 0x5B 0x5C 0x5D 0x5E 0x5F

ASCII
y z { | } ~ DELETE

Dec
121 122 123 124 125 126 127

Hex
0x79 0x7A 0x7B 0x7C 0x7D 0x7E 0x7F

369

TABLE J.2 ASCII Control Codes

ASCII
NUL SOH STX ETX EOT ENQ ACK BEL BS HT LF VT FF CR SO SI DLE DC1 DC2 DC3 DC4 NAK SYN ETB CAN

Dec
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

Hex
0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0A 0x0B 0x0C 0x0D 0x0E 0x0F 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18 Null

Description

Start of Heading Start of Text End of Text End of Transmission Enquiry Acknowledge Bell Backspace Horizontal Tabulation Line Feed Vertical Tabulation Form Feed Carrier Return Shift Out Shift In Data Line Escape Device Control 1 Device Control 2 Device Control 3 Device Control 4 Negative Acknowledge Synchronous Idle End of Transmission Block Cancel

370

Appendix J: ASCII Character Codes

TABLE J.2 ASCII Control Codes (Continued)

ASCII
EM SUB ESC FS GS RS US

Dec
25 26 27 28 29 30 31

Hex
0x19 0x1A 0x1B 0x1C 0x1D 0x1E 0x1F

Description
End of Medium Substitute Escape File Separator Group Separator Record Separator Unit Separator

371

372

Appendix J: ASCII Character Codes

Legal Information

Licenses
Stonesoft 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 Restrictions
The 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

Patent Notice
Multi-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 Agreement
The 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 Information
The 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 License Version 2, June 1991 Copyright (C) 1989, 1991 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Preamble The 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 LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 1. 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 WARRANTY 11. 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 CONDITIONS How to Apply These Terms to Your New Programs If 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.

376

Legal Information

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 USA Also 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 author Gnomovision 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 mouseclicks 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 Vice This 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 LICENSE Version 2.1, February 1999 Copyright (C) 1991, 1999 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone 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.] Preamble The 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.

Software Licensing Information

377

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 nonfree 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 LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. 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.

378

Legal Information

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 machinereadable 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 work under 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

Software Licensing Information

379

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

380

Legal Information

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 WARRANTY 15. 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 CONDITIONS How to Apply These Terms to Your New Libraries If 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 USA Also 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 1990 Ty Coon, President of Vice That's all there is to it! OpenSSL Toolkit This 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 openssl-core@openssl.org. OpenSSL 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.

Software Licensing Information

381

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 openssl-core@openssl.org. Products 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, (eay@cryptsoft.com). This product includes software written by Tim Hudson (tjh@cryptsoft.com). Original SSLeay License ----------------------Copyright (C) 1995-1998 Eric Young (eay@cryptsoft.com). All rights reserved. This package is an SSL implementation written by Eric Young (eay@cryptsoft.com). 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 (tjh@cryptsoft.com). 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 (eay@cryptsoft.com)” 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 (tjh@cryptsoft.com)” 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.] OpenLDAP This 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 2001 Redistribution 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,

382

Legal Information

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, and 3. 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. libradius1 This software includes the libradius1 package. Copyright (C) 1995,1996,1997,1998 Lars Fenneberg <lf@elemental.net> 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 94566 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 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 MessageDigest 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.

Software Licensing Information

383

TACACS+ Client This 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 algorithm 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 MessageDigest 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. libwww This 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 LICENSE http://www.w3.org/Consortium/Legal/2002/copyright-software-20021231 This 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

384

Legal Information

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 site-policy@w3.org. Joseph Reagle <site-policy@w3.org> 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 License This 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 ``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. Expat License This software contains software covered by the Expat License. Copyright (c) 1998, 1999, 2000 Thai Open Source Software Center Ltd 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. ABYSS Web Server License This software contains software covered by the ABYSS Web Server License Copyright (C) 2000 by Moez Mahfoudh <mmoez@bigfoot.com>. 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 ``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

Software Licensing Information

385

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 License This 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 Reserved Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the 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.1 This 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 apache@apache.org. 5. 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 ``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 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.

386

Legal Information

Package: discover-data Debian package author: Branden Robinson The 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 Software Permission 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 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. 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 Technology 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, 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.

Software Licensing Information

387

388

Legal Information

Glossary

A
Access Control List
A 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 Rule
A 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.

Action
What the firewall engine should do with a packet that matches the criteria for a particular rule in the security policy.

Active Management Server
See Primary Management Server, on page 411.

Address range
A 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

Administrator
An 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 Role
An Element that defines which actions an Administrator with restricted permissions is allowed to take. See also Granted Element and Permission Level.

Aggressive Mode
The 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 Chain
A 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 Channel
A method of sending alerts out from the Log Server. You can send alerts via SMTP (email), 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 Element
An 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 Entry
A 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 Escalation
Sending 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 Event
A 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 Policy
A 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 Server
A 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.

Alias
An 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 Action
An Access Rule parameter that allows a connection matching that rule to pass through the firewall to its destination.

Analyzer
1) 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.

Antispoofing
Technique used to protect against malicious packages whose IP header information has been altered. See also IP Spoofing, on page 404.

Application
A category of Tags for Situations. Meant for grouping Situations that detect known vulnerabilities in a particular software application.

Application Layer Gateway; Application Level Firewall
A 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 Action
A 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 Encryption
A 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.

Auditing
A Management Center feature that logs Administrators’ actions and allows Superusers to view and manage these logs to keep track of system changes.

Authentication
The 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/Authenticator
A 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.

Authorization
The 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 Mode
A 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 Management
The 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 Host
A 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).

Blacklisting
The process of blocking unwanted network traffic either manually or with blacklist requests from a Sensor, Analyzer, or Management Server.

Boot Recovery
A StoneGate setting that brings the engines automatically back online after boot-up.

Border Routing
Routing of connections between different autonomous systems.

Buffer Overflow
When 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.

Bugtraq
A mailing list for discussing network security related issues, such as vulnerabilities.

Bulk Encryption Algorithm
Describes symmetric encryption algorithms which operate on fixed-size blocks of plaintext and generates a block of ciphertext for each.

393

C
CA
See Certificate Authority (CA), on page 394.

CAN
A candidate for a CVE entry.

Capture Interface
A 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.

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

Certificate
Electronic 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/Response
An 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

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

CIS
See Content Inspection Server (CIS), on page 396.

Client
In 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 VPN
A 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.

Cluster
A 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 Mode
Determines 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-Analyzer
1) 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 Tracking
The 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 Address
The 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 Action
A 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.

Context
An 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 Server
A server that maintains a Certificate Revocation List (CRL), which can be used in Authentication to check if the certificate has been cancelled.

Custom Alert
An Alert Element that is defined by a StoneGate administrator, as opposed to a readymade Default Element created by Stonesoft.

CVE
A 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 Element
An 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.

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

Diagram
An Element that contains one or more network diagrams created using the Diagram Editor.

Digital Certificate
See Certificate, on page 394.

Discard Action
An 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 Clustering
See Packet Dispatch, on page 410.

DMZ Network
A 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 Spoofing
An 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 Mark
A 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 Match
A 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 address
An IP address that is assigned by using the DHCP (Dynamic Host Configuration Protocol).

Dynamic NAT
A 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
Element
A 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.

Encryption
Used 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 Domain
Networks that are defined to be behind a certain VPN gateway in a Virtual Private Network (VPN) configuration.

Encryption Key
The 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 Policy
Settings that define which encryption and authentication methods are used to establish a Virtual Private Network (VPN).

Enforce VPN Action
A 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.

Engine
The device that runs firewall, sensor, or analyzer software; a standard server or a StoneGate appliance. Represented by a Node in the Management Client.

Ethernet Rules
A set of rules in the IPS Policy that define which Ethernet traffic is allowed or discarded by a Sensor in Transparent Access Control Mode.

Expression
An Element that can be used to accurately define a whole complex set of elements by including and excluding elements using logical expressions.

399

F
Filter
A 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.

Firewall
1) 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 Cluster
A Group of two or more Firewall Engines that work together as if they were a single firewall.

Firewall Engine
The device that runs firewall software; a standard server or a StoneGate appliance Represented by the Firewall Node in the Management Client.

Firewall Node
An 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 Action
A 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.

Fragmentation
The 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
Gateway
An element that represents the firewall/VPN engine in the VPN.

400

Gateway Certificate
A Certificate used for authenticating a Gateway to other Gateways and VPN Clients in a VPN.

Gateway Profile
An element that defines a set of VPN-related capabilities that a VPN Gateway supports.

Gateway Settings
An element that contains general settings for StoneGate firewall/VPN engines related to VPN performance.

Gateway-to-Gateway VPN
In 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 Element
An 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.

Group
A 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
Hardware
A category of Tags for Situations. Meant for grouping Situations that detect known vulnerabilities in applications that run on a particular hardware platform.

Hash Signature
A 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

Heartbeat
A 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 Availability
The 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.

Host
1) 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 Standby
A 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 Authentication
A 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 Proposal
The 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 Case
An 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 History
A collection of all the logs and audit entries that track actions performed in a particular Incident Case window.

Info Panel
A 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 Rule
A 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 Interface
A 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 Point
The 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 Rule
A 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 Network
The 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 keyrelated 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 License
A 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 Spoofing
A 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 Proposal
Suggested encryption algorithms, hash algorithms, authentication methods, etc. to be used for an IPsec (IP Security) tunnel. See also IKE Proposal, on page 402.

IPS Policy
The 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 Rule
A 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
Journal
A tool in the Incident Case window that allows administrators to create a permanent record of their actions while investigating an incident.

Jump Action
A 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
License
Files 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

Lifetime
The 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 Balancing
A process for distributing work evenly across multiple, available devices to avoid overwhelming any single system.

Load Balancing Filter
A 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 Routing
A 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 Sharing
The 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.

Location
An 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 Server
A component of the Management Center responsible for storing and managing log (and alert) data.

Log Spool
A temporary storage area in a firewall node for log data before it is sent to a Log Server.

Logical Interface
An IPS Element used in the IPS policies to represent one or more physical network interfaces as defined in the Sensor properties.

406

Logs View
A tool that allows browsing logs, alerts, audit data, and connections each in an adapted version of the same user interface.

M
Main Mode
An 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 License
A 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 Center
The 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 Client
A 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 Network
The network used for communication between firewalls, Management Servers, Log Servers and the Management Client.

Management Server
A 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 Element
A 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 Agent
A 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 Client
A 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 Server
An optional StoneGate component used as a gateway by the Monitoring Client for viewing logs.

Multicast
A 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 Inspection
A 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-Link
Patented 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.

NetLink
An 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 Element
1) 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.

Node
The 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 System
A 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-link
An 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
Packet
A 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 Dispatch
A 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 Filtering
A 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 Sniffer
See 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 Level
The 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 Action
An 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

Player
Any element or IP address that was involved in an incident that is being investigated using the Incident Case element.

Policy
A container for the Access rules, Inspection rules, and NAT rules.

Policy Routing
User-defined routing based on information that is not normally used in routing, such as the source IP address, port information, or service type.

Policy Snapshot
A 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 Key
A 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 Server
The 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.

Protocol
An 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 Agent
A 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 Tag
A 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 ARP
Proxy 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.

Pruning
Deleting 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 Cryptography
A 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 Class
An 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 Policy
A 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
Refragmentation
A 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 Action
An 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 Expression
A 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 Connection
A 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 License
A 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.

RFC
See Request for Comments (RFC).

413

Rootkit
A set of tools that intruders to computer systems use for hiding their presence and the traces of their actions.

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

Router
A 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 Table
A 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.

Rule
An 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 Option
Additional 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 address
An 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 Server
A Log Server defined as a backup channel for components that primarily send their logs to some other Log Server.

414

Secondary Management Server
A 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 Cryptography
See 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 Policy
The 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.

Sensor
A 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 Cluster
Group of two or more IPS Sensor nodes that work together as if they were a single Sensor.

415

Server
1) 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 Pool
A Network Element representing a group of Servers. Used for inbound traffic management.

Service
An 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 Stealing
See IP Splicing (or Hijacking), on page 404.

SHA-1
A 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 Firewall
A firewall that has only one Firewall Engine.

Single Point of Failure
The 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.

Site
A set of resources protected by StoneGate.

416

Situation
1) 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 Type
A category of Tags for Situations. Meant for indicating what kind of events the associated Situations detect (for example, Attacks, Suspicious Traffic).

Sniffer
A 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 Agent
A 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 Server
See Secondary Management Server, on page 415.

Standby Mode
An 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 Overview
A 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 Synchronization
The 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 address
IP address that is typed in by a user or an administrator, and which does not change without their action.

Static NAT
NAT (Network Address Translation) where for each original address, there is a single, predefined translated address.

Static Routing
A form of routing that has permanent routes between networks programmed into every Routing Table.

Sub-Policy
A 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.

Subtunnel
The 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 Encryption
An 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
Tag
An 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 Period
The time interval during which the active nodes in a firewall or sensor cluster collaborate to redistribute the work load of a failed node.

Task
An Element that allows you to schedule commands to run automatically at a convenient time.

Template Policy
A 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 Filter
A 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 Action
An 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.

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

Timeline
A tool in the Logs View that allows you to select and change the time range for the logs that are displayed.

419

ToS Flag
A 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 Handler
The set of Network Elements used for inbound and outbound traffic management. Includes NetLinks, Outbound Multi-links, and Server Pools.

Traffic Management
The 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 Prioritization
The 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-firstserved 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 Mode
A Sensor configuration in which the Sensor examines Ethernet traffic according to the Ethernet Rules.

Transparent Proxy
A 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 Protocol
Any 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.

Tunneling
A 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 Tracking
Information 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 Action
A 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.

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

UTM
Short 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 Adapter
A 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 Tracking
A 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 Defragmentation
A 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 address
A 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 Client
Software 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 Profile
An element that defines the IPsec (IP Security)-related settings for one or more VPNs.

Vulnerability
An 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 , 81 predefined, 82 access rules , 145–157 action, 151 comment, 152 continue, 153–154 destination, 150 options, 151 rematching tunneled packets, 154 rule table, 147 service, 150 source, 150 time, 152 action in access rules, 151 in ethernet rules, 141 in inspection rules, 176 in IPv6 access rules, 164 active directory server , 93 address range element , 90 administrator accounts RADIUS authentication, 86 administrator roles , 81 administrators , 79–88 access control lists, 81, 83 administrator accounts, 79–88 administrator elements, 84 administrator roles, 81, 83

editor, 82 log colors, 86 monitoring user elements, 84 operator, 82 owner, 82 permission levels, 85 predefined access control lists, 82 superuser, 82 alert chains , 227–232 alert channels , 227–232 alert entries , 214, 226 alert escalation , 225–236 alert chains, 227–232 alert channels, 227–232 alert entries, 226 alert policies, 227, 232 custom alerts, 228 custom scripts for, 233–234 final actions, 231 system alerts, 228 alert policies , 227, 229–230, 232 alerts alert policies, 229–230 event traces, 222 aliases , 154, 167, 285 alias element, 90 system aliases, 287 user aliases, system-defined, 286 allow action , 141, 151, 164 analyzer , 36 correlation situations, 119

423

deployment, 43–52 element, 94 analyzers , 97–111 tester, 105 anomaly detection , 25, 37 "any network" element , 92 apply blacklist action , 151 architecture , 30 auditing, audit entries , 215 authentication authentication server, 93 RADIUS, 86

B
blacklisting , 193–198 blacklist entries, 194 blacklist requests, 195 blacklists, 195 whitelisting, 194

log server, 272 management server, 272 comments in IPv6 access rules , 166 comments in rules , 142, 152 communications between components , 37 components of the system , 32 compress situation context , 119 Configuration , 73 configuration view , 73 connection tracking , 151 connectivity diagrams , 68 contact addresses , 106 contact information , 16 contexts , 119 continue action , 151, 153–154, 164, 166–167, 177 correlation situations , 119 count situation context , 119 custom alerts , 228 custom services , 95 customer support , 16

C
CA (certificate authority), internal , 37 CA, see certificate authority capture interfaces , 100 SPAN mode, 103 wire TAP mode, 103 categories , 255–258 configuration, 256–257 examples, 257 not categorized, 256 central management , 26 certificate authority , 51 certificates , 37 CIS (content inspection server) , 93 cluster status icons , 70–72 clustering architecture, 98 sensors, 97–111 command line tools , 271 commands engine, 280

D
data for reports , 247 default services , 95 default system policy , 140, 148, 162 defense in depth , 24 deploying sensors and analyzers , 43–52 destination in access rules, 150 in ethernet rules, 141 in inspection rules, 175 in IPv6 access rules, 163 detection anomaly, 25 misuse, 25 DHCP server , 93 diagrams in system status view , 68 discard action , 141, 151, 165 discard before storing filters , 217, 219 DNS server , 93 documentation available , 15 drill-down top rate summaries , 241

424

E
editors, see predefined administrator roles elements active directory server, 93 analyzers, 36 authentication server, 93 CIS (content inspection server), 93 context, 119 DHCP server, 93 DNS server, 93 LDAP server, 93 log server, 35, 92 management server, 34 monitoring server, 35, 93 network elements, 89–95 searching for, 63 sensors, 36 services, 94 situations, 117 SNMP agent, 106 tags, 118 vulnerabilities, 118–119 encapsulated packets , 154, 167 end-user license agreement , 373 engine status icons , 70–72 ethernet rules , 137–144 action, 141 comment, 142 destination, 141 examples, 142 options, 141 rule table, 139 service, 141 source, 141 event compress , 119 event correlation , 119 event count , 119 event group , 119 event match , 120 event sequence , 120 examples access rules, 155

administrator accounts, 87 alert escalation, 234 archiving logs, 222 blacklisting, 197 categories, 257 ethernet rules, 142 filters, 210 incident case, 262 inspection rules, 178 IPS deployment, 54 log management, 222 policies, 135 pruning logs, 223 reports, 251 situation, 123 exporting reports , 247–251 style templates, 248 expressions , 91 intersection, 91 negation, 91 union, 91 external administrator accounts , 86

F
facility field , 325 filters , 201–211 fields, 202, 204 log data, 202 operation types, 205–206 operations, 202–209 temporary filters, 203, 210 types of, 204 undefined values, 207–209 final actions , 231 fingerprint of certificates , 277 fingerprint syntax , 295 firewall element , 91 firewalls network element for, 91 FTP protocol agent , 184–185

425

G
GRE protocol agent , 185 group element , 91 group situation context , 119

H
H.323 protocol agent , 185 hardware requirements , 16 heartbeat , 98 HIDS , 24 high availability , 26, 31, 98 host elements , 91 HTTP protocol agent , 185–186

I
ICMP protocol agent , 186 IDS host-based, 24 network-based, 24 IEEE 802.1Q VLAN tagging , 102 immediate discard filters , 217, 219 incident cases , 259–263 data collection, 260–261 example, 262 history, 260 journal, 260–261 player list, 260–261 inherited rules , 129 inline interfaces , 100, 104 inline serial clustering, 107 inline mode , 24 inline serial cluster , 107 inspection rules , 169–178 action, 176 comments, 177 continue, 177 continue rules, 177 destination, 175 options, 176 protocol, 175

rule table, 172 severity, 175 situation, 174 source, 175 time, 177 interface ID , 99 interfaces network interface cards, 99 internal certificate authority , 37 IP diagrams , 68 IP in IP tunneling , 154, 167 IPS deployment , 41–56 example, 54 IPS policies , 125–135 packet inspection, 126 types of, 129 IPS, inline , 24 IPv4 Encapsulation protocol agent , 186 IPv4 protocol agent , 186 IPv6 access rules , 159–167 action, 164 comment, 166 continue, 166–167 destination, 163 options, 165 rematching tunneled packets, 167 rule table, 161 service, 164 source, 163 time, 165 IPv6 Encapsulation protocol agent , 187 IPv6 protocol agent , 187

J
jump action , 151

L
LDAP server , 93 legal information , 373 location, for NATed communications , 106 log data , 214

426

log entries , 214 log files , 217, 221 log levels , 218–219 log management , 213–224 log files, 217 log levels, 218–219 log pruning, 219 log tasks, 220 logging options, 218–219 log pruning , 217, 219 log server , 35, 92 configuration file, 343 log tasks , 220 logging , 213–224 accounting, 218 logging options , 218–219 for access rules, 151 for ethernet rules, 141 for inspection rules, 176 for IPv6 access rules, 165 logical interfaces , 103–104 logs view , 74–76

M
MAC address for cluster NDIs, 102 management center , 34 deployment, 52–54 management client , 34, 61–78 management server , 34 match situation context , 120 misuse detection , 25, 37 monitoring server , 35, 93 MSP (managed service provider) , 35 MSRPC protocol agent , 187 Multi-Link monitoring , 71–72

in clusters, 102 netBIOS protocol agent , 187 NetLink status icons , 71–72 network elements , 89–95 address range, 90 alias, 90 analyzer, 94 combined sensor-analyzer, 94 expressions, 91 firewall, 91 group, 91 host, 91 network, 92 router, 92 sensor cluster, 94 servers, 92 services, 94–95 single sensor, 94 SOHO firewall, 91 network interfaces , 99 NIC (network interface card) , 99 NIDS , 24 node dedicated interface, see NDI not categorized , 256

O
online help , 65 operators, see predefined administrator roles options in access rules, 151 in ethernet rules, 141 in inspection rules, 176 in IPv6 access rules, 165 oracle protocol agent , 187–188 overviews system statistics, 69–70 owners, see predefined administrator roles

N
NATed addresses , 106 NDI , 102 NDI (node dedicated interface) , 100

P
packet inspection with IPS policy , 126

427

PDF report files , 247 period total summaries , 240 permit action , 176 policies alerts, 229–230 validating, 133 policy pre-defined, 140, 148, 162 system, 140, 148, 162 policy editing view , 77–78 policy refresh needs , 134 policy snapshots , 134 port mirroring , 103 positioning sensors , 44 post-processing reports , 250 pre-defined aliases, 287 policy, 140, 148, 162 services, 95 progress summaries , 240 protocol in inspection rules, 175 validation, 25 protocol agents , 150, 164, 180–191 FTP, 184–185 GRE, 185 H.323, 185 HTTP, 185–186 ICMP, 186 IPv4, 186 IPv4 Encapsulation, 186 IPv6, 187 IPv6 Encapsulation, 187 MSRPC, 187 netBIOS, 187 oracle, 187–188 remote shell, 188 services in firewall, 188 SIP, 188–189 SMTP, 189 SSH, 189 SunRPC, 189 TCP proxy, 189 TFTP, 190

R
RADIUS authentication , 86 refuse action , 151, 165 regular expression syntax , 295 rematching tunneled packets, 154, 167 tunneled traffic, 154, 167 remote shell protocol agent , 188 report designs , 239–247 report files , 247–251 report items , 239–245 report sections , 239–245 report tasks , 240, 246–247 reports , 237–251 bar charts, 240 curve charts, 240 drill-down top rate summaries, 241 exporting, 247–251 filters, 247 log data, 238, 247 monitoring statistics, 238 PDF files, 247 period comparison, 243 period total summaries, 240 pie charts, 240 post-processing, 250 progress summaries, 240 report designs, 239–247 report files, 247–251 report items, 239–245 report sections, 239–245 report tasks, 240, 246–247 static information summaries, 241 style templates, 248 summary types, 240–241 system reports, 251 tab-delimited text files, 247–251 tables, 240 top rate summaries, 240 requirements for hardware , 16 reset interfaces , 104 router element , 92 routing , 113–114

428

analyzer, 114 sensor, 114 rules continue action, 153, 166, 177 inheritance, 129 protocol agents, 150, 164 validating, 133, 142, 155, 167, 177

SIP protocol agent , 188–189 situation contexts correlation

S
scan detection situation context , 120 searching elements, 63 services, 63 secure sockets layer , 51 sensor cluster communications, 98 inline serial clustering, 107 interfaces, 99 sensor-analyzer element , 94 sensors , 36 capture interfaces, 100 clustering, 97–111 clusters, 94

NDIs, 102
deployment, 43–52 inline interfaces, 100, 104 logical interfaces, 103–104 NDIs, 100, 102 reset interfaces, 104 tester, 105 transparent access control mode for, 36 sequence situation context , 120 service (access rule field) , 150 service (ethernet rule field) , 141 service (IPv6 access rule field) , 164 services , 95 custom services, 95 searching for, 63 services in firewall protocol agent , 188 severity, in inspection rules , 175 single point of failure , 26, 98 single sensor element , 94

website access control, 121 situations , 117 context definition, 119 examples, 123 in inspection rules, 174 SMC, see management center SMTP protocol agent , 189 SNMP agent , 106 SOHO firewall element , 91 SOHO firewalls network element for, 91 source in access rules, 150 in ethernet rules, 141 in inspection rules, 175 in IPv6 access rules, 163 SPAN , 103 SSH protocol agent , 189 SSL , 51 standard services , 95 static information summaries , 241 status icons , 70–72 stonegate management center, see management center sub-policies , 129, 132 summaries drill-down top rate summaries, 241 period total summaries, 240 progress summaries, 240 static information summaries, 241 top rate summaries, 240 SunRPC protocol agent , 189 support services , 16

event compress, 119 event count, 119 event group, 119 event match, 120 event sequence, 120 scan detection, 120 system, 121

429

switched port analyzer port , 103 syslog servers , 222 system alerts , 228 system architecture , 30 system components , 32 analyzer, 36 log server, 35 management client, 34 management server, 34 monitoring server, 35 sensor, 36 system design communications, 37 system elements aliases, 287 services, 95 system policy , 140, 148, 162 system reports , 251 system requirements , 16 system services , 95 system situation context , 121 system statistics views , 69–70 system status view , 66–68 diagrams in, 68 system summary , 66 system-defined user aliases , 286

TFTP protocol agent , 190 time in access rules, 152 in inspection rules, 177 in IPv6 access rules, 165 TLS , 51 top rate summaries , 240 transparent access control , 36 transport layer security , 51 tunneled packets rematching, 154, 167 tunneled traffic rematching, 154, 167 type field , 327 typographical conventions , 14

U
undefined options in access rules, 151 in ethernet rules, 141 in inspection rules, 176 in IPv6 access rules, 165 user aliases, system-defined , 286 user-defined service elements , 95

T
tab-delimited text report files , 247–251 tags , 118 TAP , 103 TCP proxy protocol agent , 189 technical support , 16 template policies , 129 temporary filters , 203, 210 terminate action , 176 test access port , 103 tester , 105

V
VLAN (virtual local area network) , 102 VPN (virtual private network) user aliases, 286 vulnerabilities , 118–119

W
website access control situation context , 121 whitelisting , 194 wire 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, visit www.stonesoft.com/support

Stonesoft Corporation Itälahdenkatu 22 A FI-00210 Helsinki Finland Tel. +358 9 476 711 Fax +358 9 4767 1234
Business ID: 0837548-0 Domicile: Helsinki

Stonesoft Inc. 1050 Crown Pointe Parkway Suite 900 Atlanta, GA 30338 USA Tel. +1 770 668 1125 Fax +1 770 668 1131

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

Sign up to vote on this title
UsefulNot useful