Enterasys Intrusion Prevention System Manual

Download

Enterasys

Intrusion Prevention System

Creating Network Sensor Policies and Signatures

P/N 9034379-05

Notice

Enterasys Networks reserves the right to make changes in specifications and other information contained in this document and its web site without prior notice. The reader should in all cases consult Enterasys Networks to determine whether any such changes have been made.

The hardware, firmware, or software described in this document is subject to change without notice.

IN NO EVENT SHALL ENTERASYS NETWORKS BE LIABLE FOR ANY INCIDENTAL, INDIRECT, SPECIAL, OR CONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING BUT NOT LIMITED TO LOST PROFITS) ARISING OUT OF OR RELATED TO THIS DOCUMENT, WEB SITE, OR THE INFORMATION CONTAINED IN THEM, EVEN IF ENTERASYS NETWORKS HAS BEEN ADVISED OF, KNEW OF, OR SHOULD HAVE KNOWN OF, THE POSSIBILITY OF SUCH DAMAGES.

Enterasys Networks, Inc. 50 Minuteman Road Andover, MA 01810

Part Number: 9034379-05 November 2011

ENTERASYS, ENTERASYS DRAGON, ENTERASYS NETSIGHT, ENTERASYS NETWORKS, and any logos associated therewith, are trademarks or registered trademarks of Enterasys Networks, Inc. in the United States and other countries. For a

complete list of Enterasys trademarks, see http://www.enterasys.com/company/trademarks.aspx.

Adobe, Acrobat, and Acrobat Reader are registered trademarks of Adobe Systems Incorporated. Intel, Intel Pentium, Xeon, Celeron, and Pentium II are trademarks or registered trademarks of Intel Corporation. Cisco is a registered trademark of Cisco Systems, Inc. FireWall-1, OPSEC and Check Point are trademarks or registered trademarks of Check Point Software Technologies Ltd. Dell and PowerEdge are trademarks of Dell Inc. IPX/SPX, Novell and NetWare are trademarks or registered trademarks of Novell, Inc. Linux is a trademark of Linus Torvalds. Microsoft, Windows, and Windows NT are trademarks or registered trademarks of Microsoft Corporation. Netscape is a registered trademark of Netscape Communications Corporation. Red Hat is a registered trademark of Red Hat, Inc. Solaris is a trademark of Sun MicroSystems, Inc. SPARC is a registered trademark of SPARC International, Inc. Sun and Java are trademarks or registered trademarks of Sun Microsystems, Inc. UNIX is a registered trademark of The Open Group. Product Series Name includes software whose copyright is licensed from MySQL AB. Product Series Name contains a proprietary operating system based on Linux. GNU general public License Copyright (C) 1989, 1991 Free Software Foundation, Inc.

All other product names mentioned in this manual may be trademarks or registered trademarks of their respective companies.

Support Site URL: http://www.enterasys.com/support

Documentation URL: https://extranet.enterasys.com/downloads/

Embedded Software Copyrights

Bleeding Snort

All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. * Neither the name of the nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Enterasys Networks, INC. Software License Agreement

This document is an agreement (“Agreement”) between You, the end user, and Enterasys Networks, Inc. on behalf of itself and its Affiliates (“Enterasys”) that sets forth your rights and obligations with respect to the software contained in CD-ROM or other media. “Affiliates” means any person, partnership, corporation, limited liability company, or other form of enterprise that directly or indirectly through one or more intermediaries, controls, or is controlled by, or is under common control with the party specified. BY INSTALLING THE ENCLOSED PRODUCT, YOU ARE AGREEING TO BECOME BOUND BY THE TERMS OF THIS AGREEMENT, WHICH INCLUDES THE LICENSE AND THE LIMITATION OF WARRANTY AND DISCLAIMER OF LIABILITY. IF YOU DO NOT AGREE TO THE TERMS OF THIS AGREEMENT, RETURN THE UNOPENED PRODUCT TO ENTERASYS OR YOUR DEALER, IF ANY, WITHIN TEN (10) DAYS FOLLOWING THE DATE OF RECEIPT FOR A FULL REFUND.

IF YOU HAVE ANY QUESTIONS ABOUT THIS AGREEMENT, CONTACT ENTERASYS NETWORKS, INC. (978) 684-1000. Attn: Legal Department.

Enterasys will grant You a non-transferable, non-exclusive license to use the machine-readable form of software (the “Licensed Software”) and the accompanying documentation (the Licensed Software, the media embodying the Licensed Software, and the documentation are collectively referred to in this Agreement as the “Licensed Materials”) on one single computer if You agree to the following terms and conditions:

1. TERM. This Agreement is effective from the date on which You open the package containing the Licensed Materials. You may terminate the Agreement at any time by destroying the Licensed Materials, together with all copies, modifications and merged portions in any form. The Agreement and your license to use the Licensed Materials will also terminate if You fail to comply with any term or condition herein.

2. GRANT OF SOFTWARE LICENSE. The license granted to You by Enterasys when You open this sealed package authorizes You to use the Licensed Software on any one, single computer only, or any replacement for that computer, for internal use only. A separate license, under a separate Software License Agreement, is required for any other computer on which You or another individual or employee intend to use the Licensed Software. YOU MAY NOT USE, COPY, OR MODIFY THE LICENSED MATERIALS, IN WHOLE OR IN PART, EXCEPT AS EXPRESSLY PROVIDED IN THIS AGREEMENT.

3. RESTRICTION AGAINST COPYING OR MODIFYING LICENSED MATERIALS. Except as expressly permitted in this Agreement, You may not copy or otherwise reproduce the Licensed Materials. In no event does the limited copying or reproduction permitted under this Agreement include the right to decompile, disassemble, electronically transfer, or reverse engineer the Licensed Software, or to translate the Licensed Software into another computer language.

The media embodying the Licensed Software may be copied by You, in whole or in part, into printed or machine readable form, in sufficient numbers only for backup or archival purposes, or to replace a worn or defective copy. However, You agree not to have more than two (2) copies of the Licensed Software in whole or in part, including the original media, in your possession for said purposes without Enterasys’ prior written consent, and in no event shall You operate more than one copy of the Licensed Software. You may not copy or reproduce the documentation. You agree to maintain appropriate records of the location of the original media and all copies of the Licensed Software, in whole or in part, made by You. You may modify the machine-readable form of the Licensed Software for (1) your own internal use or (2) to merge the Licensed Software into other program material to form a modular work for your own use, provided that such work remains modular, but on termination of this Agreement, You are required to completely remove the Licensed Software from any such modular work. Any portion of the Licensed Software included in any such modular work shall be used only on a single computer for internal purposes and shall remain subject to all the terms and conditions of this Agreement.

You agree to include any copyright or other proprietary notice set forth on the label of the media embodying the Licensed Software on any copy of the Licensed Software in any form, in whole or in part, or on any modification of the Licensed Software or any such modular work containing the Licensed Software or any part thereof.

4. TITLE AND PROPRIETARY RIGHTS.

(a) The Licensed Materials are copyrighted works and are the sole and exclusive property of Enterasys, any company or a

division thereof which Enterasys controls or is controlled by, or which may result from the merger or consolidation with Enterasys (its “Affiliates”), and/or their suppliers. This Agreement conveys a limited right to operate the Licensed Materials and shall not be construed to convey title to the Licensed Materials to You. There are no implied rights. You shall not sell, lease, transfer, sublicense, dispose of, or otherwise make available the Licensed Materials or any portion thereof, to any other party.

(b) You further acknowledge that in the event of a breach of this Agreement, Enterasys shall suffer severe and irreparable

damages for which monetary compensation alone will be inadequate. You therefore agree that in the event of a breach of this Agreement, Enterasys shall be entitled to monetary damages and its reasonable attorney’s fees and costs in enforcing this Agreement, as well as in juncti ve rel ief to r estrain such breach, in additi on to any other remedies available

iii

to Enterasys.

5. PROTECTION AND SECURITY. In the performance of this Agreement or in contemplation thereof, You and your employees and agents may have access to private or confidential information owned or controlled by Enterasys relating to the Licensed Materials supplied hereunder including, but not limited to, product specifications and schematics, and such information may contain proprietary details and disclosures. All information and data so acquired by You or your employees or agents under this Agreement or in contemplation hereof shall be and shall remain Enterasys’ exclusive property, and You shall use your best efforts (which in any event shall not be less than the efforts You take to ensure the confidentiality of your own proprietary and other confidential information) to keep, and have your employees and agents keep, any and all such information and data confidential, and shall not copy, publish, or disclose it to others, without Enterasys’ prior written approval, and shall return such information and data to Enterasys at its request. Nothing herein shall limit your use or dissemination of information not actually derived from Enterasys or of information which has been or subsequently is made public by Enterasys, or a third party having authority to do so.

You agree not to deliver or otherwise make available the Licensed Materials or any part thereof, including without limitation the object or source code (if provided) of the Licensed Software, to any party other than Enterasys or its employees, except for purposes specifically related to your use of the Licensed Software on a single computer as expressly provided in this Agreement, without the prior written consent of Enterasys. You agree to use your best efforts and take all reasonable steps to safeguard the Licensed Materials to ensure that no unauthorized personnel shall have access thereto and that no unauthorized copy, publication, disclosure, or distribution, in whole or in part, in any form shall be made, and You agree to notify Enterasys of any unauthorized use thereof. You acknowledge that the Licensed Materials contain valuable confidential information and trade secrets, and that unauthorized use, copying and/or disclosure thereof are harmful to Enterasys or its Affiliates and/or its/their software suppliers.

6. MAINTENANCE AND UPDATES. Updates and certain maintenance and support services, if any, shall be provided to You pursuant to the terms of a Enterasys Service and Maintenance Agreement, if Enterasys and You enter into such an agreement. Except as specifically set forth in such agreement, Enterasys shall not be under any obligation to provide Software Updates, modifications, or enhancements, or Software maintenance and support services to You.

7. DEFAULT AND TERMINATION. In the event that You shall fail to keep, observe, or perform any obligation under this Agreement, including a failure to pay any sums due to Enterasys, or in the event that You become insolvent or seek protection, voluntarily or involuntarily, under any bankruptcy law, Enterasys may, in addition to any other remedies it may have under law, terminate the License and any other agreements between Enterasys and You.

(a) Immediately after any termination of the Agreement or if You have for any reason discontinued use of Software, You

shall return to Enterasys the original and any copies of the Licensed Materials and remove the Licensed Software from any modular works made pursuant to Section 3, and certify in writing that through your best efforts and to the best of your knowledge the original and all copies of the terminated or discontinued Licensed Materials have been returned to Enterasys.

(b) Sections 4, 5, 7, 8, 9, 10, 11, and 12 shall survive termination of this Agreement for any reason.

8. EXPORT REQUIREMENTS

. You understand that Enterasys and its Affiliates are subject to regulation by agencies of the U.S. Government, including the U.S. Department of Commerce, which prohibit export or diversion of certain technical products to certain countries, unless a license to export the product is obtained from the U.S. Government or an exception from obtaining such license may be relied upon by the exporting party.

If the Licensed Materials are exported from the United States pursuant to the License Exception CIV under the U.S. Export Administration Regulations, You agree that You are a civil end user of the Licensed Materials and agree that You will use the Licensed Materials for civil end uses only and not for military purposes.

If the Licensed Materials are exported from the United States pursuant to the License Exception TSR under the U.S. Export Administration Regulations, in addition to the restriction on transfer set forth in Section 4 of this Agreement, You agree not to (i) reexport or release the Licensed Software, the source code for the Licensed Software or technology to a national of a country in Country Groups D:1 or E:2 (Albania, Armenia, Azerbaijan, Belarus, Cambodia, Cuba, Georgia, Iraq, Kazakhstan, Kyrgyzstan, Laos, Libya, Macau, Moldova, Mongolia, North Korea, the People’s Republic of China, Russia, Tajikistan, Turkmenistan, Ukraine, Uzbekistan, Vietnam, or such other countries as may be designated by the United States Government), (ii) export to Country Groups D:1 or E:2 (as defined herein) the direct product of the Licensed Software or the technology, if such foreign produced direct product is subject to national security controls as identified on the U.S. Commerce Control List, or (iii) if the direct product of the technology is a complete plant o r any major component of a plant, export to Country Groups D:1 or E:2 the direct product of the plant or a major component thereof, if such foreign produced direct product is subject to national security controls as identified on the U.S. Commerce Control List or is subject to State Department controls under the U.S. Munitions List.

9. UNITED STATES GOVERNMENT RESTRICTED RIGHTS. The Licensed Materials (i) were developed solely at private expense; (ii) contains “restricted computer software” submitted with restricted rights in accordance with section 52.227-19 (a) through (d) of the Commercial Computer Software-Restricted Rights Clause and its successors, and (iii) in all respects is proprietary data belonging to Enterasys and/or its suppliers. For Department of Defense units, the Licensed Materials are considered commercial computer software in accordance with DFARS section 227.7202-3 and its successors, and use, duplication, or disclosure by the U.S. Government is subject to restrictions set forth herein.

10. LIMITED WARRANTY AND LIMITATION OF LIABILITY. The only warranty Enterasys makes to You in connection with this license of the Licensed Materials is that if the media on which the Licensed Software is recorded is defective, it will be replaced without charge, if Enterasys in good faith determines that the media and proof of payment of the license fee are returned to Enterasys or the dealer from whom it was obtained within ninety (90) days of the date of payment of the license fee.

NEITHER ENTERASYS NOR ITS AFFILIATES MAKE ANY OTHER WARRANTY OR REPRESENTATION, EXPRESS OR IMPLIED, WITH RESPECT TO THE LICENSED MATERIALS, WHICH ARE LICENSED "AS IS". THE LIMITED WARRANTY AND REMEDY PROVIDED ABOVE ARE EXCLUSIVE AND IN LIEU OF ALL OTHER WARRANTIES, INCLUDING IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, WHICH ARE EXPRESSLY DISCLAIMED, AND STATEMENTS OR REPRESENTATIONS MADE BY ANY OTHER PERSON OR FIRM ARE VOID. ONLY TO THE EXTENT SUCH EXCLUSION OF ANY IMPLIED WARRANTY IS NOT PERMITTED BY LAW, THE DURATION OF SUCH IMPLIED WARRANTY IS LIMITED TO THE DURATION OF THE LIMITED WARRANTY SET FORTH ABOVE. YOU ASSUME ALL RISK AS TO THE QUALITY, FUNCTION AND PERFORMANCE OF THE LICENSED MATERIALS. IN NO EVENT WILL ENTERASYS OR ANY OTHER PARTY WHO HAS BEEN INVOLVED IN THE CREATION, PRODUCTION OR DELIVERY OF THE LICENSED MATERIALS BE LIABLE FOR SPECIAL, DIRECT, INDIRECT, RELIANCE, INCIDENTAL OR CONSEQUENTIAL DAMAGES, INCLUDING LOSS OF DATA OR PROFITS OR FOR INABILITY TO USE THE LICENSED MATERIALS, TO ANY PARTY EVEN IF ENTERASYS OR SUCH OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. IN NO EVENT SHALL ENTERASYS OR SUCH OTHER PARTY'S LIABILITY FOR ANY DAMAGES OR LOSS TO YOU OR ANY OTHER PARTY EXCEED THE LICENSE FEE YOU PAID FOR THE LICENSED MATERIALS.

Some states do not allow limitations on how long an implied warranty lasts and some states do not allow the exclusion or limitation of incidental or consequential damages, so the above limitation and exclusion may not apply to You. This limited warranty gives You specific legal rights, and You may also have other rights which vary from state to state.

11. JURISDICTION. The rights and obligations of the parties to this Agreement shall be governed and construed in accordance with the laws and in the State and Federal courts of the Commonwealth of Massachusetts, without regard to its rules with respect to choice of law. You waive any objections to the personal jurisdiction and venue of such courts. None of the 1980 United Nations Convention on the Limitation Period in the International Sale of Goods, and the Uniform Computer Information Transactions Act shall apply to this Agreement.

12. GENERAL.

(a) This Agreement is the entire agreement between Enterasys and You regarding the Licensed Materials, and all prior

agreements, representations, statements, and undertakings, oral or written, are hereby expressly superseded and canceled.

(b) This Agreement may not be changed or amended except in writing signed by both parties hereto.

(d) This Agreement shall not be assignable by You without the express written consent of Enterasys, The rights of

Enterasys and Your obligations under this Agreement shall inure to the benefit of Enterasys’ assignees, licensors, and licensees.

(e) Section headings are for convenience only and shall not be considered in the interpretation of this Agreement.

(f) The provisions of the Agreement are severable and if any one or more of the provisions hereof are judicially determined

to be illegal or otherwise unenforceable, in whole or in part, the remaining provisions of this Agreement shall nevertheless be binding on and enforceable by and between the parties hereto.

(g) Enterasys’ waiver of any right shall not constitute waiver of that right in future. This Agreement constitutes the entire

understanding between the parties with respect to the subject matter hereof, and all prior agreements, representations, statements and undertakings, oral or written, are hereby expressly superseded and canceled. No purchase order shall supersede this Agreement.

(h) Should You have any questions regarding this Agreement, You may contact Enterasys at the address set forth below.

Any notice or other communication to be sent to Enterasys must be mailed by certified mail to the following address: ENTERASYS NETWORKS, INC., 50 Minuteman Road, Andover, MA 01810 Attn: Manager - Legal Department.

Contents

About This Guide

Intended Audience ............................................................................................................................................. xi

Version Support ................................................................................................................................................. xi

Related Documents ...........................................................................................................................................xi

Conventions ...................................................................................................................................................... xii

Getting Help ...................................................................................................................................................... xii

Chapter 1: Network Sensor Overview

Enterasys IPS Network Sensors .................................................................................................................... 1-1

Virtual Network Sensors ........................................................................................................................... 1-2

Network Sensor Policies ................................................................................................................................. 1-2

Network Sensor Policy Modules .............................................................................................................. 1-4

Network Sensor Signatures ............................................................................................................................ 1-9

Signature Libraries and Event Groups ................................................................................................... 1-10

Basic and Extended Signatures ............................................................................................................. 1-14

Configuring Port Macros ............................................................................................................................... 1-14

Procedure ............................................................................................................................................... 1-15

Chapter 2: Creating Network Sensor Policies

Creating New Policies .................................................................................................................................... 2-1

Copying Existing Policies ............................................................................................................................... 2-3

Configuring the Application Filter Module ....................................................................................................... 2-3

General Settings Tab ............................................................................................................................... 2-4

IP Settings Tab ......................................................................................................................................... 2-6

Port Settings Tab ..................................................................................................................................... 2-8

Protocol Settings Tab ............................................................................................................................. 2-11

VLAN Settings Tab ................................................................................................................................. 2-13

Probe Settings Tab ................................................................................................................................ 2-14

Rule Settings Tab ................................................................................................................................... 2-16

Signature Settings Tab ........................................................................................................................... 2-18

Configuring the Covert Channel Analysis Module ........................................................................................ 2-20

Backdoor Settings .................................................................................................................................. 2-20

Fast ICMP Settings ................................................................................................................................ 2-21

Enable Loki Check Setting ..................................................................................................................... 2-21

Procedure ............................................................................................................................................... 2-21

Configuring the DoS Check Module ............................................................................................................. 2-22

Procedure ............................................................................................................................................... 2-23

Configuring the Dragon Filter Module ........................................................................................................... 2-24

Writing a Filter Rule ................................................................................................................................ 2-25

Procedure ............................................................................................................................................... 2-26

Configuring the Dynamic Module ................................................................................................................ 2-28

Procedure ............................................................................................................................................... 2-28

Configuring the Header Search Module ...................................................................................................... 2-29

Specifying Search Strings ...................................................................................................................... 2-29

Procedure ............................................................................................................................................... 2-30

Example ................................................................................................................................................. 2-31

Configuring the Logging Module ................................................................................................................... 2-31

Procedure ............................................................................................................................................... 2-32

Configuring the Network Layer Module ........................................................................................................ 2-33

General Settings Tab ............................................................................................................................. 2-34

vii

Log Option Tab ...................................................................................................................................... 2-39

Log Protocol Tab .................................................................................................................................... 2-41

Log Frag Tab .......................................................................................................................................... 2-42

Log Static Tab ........................................................................................................................................ 2-44

Log Broadcast Tab ................................................................................................................................. 2-46

Configuring the Probe Detection Module ...................................................................................................... 2-47

Procedure ............................................................................................................................................... 2-48

Configuring the Protocol Analysis Module .................................................................................................... 2-50

DNS Analysis Configuration ................................................................................................................... 2-51

FTP Analysis Configuration .................................................................................................................... 2-54

Finger Analysis Configuration ................................................................................................................ 2-56

H.225 Analysis Configuration ................................................................................................................. 2-58

H.245 Analysis Configuration ................................................................................................................. 2-61

HTTP Analysis Configuration ................................................................................................................. 2-63

ICMP Analysis Configuration ................................................................................................................ 2-66

MGCP Analysis Configuration ................................................................................................................ 2-69

RIP Analysis Configuration .................................................................................................................... 2-72

RPC Analysis Configuration ................................................................................................................... 2-74

SIP Analysis Configuration ..................................................................................................................... 2-78

SMB Analysis Configuration ................................................................................................................... 2-81

SNMP Analysis Configuration ................................................................................................................ 2-83

Telnet Analysis Configuration ................................................................................................................ 2-85

Configuring the SNMP Trap Module ............................................................................................................. 2-88

Procedure ............................................................................................................................................... 2-88

Configuring the TCP State Module ............................................................................................................... 2-89

Procedure ............................................................................................................................................... 2-89

Configuring the Transport Layer Module ...................................................................................................... 2-91

General Settings Tab ............................................................................................................................. 2-91

Stream Rebuilding Tab .......................................................................................................................... 2-94

Flags Tab ............................................................................................................................................... 2-96

Log Syn Tab ........................................................................................................................................... 2-97

Log Session Tab .................................................................................................................................... 2-99

Log Start Stop Tab ............................................................................................................................... 2-101

Log Destination Tab ............................................................................................................................. 2-103

Log Server Tab .................................................................................................................................... 2-105

Log Syn Pattern Tab ............................................................................................................................ 2-108

Log Pairs Tab ....................................................................................................................................... 2-109

Chapter 3: Creating Network Sensor Signatures

Signature Overview ........................................................................................................................................ 3-1

Resource-Based Signatures .................................................................................................................... 3-1

Suspicious Traffic ..................................................................................................................................... 3-2

Server Messages ..................................................................................................................................... 3-2

Indirect Signatures ................................................................................................................................... 3-2

Tips for Creating Signatures .................................................................................................................... 3-3

Creating Custom Signature Libraries ............................................................................................................. 3-5

Signatures and Live Update ..................................................................................................................... 3-5

Creating a Custom Library ....................................................................................................................... 3-6

Copying Existing Signatures Into a Custom Library ................................................................................. 3-8

Using the Signature Filter Dialog ............................................................................................................. 3-9

Creating Custom Signatures ........................................................................................................................ 3-12

Configuring Basic Signature Properties ................................................................................................. 3-14

Configuring Extended Signature Properties ........................................................................................... 3-21

Creating Custom Event Groups .................................................................................................................... 3-43

Example of Signature Creation ..................................................................................................................... 3-44

viii

Appendix A: Keywords/XML Attributes

6.x to 7.x Mappings ........................................................................................................................................A-1

Network Sensor Signature Fields .................................................................................................................A-60

Host Sensor Mappings ................................................................................................................................. A-61

Agent Mappings ............................................................................................................................................ A-61

Index

The Enterasys Intrusion Prevention System (IPS) is a solution consisting of an Intrusion Detection System (IDS), active response, and intrusion prevention. Enterasys IPS administrators can configure a variety of elements. Administrators are responsible for configuring Network Sensors, Host Sensors, and the management tools of the Enterprise Management Server (EMS). Depending on your administrative role, you have access to the root of the operating system, XML, and/or the GUI configuration methods. It is recommended that all configuration available through the GUI be performed using the GUI. XML configuration is described in the Configuration Guide.

This guide describes how to create network sensor policies and signatures. This guide does not describe how to add network sensor nodes or virtual sensors to your managed Enterasys IPS environment. Refer to the Configuration Guide for information about using the EMS client GUI to set up and manage your Enterasys IPS environment. Refer to Creating Host Sensor Policies for information on creating host sensor policies.

Intended Audience

This document is intended for experienced network administrators who are responsible for implementing and maintaining an Intrusion Prevention System.

About This Guide

Version Support

This guide supports Enterasys Intrusion Prevention System Version 7.4, and higher.

Related Documents

The Enterasys IPS user documentation listed below is available from

https://extranet.enterasys.com/downloads.

Enterasys IPS Document Title Description

Appliance Hardware Installation Guide Describes how to set up the Enterasys IPS appliances.

Configuration Guide Describes how to configure Enterasys IPS using GUI

Creating Host Sensor Policies Describes how to create custom Host Sensor policies.

Creating Network Sensor Policies and Signatures

Analysis and Reporting Guide Describes the Enterasys IPS reporting tools. Reporting tools

Command Line Tools Reference Describes the forensics command line tools you can use to

management tools. It also describes the placement of Enterasys IPS components within your network.

Describes how to create custom Network Sensor policies and signatures.

available from the command line are described in the Command Line Tools Reference.

analyze the events database or a single dragon.db file.

Creating Network Sensor Policies and Signatures xi

Conventions

The following conventions are used in this document.

<installdir> Indicates to enter the path were you installed Enterasys IPS. The default directory is

bold type Actual user input values or names of screens and commands.

blue type Indicates a hypertext link. When reading this document online, click the text in blue to

italic type User input value required.

courier Used for command-level input or output.

Getting Help

For additional support, contact Enterasys Networks using one of the following methods:

World Wide Web http://www.enterasys.com/support

Phone 1-800-872-8440 (toll-free in U.S. and Canada)

Email support@enterasys.com

/usr/dragon.

go to the referenced figure, table, or section.

or 1-978-684-1888

For the Enterasys Networks Support toll-free number in your country:

http://www.enterasys.com/support

To expedite your message, please type [dragon] in the subject line.

Before contacting Enterasys Networks for technical support, have the following information ready:

• Your Enterasys Networks service contract number

• A description of the failure

• A description of any action(s) already taken to resolve the problem (for example, changing mode switches, and rebooting the unit.)

• The serial and revision numbers of all involved Enterasys Networks products in the network

• A description of your network environment (for example, layout, and cable type)

• Network load and frame size at the time of trouble (if known)

• The device history (for example, have you returned the device before, is this a recurring problem)

• Any previous Return Material Authorization (RMA) numbers

xii About This Guide

This chapter provides an overview of Network Sensor operation and explains what network sensor policies and signatures are. This chapter also includes information about configuring port macros, which can be used in network sensor policies and signatures.

For information about... Refer to page...

Enterasys IPS Network Sensors 1-1

Network Sensor Policies 1-2

Network Sensor Signatures 1-9

Configuring Port Macros 1-14

Enterasys IPS Network Sensors

The Enterasys IPS Network Sensor is a packet-based Network Intrusion Detection System (NIDS) and response system. It collects network packets and analyzes them for a variety of suspicious activities. Suspicious activity may indicate network abuse, probes, intrusions, or vulnerabilities. The Network Sensor also monitors network packets for computer criminals, hackers, employee misuse, and network anomalies. Multiple Network Sensors can operate jointly to provide enterprise coverage of complex networks that are managed by the Enterprise Management Server (EMS). Network Sensor can send pages and email alerts when it detects suspicious events while taking action to stop the event and record the event for future forensic analysis. It can take action to shut down the connection to avoid further damage.

Network Sensor Overview

Network Sensors typically are deployed at network aggregation points and ensure the validity of traffic in layers two, three, and four. The sensors can reassemble fragmented frames and reconstruct TCP and UDP streams to counteract detection evasion tools. Network Sensors use signature-based pattern matching, protocol analysis and decoding, and anomaly detection techniques.

When an attack is detected, Network Sensor employs a variety of active response techniques to block the would-be intruder, including taking action to stop the sessions and reconfiguring firewall policies or switch and router Access Control Lists. Network Sensor offers deep forensic capabilities, including flexible packet capture and complete session information (such as information about HTTP, FTP, POP, and certain IPs or networks) needed to analyze network-based attacks.

Creating Network Sensor Policies and Signatures 1-1

Network Sensor Policies

Network Sensor features include:

• Open tunable signatures which allow implementation, modification, and custom creation of a

• Multi-interface monitoring that combines multiple network interfaces into a single traffic

• IP defragmentation and TCP/UDP stream reassembly that identifies attackers who attempt to

• Protocol decoding for most commonly targeted protocols that identifies attackers who

• IDS Denial of Service (DoS) countermeasures that defeat tools such as “stick” and “snot” that

• Event sniping which terminates an attack session via a TCP reset or ICMP unreachable

• Probe prevention that defeats or confuses many scanning techniques by issuing false

• Backdoor and rogue server detection using varied techniques

set of signatures designed to detect the attacks that apply to each unique environment

stream for analysis, enabling a dual-tap solution

evade an IDS by distributing attacks over multiple packets

attempt to hide an attack within the protocol

attempt to DoS an intrusion detection system

message, stopping the attack before real damage can occur

responses to the probe, misleading attackers about the true nature of the network and/or target system

Virtual Network Sensors

Up to four virtual sensors can be created on each physical Network Sensor. Virtualization can be based on such things as VLAN ID, IP subnet, IP protocol number, TCP/UDP port number, or physical network interface card. Each virtual sensor can then be configured with individual policies and signatures suitable for the specific role of that sensor.

Note that at least one virtual sensor must be configured on a Network Sensor device, because policies and signatures can only be assigned to virtual network sensors.

Network Sensor Policies

Network Sensor policies control aspects of the sensors which do not directly rely on or require signatures. For example, a policy may include protocol decoders and checks on the header portion of packets. Signatures, on the other hand, look specifically at the data portion of packets for certain patterns.

A Network Sensor policy is comprised of “modules” that define the operation of the virtual sensor to which the policy is applied. Each module provides the parameters to configure the behavior of the sensor relative to a logical grouping of sensor tasks.

Enterasys provides you with a set of “master” policy modules which, although they cannot be modified, can be used to create your own custom policies that are associated with a virtual sensor.

You create your custom policies from within the Network Policy view, which is displayed by clicking on the Network Policy View and Signature Libraries icon in the main EMS window.

Figure 1-1 shows the Network Policies tab within the Network Policy view, with the list of default

master policy modules expanded.

1-2 Network Sensor Overview

Figure 1-1 Network Policy View

Network Sensor Policies

When you create your own custom policies, Enterasys IPS automatically adds four basic master policy modules that must be included in any policy in order to be deployed:

• Dynamic Module

• Logging Module

• Network Layer Module

• Transport Layer Module

In addition, you can also select any of the other master policy modules to be included in your custom policy, as shown in Figure 1-2.

Creating Network Sensor Policies and Signatures 1-3

Network Sensor Policies

Figure 1-2 Adding Master Modules to a Custom Policy

Once you have added the desired modules to your custom policy, you configure the module parameters for the particular virtual sensor to which that policy will be applied. Procedures for creating and configuring custom policies are provided in Chapter 2, Creating Network Sensor

Policies.

Network Sensor Policy Modules

Your choice of policy modules to include in a custom policy depends on the configuration of the virtual sensor to which the policy will be applied. You should consider:

• the types of traffic and packets that will be received by the virtual sensor,

• the address of the network the sensor is protecting (its protected network)

• in order to create policies that generate or suppress (filter) the desired events by the sensor and configure the desired logging/SNMP trap behavior by the sensor.

That is, you must know the types of traffic and packets that will be received by the virtual sensor, as well as the address of the network the sensor is protecting (its protected network) in order to create policies that generate or suppress (filter) the desired events by the sensor and configure the desired logging/SNMP trap behavior by the sensor.

The following sections briefly describe the high-level behaviors that can be configured by each of the policy modules. More details are provided in Chapter 2, Creating Network Sensor Policies.

1-4 Network Sensor Overview

Network Sensor Policies

Application Filter Module

This module defines traffic criteria that can be ignored by the sensor. Use this module to refine the data which the sensor analyzes, by telling the sensor what types of traffic and packets to ignore. By reducing the amount of data that the sensor has to look at, and therefore the number of events generated, you can often improve the performance of the sensor as well as the analysis process.

Application filters are applied before any inspection of data occurs. Therefore, if a filter is matched, the sensor does not do any further processing of the data — that is what is meant by saying that the data is “ignored.” In general, if you know of a particular class of traffic that can be ignored (for example, from a particular IP address or VLAN), then you should use a filter, since this will generally lessen the load on the sensor.

You can tell the sensor to ignore traffic based on the following criteria:

• Direction with Respect to the Sensor’s Protected Network, set using the General Settings tab.

• IP Address and Direction, set using the IP Settings tab.

• TCP and UDP Port Number and Direction, set using the Port Settings tab.

• IP Protocol Number, set in the Protocol Settings tab.

• Specific VLAN or range of VLAN numbers, set in the VLAN Settings tab.

• Traffic That Looks Like a Port Scan or Port Sweep, set using the Probe Settings tab.

• IP Address, Port, and Protocol Rule combinations, set in the Rule Settings tab.

• Signatures, set using the Signature Settings tab.

Covert Channel Analysis Module

Many hackers use ICMP echo request and echo reply packets to communicate covertly. Specialized ICMP client and servers such as Back Orifice 2000 and LOKI are good examples. The Covert Channel Analysis module provides parameters to configure three types of analysis:

• Backdoor Settings, which enable discovery of streams of unsolicited ICMP replies or ICMP streams with static sequence numbers.

• Fast ICMP Settings, which also catch backdoors that utilize ICMP.

• Enable Loki Check Setting, which catches Loki traffic.

DoS Check Module

This module allows you to add Denial of Service checking to a Network Sensor policy. When Denial of Service checking is enabled, the Network Sensor searches packets for distinct trademarks of specific denial of service tools that are in use and freely available. The sensor will generate different DoS internal events, depending on the tool. If a Denial of Service attack is observed, the event data will contain the attack information.

Creating Network Sensor Policies and Signatures 1-5

Network Sensor Policies

Dragon Filter Module

The Dragon Filter module allows you to eliminate the reporting of events that you know are not significant on your network—that is, are just “background noise” that can safely be ignored. For example, you may use the SNMP public community for your network management. When you use the Enterasys IPS reporting tools to view Enterasys IPS events being generated on your network, you may notice that there are thousands of SNMP:PUBLIC events being generated from a source IP address that matches the address of your management station. In such a case, you can safely ignore those events, so you would write a Dragon filter that would drop (not report) SNMP:PUBLIC events if the source IP address equals the IP address of your management station.

The events that can be filtered with Dragon filters include those generated by signatures applied to a sensor (for example, the signature with the name SNMP:PUBLIC) as well as internal events generated by a network policy applied to a sensor (for example, the ICMP:BD-REPLY event is generated by backdoor analysis configured with the Covert Channel Analysis module).

Dragon filters are applied after data has been inspected, unlike Application filters that are applied before data has been inspected. Therefore, Dragon Filter statements could be considered more CPU intensive, in the sense that they can only be applied after the pattern matching operations are completed. However, since both Dragon Filters and Application Filters are fairly quick operations, neither greatly impacts the sensor’s performance (unless there are hundreds of them).

Dynamic Module

The Dynamic Module is one of the default modules added to every custom policy. It enables the sensor to record packets from IP addresses that are involved in events. When an event occurs, the Network Sensor makes a best effort to grab subsequent packets from the source and destination IP addresses of the event packet. The number of recorded packets is determined by the specific alarm or signature. Additional Dynamic packet logging can be set for all events, by specifying the number of Cushion packets the Network Sensor should collect in addition to the normal number of packets specified by the signature or alarm.

For example, if a PHF attack signature has a Dynamic packet capture level of 10 packets and the Cushion value is set to 5 packets in this module, the Network Sensor will attempt to collect 15 packets. This parameter is meant as an easy way to quickly turn up the sensitivity of a Network Sensor. The extra logging may have a negative impact on system performance or on Network Sensor hard drive space.

Header Search Module

The Header Search module allows you to configure the Network Sensor to search IP and TCP headers for a specific string of data. When you configure a Header Search rule, you identify:

• A start byte and a stop byte in the header of either IP or TCP traffic. These bytes specify the part of the header to check.

• The frequency, in packets, of the check. A frequency of 0 means check all packets.

• The pattern to search for.

• The name of the event to generate when the rule is matched.

Refer to “Specifying Search Strings” on page 2-29 for information about how to specify the pattern to search for.

1-6 Network Sensor Overview

Network Sensor Policies

Logging Module

The Logging Module is one of the default and required modules that must be included in a Network Sensor policy. This module defines where event logs are stored and how they are displayed.

Network Layer Module

The Network Layer Module is one of the default and required modules that must be included in a Network Sensor policy. This module defines what IP packet header fields the Network Sensor should analyze and what actions the sensor should take when it finds certain anomalous values in those fields (malformed headers, headers that don’t match the relevant RFCs). You can also configure certain fragment rebuilding parameters.

• IP packets can be logged or ignored based on IP option type and source IP address, or on IP protocol and source address.

• Fragmented packets can be logged or ignored based on source address and protocol.

• Packets from a particular network or IP address can be logged.

• Packets with strange broadcast destination addresses can be logged. These packets are most likely denial of service attacks, network probes, or malfunctioning routers.

Probe Detection Module

The parameters set with the Probe Detection Module configure the way the Network Sensor tracks probing activities that cannot be detected by rule-matching or protocol anomaly detection. The probe detection module builds vast internal tables to keep track of the following factors:

• Number of destination hosts

• Number of destination ports

• Number of source hosts

• Time over which the packets were sent

The module provides configuration settings that control how the sensor collects information and generates events under certain situations:

• The options in the Probe Detection Settings area configure the thresholds used by the Network Sensor when it performs port scan and port sweep analysis.

• The Port Ranges table is used to specify which port ranges you want the Network Sensor to consider when analyzing for port scans and sweeps.

Creating Network Sensor Policies and Signatures 1-7

Network Sensor Policies

Protocol Analysis Module

The Protocol Analysis Module allows you to configure the Network Sensor to perform analysis on a variety of protocols. Basically, this module checks whether packets meet the requirements of the relevant protocol RFCs.

The protocols that can be analyzed include:

•DNS •RIP

•FTP •RPC

•Finger •SIP

• H.225 and H.245 • SMB

•HTTP •SNMP

•ICMP •Telnet

• MGCP

SNMP Trap Module

The SNMP Trap Module configures the parameters used by the Network Sensor when it sends SNMP traps to SNMP servers. When the sensor creates an SNMP trap, it can select a particular IP address to show up in the SNMP record. This IP address can be different from the interface from which the sensor sends the SNMP traps, which is useful if a particular IP address is required for recognition.

TCP State Module

TCP State Module is a connection tracking mechanism that Enterasys IPS uses to flag packets that are not part of an established TCP session. This is particularly effective against certain attacks like “stick” and “snot” that use multiple acknowledgement packets that are not part of a session.

Some additional filtering is also applied to UDP and ICMP (for example, an orphaned ICMP port unreachable message), but because these are connectionless protocols, the most comprehensive connection filtering capability is for TCP.

Transport Layer Module

The Transport Layer Module is one of the default and required modules that must be included in a Network Sensor policy. This module contains 10 tabs for configuring Transport Layer logging and event generation options.

• The General Settings tab allows you to tell the sensor to:

– Log any TCP or UDP packet with a source or destination port of zero. Such packets may

be the result of NAT devices, busy DNS servers, and a variety of hacker scanning and probing attacks.

– Verify the integrity of inbound TCP packets by calculating their checksum and comparing

it to the value in the packet. If a discrepancy is discovered, the packet is dropped. You can also log such events.

– Analyze all of the data in captured SYN packets for non-zero bytes and generate an event

when such packets are identified.

1-8 Network Sensor Overview

Network Sensor Signatures

– Look for any packet that has a zero length TCP option or a post EOL TCP option and

generate an event when such packets are identified.

– Identify SYN attacks and generate an event.

• The Stream Rebuilding tab settings tell the Network Sensor which traffic flows should be reconstructed. You can reconstruct UDP and TCP sessions for all types of traffic.

• The Flags tab allows you to configure the sensor to look for a variety of unusual TCP flag combinations in order to detect a variety of TCP flag probes (for example, Fin-Syn scanning, remote OS detection). The Flags tab provides pre-configured combinations, and you can also configure your own flag combinations.

• You can use the Log Syn tab to configure rules that tell the sensor whether to log or ignore SYN packets (initial TCP session requests) to specific destination IP addresses or networks, and destination ports.

• The Log Session tab allows you to configure rules to tell the Network Sensor to log or ignore specific network sessions such as Telnet or FTP, based on the IP address of interest, and the target UDP or TCP ports.

• The Log Start Stop tab settings tell the sensor to log or ignore TCP session starts and stops. You can also dynamically define the number of additional packets to log when these alerts start.

• The Log Destination tab can be used to tell the sensor to log or ignore traffic attempting to reach nonexistent hosts on the protected network. This type of activity could indicate a probe or an incorrect service configuration.

• The Log Server tab settings help find illegal TCP services by looking for SYN-ACK packets coming from protected hosts. You can also dynamically define the number of additional packets to log when these alerts start.

• To search all TCP Syn packets for a specific pattern, use the Log SYNPattern tab to create rules that specify a list of event names and data patterns to look for in each SYN packet that has a data payload.

Network Sensor Signatures

The Network Sensor has a powerful signature recognition engine that can quickly process a packet or network session for suspicious data strings in the data portion of packets. These suspicious data strings are defined in signatures, which are stored and read each time the Network Sensor is started.

When a signature data pattern is matched, the Network Sensor can drop the packet, send a transport layer error packet (a TCP reset for TCP connections or an ICMP port unreachable message for UDP traffic), and/or instantiate a persistent firewall blocking rule, in addition to generating an event.

Enterasys IPS ships with a comprehensive set of vulnerability and exploit-based signatures, and Enterasys continually provides signature updates with the Dragon Live Update feature. (Refer to the discussion of Live Update in the Configuration Guide for more information.)

The predefined signatures are organized in Master Libraries, which can be viewed from the Signature Libraries tab in the Network Policy View, as shown in Figure 1-3 on page 1-10.

You can assign Master Libraries directly to a virtual Network Sensor, or you can create your own custom signatures and signature libraries and assign them to a sensor, as described in Chapter 3,

Creating Network Sensor Signatures.

Creating Network Sensor Policies and Signatures 1-9

Network Sensor Signatures

Figure 1-3 Master Signature Libraries

Signature Libraries and Event Groups

The predefined signatures shipped with Enterasys IPS are organized into Master Libraries based on the signature’s function. When an event is generated as a result of a signature match, the event is named with the name of the signature. For example, if the signature AFS:OVERFLOWTCPDUMP (from the ATTACKS Master Library) is matched, an event named AFS:OVERFLOWTCPDUMP is generated.

In the Enterasys IPS Realtime reporting tools, generated events are organized by Event Groups, which have the same names as the Master Libraries. So for example, an AFS:OVERFLOWTCPDUMP event will be associated with the ATTACKS Event Group. You can use Event Groups as one way to filter event reporting.

When you create your own custom signature libraries and custom signatures, the events generated when your custom signatures are matched will be named with the name of your custom signature and will be assigned to the event group specified during signature configuration.

The following sections describe the type of signatures contained in the predefined Master Libraries, and therefore, the types of events grouped under the equivalent Event Groups in the Enterasys IPS Realtime reporting tools.

1-10 Network Sensor Overview

Network Sensor Signatures

Event Group Descriptions

This section describes all of the Enterasys IPS Event Groups. You may also create your own custom Event Groups. Creating your own custom Event Groups is described in Chapter 3,

Creating Network Sensor Signatures.

Applications (APPS)

This category contains signatures for applications that are not suspicious or a form of misuse. A signature may be placed in APPS if it is traffic that does not fit into MISUSE or SUSPICIOUS, because the applications themselves are normally used in business (unlike P2P clients and other apps).

ATTACKS

An ATTACK is an event that is most commonly generated from a potential “attacker” and is destined to one or more “victims” (that is, in TCP, the establisher of a connection). The results of an ATTACK may not always result in remote access to the end host. However, it will always have the potential to compromise the integrity of the end system. This could come in the form of (but not limited to) data leakage or modification, access loss (DoS), or actual remote access.

What doesn't belong there:

Any string that can be transmitted or seen in legal/normal traffic.

BETA

This category is used mostly for the converted signature set, but also contains any signature that has been tested with Enterasys IPS, but not tested for all environments. Any signature of this type is placed in this classification for a short time for customers to test.

COMPROMISE

A COMPROMISE is an event which generally comes from a “victim” to one or more potential “attackers.” Events in this category will be the direct result of something that would/should be in any of the other categories, except VIRUS.

What doesn't belong there:

Any string that can be transmitted or seen in legal/normal traffic.

DYNAMIC

This category is for follow-on signatures, which are signatures that are applied to packets captured as a result of another signature match.

FAILURES

This category is for signatures that detect errors sent from one host to another indicating that a particular request could not be fulfilled.

LEGACY

Since signatures are never deleted, this category contains signatures that have been deprecated for some reason.This category also includes old signatures that are false positive prone (for example, maybe the application is no longer used). The signatures are kept in this category for historical reference.

Creating Network Sensor Policies and Signatures 1-11

Network Sensor Signatures

MALWARE

This category contains signatures to detect traffic specific to malware, that does not belong in the TROJAN, SUSPICIOUS or VIRUS categories. Examples include 180solutions and HotBar, where user-agents and setting updates are tracked.

MISUSE

This category contains signatures that detect anything that does not directly compromise the integrity of a host, but is typically forbidden by corporate policy for legal/security reasons. This type of traffic includes such things as, for example, chat, porn, or job searching.

What doesn't belong there:

Things that are against most corporate security policies like system management applications (for example, PC Anywhere), or data hiding and encryption channels, or anything else that typically requires additional analysis (anything that might belong in SUSPCIOUS).

MISUSE-P2P

This category contains signatures that detect the use of peer-to-peer software, for example, file sharing networks such as Limewire, Gnutella, or Napster.

NETWORK

This category was created for network applications and signatures that detect their traffic.

PROBE

A PROBE is generally a characteristic of a scanner of some kind. For example, seeing “Host: Nessus” in a web request would point to someone running a probe against you.

What doesn't belong there:

A PROBE is not related to the target application/service itself. For instance, AnyForm is an application that has not be updated in many years and has many vulnerabilities. It is typically probed for by automated scanners, but this still does not make its presence in a request a probe. Its presence is indeed suspicious, but requires further analysis to determine its true reason for being there. For this reason, an event like that would be placed in the SUSPICIOUS category.

SCADA

This category contains signatures that are related to Supervisory Control And Data Acquisition (SCADA) networks. This includes any type of infrastructure processes.

STANDARD-IPS

This category contains signatures that have low rates of false-positives, and can be trusted to be run inline, that is, in IPS mode instead of IDS mode.

SUSPICIOUS

Many events in this category will be attacks, but their presence is not 100% indicative of an attack. This category is comprised of events that do have the chance of occurring naturally and legally in traffic. These events require a bit more analysis to ensure they are positive alarms.

What doesn't belong there:

Anything that can go into another category with 100% certainty (or close to it). For example, a bunch of NOOPs followed by shellcode and /bin/sh in Telnet traffic is definitely an ATTACK.

1-12 Network Sensor Overview

Network Sensor Signatures

TROJAN

This category contains signatures that detect any indication of a back channel actually being set up, or of someone remotely accessing a system. Back Orifice and NetBus channels are example of such traffic.

VIRUS

This category contains signatures that detect any program that automatically propagates itself and carries a Trojan or system logs as its payload. The key differentiator between this category and other likely categories is that the program tries to spread and infect other hosts in the process, all automatically.

What doesn't belong there:

Not the actual sending of a log back to an attacker, or someone trying to access a Trojan/backdoor that was installed by a virus. Most of that type of activity is ATTACK, SUSPICIOUS, or COMPROMISE activity. Also, viruses that do not carry a backdoor or send out sensitive information are typically not looked for by Enterasys IPS, as virus scanners are much more adept at finding this behavior.

VOIP

The VOIP category is for signatures that trigger on any of the VoIP protocols. The VoIP decoders (see the “Configuring the Protocol Analysis Module” on page 2-50) also generate events, which are referenced in the Realtime console by this category.

VULNERABILITY

These signatures are passive in nature. These are systems on the network that could leave you open to attack. For example, telnet sessions to routers where a password is not required, or old servers that are riddled with vulnerabilities like outdated sendmail servers. These signatures are just looking for banners indicating that one of these systems are on your network, not that someone has tried to attack it.

What doesn't belong there:

Any activity related to someone trying to gain access to a system. Someone sending a NULL password is not a VULNERABILITY. The fact that a router let the person log on with a NULL password is a VULNERABILITY.

WEB-APPLICATION-ATTACK

These signatures refer to any type of web application attack, which includes web servers, and any type of attack that does not fit in the other web categories.

WEB-BROWSER-ATTACK

Signatures detecting any attack against a web browser, such as Internet Explorer, Mozilla (including Firefox), Opera, and Lynx, are placed in this category.

WEB-FILE-INCLUDE

These signatures refer mostly to PHP applications that are vulnerable to remote-file include vulnerabilities.

WEB-SQL-ATTACK

These signatures include any type of web attack that is a form of SQL injection.

Creating Network Sensor Policies and Signatures 1-13

Configuring Port Macros

WEB-XSS-ATTACK

Signatures for Cross-Site Scripting (XSS) attacks are placed in this category.

Basic and Extended Signatures

The Enterasys IPS signature language was extended with the v7.2 release to include a number of new features such as full Perl-compatible regular expression support, communication of state information across signatures, per-signature thresholding, enhanced packet header tests, as well as additional Network Layer, Transport Layer, and Application Layer properties. A new tab containing the “Extended” signature properties was added to the Signature Property Settings window, and a number of extended master signatures have been added to the Master Libraries. However, the majority of master signatures remain “Basic” signatures.

Enterasys IPS firmware versions previous to v7.2 cannot use extended signatures, but they can use basic signatures.

Note: If you want to change an existing basic signature with a basic pattern to an extended signature, you must first remove the basic pattern(s), then create the extended pattern(s).

Configuring Port Macros

Port macros define complex ranges of ports, providing a simple way to apply a policy module or signature across several ports or a complex range of ports. Port macros can be configured using the Default Network Sensor Setting on the Network Policies tab in the Network Policy View. You can then assign them by name in a Network Sensor module or signature.

Enterasys IPS provides a number of predefined macros, listed in Tab le 1-1. You can also define your own macros or add to or edit the existing macros.

Table 1-1 Pre-defined Macros

Macro Description

W web; search for traffic on ports 80, and 3128 and 8080 (common proxy ports)

B not web; NOOP overflows, ignore port 80

U compromise; search for UNIX keywords on ports 22, 53, 143,443, and 2049

N compromise; search for NT keywords on ports 23, 53, 80, 135, and 139

X X Windows; search for X Windows events on ports 6000 – 6070

H high ports; search traffic above port 1023

L low ports; search traffic equal to or below 1023

A any ports; search traffic above port 0

M net manage; search SNMP traffic to 161 and between 32771 – 32800 (RPC/Solaris)

Q search traffic going to/ from ports in the range 27900 through 27999

R rpc; search RPC traffic

S ssh abuse; search for SSH servers not on port 22

T telconvert; used by TELCONVERT to specify ports to decode telnet options

P misuse; search FTP/web/NNTP for unwanted activities

1-14 Network Sensor Overview

Table 1-1 Pre-defined Macros (continued)

H-UDP-FILTER Searches for P2P traffic between hosts infected with the Conficker worm.

Procedure

To configure port macros:

1. Click the Network Policy View icon, and then on the Network Policies tab.

2. Click Default Network Sensor Settings.

Configuring Port Macros

Macro Description

MSRPC Searches for all traffic related to the Microsoft Remote Procedure Call on Ports 135,

137-139, 445, and 1024-5000.

SMB Searches for all Server Message Block traffic on ports 134, 445, and 137-139.

The display area is populated with port macro settings. Existing port macros are listed.

3. Click New to create a new port macro.

The Enter name dialog box appears requesting a port macro name.

4. Enter a name for the new port macro and click OK.

The new port macro name is listed in the Port Macros list.

5. Click the new port macro name, then click Add.

Creating Network Sensor Policies and Signatures 1-15

Configuring Port Macros

Field Description

What type of port do you want to add? The type of port you want to add to the macro:

The Add Port Information dialog box appears.

• Port — to add a single port

• Port Range — to add a port range, by specifying the low and

high port numbers

• Not Port — to specify a port that is not to be considered

• Not Port Range — to specify a port range that is not to be

considered

Port Port number or range of port numbers

Direction The direction of traffic:

• any — any direction

• toward — toward the protected network

• from — from the protected network

• internal — source and destination within the protected network

• external — source and destination outside the protected

network

6. Select the type of port you want to add to the macro

7. Specify the port number or range of port numbers.

8. Specify the direction of the traffic:

9. Click OK when done.

The port definitions are added to the Port Macro Information table for the macro being configured.

To remove a macro from the list of port macros, select the macro name and click the Remove button under the list of port macros.

To edit an existing macro, select the macro name in the Port Macros list, then select a row in the Port Macro Information table. Click the Edit or Remove button under the table.

1-16 Network Sensor Overview

Creating Network Sensor Policies

This chapter describes how to create and revise Network Sensor policies.

For information about... Refer to page...

Creating New Policies 2-1

Copying Existing Policies 2-3

Configuring the Application Filter Module 2-3

Configuring the Covert Channel Analysis Module 2-20

Configuring the DoS Check Module 2-22

Configuring the Dragon Filter Module 2-24

Configuring the Dynamic Module 2-28

Configuring the Header Search Module 2-29

Configuring the Logging Module 2-31

Configuring the Network Layer Module 2-33

Configuring the Probe Detection Module 2-47

Configuring the Protocol Analysis Module 2-50

Configuring the SNMP Trap Module 2-88

Configuring the TCP State Module 2-89

Configuring the Transport Layer Module 2-91

Creating New Policies

A Network Sensor policy is composed of modules, each of which provides the parameters to define a virtual sensor’s behavior relative to a logical grouping of sensor tasks. You create a new policy by adding the desired modules from the list of master modules provided by Enterasys, and then configuring the module parameters.

To create a new policy:

1. Click the Network Policy View icon, and then the Network Policies tab.

2. In the tree, right-click Custom Policies, and select Add Network Policy.

The Network Policy Configuration window appears.

Creating Network Sensor Policies and Signatures 2-1

Creating New Policies

3. Enter the name of the policy.

You can use any alphanumeric characters. Each policy must have a unique name.

4. Click OK.

The policy is added to the tree under Custom Policies, and required modules are listed below it.

5. Right-click the new policy’s name to add other modules. The Network Module Creation/Deletion window appears.

The available modules not yet added to the policy are listed in the left pane, and the required modules are listed in the right pane.

6. To add a module to the policy, highlight the module and click the arrow to move it to the Current Configuration Objects column.

To delete a module from the policy, highlight the module and click the arrow to move it to the Available Configuration Objects column.

7. Click OK when you are finished adding modules to the new policy.

2-2 Creating Network Sensor Policies

Copying Existing Policies

You can copy any custom or master policy and then paste it as a new custom policy. You cannot paste custom policies into the Master Policies node.

To copy a policy:

1. Click the Network Policy View icon, and then the Network Policies tab.

2. Right-click a policy and highlight Copy.

3. Right-click Custom Policies and highlight Paste.

A window appears asking you to provide a name for the policy.

4. Enter the name of the policy.

You can enter any alphanumeric characters. Every policy must have a unique name.

5. Click OK.

The policy is added to the tree under Custom Policies.

You can modify all module settings by clicking on the module name. Information about configuring policy module parameters is provided in the following sections.

Configuring the Application Filter Module

Copying Existing Policies

This module defines traffic criteria that can be ignored by the sensor. Use this module to refine the data that the sensor analyzes, by telling the sensor what types of traffic and packets to ignore. By reducing the amount of data that the sensor has to look at, and therefore the number of events generated, you can often improve the performance of the sensor as well as the analysis process.

The Application Filter Module has eight tabs, described in the following sections.

For information about... Refer to page...

General Settings Tab 2-4

IP Settings Tab 2-6

Port Settings Tab 2-8

Protocol Settings Tab 2-11

VLAN Settings Tab 2-13

Probe Settings Tab 2-14

Rule Settings Tab 2-16

Signature Settings Tab 2-18

Creating Network Sensor Policies and Signatures 2-3

Configuring the Application Filter Module

General Settings Tab

Use the settings on the General Settings tab to configure the sensor to ignore traffic based on direction with respect to the sensor’s protected network.

The sensor can ignore traffic that is:

• Entirely within the protected network (both source and destination addresses inside protected network)

• Entirely external to the protected network (both source and destination addresses outside of protected network)

• From the protected network (only source address within protected network)

• To the protected network (only destination address within protected network)

You can potentially improve performance by watching only the traffic that is coming into or out of your protected networks and ignoring internal traffic. For example, if you have a lot of internal network traffic such as NFS, Microsoft file sharing, or internal DNS lookups, then ignoring internal traffic will result in a noticeable performance increase. With Linux, the performance increase will result from Enterasys IPS’s quick decision to drop internal packets.

Ignoring all entirely external packets to the protected networks allows the Network Sensor to concentrate only on packets that involve the protected network in some way.

Ignoring all packets sourced within the protected networks and destined for IP addresses not in the protected networks allows the sensor to concentrate on packets entering the set of protected network ranges.

Ignoring all packets with a destination IP address in the protected networks and a source IP address not in the protected networks allows the sensor to concentrate on packets leaving the set of protected ranges.

Procedure

To configure general settings:

1. Click the Network Policy View icon, and then the Network Policies tab.

2. Expand the tree by clicking on the expansion symbol, then select the custom policy name.

The modules for that policy are displayed in the tree.

3. Click the Application Filter Module in the tree. The Application Filter Module settings display in the right pane.

2-4 Creating Network Sensor Policies

Configuring the Application Filter Module

4. Click the General Settings tab.

5. Check the desired checkbox(es). The Traffic Direction Chart provides a visual representation of the traffic that will be ignored.

• Ignore External Traffic: To ignore traffic entirely external to the protected network (both

source and destination addresses outside of protected network)

• Ignore Internal Traffic: To ignore traffic entirely within the protected network (both

source and destination addresses inside protected network)

• Ignore From Traffic: To ignore traffic from the protected network (only source address

within protected network)

• Ignore To Traffic: To ignore traffic to the protected network (only destination address

within protected network)

6. Click Commit to commit your changes to the policy being configured.

Example

To ignore traffic that is entirely external to the protected network and traffic from the protected network destined for external addresses, you would add the following settings to the General Settings tab:

Creating Network Sensor Policies and Signatures 2-5

Configuring the Application Filter Module

IP Settings Tab

Use the settings on the IP Settings tab to configure the sensor to ignore traffic with a set of IP addresses or specific networks as the source address, the destination address, or both source and destination address.

Procedure

To configure IP settings:

1. Click the Network Policy View icon, and then the Network Policies tab.

2. Expand the tree by clicking on the expansion symbol, and then select the custom policy name.

The modules for that policy are displayed in the tree.

3. Click the Application Filter Module in the tree.

4. Click the IP Settings tab.

5. Click Add to invoke the Ignored IP Address Settings window. Or, click Edit All to display the Edit All Ignored IP text editing window.

6. In the IP Address (CIDR) field, enter a specific IP address or network and mask that you want to ignore using the following format:

Select the appropriate IP version checkbox. Network masks can range from 0-32 for IPv4 and 0-128 for IPv6.

7. Specify the Direction of the traffic to ignore:

– any: Ignores traffic if the IP address is the source or destination.

– source: Ignores traffic if the IP address is the source.

– destination: Ignores traffic if the IP address is the destination.

– both: Ignores traffic if the IP address is the source and destination.

8. Click OK. The values are displayed in the Ignored IP Addresses table.

2-6 Creating Network Sensor Policies

Configuring the Application Filter Module

9. To edit an IP address setting, select the IP address in the table and click Edit or Edit All. If you select Edit All, you can edit all the ignored IP addresses at once in the Edit All Ignored IP text editing window.

10. Click Commit to add your changes to the policy being configured.

Example

To ignore traffic to and from the network 192.168.1.0/24, you would add the following settings to the IP Settings tab:

Creating Network Sensor Policies and Signatures 2-7

Configuring the Application Filter Module

Port Settings Tab

Use the settings on the Port Settings tab to tell the sensor to ignore traffic with specific TCP or UDP port numbers or ranges of port numbers as the source port, the destination port, or both source and destination ports.

The following table provides common port numbers. The original source for this information was

http://www.iana.org.

Table 2-1 Common Port Numbers

Protocol Port Number/Type Description

ftp-data 20/tcp File Transfer [Default Data]

ftp 21/tcp File Transfer [Control]

ssh 22/tcp SSH Remote Login Protocol

ssh 22/udp SSH Remote Login Protocol

telnet 23/tcp Telnet

smtp 25/tcp Simple Mail Transfer

domain 53/tcp Domain Name Server

domain 53/udp Domain Name Server

finger 79/tcp Finger

finger 79/udp Finger

http 80/tcp World Wide Web HTTP

pop2 109/tcp Post Office Protocol - Version 2

pop2 109/udp Post Office Protocol - Version 2

pop3 110/tcp Post Office Protocol - Version 3

pop3 110/udp Post Office Protocol - Version 3

sunrpc 111/tcp SUN Remote Procedure Call

sunrpc 111/udp SUN Remote Procedure Call

ident 13/tcp

nntp 119/tcp Network News Transfer Protocol

nntp 119/udp Network News Transfer Protocol

netbios-ns 137/tcp NETBIOS Name Service

netbios-ns 137/udp NETBIOS Name Service

netbios-dgm 138/tcp NETBIOS Datagram Service

netbios-dgm 138/udp NETBIOS Datagram Service

netbios-ssn 139/tcp NETBIOS Session Service

netbios-ssn 139/udp NETBIOS Session Service

imap 143/tcp Internet Message Access Protocol

imap 143/udp Internet Message Access Protocol

2-8 Creating Network Sensor Policies

Configuring the Application Filter Module

Table 2-1 Common Port Numbers (continued)

Protocol Port Number/Type Description

snmp 161/udp SNMP

snmptrap 162/tcp SNMPTRAP

snmptrap 162/udp SNMPTRAP

https 443/tcp http protocol over TLS/SSL

https 443/udp http protocol over TLS/SSL

exec 512/tcp remote process execution

who 513/udp maintains data bases showing who's

shell 514/tcp cmd

syslog 514/udp

printer 515/tcp spooler

socks 1080/tcp Socks

socks 1080/udp Socks

nfs 2049/tcp Network File System - Sun Microsystems

nfs 2049/udp Network File System - Sun Microsystems

mysql 3306/tcp MySQL

mysql 3306/udp MySQL

Procedure

To configure the sensor to ignore traffic based on TCP and UDP port number and direction:

1. Click the Network Policy View icon, and then the Network Policies tab.

2. Expand the tree by clicking on the expansion symbol, and then select the custom policy name.

The modules for that policy are displayed in the tree.

3. Click the Application Filter Module in the tree.

Creating Network Sensor Policies and Signatures 2-9

Configuring the Application Filter Module

4. Click the Port Settings tab.

5. To configure an Ignored Port or an Ignored Port Range, click the Add button located below the appropriate table.

Or, alternatively, you can click the Edit All button to display the Edit All Ignored Ports text editing window and enter the desired port information as text strings.

6. Enter the number of a specific port to ignore, or the numbers of the beginning and end ports in a range of ports to ignore. Port numbers can range from 1 to 65535. Refer to Tabl e 2 -1 on page 2-8 for a list of common port numbers.

7. Specify the Direction of the traffic to ignore:

– any: Ignore the traffic if the port is the source or destination port.

– source: Ignore the traffic if the port is the source port.

– destination: Ignore the traffic if the port is the destination port.

– both: Ignore the traffic if the port is the source and destination port.

8. Click OK. The values are displayed in the table.

9. Click Commit to add your changes to the policy being configured.

2-10 Creating Network Sensor Policies

Example

To ignore all FTP traffic, both data packets (port 20) and control packets (port 21) whether the port is the source or destination (any), you would add the following settings to the Port Settings tab.

Protocol Settings Tab

Use the Protocol Settings tab to tell the sensor to ignore traffic related to specific protocols, identified by number.

The following table lists common protocols and their associated values. The original source for this information was http://www.iana.org.

Table 2-2 Protocol Numbers

Number Protocol Description

Configuring the Application Filter Module

1 ICMP Internet Control Message [RFC792]

2 IGMP Internet Group Management [RFC1112]

3 GGP Gateway-to-Gateway [RFC823]

4 IP IP in IP (encapsulation) [RFC2003]

6 TCP Transport Control Protocol

8 EGP Exterior Gateway Protocol [RFC888,DLM1]

9 IGP any private interior gateway [IANA]

17 UDP User Datagram [RFC768,JBP]

45 IDRP Inter-Domain Routing Protocol [Sue Hares]

46 RSVP Reservation Protocol [Bob Braden]

47 GRE General Routing Encapsulation [Tony Li]

53 SWIPE IP with Encryption [JI6]

55 MOBILE IP Mobility [Perkins]

57 SKIP SKIP [Markson]

88 EIGRP EIGRP [CISCO,GXS]

94 IPIP IP-within-IP Encapsulation Protocol [JI6]

115 L2TP Layer Two Tunneling Protocol [Aboba]

Creating Network Sensor Policies and Signatures 2-11

Configuring the Application Filter Module

Procedure

To configure the sensor to ignore traffic based on specific protocols:

1. Click the Network Policy View icon and the Network Policies tab.

2. Expand the tree by clicking the expansion symbol, and then select the custom policy name.

The modules for that policy are displayed in the tree.

3. Click the Application Filter Module in the tree.

4. Click the Protocol Settings tab.

5. Click Add.

6. Select the protocol to ignore from the Protocol drop-down list. Protocol numbers can range from 1 to 255. Refer to Table 2-2 on page 2-11 for a list of common protocols.

7. Click OK. The ignored protocol is listed in the table.

8. Click Commit to add your changes to the policy being configured.

Example

To ignore all IGMP (multicast) traffic, you would add the following settings to the Protocol Settings tab. Note that the EMS adds the name of the protocol to the Ignored Protocols table, even though you entered only the protocol number.

2-12 Creating Network Sensor Policies

VLAN Settings Tab

The sensor can ignore traffic belonging to a specific VLAN or range of VLAN numbers.

Procedure

To configure the sensor to ignore specific VLAN traffic:

1. Click the Network Policy View icon and the Network Policies tab.

2. Expand the tree by clicking the expansion symbol, and then select the custom policy name.

The modules for that policy are displayed in the tree.

3. Click the Application Filter Module in the tree.

4. Click the VLAN Settings tab.

Configuring the Application Filter Module

5. To configure an Ignored VLAN or Ignored VLAN Range, click Add located below the appropriate table.

6. Enter either a VLAN number or the beginning and ending VLAN numbers of a range of VLANs.

7. Click OK. The VLAN Tag and/or the VLAN Range is listed in the appropriate table.

8. Click Commit to add your changes to the policy being configured.

Creating Network Sensor Policies and Signatures 2-13

Configuring the Application Filter Module

Example

To ignore traffic tagged for VLANs 100 through 110, you would add the following settings to the VLAN Settings tab:

Probe Settings Tab

If the Probe Detection Module (Configuring the Probe Detection Module on page 2-47) is included in the policy being configured, and probe detection is enabled, you can refine probe detection operation using the settings in the Probe Settings tab.

Note: In the context of Enterasys IPS, probe detection means detection of port scans and port sweeps. It does not include any application layer tests.

The sensor can be told to ignore traffic from legitimate port scanning applications, such as network vulnerability scanners and NAC (network access control) tools, network management and monitoring tools, such as What’s Up Gold, as well as traffic that looks like a port scan or sweep but is not, such as web server responses to web browser requests sent from multiple local source ports.

In order to ignore such traffic, you configure an IP address or CIDR block that defines the source of the traffic to ignore and the destination port that should be ignored. Enterasys IPS ignores both the UDP and TCP ports of that number. Return traffic from these sites is also ignored for port scanning purposes.

Procedure

To configure the sensor to ignore traffic that looks like a port scan or port sweep:

1. Click the Network Policy View icon, and then the Network Policies tab.

2. Expand the tree by clicking on the expansion symbol, and then select the custom policy name.

The modules for that policy are displayed in the tree.

3. Click the Application Filter Module in the tree.

4. Click the Probe Settings tab.

5. Click Add and enter the following information in the Ignored Probe Settings window:

– IP Address (CIDR): Enter a specific IP address or network and mask that you want to

ignore using the following format:

Select the appropriate IP version checkbox. Network masks can range from 0-32 for IPv4 and 0-128 for IPv6.

2-14 Creating Network Sensor Policies

Configuring the Application Filter Module

– Port: Enter the destination port number that you want to ignore. Port numbers can range

from 1 to 65535. To ignore all destination ports, enter 0.

Alternatively, click the Edit All button to display the Edit All Probes text editing window and enter the probe information as text strings.

6. Click OK. The values are displayed in the table.

7. Click Commit to add your changes to the policy being configured.

Example

If you wanted to ignore all traffic from 1.1.2.100 to any web server (port 80) and to any SNMP devices (port 161), you would add the following information to the Probe Settings tab.

Creating Network Sensor Policies and Signatures 2-15

Configuring the Application Filter Module

Editing Existing Probe Settings

• To edit a single probe setting, highlight the ignored probe and click Edit. The probe is displayed in the Ignored Probe Settings dialog box. Click OK when done.

• To edit multiple probe settings, click Edit All. All probes listed in the table are displayed in the Edit All Probes text editor. Click OK when done.

Rule Settings Tab

The sensor can ignore specific traffic based on a combination of IP address, port, and protocol settings. To configure such a rule, you specify the source and destination IP addresses and UDP or TCP port numbers and the IP protocol, by number. Zero can be used to represent any port or protocol. The IP addresses can identify specific hosts or sub-networks to ignore. An IP address of

0.0.0.0 can be used to represent any IP address.

Procedure

To configure the sensor to ignore traffic with specific IP address, port, and protocol attributes:

1. Click the Network Policy View icon, and then the Network Policies tab.

2. Expand the tree by clicking the expansion symbol, and then select the custom policy name.

The modules for that policy are displayed in the tree.

3. Click the Application Filter Module in the tree.

4. Click the Rule Settings tab.

5. Click Add and enter the following information:

• Source IP Address (CIDR): Enter a specific source IP address or network and mask that

you want to ignore using the following format:

Select the appropriate IP version checkbox. Network masks can range from 0-32 for IPv4 and 0-128 for IPv6.

• Source Port: Enter the number of a specific source port to ignore. Port numbers can range

from 1 to 65535. Enter 0 to specify any port. Refer to Tab le 2-1 on page 2-8 for a list of common port numbers.

2-16 Creating Network Sensor Policies

Configuring the Application Filter Module

If you select ICMP in the Protocol field, enter the appropriate ICMP type in the Source Port field.

• Destination IP Address (CIDR): Enter a specific destination IP address or network and

mask that you want to ignore using the following format:

Select the appropriate IP version checkbox. Network masks can range from 0-32 for IPv4 and 0-128 for IPv6. An IP address of 0.0.0.0 for IPv4 or :: for IPv6 can be used to represent any IP address.

• Destination Port: Enter the number of a specific destination port to ignore. Port numbers

can range from 1 to 65535. Enter 0 to specify any port. Refer to Table 2- 1 on page 2-8 for a list of common port numbers.

If you select ICMP in the Protocol field, enter the appropriate ICMP code in the Destination Port field.

• Protocol: Select the protocol to ignore from the drop-down list. Refer to Tab le 2-2 on

page 2-11 for a list of common protocol numbers. Use a 0 as a wildcard for any protocol.

Creating Network Sensor Policies and Signatures 2-17

Configuring the Application Filter Module

Alternatively, click Edit All to display the Edit All Ignored Rules text editing window and enter the rule information as text strings.

6. Click OK. The values are displayed in the table.

7. Click Commit to add your changes to the policy being configured.

Example

To ignore all local SNMP traffic, you would configure two ignore rules, as shown in the figure below. The first specifies that for protocol 17, UDP User Datagram, ignore any packets sent from any port (0) on any device in network 1.1.2.0/24 to port 161 (SNMP/UDP) on any destination device in network 1.1.2.0/24. The second specifies that for protocol 17, ignore any packets sent from port 161 on any device in network 1.1.2.0/24 to any port (0) on any destination device in network 1.1.2.0/24.

Signature Settings Tab

You can configure a virtual sensor to ignore specific signatures from all available signatures using the Signature Settings tab of the Application Module. When you configure the sensor to ignore a signature, no events will be generated when traffic matches that signature.

However, if you don’t want to ignore all the traffic that matches that signature, instead of writing an Application filter, you can write a Dragon filter to fine tune exactly what traffic that matches that signature can be ignored. Refer to “Configuring the Dragon Filter Module” on page 2-24 for more information.

2-18 Creating Network Sensor Policies

Configuring the Application Filter Module

Procedure

To configure a sensor to ignore a signature:

1. Click the Network Policy View icon, and then the Network Policies tab.

2. Expand the tree by clicking on the expansion symbol, and then select the custom policy name.

The modules for that policy are displayed in the tree.

3. Click the Application Filter Module in the tree.

4. Click the Signature Settings tab.

5. Click Add. The Signature Editor window displays.

6. To select a specific signature, expand the desired signature group, select the signature, and click Add--> to move it to the to Ignored Signatures column.

7. Click OK. The ignored signatures are listed in the table on the tab page.

8. Click Commit to add your changes to the policy being configured.

Creating Network Sensor Policies and Signatures 2-19

Configuring the Covert Channel Analysis Module

Example

If you wanted the virtual sensor to ignore the TEL:NT-GUEST and XOPEN:FAIL signatures from the FAILURES group, you would add them to the Ignored Signatures list in the Signatures Editor window, as shown in the figure below.

Configuring the Covert Channel Analysis Module

Many hackers use ICMP echo request and echo reply packets to communicate covertly. Specialized ICMP client and servers such as Back Orifice 2000 and LOKI are good examples. This module provides parameters to configure three types of ICMP traffic analysis.

Backdoor Settings

The backdoor parameters in this module enable discovery of streams of unsolicited ICMP replies or ICMP streams with static sequence numbers. You configure the total number of ICMP type 0 (ping reply) and type 8 (ping request) packets to collect, and the threshold, n, for generating an alert. If n more ping replies than ping requests have been collected, or if n ICMP replies with the same ICMP sequence number have been collected in a row, an alert is generated.

2-20 Creating Network Sensor Policies

Backdoor analysis uses two algorithms. The first algorithm collects the specified number of ICMP echo request and echo response packets, then compares the total number of echo requests with the number of echo responses. The numbers should match. If the numbers are off by the specified threshold, the collected traffic is analyzed further to determine which IP address is sending unsolicited echo response packets. The internal event generated is ICMP:BD-REPLY.

The second algorithm looks at all collected ICMP echo request and response pairs and looks for ICMP sequence numbers that do not change. Typically, ICMP ping packets increment their sequence number by one for each subsequent ping. Many hacker ICMP communication tools do not do this, including tools like Loki. The internal event generated is ICMP:BD-SEQ.

In all cases, the Network Sensor attempts to collect some of the ICMP packets in question after a suspect IP has been identified. Broken routers, bad routes and broken IP stacks can cause false positives for these alerts, and a manual inspection of the ICMP traffic is usually required.

Fast ICMP Settings

Fast ICMP analysis can indicate unusual patterns of ICMP traffic, the use of an ICMP backdoor, or an incoming ICMP flood. You configure the minimum number of ICMP packets required to make a Fast ICMP determination, and the Time modifier, in seconds. The configured minimum number of ICMP packets must be received within the configured time in order to generate an event.

The internal event generated is FAST-ICMP.

Configuring the Covert Channel Analysis Module

Enable Loki Check Setting

Loki is a tool used to communicate between a client and server using ICMP. Tools such as this are commonly used by hackers as covert channels to access systems they have broken into. Enable the Loki check to search ICMP echo response and echo request packets for evidence of Loki traffic.

The internal event generated is LOKI.

Procedure

To configure the sensor to perform ICMP traffic analysis:

1. Click the Network Policy View icon and the Network Policies tab.

2. Expand the tree by clicking the expansion symbols and select the custom policy name.

The modules for that policy are displayed in the tree.

Creating Network Sensor Policies and Signatures 2-21

Configuring the DoS Check Module

3. Click the Covert Channel Analysis Module in the tree.

4. If you do not want ICMP packet analysis performed, check the Disable Covert Analysis checkbox.

5. By default, checking ICMP echo request and echo response packets for evidence of Loki traffic is enabled. If you wish to disable these checks, deselect the Enable Loki Check checkbox.

6. If you want the sensor to perform Fast ICMP analysis, configure the following parameters:

• Fast ICMP Number: Enter the minimum number of ICMP packets that must be received

within the required time period in order to generate a FAST-ICMP event.

• Fast ICMP Time Mod: Enter the time period, in seconds, for making a Fast ICMP

determination.

7. If you want the sensor to perform Backdoor analysis, configure the following parameters:

• Backdoor Threshold: Enter the threshold for generating an ICMP:BD-REPLY event. If the

number of ICMP echo requests collected and the number of echo responses collected differ by at least this threshold amount, the event is generated.

• Backdoor Collection: Enter the number of ICMP packets that should be collected for

analysis. The maximum number is 2500 packets.

8. Click Commit to add your changes to the policy being configured.

Configuring the DoS Check Module

This module allows you to add Denial of Service checking to a Network Sensor policy. When Denial of Service checking is enabled, the Network Sensor searches packets for distinct trademarks of specific denial of service tools that are in use and freely available. The sensor will generate different DOS internal events, depending on the tool. If a Denial of Service attack is observed, the event data will contain the attack information.

2-22 Creating Network Sensor Policies

Configuring the DoS Check Module

The DoS check module implements two classes of tests for DoS/DDoS agents:

• Rate-based tests. For example, high rates of inbound SYN packets may indicate a SYN flood DoS.

• Packet header tests. For example, the “Bonk” DoS tool is detected through a specific IP ID value in the IP header along with a specific IP offset value.

The DoS check module can generate the following events, each of which describes a different DoS/DDoS tool or condition:

Table 2-3 DoS Check Module Events

Event DoS/DDoS Tool or Condition

[DOS-JOLT] icmp,jolt/win95ping

[DOS-MODEM] icmp,modem-attack

[DOS-1234] icmp,x1234

[DOS-JOLT2] icmp,jolt2

[DOS-BONK] udp,bonk

[DOS-BOINK] udp,boink

[DOS-TEARDROP] udp,teardrop/overdrop

[DOS-NEWTEAR] udp,newtear

[DOS-NESTEA] udp,nestea/nestea2

[DOS-OSHARE] udp,oshare

[DOS-SAIHYOUSEN] udp,SAIHYOUSEN

[DOS-SYNDROP] tcp,syndrop

[DOS-LAND] tcp,land/latiera

[DOS-TARGA] tcp,winnuke-targa

[DOS-WINNUKE] tcp,winnuke

[SYN-BOMB] target=%d.%d.%d.%d,%s,%s,%s

A list of Network Sensor internal events is available on the Dragon web site:

https://dragon.enterasys.com/downloads/docs/SensorInternalEvents.htm

Procedure

To configure Denial of Service checking:

1. Click the Network Policy View icon and the Network Policies tab.

2. Expand the tree by clicking the expansion symbols and select the custom policy name.

The modules for that policy are displayed in the tree.

Creating Network Sensor Policies and Signatures 2-23

Configuring the Dragon Filter Module

3. Click the DoS Check Module in the tree. The DoS Check settings are displayed.

4. Denial of Service checking is enabled by default. To disable it, deselect the Enable Denial of Service Check checkbox.

5. It is not recommended that you Enable Denial of Service Debugging unless requested to do so by Enterasys Technical Support. When enabled, debugging information is logged in the NetworkSensor.log.

6. Click Commit to add your changes to the policy being configured.

Configuring the Dragon Filter Module

You can use the Dragon Filter module to reduce the number of event false positives being reported by Enterasys IPS. Events generated by signatures, or internal events generated by network sensor policy settings, can be eliminated based on a combination of source and destination IP addresses, IP protocol, source and destination TCP/UDP ports, or ICMP type.

Before writing a Dragon filter, you will use the Enterasys IPS reporting tools to analyze the types of events being generated and to identify the events that should be filtered. For example, if you have an administration computer that uses SSH to login to other computers, you will see a large number of SSH events involving the administration computer being generated. Since these events can safely be ignored, you can write a filter for the relevant SSH signatures to ignore them.

From analyzing the SSH events reported, you may determine that both SSH version 1 and 2 protocols are used from the administration computer’s IP address of 10.10.100.100. You would then write two filters, one for the event SSH:VERSION-1 and another for SSH:VERSION-2, each of which would filter the event if the IP address 10.10.100.100 is either the source or destination IP address of the traffic.

2-24 Creating Network Sensor Policies

Writing a Filter Rule

A Dragon filter consists of an event name and filter rules, which are created using keywords and operators.

Event Names

Events generated by signatures have the same name as the signature. For example, events generated when traffic matches the signature named RLOGIN:ROOT will also be named RLOGIN:ROOT. The names and descriptions of internal events generated by policy settings are listed in the document Sensor Internal Events at this link:

https://dragon.enterasys.com/downloads/docs/SensorInternalEvents.htm

Keywords and Operators

The keywords used in Dragon filters are listed in Tabl e 2 -4:

Table 2-4 Dragon Filter Keywords

Keyword Example Description

host host 10.100.100.10 Will match Source IP and Destination IP

srchost srchost 10.100.100.1 Will only match the Source IP

Configuring the Dragon Filter Module

dsthost dsthost 10.100.100.205 Will only match the Destination IP

port port 1234 Will match both Source or Destination ports

srcport srcport 80 Will only match on the Source port

dstport dstport 6000 Will only match on the Destination port

net net 10.100.100.0/24 Will match on the specified CIDR block

srcnet srcnet 10.100.100.0/24 Will only match against the source IP

dstnet dstnet 10.100.100.0/24 Will only match against the destination IP

tcp tcp Will match the TCP protocol

udp udp Will match the UDP protocol

icmp icmp Will match the ICMP protocol

The operators used in Dragon filters include and, or, and not.

Keyword rules and operators can be nested, by using parentheses to define precedence order.

Usage Notes

Although the Dragon filters are very powerful, please note the following constraints:

• Precedence of multiple operators must be defined using parentheses. If more than one operator is used in a rule, any operators that are not nested will produce unpredictable results. See Examples of Dragon Filter Rules below for examples of precedence.

• Do not wrap atomic items with parentheses. For example, (net 10.0.0.0/8) is incorrect usage.

Creating Network Sensor Policies and Signatures 2-25

Configuring the Dragon Filter Module

• Only one filter can be created per event name.

• There is no upper limit on the number of filters that can be created.

Examples of Dragon Filter Rules

To filter SSH Version 1 and 2 events involving the IP address 10.100.100.100 as either the source or destination, two filters are required:

To filter FTP:USER-ROOT (FTP login as user = root) events if one of the IP addresses of the event is from the 10.200.200.0/24 CIDR block, but not if the source address is either 10.200.200.1 or

10.200.200.2, the filter would be:

To filter SSH Version 1 events involving IP addresses 10.100.100.100 and 10.100.100.25 as source or destination, or port 222 as source or destination, the filter would be:

Procedure

To configure a Dragon filter:

1. Click the Network Policy View icon and the Network Policies tab.

2. Expand the tree by clicking the expansion symbols and select the desired custom policy name.

3. Click the Dragon Filter Module in the tree.

The modules for that policy are displayed in the tree.

2-26 Creating Network Sensor Policies

4. Click New. The Dragon Filter Editor window is displayed.

Configuring the Dragon Filter Module

5. Enter the name of the event to be filtered in the Event Name: field (refer to “Event Names” on page 2-25) or click Browse to display the Event Chooser window and select from the displayed events.

6. Enter the filter rules in the Filter: field. (Refer to “Writing a Filter Rule” on page 2-25.)

7. Optionally, enter a brief description of the filter in the Description: field.

8. Click OK to add the new filter to the table.

9. When you are finished adding new filters, click Commit to add your changes to the policy being configured.

Editing Dragon Filters

• To edit a single Dragon filter, highlight the filter and click Edit. The filter is displayed in the Dragon Filter Editor box. Click OK when done.

• To edit multiple filters, click Edit All. All filters listed in the table are displayed in the Edit All Dragon Filters text editor. Click OK when done.

Creating Network Sensor Policies and Signatures 2-27

Configuring the Dynamic Module

Dynamic Logging enables the sensor to record packets from IP addresses that are involved in events. When an event occurs, the Network Sensor makes a best effort to grab subsequent packets from the source and destination IP addresses of the event packet. The number of recorded packets is determined by the specific alarm or signature. Additional amounts of Dynamic packet logging can be set for all events, by specifying the number of Cushion packets the Network Sensor should collect in addition to the normal number of packets specified by the signature or alarm.

For example, if a PHF attack signature has a Dynamic packet capture level of 10 packets and the Cushion value is set to 5 packets, the Network Sensor will attempt to collect 15 packets. This parameter is meant as an easy way to quickly turn up the sensitivity of a Network Sensor. The extra logging may have a negative impact on system performance or on Network Sensor hard drive space.

Procedure

To configure Dynamic logging:

1. Click the Network Policy View icon, and then the Network Policies tab.

2. Expand the tree by clicking the expansion symbol and selecting the custom policy name.

The modules for that policy are displayed in the tree.

3. Click the Dynamic Module in the tree.

The Dynamic Settings window is displayed.

4. Specify the Number of Cushion Packets the Network Sensor should collect in addition to the normal number of packets specified by the signature or alarm.

5. By default, the Enable Logging checkbox is selected. Deselect the checkbox to turn off Dynamic logging.

6. Click Commit to add your changes to the policy being configured.

2-28 Creating Network Sensor Policies

Configuring the Header Search Module

The Header Search module allows you to configure the Network Sensor to search IP (network layer) and TCP (transport layer) headers for a specific string of data. When you configure a Header Search rule, you identify:

• A start byte and a stop byte in the header of either IP or TCP traffic. These bytes specify the part of the header to check.

• The frequency, in packets, of the check. A frequency of 0 means check all packets.

• The pattern to search for.

• The name of the event to generate when the rule is matched.

For example, to search the entire IP header, a start byte of 0 and a stop byte of 20 would be used. If the stop byte is outside of the header (there may be options or padding in some cases), the rule does not match. If you wanted to search all IP packets with options looking for a particular string, you could use a start byte of 20 and an end byte of 30.

Note: With the introduction of extended signature language in Enterasys IPS v7.2, the preferred method of matching portions of network layer or transport layer headers is by means of a custom extended signature. Refer to “Creating Custom Signatures” on page 3-12 for more information.

Configuring the Header Search Module

Specifying Search Strings

The Network Sensor has several string definition features that allow for creation of powerful, yet efficient pattern searches. The most basic string definition is to simply type a string of letters and numbers without any spaces such as this:

This-is-a-test-string

To specify non-printable characters, you can use the ‘/’ (slash) character as an escape character to specify two alphanumeric values which represent a hex number. The hex ASCII code for ‘-’ is 0x2d which means that the above example could be represented like:

This/2dis/2da/2dtest/2dstring

To search for a ‘/’ character, use the hex value for ‘/’ which is 0x2f. Here is a string that searches for /cgi-bin/phf:

/2fcgi-bin/2fphf

You can use the 0x20 character to represent a space. The following example searches for “see spot run” followed by a new line:

see/20spot/20run/0a

Wild Cards

There are four available wild card characters—the question mark (?), the asterisk (*), the dollar sign ($), and the point sign (#). All wild cards represent a single byte that may be used to represent the following ranges:

? – Any byte

* – Any printable character (alpha-numeric, /n, /r, and so on)

$ – Any non-printable character (negative of printable character set)

# – Any number

Creating Network Sensor Policies and Signatures 2-29

Configuring the Header Search Module

Because these characters are used as wild cards, attempting to search for them in normal traffic requires that the corresponding hex escape code by used. The escape codes are:

? – 0x3f

* – 0x2a

$ – 0x24

# – 0x23

Procedure

To configure a Header Search rule:

1. Click the Network Policy View icon, and then the Network Policies tab.

2. Expand the tree by clicking the expansion symbol, and then select the custom policy name.

The modules for that policy are displayed in the tree.

3. Click the Header Search Module in the tree.

4. Click New to open the Header Search Editor.

5. Select the type of header, TCP or IP from the drop-down menu in the Protocol Type field.

6. Indicate the range (in bytes) of the search in the header portion of the packet by entering values in the Start and Stop fields. The Stop value should always be higher than the Start value. The upper bound for start and stop bytes is 254.

7. Specify the frequency of the check in the Frequency field. A frequency of 0 means check all packets. A frequency of 5 means check every five packets. The upper bound for frequency is

254.

8. In the Event Name field, specify the name of the event that should be generated when this header check rule is matched. You can specify any name you want for this event. The name can be any combination of characters, excluding spaces, up to a maximum of 28 characters.

Or, click the Browse button to display the Event Chooser window and select from the events displayed.

2-30 Creating Network Sensor Policies

9. In the Pattern field, specify the pattern, or search string, to be matched. Refer to “Specifying

10. Click OK. The values are displayed in the table.

11. Click Commit to add your changes to the policy being configured.

Example

The following example searches the entire IP header for the IP address 127.0.0.1 and generates an event named [SEARCH127] if that address is found. The entire header is specified by a Start value of 0 and a Stop value of 20. The Frequency value of 5 means search every five packets.

Configuring the Logging Module

Search Strings” on page 2-29 for information about how to create a search string.

Editing Header Search Rules

To edit an existing header search rule, highlight the rule and click Edit. The rule is displayed in the Header Search Editor. Click OK when done.

Configuring the Logging Module

The Logging Module is one of the default and required modules that must be included in a Network Sensor policy. This module defines where event logs are stored and how they are displayed.

By default, the Ring Buffer option is selected, which instructs the sensor to write to a shared memory ring buffer. This option should always be selected.

Creating Network Sensor Policies and Signatures 2-31

Configuring the Logging Module

Procedure

To configure event logging:

1. Click the Network Policy View icon, and then the Network Policies tab.

2. Expand the tree by clicking the expansion symbol and selecting the custom policy name.

The modules for that policy are displayed in the tree.

3. Click the Logging Module in the tree.

The display area shows the Logging Module Settings.

4. Leave the Ring Buffer option selected. This option configures the sensor to write to a shared memory ring buffer and is required for Enterasys IPS operation.

5. Selecting the Alarm Log File option configures the sensor to log events to a file in a “syslog” style format where one line is used for every recorded event. The log file name used is dragon.log and is stored in chronological directories in the /DB directory. For example: ~/DB/2007Nov02.

Note: When the Alarm Log File option is selected, in effect, each event is written twice, which may affect performance. All of the data that would be written to a dragon.log file is contained in the dragon.db file.

6. Selecting the Alarm Log Display option configures the sensor to send events to standard output for live monitoring.

7. Selecting the SysLog option configures the sensor to log output and debugging information to the system log rather than to standard output or a file.

8. Selecting the Local DB option allows full packet logging to the local file system.

9. Selecting the Swatch option forces the Alarm Log File option to log to a single file in the main directory. You can only select this option if you have already selected the Alarm Log File option.

10. The Repeat Tracking and Repeat Threshold options allow you to reduce the number of similar events being logged. When configured, the sensor will stop logging consecutive similar events from a single Source IP or Destination IP address after the specified threshold number has been reached. When the next different event occurs, the sensor will generate a final event, with an indication of the number of repeats that were not generated.

2-32 Creating Network Sensor Policies

Configuring the Network Layer Module

For example, if you enabled repeat tracking for source IP with a repeat threshold of 3, and many identical events were generated consecutively from the same source IP, only 3 of the events would be logged. As soon as a different event occurred after the threshold was met, a final event would be logged that reported the number of unlogged events, as shown in the following log example. In this case, 9 additional repeat events were not logged.

11:24:49 [F] 10.100.100.53 134.141.133.174 [SSH:VERSION-1] (tcp,sp=22,dp=36991) sensor1

11:24:52 [F] 10.100.100.53 134.141.133.174 [SSH:VERSION-1] (tcp,sp=22,dp=36992) sensor1

11:24:52 [F] 10.100.100.53 134.141.133.174 [SSH:VERSION-1] (tcp,sp=22,dp=36993) sensor1

11:25:23 [F] 10.100.100.53 134.141.133.174 [SSH:VERSION-1] (tcp,sp=22,dp=36992,repeat=9) sensor1

11:25:23 [T] 134.141.133.174 10.100.100.53 [WEB:NETSCAPE] (tcp,sp=37011,dp=80) sensor1

This option enhances performance by not logging similar events. It is very useful to prevent a network error, such as a bad router causing low TTL events, from filling up the Network Sensor logs.

A common setting for Repeat Threshold is between 100 and 500.

11. Click Commit to add your changes to the policy being configured.

Configuring the Network Layer Module

The Network Layer Module has six tabs, described in the following sections.

For information about...

General Settings Tab 2-34

Log Option Tab 2-39

Log Protocol Tab 2-41

Log Frag Tab 2-42

Log Static Tab 2-44

Log Broadcast Tab 2-46

Refer to page...

Creating Network Sensor Policies and Signatures 2-33

Configuring the Network Layer Module

General Settings Tab

The General Settings tab, with its Basic Settings and Advanced Settings sub-tabs, allow you to configure the sensor to perform the desired action when any packet header contains certain anomalous values. The Advanced Settings tab also allows you to configure certain fragment rebuilding parameters.

Procedure

To configure the basic and advanced general settings:

1. Click the Network Policy View icon, and then the Network Policies tab.

2. Expand the tree by clicking on the expansion symbol, and then select the custom policy name.

The modules for that policy are displayed in the tree.

3. Click the Network Layer Module in the tree.

4. Click the General Settings tab.

5. Click the Basic Settings tab.

6. You must select the Enable Network Layer Analysis option to enable Network Layer Analysis. This option is enabled by default.

7. Selecting Enable Debugging tells the sensor to output the current status of the network layer fragment reassembly algorithm and how it is rebuilding fragmented traffic. Do not enable this option unless told to do so by Enterasys Technical Support.

8. Selecting Check IP Options for Zero Length or EOL tells the sensor to look for any packets with IP options of zero length or post EOL (End Of Line) IP options. This option is selected by default.

There are non-compliant IP stacks in existence that make a variety of violations in normal everyday traffic. This means that this setting may result in many false positives. Some denial of service attacks exist for network devices that simply consist of post EOL IP options.

2-34 Creating Network Sensor Policies

Configuring the Network Layer Module

9. Selecting Log Localhost Traffic tells the sensor to log any packet with a source or destination address to or from 127.0.0.0/8. This address space is reserved. A variety of attacks choose their source addresses from this block. This option is selected by default.

Application Note for Ethernet Only: Because these packets are probably spoofed, the hardware

address is recorded for these packets for further analysis. Keep in mind that if a hacker has local layer 2 network access, they can spoof the source hardware address. However, if the attacker is remote, the hardware address can tell you where the attack is coming from on your network.

There is also a good chance that these events result from incorrectly configured routers. In this case, the hardware address is also useful in debugging these problems.

Many tools that use IP source address spoofing that choose from the range of 0.0.0.0 to

255.255.255.255 have a one in 256 chance of choosing an address in the 127.0.0.0/8 range. Tools like NMAP have this problem when they spoof decoy packets.

10. Selecting Log Same Source and Destination Address or Log Null Source or Destination Address tells the sensor to log packets with the same address as both source and destination and to log packets with a null value for source or destination address. These options are selected by default.

These types of packets could be an attack, a NAT problem, or a wide variety of other issues. Regardless, these events are interesting and recorded. For Ethernet sensors, the data portion of these events also includes the hardware address for further analysis. Most commonly, these events occur with poorly configured routers and multicast protocols. Keep in mind that denial of service attacks do not need to reply back to their source address, but most attacks do.

11. When you select Log Checksum Events, you also must enter a Checksum Verification Frequency. Selecting this option tells the sensor to validate the IP checksums of packets that are directed at the protected network. The frequency value indicates how often this test should be carried out. For example, a value of 5 indicates that the test should be carried out every 5th packet. This option is not selected by default.

Purposely crafted IP packets with bad checksums can fool packet-based IDS devices into accepting packets that a destination host would reject. Although the frequency value provides a statistical sampling technique designed to balance performance with IP checksum verification, in many cases, this option should not be enabled.

Modern routers drop any IP packets that do not have the correct checksums. In an Internet environment, it is very difficult for an attacker to send corrupted IP packets unless they are one hop away from the Network Sensor. This prevents Internet attackers from using this technique. However, insiders and attackers who have an intimate knowledge of your topology could exploit this. All of these factors (including the impact on performance) should be weighed when enabling or disabling this feature.

Creating Network Sensor Policies and Signatures 2-35

Configuring the Network Layer Module

12. Click the Advanced Settings pane.

13. Selecting Log Packets with Reserve Bit Turned On causes the sensor to log any IP packet with the reserved bit turned on. This bit is not used by IP networks, but is still part of the IP header. It is reserved for future use. Several years ago, many packet filters could be bypassed simply by enabling this bit. Old routers incorrectly treated this bit as part of the IP fragmentation offset field.

14. Selecting Log First Fragmented Packet enables the sensor to decode any TCP fragments with an IP fragment offset of zero. The fragment must contain enough information in the packet to obtain the source port, destination port and TCP flags.

Offsets of zero occur naturally on some networks, but also occur when hackers want to artificially create fragmented packets for Syn scanning, bypassing of firewalls, and other activities. Selecting this option tells the Network Sensor to record any of these packets and decode the source and destination port as well as the TCP flags. Basically, when TCP traffic is fragmented, this setting will attempt to log the beginning of the fragmented packet for further analysis. These events are labeled [FIRST-TCP-FRAG].

15. Selecting Log Frag TCP Flags Overlay enables the sensor to decode TCP packets with a fragment offset of 1.

Fragment offsets of 1 happen on some networks, but they are extremely rare. More likely they are artificial packets generated by a hacker. It is a technique used to bypass some firewalls and avoid port scanning detection. Using an offset of 1 creates packets that have source and destination ports in one packet, and the TCP flags in another. This confuses many network devices including firewalls and some intrusion detection systems. The Network Sensor will record the entire packet, and gather subsequent packets if Dynamic logging (See “Configuring

the Dynamic Module” on page 2-28) is enabled. However, if other portions of the fragmented

packet arrive first, it may not be recorded. These events are labeled [TCP-FRAG-OVERLAY].

This setting most commonly picks up on NMAP fragmented Syn scans where the TCP destination and source ports arrive in the first fragment, but the TCP flags arrive in the second packet. It also occurs when a remote attacker attempts to bypass a network IDS by artificially fragmenting their packets into smaller packets.

2-36 Creating Network Sensor Policies

Configuring the Network Layer Module

16. Specifying a Log <= TTL Value tells the sensor to log any packet with an IP time-to-live value less than or equal to the specified value. The default value is 0. A common value for the TTL value is 5. The maximum value is 10.

The intent of this option is to record traceroute packets as well as attempts to bypass intrusion detection systems with small TTL settings. When packets are logged, the protocol and ports are recorded.

The Network Sensor will report a [LOWTTL-UDP] or a [LOWTTL-TCP] event if the packet is UDP or TCP, less than the TTL value, and the destination port is less than 1024. This is to differentiate possible traceroute attempts to ports above 1024 with events names such as [TRACE-TCP] and [TRACE-UDP]. ICMP-based traceroute events are labeled [TRACE-ICMP]. Finally, unknown low TTL packets that are not UDP, TCP or ICMP are labeled [LOWTTL-UNKNOWN].

17. Specifying a value for Drop Packets with minimum TTL causes the Network Sensor to drop packets that destination machines may never receive, rather than try to reassemble them. If a Network Sensor is n hops in front of a protected network, the Network Sensor should ignore all packets with a TTL of n-1.

Topology can be used against packet-based IDS products. IP packets with low TTLs may not make it to their destination. If the Network Sensor is not aware of these topology constraints, it might attempt to reassemble packets that destination machines never even see.

18. When Enable Fragment Rebuild is selected, the Network Sensor attempts to rebuild all IP fragments that are traveling to the protected network. For performance reasons, the Network Sensor does not attempt to reassemble fragments from the protected network.

Fragments are reassembled when the total amount of data is equal to the packet length determined by the fragment without the more fragments (MF) bit set. When a pseudo-packet is rebuilt, it is injected into the Network Sensor packet processing engine for evaluation. If an event occurs with this packet, an extra event is also generated indicating that the packet was reconstructed. For packet analysis, these pseudo-packets have an IP checksum of zero, a TTL of 255 and an ID value of 0xffff. If an event occurred and was rebuilt from IP fragments, it will also include an event name of [FRAG-REBUILD] and message data of (this-event-was-reconstructed).

19. When Enable Large Fragment is selected, the Network Sensor alerts on any fragment offset larger than a fixed value of 565. Since fragment offsets are measured in units of 8 bytes, an event is generated for any fragment whose initial position in the original packet is larger than 4520 bytes. The value is currently set to be larger than a fragmented packet from an FDDI network.

20. The Fragment Rebuild Size determines the size of the data structure the Network Sensor devotes to the reassembly of packets that have been fragmented at the network layer. The values you can choose are:

– very-low — 503 bytes

– low — 1009 bytes (default)

– medium — 2003 bytes

– high — 3301 bytes

– very-high — 6007 bytes

– maximum — 10,007 bytes

Creating Network Sensor Policies and Signatures 2-37

Configuring the Network Layer Module

21. Specifying a value for Small Fragment Offset tells the Network Sensor to alert on any IP fragment offset that is larger than 0 but smaller than the specified byte length.

There are several tools available that will automatically fragment traffic for a hacker. Many of these tools generate fragments with small payloads. These payloads of 24, 16 or even 8 bytes seldom occur naturally. They are a good indication that someone may be performing a denial of service attack on your network or attempting to bypass a packet-based intrusion detection system. If the fragments are all of an offset of 1, this is a common signature of a fragmented port scan.

The offset value is specified in fragmented units, which means that a value of 1 translates to eight bytes. Values of 16 and 24 are good choices. The default value is 32.

22. Specifying a value for Max MTU Size (Bytes) (in bytes) tells the sensor to drop any IP packet to the protected network that has the don’t fragment (DF) bit set and is larger than this specified value. For example, suppose a Network Sensor is in front of a network segment with an MTU of 1300 bytes, possibly a VPN. If a packet destined for the WWW server shows up with a size of 1350 bytes and its don’t fragment bit set, the border device will drop the packet and probably issue an ICMP fragmentation needed message. If the sensor is not aware of this topology issue, it may incorrectly pick up that packet and become confused, especially if this packet was crafted to look like it was part of an ongoing attack session.

You should specify a value equal to the maximum segment size (MSS) of your network. Packets that are larger will require fragmentation. The default, and maximum, value is 1500 bytes.

23. Selecting the Log Max MTU Events option tells the sensor to log Max MTU events.

24. Selecting Favor Old tells the Network Sensor to favor old data when it receives overwriting data.

When IP fragments are reassembled, it is possible for a hacker to generate traffic that overwrites itself. Imagine a single packet split into two fragments. If a hacker sends the first fragment, followed by a fake first fragment, some operating systems will keep the original data while others will believe the second fake fragment. This discrepancy can be used to confuse a network sensor.

Windows NT and Solaris systems tend to keep the data in the first few packets and discard any overwriting data. Other systems, such as Linux, Irix, and HP-UX, favor new data. You can choose to favor old data on the system.

An alert titled [FRAG-OVERLAP] is generated during IP fragmentation reconstruction if overlapping data is detected. This may indicate that a network problem has occurred or that a malicious user is attempting to bypass the packet-based IDS system or the firewall.

All networks tend to have overwriting IP fragments that result from corrupted packets and broken equipment. An analysis of the overwritten data and the subsequent packets from the IP addresses involved should be conducted for each event of this type. If the data is very random or seems like garbage, it is fairly safe to ignore these events. On the other hand if the event is web traffic, email traffic or something that is recognizable, some time should be invested to discern the nature of the event. In most cases, the responses from the target will not be fragmented and can be used to provide some clue as to what is happening.

25. Click Commit to add your changes to the policy being configured.

2-38 Creating Network Sensor Policies

Log Option Tab

A variety of IP options can be recorded based on option type and source IP address. You can specify a list of rules that ignore or log IP packets with options. A Log Option rule has three arguments. The first tells the Network Sensor to log or ignore the specific option. A source IP address or network block is the second argument. The third argument is the actual option. Use an asterisk (*) as a wildcard for any IP option.

Events of this type are named [IP-OPTIONS].

The following table lists some common IP option values:

Table 2-5 Common IP Option Values

Dec Binary Hex Name

0 00000000 0x00 EOL

1 00000001 0x01 NOOP

7 00000111 0x07 RECORD

68 01000100 0x44 TIMESTAMP

130 10000010 0x82 BASIC_SECURITY

131 10000011 0x83 LOOSE_SOURCE_ROUTE

Configuring the Network Layer Module

133 10000101 0x85 SECURITY

136 10001000 0x88 ID

137 10001001 0x89 STRICT_SOURCE_ROUTE

148 10010100 0x94 ALERT

Procedure

To configure the sensor to log or not log based on IP options:

1. Click the Network Policy View icon and the Network Policies tab.

2. Expand the tree by clicking the expansion symbols and select the desired custom policy name.

The modules for that policy are displayed in the tree.

3. Click the Network Layer Module in the tree.

The display area is populated and the last tab selected is on top.

4. Click the Log Option tab.

Creating Network Sensor Policies and Signatures 2-39

Configuring the Network Layer Module

5. Click Add to display the Network Layer Log Options dialog box.

6. Select the desired Action, either log or ignore.

7. Enter the source IP address or CIDR block for the rule using the following format:

Select the appropriate IP version checkbox. Network masks can range from 0-32 for IPv4 and 0-128 for IPv6.

8. Enter the option value. Refer to Table 2-5 on page 2-39 for a list of common option values. Use an asterisk (*) as a wildcard for any option.

9. Click OK. The rule is displayed in the table.

10. Click Edit or Delete to change or delete existing rules.

11. Use the Move Up and Move Down buttons to place the rules in the desired order.

12. Click Commit to add your changes to the policy being configured.

Example

The following example shows three rules configured. The first rule tells the sensor to log loose source routed packets (option number 131) from any source. The second rule tells the sensor to log strict source routed packets (option number 137) from any source. The third rule tells the sensor to ignore alert traffic (option number 148) sourced from network 10.100.100.0/24, the local network.

2-40 Creating Network Sensor Policies

Log Protocol Tab

The Network Sensor can be told to log or ignore packets based solely on IP protocol and source address. Events of this type are named [PROTO]. A Log Protocol rule has three arguments. The first tells the Network Sensor to log or ignore the specific protocol. A source IP address or network block is the second argument. The third argument is the actual protocol.

Refer to Tab le 2-2 on page 2-11 for a list of common protocols and their numbers. Use a 0 as a wildcard for any protocol.

Procedure

To configure the Network Sensor to log or ignore packets based on IP protocol:

1. Click the Network Policy View icon and the Network Policies tab.

2. Expand the tree by clicking the expansion symbols and select the desired custom policy name.

The modules for that policy are displayed in the tree.

3. Click the Network Layer Module in the tree.

4. Click the Log Protocol tab.

5. Click Add to display the Network Layer Log Protocol dialog box.

Configuring the Network Layer Module

6. Select the desired Action, either log or ignore.

7. Enter the source IP address or CIDR block for the rule using the following format:

Select the appropriate IP version checkbox. Network masks can range from 0-32 for IPv4 and 0-128 for IPv6.

8. Select the protocol from the drop-down list. Refer to Table 2-2 on page 2-11 for a list of common protocol values. Use a 0 as a wildcard for any protocol.

Creating Network Sensor Policies and Signatures 2-41

Configuring the Network Layer Module

9. Click OK. The rule is displayed in the table.

10. Click Edit or Delete to change or delete existing rules.

11. Use the Move Up and Move Down buttons to place the rules in the desired order.

12. Click Commit to add your changes to the policy being configured.

Examples

This example shows the rules that cause the sensor to log any traffic that is not UDP, TCP, or ICMP.

This example shows the rules that cause the sensor to log all ICMP traffic not from the local network, 10.100.100.0/24.

Log Frag Tab

The Network Sensor can watch for any fragmented packets and log them. On most networks, fragments do not occur a majority of the time. When they do happen, they are usually small in number and due to a poorly performing network or the result of hacker traffic. Fragments can be used to conduct network scanning and cause denial of service attacks, among other things.

A Log Frag rule has three arguments. The first tells the Network Sensor to log or ignore fragmented packets of the specified type. A source IP address or network block is the second argument. The third argument is the protocol. A value of 0 for the protocol acts as a wildcard and logs fragmented packets regardless of IP protocol. Events of this type are named [FRAG].

Procedure

To configure the Network Sensor to log or ignore fragmented packets based on IP protocol:

1. Click the Network Policy View icon and the Network Policies tab.

2. Expand the tree by clicking the expansion symbols and select the desired custom policy name.

The modules for that policy are displayed in the tree.

3. Click the Network Layer Module in the tree.

4. Click the Log Frag tab.

The display area is repopulated.

2-42 Creating Network Sensor Policies

5. Click Add to invoke the Network Layer Log Frag dialog box.

Configuring the Network Layer Module

6. Select the desired Action, either log or ignore.

7. Enter the source IP address or CIDR block for the rule using the following format:

Select the appropriate IP version checkbox. Network masks can range from 0-32 for IPv4 and 0-128 for IPv6.

8. Select the protocol from the Protocol drop-down list or you can enter the protocol’s numeric value. Refer to Tab le 2- 2 on page 2-11 for a list of common protocol values. Use a 0 as a wildcard for any protocol.

Note: The protocol is displayed numerically in the Log Broadcast tab’s Protocol column.

9. Click OK. The rule is displayed in the table.

10. Click Edit or Delete to change or delete existing rules.

11. Use the Move Up and Move Down buttons to place the rules in the desired order.

12. Click Commit to add your changes to the policy being configured.

Examples

The following example shows the rules to ignore UDP fragments but log all others.

Creating Network Sensor Policies and Signatures 2-43

Configuring the Network Layer Module

This example shows the rules to ignore fragmented packets from the internal network (10.100.100.0/24) but log all others.

This example shows the rules to log all ICMP and UDP fragments.

Log Static Tab

The Network Sensor can be configured to log all packets from a particular network or IP address. A Log Static rule has two arguments: a unique name to be associated with the rule, and an IP address or CIDR mask. When traffic occurs matching these rules, an event is generated with the name specified. Events logged by this type of rule decode IP protocol, source and destination port for UDP and TCP as well as additional information such as TCP flags.

Procedure

To configure the Network Sensor to log packets from a particular network or IP address:

1. Click the Network Policy View icon and the Network Policies tab.

2. Expand the tree by clicking the expansion symbols and select the desired custom policy name.

The modules for that policy are displayed in the tree.

3. Click the Network Layer Module in the tree.

4. Click the Log Static tab.

2-44 Creating Network Sensor Policies

5. Click Add to invoke the Network Layer Log Static dialog box.

Configuring the Network Layer Module

6. In the Event Name field, specify the name of the event that should be generated when this Log Static rule is matched. You can specify any name you want for this event. The name can be any combination of characters, excluding spaces, up to a maximum of 28 characters.

Or, click the Browse button to display the Event Chooser window and select from the events displayed.

7. Enter the source IP address or CIDR block for the rule using the following format:

Select the appropriate IP version checkbox. Network masks can range from 0-32 for IPv4 and 0-128 for IPv6.

8. Click OK. The rule is displayed in the table.

9. Click Edit or Delete to change or delete existing rules.

10. Click Commit to add your changes to the policy being configured.

Example

In the example below, two rules have been configured. The Network Sensor will generate the event [NETWORK1] when traffic to and from 10.100.100.0/24 is logged. The event [SUSPECT] will be generated when traffic to and from 128.129.10.32 is logged.

Creating Network Sensor Policies and Signatures 2-45

Configuring the Network Layer Module

Log Broadcast Tab

The Network Sensor can be configured to watch for packets with strange broadcast destination addresses. These packets are most likely denial of service attacks, network probes, or malfunctioning routers. The Network Sensor ignores internal broadcast traffic and concentrates on traffic from non-protected networks. Target addresses that end in .255 or .0 are common hacker probe values.

A Log Broadcast rule has two arguments. The first argument is the protocol and the second argument is the destination IP address. The destination address should be a normal IP address without any network bit mask. Events of this type are named [BROADCAST].

Refer to Tab le 2-2 on page 2-11 for a list of common protocols and their numbers. Use a 0 as a wildcard for any protocol.

Procedure

To configure the Network Sensor to log packets based on broadcast address:

1. Click the Network Policy View icon and the Network Policies tab.

2. Expand the tree by clicking the expansion symbols and select the desired custom policy name.

The modules for that policy are displayed in the tree.

3. Click the Network Layer Module in the tree.

4. Click the Log Broadcast tab.

5. Click Add to invoke the settings window.

6. Select the protocol from the Protocol drop-down list or you can enter the protocol’s numeric value. Refer to Tab le 2- 2 on page 2-11 for a list of common protocol values. Use a 0 as a wildcard for any protocol.

Note: The protocol is displayed numerically in the Log Broadcast tab’s Protocol column.

2-46 Creating Network Sensor Policies

Configuring the Probe Detection Module

7. Enter the destination IP Address and select the appropriate IP version checkbox. No network mask is required.

8. Click OK. The rule is displayed in the table.

9. Click Edit or Delete to change or delete existing rules.

10. Click Commit to add your changes to the policy being configured.

Examples

The following example shows the rules to log packets going to 10.100.100.255 or 10.100.100.0

This example shows the rules to log ICMP Smurf attacks.

Configuring the Probe Detection Module

The parameters set with this module configure the way the Network Sensor tracks probing activities that cannot be detected by rule-matching or protocol anomaly detection. The probe detection module builds vast internal tables to keep track of the following factors:

• Number of destination hosts

• Number of destination ports

• Number of source hosts

• Time over which the packets were sent

The module provides configuration settings that control how the sensor collects information and generates events under certain situations.

The Probe Detection module has two areas for configuration:

• The options in the Probe Detection Settings area configure the thresholds used by the Network Sensor when it performs port scan and port sweep analysis.

• The Port Ranges table is used to specify which port ranges you want the Network Sensor to consider when analyzing for port scans and sweeps.

Note: You can use the Probe Settings Tab (page 2-14) in the Application Filter Module to tell the sensor to ignore traffic from legitimate port scanning applications at specific IP addresses and ports.

Creating Network Sensor Policies and Signatures 2-47

Configuring the Probe Detection Module

Procedure

To configure the Network Sensor probe detection settings:

1. Click the Network Policy View icon, and then the Network Policies tab.

2. Expand the tree by clicking on the expansion symbol, and then select the custom policy name.

The modules for that policy are displayed in the tree.

3. Click the Probe Detection Module in the tree.

4. Enable Probe Detection must be selected to enable the module. It is selected by default.

5. Select Enable Ve rb o se Mode to specify an ordered list of the information used to generate an alert. For a port scan, this option instructs the sensor to provide a list of all of the ports that were probed. In the case of a sweep, all of the IP addresses that were probed are placed in the event payload.

The size of the payload is limited to 1500 bytes. The sensor will include as much of the detail as possible and leave (...) at the end if the payload was truncated.

2-48 Creating Network Sensor Policies

Configuring the Probe Detection Module

6. Specify the Sliding window length in seconds value, which is a limit value for the probe engine buffer. This option tells the Network Sensor how long (in seconds) it will collect unique network packets or events before evaluating the entire collection for sweeps and scans. Packets are collected for unique protocol, destination service, source IP address, and destination IP address values. For example, if IP #1 sent an ICMP echo request to IP #2, this packet would be collected. Subsequent echo requests from IP #1 to IP #2 would not be collected because they are not new traffic. Likewise, if IP #1 visited IP #2’s web server on port 80, the first packet would be collected but all other port 80 traffic between them would not.

Once the Sliding window length value is reached, the Network Sensor conducts an analysis of the data collected during the specified time period. After that, the probe engine buffer is flushed. The maximum number of seconds is 1209600 (two weeks).

Adjusting this parameter changes the “sensitivity” of the Probe Detection module. To detect slow port scans, this value should be set to a longer duration. However, a longer duration could allow an overwhelming amount of data to accumulate, which could lower Network Sensor performance.

Note: Each conversation (TCP, UDP, ICMP) contains two flows (for example, two distinct source and destination pairs).

7. Specify the PROTOCOL-SCAN Event Threshold in the Unique protocols needed per host field. When the number of different protocols used by an external host to probe a computer on the protected network exceeds the protocol scan event threshold, a [PROTOCOL-SCAN] event is generated.

8. Specify the UDP-SCAN/TCP-SCAN Event Threshold in the Unique ports needed per host field. This value specifies the maximum number of destination ports that must be accessed per destination host before the network sensor determines that the destination host has been scanned and generates a [UDP-SCAN] or [TCP-SCAN] event.

This option attempts to find patterns of network traffic between two IP addresses that involve many different ports. For example, if IP #1 sends traffic to IP #2 on ports 21, 25, 53, and 80, this could count as four ports. If this number exceeds the maximum number of Unique ports needed per host, a port scan is reported from IP #1 to IP #2.

Refer to the description of Sliding Window Length in seconds above for more information about packet collection for analysis using this option value.

9. Specify the UDP-SWEEP/TCP-SWEEP Event Threshold in the Unique hosts needed per port field. This field specifies the maximum number of destination hosts that can be accessed on a specific port before the network sensor determines that these hosts have been swept and generates a [TCP-SWEEP] or [UDP-SWEEP] event.

This option attempts to discover sweeps for single ports to many IP addresses. For example, if IP #1 attempts to access email (port 25) on IP #2, #3, #4 and #5, this counts as four events that may be evaluated as a sweep. If this number exceeds the maximum value of Unique hosts needed per port, a port sweep is reported from the originating IP. For network sweeps, ICMP netmask, timestamp and echo requests are also considered.

Refer to the description of Sliding window length in seconds above for more information about packet collection for analysis using this option value.

Creating Network Sensor Policies and Signatures 2-49

Configuring the Protocol Analysis Module

10. Configure the Monitored Port Ranges table to specify which port ranges you want Network Sensor to consider when analyzing for port scans and sweeps. Enter a port number in the Beginning Port and End Port fields, then click Add.

There are a variety of port scan and port sweep signatures that exist in normal network traffic. For example, most web browsers choose a local source port when connecting to port 80 on the web server. For every new web request, the web browser usually increments its local source port. This can be considered a port scan because it looks like the web server is connected to the client on many different ports. One way to combat this is to tell Network Sensor all of the target ports that should be monitored for port scans.

11. To remove a configured port range, select the desired row in the table and click Delete.

12. Click Commit to add your changes to the policy being configured.

Configuring the Protocol Analysis Module

This module allows you to configure the Network Sensor to perform analysis on a variety of protocols. Basically, this module checks whether packets meet the requirements of the relevant protocol RFCs.

Note that some of the protocol analysis techniques in this module are enabled by default and some are disabled by default, so when you add this module to a custom policy, you should check the default configuration of the protocols in which you are interested.

This section briefly describes the protocols but does not explain all the configurable options since we assume you have intimate knowledge of the protocols if you are changing the default values.

For information about... Refer to page...

DNS Analysis Configuration 2-51

FTP Analysis Configuration 2-54

Finger Analysis Configuration 2-56

H.225 Analysis Configuration 2-58

H.245 Analysis Configuration 2-61

HTTP Analysis Configuration 2-63

ICMP Analysis Configuration 2-66

MGCP Analysis Configuration 2-69

RIP Analysis Configuration 2-72

RPC Analysis Configuration 2-74

SIP Analysis Configuration 2-78

SMB Analysis Configuration 2-81

SNMP Analysis Configuration 2-83

Telnet Analysis Configuration 2-85

2-50 Creating Network Sensor Policies

DNS Analysis Configuration

This feature detects and converts attempted IDS evasion techniques that use the DNS protocol. This evasion technique was first published by Robert Graham and exploits the protocol conventions within DNS.

The evasion technique exploits the label field within the DNS protocol. The label field is where the host, domain names, and other requests are described. It is also where a hacker can request the version of Bind that the DNS server is running. This request is often malicious since there are remote exploits for certain versions of Bind.

The DNS evasion technique works as follows. The DNS label field consists of a sequence of length followed by letters. For example, 3www9enterasys3com. This is the layout of the label field. The version bind requests are shown as: 7version4bind. Network Sensor has a signature for this query. However, the evasion tactic makes use of the DNS protocol’s ability to insert pointers in the label field. The pointers allow you to skip around in the label field so labels are no longer in sequenced order. So using this technique, a valid label field that asks for the version of Bind could be 7versi(pointer to o)indon4b. The DNS server looks at this request and interprets it as, read the next 7 letters, v-e-r-s-i (jump to o) o-n, read 4 letters b (jump to after pointer) i-n-d. To the DNS server, this is a valid request. The Network Sensor converts these obscured requests into normal requests that can be matched with signatures.

For in-depth examples, please read the paper on DNS IDS evasion that Judy Novak wrote for Enterasys Networks. The paper is located in the Whitepapers section on the Dragon web site:

https://dragon.enterasys.com.

Configuring the Protocol Analysis Module

Procedure

To configure DNS Analysis settings:

1. Click the Network Policy View icon and the Network Policies tab.

2. Expand the tree by clicking the expansion symbols and select the desired custom policy name.

The modules for that policy are displayed in the tree.

3. Click the Protocol Analysis Module in the tree.

Creating Network Sensor Policies and Signatures 2-51

Configuring the Protocol Analysis Module

4. Expand DNS Analysis in the Protocol column.

5. DNS analysis is enabled by default. To disable it, click disable in the Property column, then select yes from the drop-down list in the Value column.

6. Verbose mode is disabled by default. When enabled, the sensor will log events when certain evasions occur. To enable it, click verbose in the Property column, then select yes from the drop-down list in the Value column.

7. The sensor looks at traffic traveling in any direction on the well-known port 53. To edit the existing port 53 configuration, select that row in the table and click Edit Port. The Add Port Information dialog box is displayed.

8. To add or exclude a port or port range for analysis, click Add Port. The Add Port Information dialog box is displayed.

2-52 Creating Network Sensor Policies

Configuring the Protocol Analysis Module

a. Select the type of port to add or exclude, then enter the port number or low and high

numbers for a range. Refer to Tab le 2-1 on page 2-8 for a list of common port numbers.

b. Select the direction of the traffic to be analyzed and click OK.

9. To add a Port Macro to the port list, click Add PortMacro. The Port Macro Selection dialog box is displayed. Select the desired macro and click OK.

Note: To display existing port macros and their definitions, or to add a new macro, click Default Network Sensor Settings in the Network Policies tab of the Network Policy View. See

“Configuring Port Macros” on page 1-14 for information about creating or editing port macros.

10. Click Commit to add your changes to the policy being configured.

Creating Network Sensor Policies and Signatures 2-53

Configuring the Protocol Analysis Module

FTP Analysis Configuration

The FTP protocol works by establishing a control connection and a data connection when data needs to be sent. The control connection can use Telnet commands that begin with the IAC byte (0xff). FTP analysis watches the control connection for these types of commands and interprets them for signature matching.

Many times when an IAC command is sent in an FTP control connection, it is used as an attempt to evade an IDS. When FTP analysis is enabled, an event is generated for these types of evasions.

In addition, FTP analysis decodes TCP port 21 packets and streams that specify a port command for file transfer (port-request-check property). The decode extracts the command string which is of the form port x,x,x,x,p,p where x,x,x,x is the destination IP address and p,p is the destination port. If the destination IP address is not equal to the source address of this packet, the packet is logged as a security event [FTP-BOUNCE].

This attack may indicate FTP port scanning, FTP mail bombing, FTP hijacking and a variety of other suspicious events. However, this attack could also result from a non-passive FTP file transfer attempt from a network address translated client. It also looks for general port requests (the p,p from the x,x,x,x,p,p), which specify addresses lower than port 1024. Such a port may indicate attempts at email spoofing, remote login attempts, and other types of attacks.

Procedure

To configure FTP Analysis settings:

1. Click the Network Policy View icon and the Network Policies tab.

2. Expand the tree by clicking the expansion symbols and select the desired custom policy name.

The modules for that policy are displayed in the tree.

3. Click the Protocol Analysis Module in the tree.

4. Expand FTP Analysis in the Protocol column.

2-54 Creating Network Sensor Policies

Configuring the Protocol Analysis Module

5. FTP analysis is enabled by default. To disable it, click disable in the Property column, then select yes from the drop-down list in the Value column.

6. Verbose mode is disabled by default. When enabled, the sensor will log events when certain evasions occur. The event logged when evasions are detected is [FTP:IAC-EVADE]. To enable it, click verbose in the Property column, then select yes from the drop-down list in the Value column.

7. The sensor looks at traffic traveling in any direction on the FTP control port 21. To edit the existing port 21 configuration, select that row in the table and click Edit Port. The Add Port Information dialog box is displayed.

8. To add or exclude a port or port range for analysis, click Add Port. The Add Port Information dialog box is displayed.

a. Select the type of port to add or exclude, then enter the port number or low and high

numbers for a range. Refer to Tab le 2-1 on page 2-8 for a list of common port numbers.

b. Select the direction of the traffic to be analyzed and click OK.

Creating Network Sensor Policies and Signatures 2-55

Configuring the Protocol Analysis Module

9. To add a Port Macro to the port list, click Add PortMacro. The Port Macro Selection dialog box is displayed. Select the desired macro and click OK.

Note: To display existing port macros and their definitions, or to add a new macro, click Default Network Sensor Settings in the Network Policies tab of the Network Policy View.See

“Configuring Port Macros” on page 1-14 for information about creating or editing port macros.

10. Click Commit to add your changes to the policy being configured.

Finger Analysis Configuration

The Network Sensor can decode attempts to “bounce” a finger request. Most finger servers recursively query other finger servers. For example, attempting to issue a command, finger root@site2@site1, may cause the finger daemon at site1 to finger the daemon at site2 for the user root. It is an easy way for some hackers to probe networks and hide their true source location. It is also a well-known Denial-of-Service tool. These events are named [FINGER-BOUNCE].

Procedure

To configure Finger Analysis settings:

1. Click the Network Policy View icon and the Network Policies tab.

2. Expand the tree by clicking the expansion symbols and select the desired custom policy name.

The modules for that policy are displayed in the tree.

3. Click the Protocol Analysis Module in the tree.

2-56 Creating Network Sensor Policies

4. Expand Finger Analysis in the Protocol column.

Configuring the Protocol Analysis Module

5. Finger analysis is enabled by default. To disable it, click disable in the Property column, then select yes from the drop-down list in the Value column.

7. The sensor looks at traffic traveling in any direction on the well-known port 79. To edit the existing port 79 configuration, select that row in the table and click Edit Port. The Add Port Information dialog box is displayed.

8. To add or exclude a port or port range for analysis, click Add Port. The Add Port Information dialog box is displayed.

a. Select the type of port to add or exclude, then enter the port number or low and high

numbers for a range. Refer to Tab le 2-1 on page 2-8 for a list of common port numbers.

Creating Network Sensor Policies and Signatures 2-57

Configuring the Protocol Analysis Module

b. Select the direction of the traffic to be analyzed and click OK.

9. To add a Port Macro to the port list, click Add PortMacro. The Port Macro Selection dialog box is displayed. Select the desired macro and click OK.

Note: To display existing port macros and their definitions, or to add a new macro, click Default Network Sensor Settings in the Network Policies tab of the Network Policy View. See

“Configuring Port Macros” on page 1-14 for information about creating or editing port macros.

10. Click Commit to add your changes to the policy being configured.

H.225 Analysis Configuration

H.225 is the ITU-T’s call signaling protocol that can be used in session establishment for Voice over IP (VoIP). The H.225 protocol analyzer verifies that a legal message type is used, as defined in the ITU-T H.225 specification. The protocol analyzer also verifies that the H.225 message contains all of the mandatory IEs (Information Elements) and that any optional IEs used are legitimate. The format for each IE is checked to be correct and that the values of each field is within the proper range where applicable. Also, the H.225 Analyzer verifies that the User-User IE which is packed using PER (Packed Encoding Rules) uses the correct protocol identifier. If any of these conditions fail, then the H.225 protocol decoder raises an event [H225:INVALID-MESSAGE].

Analysis of this protocol is disabled by default because not all infrastructures support VoIP.

Note: If the H.225 messages are encrypted, then the protocol decoder will generate an event for every message.

2-58 Creating Network Sensor Policies

Configuring the Protocol Analysis Module

Procedure

To configure H.225 Analysis settings:

1. Click the Network Policy View icon and the Network Policies tab.

2. Expand the tree by clicking the expansion symbols and select the desired custom policy name.

The modules for that policy are displayed in the tree.

3. Click the Protocol Analysis Module in the tree.

4. Expand H225 Analysis in the Protocol column.

5. H.225 analysis is disabled by default. To enable it, click disable in the Property column, then select no from the drop-down list in the Value column.

6. All of the H.225 analysis properties are enabled by default. To disable any of them, click the desired property in the Property column, then select no from the drop-down list in the Value column. Refer to the ITU-T H.225 specification for descriptions of the properties.

7. Verbose mode is disabled by default. When enabled, the sensor will log events when certain evasions occur. To enable it, click verbose in the Property column, then select yes from the drop-down list in the Value column.

8. The sensor looks at traffic traveling in any direction on port 1720. To edit the existing port 1720 configuration, select that row in the table and click Edit Port. The Add Port Information dialog box is displayed.

9. To add or exclude a port or port range for analysis, click Add Port. The Add Port Information dialog box is displayed.

Creating Network Sensor Policies and Signatures 2-59

Configuring the Protocol Analysis Module

a. Select the type of port to add or exclude, then enter the port number or low and high

numbers for a range. Refer to Tab le 2-1 on page 2-8 for a list of common port numbers.

b. Select the direction of the traffic to be analyzed and click OK.

10. To add a Port Macro to the port list, click Add PortMacro. The Port Macro Selection dialog box is displayed. Select the desired macro and click OK.

Note: To display existing port macros and their definitions, or to add a new macro, click Default Network Sensor Settings in the Network Policies tab of the Network Policy View. See

“Configuring Port Macros” on page 1-14 for information about creating or editing port macros.

11. Click Commit to add your changes to the policy being configured.

2-60 Creating Network Sensor Policies

H.245 Analysis Configuration

H.245 is also an ITU-T call signaling protocol that can be used in session establishment for Voice over IP (VoIP). The H.245 protocol analyzer verifies that capability exchange, command, request, and response messages are legal, as defined in the ITU-T H.245 specification. If any errors are found, then the H.245 protocol decoder raises an event [H245:INVALID-MESSAGE].

Analysis of this protocol is disabled by default because not all infrastructures support VoIP.

Note: If the H.245 messages are encrypted, then the protocol decoder will generate an event for every message.

Procedure

To configure H.245 Analysis settings:

1. Click the Network Policy View icon and the Network Policies tab.

2. Expand the tree by clicking the expansion symbols and select the desired custom policy name.

The modules for that policy are displayed in the tree.

3. Click the Protocol Analysis Module in the tree.

4. Expand H245 Analysis in the Protocol column.

Configuring the Protocol Analysis Module

5. H.245 analysis is disabled by default. To enable it, click disable in the Property column, then select no from the drop-down list in the Value column.

6. All of the H.245 analysis properties are enabled by default. To disable any of them, click the desired property in the Property column, then select no from the drop-down list in the Value column. Refer to the ITU-T H.245 specification for descriptions of the properties.

Creating Network Sensor Policies and Signatures 2-61

Configuring the Protocol Analysis Module

7. Verbose mode is disabled by default. When enabled, the sensor will log events. To enable it, click verbose in the Property column, then select yes from the drop-down list in the Value column.

8. The sensor looks at traffic traveling in any direction on port 1722. To edit the existing port 1722 configuration, select that row in the table and click Edit Port. The Add Port Information dialog box is displayed.

9. To add or exclude a port or port range for analysis, click Add Port. The Add Port Information dialog box is displayed.

a. Select the type of port to add or exclude, then enter the port number or low and high

numbers for a range. Refer to Tab le 2-1 on page 2-8 for a list of common port numbers.

b. Select the direction of the traffic to be analyzed and click OK.

2-62 Creating Network Sensor Policies

10. To add a Port Macro to the port list, click Add PortMacro. The Port Macro Selection dialog box is displayed. Select the desired macro and click OK.

Note: To display existing port macros and their definitions, or to add a new macro, click Default Network Sensor Settings in the Network Policies tab of the Network Policy View. See

“Configuring Port Macros” on page 1-14 for information about creating or editing port macros.

11. Click Commit to add your changes to the policy being configured.

HTTP Analysis Configuration

HTTP Analysis configuration simulates a web server when analyzing web traffic. The Network Sensor signatures that are string-based (not an exact binary match) are run through a filter before having their signatures matched. It protects the Network Sensor’s integrity by performing several transforms on the collected data that can be used to confuse the Network Sensor.

Configuring the Protocol Analysis Module

The HTTP Analysis settings includes the following properties that can be enabled or disabled:

• doc-root — If the doc-root attribute is enabled, then the HTTP Analysis module will log attempts by a web client to navigate to portions of the web server fleshiest that are not within the web server root directory. Such a web request would include a string like "../" or "..\". If such a request is detected, then a [WEB:DOCROOT] event is generated.

• fast-analyze — Fast Analyze is a component of the Adaptive Pattern Matching Engine which provides streamlined processing for HTTP responses. HTTP response headers are examined and the payload is selectively inspected for signature-related events.

• iis-unicode — IIS-unicode interprets Unicode representations the way that IIS does.

• unicode — Unicode decodes Unicode representations that are allowed in the Unicode Standard version 2. The main advantage to turning on unicode is that any web attack, such as /cgi-bin/phf, can be encoded using Unicode and evade common IDS web signatures. Any URL can be encoded with a valid Unicode representation of an ASCII character, and Network Sensor substitutes the correct character so signatures can match.

• multi-method — Multi-method is used to detect multiple requests made within a single packet.

• null-method — Null method is used to detect multiple requests made within a null packet.

The Allow Method section of the HTTP Analysis Settings window lists selected RFC 2616 (HTTP

1.1) methods that you can select as acceptable for use on web servers located on the protected

network.

Note: If you have a problem with web signatures not triggering events when the HTTP Analysis module is turned on, set the fast-analyze property to no. Commit and then Deploy the change to your sensors.

Creating Network Sensor Policies and Signatures 2-63

Configuring the Protocol Analysis Module

Procedure

To configure HTTP Analysis settings:

1. Click the Network Policy View icon and the Network Policies tab.

2. Expand the tree by clicking the expansion symbols and select the desired custom policy name.

The modules for that policy are displayed in the tree.

3. Click the Protocol Analysis Module in the tree.

4. Expand HTTP Analysis in the Protocol column.

5. HTTP analysis is enabled by default. To disable it, click disable in the Property column, then select yes from the drop-down list in the Value column.

6. Some of the HTTP analysis properties are enabled by default, while others are disabled by default. Refer to the descriptions above to determine whether you want to change the default settings. To change a property setting, click it in the Property column, then select yes or no from the drop-down list in the Value column.

8. In the Allow Method window, select the desired RFC 2616 (HTTP 1.1) methods that are acceptable for use on web servers located on the protected network.

9. By default, the Network Sensor will analyze traffic directed toward ports 80, 8080, and 3128. To add or exclude a port or port range for analysis, click Add Port. The Add Port Information dialog box is displayed.

2-64 Creating Network Sensor Policies

Configuring the Protocol Analysis Module

a. Select the type of port to add or exclude, then enter the port number or low and high

numbers for a range. Refer to Tab le 2-1 on page 2-8 for a list of common port numbers.

b. Select the direction of the traffic to be analyzed and click OK.

10. To add a Port Macro to the port list, click Add PortMacro. The Port Macro Selection dialog box is displayed. Select the desired macro and click OK.

Note: To display existing port macros and their definitions, or to add a new macro, click Default Network Sensor Settings in the Network Policies tab of the Network Policy View. See

“Configuring Port Macros” on page 1-14 for information about creating or editing port macros.

11. Click Commit to add your changes to the policy being configured.

Creating Network Sensor Policies and Signatures 2-65

Configuring the Protocol Analysis Module

ICMP Analysis Configuration

The ICMP protocol is used by a variety of normal and hacker activities. Logging all of that activity generates a lot of information. You can configure ICMP Analysis settings to filter ICMP traffic and only log specific ICMP events by using the ICMP Log Elements section of the ICMP Analysis Settings window.

Tab le 2-6 below lists the ICMP type and code values that you can use to filter ICMP traffic.

Table 2-6 ICMP Protocol Values

Type Code Name [Reference]

0 - ECHO REPLY

3 0 DESTINATION UNREACHABLE

3 1 HOST UNREACHABLE

3 2 PROTOCOL UNREACHABLE

3 3 PORT UNREACHABLE

3 4 FRAGMENTATION NEEDED

3 5 SOURCE ROUTE FAILED

3 6 NETWORK UNKNOWN

3 7 HOST UNKNOWN

3 8 HOST ISOLATED

3 9 PROHIBITED NETWORK

3 10 PROHIBITED HOST

311NETWORK TOS

312HOST TOS

3 13 ADMIN PROHIBITED FILTER

4 - SOURCE QUENCH

8 - ECHO (PING)

9 - IDRP Router Advertisement [RFC1256]

10 - IDRP Router Selection [RFC1256]

11 - TIME EXCEEDED

12 - DATA PROBLEM

13 - TIMESTAMP REQUEST

14 - TIMESTAMP REPLY

15 - INFO REQUEST

16 - INFO REPLY

17 - NETMASK REQUEST

18 - NETMASK REPLY

30 - TRACEROUTE

2-66 Creating Network Sensor Policies

Configuring the Protocol Analysis Module

Procedure

To configure ICMP Analysis settings:

1. Click the Network Policy View icon and the Network Policies tab.

2. Expand the tree by clicking the expansion symbols and select the desired custom policy name.

The modules for that policy are displayed in the tree.

3. Click the Protocol Analysis Module in the tree.

4. Expand ICMP Analysis in the Protocol column.

5. ICMP analysis is enabled by default. To disable it, click disable in the Property column, then select yes from the drop-down list in the Value column.

6. The large property is used to log all ICMP packets that exceed a certain size. Values of 1300, 1400, and even 1450 can be used to detect ICMP-based denial of service attacks and in some cases, hacker backdoors that use ICMP as a transport protocol. The value of large is set to 1400 by default. To change it, click large in the Property column, then enter the desired value in the Value column. The maximum value is 65535.

Creating Network Sensor Policies and Signatures 2-67

Configuring the Protocol Analysis Module

7. Configure your filters in the ICMP Log Elements window. Click Add. The Add ICMP Log Element dialog box is displayed.

a. Select the desired action, either ignore or log, from the Action drop-down menu.

b. Enter the network source IP address using the following format:

Select the appropriate IP version checkbox. Network masks can range from 0-32 for IPv4 and 0-128 for IPv6. To indicate any network, use 0.0.0.0/0 for IPv4 addresses and ::/0 for IPv6 addresses.

c. Enter the ICMP traffic type to be logged or ignored in the Ty p e field. Refer to Ta ble 2-6 on

page 2-66 for a list of ICMP type and code values. To specify any type of traffic, select the Any box.

d. Enter the ICMP code value. Refer to Tab le 2 -6 on page 2-66 for a list of ICMP type and

code values. If no code value is needed, select the Any box.

e. Click OK to add the filter to the table.

8. Click Edit or Remove to change or delete existing filters.

9. Use the Move Up and Move Down buttons to place the rules in the desired order.

10. Click Commit to add your changes to the policy being configured.

Examples

The following example shows four ICMP filter rules that tell the sensor to ignore echo replies, ICMP errors, and echo requests from any network, but log all other ICMP traffic.

2-68 Creating Network Sensor Policies

This example tells the sensor to log ICMP protocol unreachable messages, port unreachable ICMP packets, admin prohibited filter packets, IDRP router advertisements, and IDRP router selection messages.

MGCP Analysis Configuration

The Media Gateway Control Protocol (MGCP) was developed by the Internet Engineering Task force (IETF) organization. MGCP is designed for controlling a media gateway from external call control elements called Media gateway controllers or Call agents. The MGCP protocol is an ASCII-text based protocol (like HTTP and SIP) and is described in RFC 3435 [1].

Configuring the Protocol Analysis Module

This MGCP protocol decoder implementation is a top-down parser of the MGCP message (excluding the content). The protocol decoder for the MGCP protocol performs the following two functions:

• The protocol decoder verifies that the MGCP message, consisting of the command line and has the proper BNF syntax as specified in Appendix A of RFC 3435 [1]. If the syntax of the MGCP message is not correct the protocol decoder generates an event.

• The protocol decoder checks that the parameter names present in the MGCP message conform to the constraints (regarding their presence in the command present in the command line) listed in the Table present in section 3.3 RFC 3435 [1].

The protocol decoder assumes that the MGCP messages will be present on the port configured by the EMS.

The protocol decoder assumes that the MGCP messages arriving on the configured port are not encrypted. If encrypted messages arrive, then the protocol decoder will generate an event for every message.

The protocol decoder is stateless. It does not keep track of “connection” related to the message — that is, it does not try to associate an S message with a connection (existing or new). It takes a message, verifies that it conforms to the BNF syntax and generates an event if the message does not conform to the syntax.

Procedure

To configure MGCP Analysis settings:

1. Click the Network Policy View icon and the Network Policies tab.

2. Expand the tree by clicking the expansion symbols and select the desired custom policy name.

The modules for that policy are displayed in the tree.

3. Click the Protocol Analysis Module in the tree.

Creating Network Sensor Policies and Signatures 2-69

Configuring the Protocol Analysis Module

4. Expand MGCP Analysis in the Protocol column.

5. MGCP analysis is disabled by default. To enable it, click disable in the Property column, then select no from the drop-down list in the Value column.

6. All of the MGCP analysis properties are enabled by default. To disable any of them, click the desired property in the Property column, then select no from the drop-down list in the Value column. Refer to RFC 3435 for descriptions of the properties.

8. The sensor looks at traffic traveling in any direction on port 2427. To edit the existing port 2427 configuration, select that row in the table and click Edit Port. The Add Port Information dialog box is displayed.

9. To add or exclude a port or port range for analysis, click Add Port. The Add Port Information dialog box is displayed.

2-70 Creating Network Sensor Policies

Enterasys Intrusion Prevention System Manual

Specifications and Main Features

Frequently Asked Questions

User Manual