Sourcefire 3D System for Nokia User Guide - Check Point

Sourcefire 3D System for Nokia User Guide

Version 4.7

Intellectual Property Notices, Disclaimers, and Terms of Use Applicable to the User Documentation. The legal notices, disclaimers, terms of use, and other information contained herein (the “terms”) apply only to Sourcefire, Inc. appliance discussed in the Documentation (“Documentation”) and your use of it. The terms do not apply to or govern the use of Sourcefire's web site or Sourcefire's appliance discussed in the Documentation. Sourcefire appliances are available for purchase and subject to a separate license containing very different terms of use. Terms Of Use and Copyright and Trademark Notices The copyright in the Documentation is owned by Sourcefire, Inc., and is protected by copyright pursuant to US copyright law, international conventions, and other laws. You may use, print out, save on a retrieval system, and otherwise copy and distribute the documentation solely for non-commercial use, provided that (i) you do not modify the documentation in any way and (ii) you always include Sourcefire's copyright, trademark, and other notices, as well as a link to, or print out of, the full contents of this page and its terms. No part of the documentation may be used in a compilation or otherwise incorporated into another work, or be used to create derivative works, without the express prior written permission of Sourcefire, Inc. Sourcefire, Inc. reserves the right to change the Terms at any time, and your continued use of the Documentation shall be deemed an acceptance of those terms. Sourcefire, the Sourcefire logo, Snort, the Snort logo, 3D Sensor, Intrusion Sensor, Intrusion Agent, Realtime Network Awareness, RNA Sensor, Defense Center, Master Defense Center, Success Pack, and 3D System, are trademarks or registered trademarks of Sourcefire, Inc. All other trademarks are property of their respective owners. © 2008 Sourcefire, Inc. All rights reserved. Liability Disclaimers THE DOCUMENTATION AND ANY INFORMATION AVAILABLE FROM IT MAY INCLUDE INACCURACIES OR TYPOGRAPHICAL ERRORS. SOURCEFIRE, INC. MAY CHANGE THE DOCUMENTATION FROM THE TIME TO TIME. SOURCEFIRE, INC. MAKES NO REPRESENTATIONS OR WARRANTIES ABOUT THE ACCURACY OR SUITABILITY OF THE SOURCEFIRE, INC. WEB SITE, THE DOCUMENTATION, AND/OR ANY APPLIANCE OR INFORMATION. SOURCEFIRE, INC. PROVIDES THE SOURCEFIRE, INC. WEB SITE, THE DOCUMENTATION, AND ANY APPLIANCE OR INFORMATION “AS IS” AND SOURCEFIRE, INC. DISCLAIMS ANY AND ALL EXPRESS OR IMPLIED WARRANTIES, INCLUDING BUT NOT LIMITED TO WARRANTIES OF TITLE OR THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL SOURCEFIRE, INC. BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, PUNITIVE, OR CONSEQUENTIAL DAMAGES (INCLUDING BUT NOT LIMITED TO PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES, LOSS OF DATA, LOSS OF PROFITS, AND/OR BUSINESS INTERRUPTIONS), ARISING OUT OF OR IN ANY WAY RELATED TO THE SOURCEFIRE, INC. WEB SITE, THE DOCUMENTATION, AND/OR ANY SOFTWARE OR INFORMATION, NO MATTER HOW CAUSED AND/OR WHETHER BASED ON CONTRACT, STRICT LIABILITY, NEGLIGENCE OR OTHER TORTUOUS ACTIVITY, OR ANY OTHER THEORY OF LIABILITY, EVEN IF SOURCEFIRE, INC. IS ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. BECAUSE SOME STATES/JURISDICTIONS DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES, THE ABOVE LIMITATIONS MAY NOT APPLY TO YOU. The Documentation may contain “links” to sites on the Internet that are not created by, or under the control of Sourcefire, Inc. Sourcefire, Inc. provides such links solely for your convenience, and assumes no responsibility for the availability or content of such other sites. 840806302007

Table of Contents

Chapter 1:

Introduction to the Sourcefire 3D System............................. 25 Components of the Sourcefire 3D System......................................................... Real-time Network Awareness (RNA) ................................................... Intrusion Prevention System (IPS) ......................................................... Real-time User Awareness (RUA).......................................................... Defense Centers.................................................................................... Master Defense Centers ....................................................................... Intrusion Agents .................................................................................... Estreamer .............................................................................................. RNA Visualizer .......................................................................................

26 26 27 28 28 29 29 29 29

Logging into the Appliance ................................................................................. 30 Logging into the Appliance to Set Up an Account .............................................. 32 Logging Out of the Appliance ............................................................................. 33 Specifying Your User Preferences ...................................................................... Changing Your Password....................................................................... Setting Event Preferences..................................................................... Setting Your Default Time Zone ............................................................ Specifying Your Home Page ..................................................................

34 34 35 37 38

Using the Context Menu .................................................................................... 39 Documentation Resources ................................................................................. 40

Version 4.7


3

Table of Contents

Chapter 2:

Managing Sensors.................................................................... 44 Management Concepts ...................................................................................... What Can Be Managed by a Defense Center?...................................... Beyond Policies and Events................................................................... Using Redundant Defense Centers .......................................................

45 45 47 48

Working with Sensors ........................................................................................ 48 Understanding the Sensors Page .......................................................... 49

Chapter 3:

VERSION 4.7

Managing a Sourcefire Sensor on Nokia............................................................. Adding a Sourcefire Sensor on Nokia to the Defense Center ............... Adding Feature Licenses for a Sourcefire Sensor on Nokia .................. Deleting a Sourcefire Sensor on Nokia from a Defense Center ............ Resetting Management of a Sourcefire Sensor for Nokia .....................

50 51 54 55 56

Managing Sensor Groups ................................................................................... Creating Sensor Groups......................................................................... Editing Sensor Groups ........................................................................... Deleting Sensor Groups.........................................................................

56 57 58 58

Editing a Managed Sensor’s System Settings .................................................... Viewing a Sensor’s Information Page.................................................... Stopping and Restarting a Managed Sensor ......................................... Managing Communication on a Managed Sensor................................. Setting the Time on a Managed Sensor ................................................

59 60 62 62 63

Configuring High Availability ............................................................................... Guidelines for Implementing High Availability ....................................... Setting Up High Availability.................................................................... Monitoring the High Availability Status.................................................. Disabling High Availability and Unregistering Sensors........................... Pausing Communication between HAed Defense Centers................... Restarting Communication between HAed Defense Centers...............

63 66 67 69 70 71 71

Working with the Master Defense Center ............................ 73 Understanding Event Aggregation...................................................................... Aggregating Intrusion Events ................................................................ Aggregating Compliance Events............................................................ Limitations on Event Aggregation..........................................................

74 75 76 76

Understanding Global Policy Management......................................................... Managing Global Intrusion Policies........................................................ Using RNA Detection Policies on a Master Defense Center................. Using Health Policies on a Master Defense Center .............................. Using System Policies on a Master Defense Center............................. Master Defense Center Policy Management Limitations......................

78 78 79 79 80 80

SOURCEFIRE 3D SYSTEM FOR NOKIA USER GUIDE

4

Table of Contents

Adding and Deleting Defense Centers ............................................................... Adding a Master Defense Center .......................................................... Adding a Defense Center ...................................................................... Deleting a Defense Center .................................................................... Resetting Management of a Defense Center........................................

81 81 84 87 88

Using the Appliances Page ................................................................................. 90 Editing Settings for a Managed Defense Center ................................................ Viewing the Defense Center Information Page ..................................... Editing the Event Filter Configuration .................................................... Editing or Disabling Remote Management Communications................ Managing the Health Blacklist ............................................................... Managing High Availability Defense Centers.........................................

91 91 93 94 95 95

Managing Appliance Groups............................................................................... Creating Appliance Groups .................................................................... Editing Appliance Groups....................................................................... Deleting Appliance Groups ....................................................................

96 96 97 97

Editing Master Defense Center System Settings ............................................... 98 Listing Master Defense Center Information .......................................... 98 Viewing a Master Defense Center License ........................................... 98 Configuring Network Settings ............................................................... 99 Shutting Down and Restarting the System ........................................... 99 Configuring Remote Management Networking................................... 100 Setting System Time ........................................................................... 100 Blacklisting Health Policies .................................................................. 100

Chapter 4:

Using Detection Engines and Interface Sets...................... 102 Understanding Detection Engines .................................................................... 103 Understanding Default Detection Engines .......................................... 104 Managing Detection Engines............................................................................ Creating a Detection Engine ................................................................ Editing a Detection Engine .................................................................. Deleting a Detection Engine ................................................................

105 105 107 108

Using Detection Engine Groups ....................................................................... 109 Creating Detection Engine Groups ...................................................... 109 Deleting Detection Engine Groups ...................................................... 109 Using Variables within Detection Engines ......................................................... 110 Assigning Values to a Variable in Detection Engines........................... 111 Creating New Variables for Detection Engines.................................... 112 Deleting and Resetting Variables......................................................... 113 Using Interface Sets ......................................................................................... Creating an Interface Set ..................................................................... Editing an Interface Set ....................................................................... Deleting an Interface Set .....................................................................

VERSION 4.7


114 116 118 119

5

Table of Contents

Editing Network Interfaces ............................................................................... 120 Configuring Non-Standard Detection Engine Features ..................................... 121

Chapter 5:

Chapter 6:

Introduction to Sourcefire RNA ............................................ 125 Understanding RNA .......................................................................................... What Data Does RNA Collect? ............................................................ What Information Does RNA Provide? ................................................ How Can You Use RNA? ..................................................................... What are the Prerequisites for RNA Data Collection? .........................

126 127 127 132 133

Configuring RNA Detection Policies ................................................................. Creating an RNA Detection Policy ....................................................... Applying an RNA Detection Policy....................................................... Editing an RNA Detection Policy.......................................................... Deleting an RNA Detection Policy .......................................................

134 138 146 147 147

Using the Network Map ......................................................... 149 Understanding the Network Map ..................................................................... 150 Working with the Hosts Network Map ............................................................. 152 Working with the Bridges Network Map .......................................................... 155 Working with the Services Network Map......................................................... 157 Working with the Vulnerabilities Network Map ................................................ 158 Working with the Host Attributes Network Map .............................................. 161 Working with Custom Network Topologies ...................................................... 162 Creating Custom Topologies ............................................................... 164 Managing Custom Topologies ............................................................. 169

Chapter 7:

Using Host Profiles ................................................................. 172 Viewing Host Profiles........................................................................................ 175 Working with Basic Host Information in the Host Profile ................................. 176 Working with Operating Systems in the Host Profile.......................... 179 Working with VLAN Tags in the Host Profile .................................................... 180 Working with User History in the Host Profile.................................................. 181 Working with Host Attributes in the Host Profile.............................................. 181 Assigning Host Attribute Values .......................................................... 182 Working with Host Protocols in the Host Profile .............................................. 182 Working with White List Violations in the Host Profile ..................................... 183 Creating a White List Host Profile from a Host Profile ........................ 185

VERSION 4.7


6

Table of Contents

Working with Services in the Host Profile ........................................................ Service Detail....................................................................................... Service Banner..................................................................................... Editing Service Identities .....................................................................

185 189 190 191

Working with Client Applications in the Host Profile ........................................ 193 Viewing Client Applications in the Host Profile.................................... 193 Deleting Client Applications from the Host Profile .............................. 194 Working with Detected Vulnerabilities in the Host Profile ................................ Viewing Vulnerability Details................................................................ Setting the Vulnerability Impact Qualification ...................................... Downloading Patches for Vulnerabilities ............................................. Setting Vulnerabilities for Individual Hosts ..........................................

195 197 199 199 200

Working with the Predefined Host Attributes................................................... 201 Assigning a Host Criticality Value to a Host......................................... 201 Adding Notes to a Host ....................................................................... 202 Working with User-Defined Host Attributes ..................................................... Restrictions on User-Defined Host Attributes ..................................... Creating User-Defined Host Attributes................................................ Editing a User-Defined Host Attribute ................................................. Deleting a User-Defined Host Attribute...............................................

202 203 203 206 207

Working with Scan Results in a Host Profile .................................................... 207 Scanning a Host from the Host Profile ................................................ 208

Chapter 8:

Working with RNA Events...................................................... 210 Viewing RNA Event Statistics ........................................................................... Statistics Summary.............................................................................. Event Breakdown ................................................................................ Protocol Breakdown ............................................................................ Service Breakdown.............................................................................. OS Breakdown.....................................................................................

211 212 214 215 215 216

Understanding RNA Event Workflows.............................................................. 217 Working with Network Discovery and Host Input Events ................................ Understanding RNA Network Discovery Event Types......................... Understanding RNA Host Input Event Types ...................................... Viewing RNA Network Discovery and Host Input Events ................... Understanding the RNA Events Table ................................................. Searching for RNA Network Discovery Events....................................

VERSION 4.7


218 219 223 225 226 228

7

Table of Contents

Chapter 9:

Working with Hosts .......................................................................................... Viewing Hosts...................................................................................... Understanding the Hosts Table ........................................................... Creating a Traffic Profile for Selected Hosts........................................ Creating a Compliance White List Based on Selected Hosts .............. Locating WhoisInformation for a Host................................................. Searching for Hosts .............................................................................

231 232 234 237 238 238 239

Working with Host Attributes ........................................................................... Viewing Host Attributes....................................................................... Understanding the Host Attributes Table ............................................ Setting Host Attributes for Specific Hosts........................................... Searching for Host Attributes ..............................................................

244 244 246 247 248

Working with Services...................................................................................... Viewing Services ................................................................................. Understanding the Services Table ....................................................... Searching for Services .........................................................................

251 251 254 256

Working with Client Applications ...................................................................... Viewing Client Applications ................................................................. Understanding the Client Applications Table ....................................... Searching for Client Applications .........................................................

261 262 264 265

Working with Vulnerabilities ............................................................................. Viewing Vulnerabilities......................................................................... Understanding the Vulnerabilities Table .............................................. Deactivating Vulnerabilities.................................................................. Searching for Vulnerabilities ................................................................

267 267 269 271 272

Working with Flow Data and Traffic Profiles ...................... 275 Viewing the Flow Summary Page..................................................................... 277

VERSION 4.7

Understanding Flow Data ................................................................................. Understanding Flow Summary Data.................................................... Understanding Flow Data Graphs........................................................ Understanding Flow Data Tables......................................................... Viewing Flow Data............................................................................... Searching for Flow Data ......................................................................

279 282 283 291 299 299

Manipulating Flow Data Graphs........................................................................ Viewing Aggregated Flow Data ........................................................... Manipulating a Flow Data Graph on a Workflow Page ........................ Drilling Down through a Flow Data Workflow ..................................... Recentering and Zooming on Line Graphs .......................................... Changing the Graph Type .................................................................... Selecting Data to Graph....................................................................... Selecting Datasets............................................................................... Detaching Flow Data Graphs ............................................................... Exporting Flow Data ............................................................................

305 306 307 309 312 313 313 316 318 318


8

Table of Contents

Creating Traffic Profiles ..................................................................................... Providing Basic Profile Information...................................................... Specifying Traffic Profile Conditions .................................................... Adding a Host Profile Qualification ...................................................... Setting Profile Options......................................................................... Saving a Traffic Profile ......................................................................... Activating and Deactivating Traffic Profiles ......................................... Editing a Traffic Profile......................................................................... Understanding Condition-Building Mechanics .....................................

319 323 324 325 328 329 330 330 331

Viewing Traffic Profiles...................................................................................... 337

Chapter 10:

Using RNA as a Compliance Tool ......................................... 340 Understanding Compliance White Lists ........................................................... Understanding White List Targets ....................................................... Understanding White List Host Profiles .............................................. Understanding White List Evaluations................................................. Understanding White List Violations....................................................

342 343 344 348 349

Creating Compliance White Lists ..................................................................... Surveying Your Network...................................................................... Providing Basic White List Information................................................ Configuring Compliance White List Targets ........................................ Configuring Compliance White List Host Profiles................................

350 352 354 355 358

Managing Compliance White Lists ................................................................... 370 Modifying a Compliance White List..................................................... 370 Deleting a Compliance White List ....................................................... 370

VERSION 4.7

Working with Shared Host Profiles................................................................... Creating Shared Host Profiles.............................................................. Modifying a Shared Host Profile .......................................................... Deleting a Shared Host Profile............................................................. Resetting Built-In Host Profiles to Their Factory Defaults ...................

371 371 373 377 377

Working with White List Events ....................................................................... Viewing White List Events................................................................... Understanding the White List Events Table ........................................ Searching for Compliance White List Events ......................................

378 379 381 382

Working with White List Violations................................................................... Viewing White List Violations .............................................................. Understanding the White List Violations Table.................................... Searching for White List Violations......................................................

385 385 388 389


9

Table of Contents

Chapter 11:

Chapter 12:

Configuring Compliance Policies and Rules....................... 392 Creating Rules for Compliance Policies ............................................................ Providing Basic Rule Information......................................................... Specifying Compliance Rule Trigger Criteria........................................ Adding a Host Profile Qualification ...................................................... Adding a Flow Tracker ......................................................................... Adding a User Qualification ................................................................. Adding Snooze and Inactive Periods.................................................... Understanding Rule-Building Mechanics .............................................

394 396 396 411 415 426 428 429

Managing Rules for Compliance Policies .......................................................... Modifying a Rule.................................................................................. Deleting a Rule .................................................................................... Creating a Rule Group.......................................................................... Deleting a Rule Group..........................................................................

437 437 438 438 439

Creating Compliance Policies............................................................................ Providing Basic Policy Information....................................................... Adding Rules and White Lists to a Compliance Policy ........................ Setting Rule and White List Priorities .................................................. Adding Responses to Rules and White Lists.......................................

439 441 441 442 443

Managing Compliance Policies ......................................................................... Activating and Deactivating Compliance Policies ................................ Modifying a Compliance Policy............................................................ Deleting a Compliance Policy ..............................................................

445 446 446 446

Working with Compliance Events..................................................................... Viewing Compliance Events ................................................................ Understanding the Compliance Events Table...................................... Searching for Compliance Events........................................................

447 447 450 452

Configuring Responses for Compliance Policies............... 456 Configuring Alerts ............................................................................................. Creating Alerts ..................................................................................... Modifying Alerts .................................................................................. Deleting Alerts ..................................................................................... Activating and Deactivating Alerts .......................................................

457 460 467 467 468

Assigning Notification Alerts to RNA Events .................................................... 468 Configuring External Alerting on Impact Flags.................................................. 470 Configuring Remediations ................................................................................ Configuring Remediations for Check Point Firewalls........................... Configuring Remediations for Cisco IOS Routers................................ Configuring Remediations for Cisco PIX Firewalls............................... Configuring Nessus Scan Remediations.............................................. Configuring Nmap Remediations......................................................... Configuring Set Attribute Remediations ..............................................

VERSION 4.7


471 473 493 501 506 514 520

10

Table of Contents

Chapter 13:

Working with Remediation Status Events ........................................................ Viewing Remediation Status Events.................................................... Understanding the Remediation Status Table ..................................... Searching for Remediation Status Events ...........................................

524 524 525 527

Configuring Response Groups.......................................................................... Creating a Response Group................................................................. Modifying a Response Group .............................................................. Deleting a Response Group................................................................. Activating and Deactivating Response Groups....................................

530 530 531 532 532

Enhancing RNA Detection ..................................................... 533 Assessing Your Detection Strategy................................................................... Are Your Sensors Correctly Placed? .................................................... Do Unidentified Operating Systems Have a Unique TCP Stack? ........ Can RNA Identify All Services?............................................................ Have You Applied Patches that Fix Vulnerabilities?............................. Do You Want to Track Third-Party Vulnerabilities? ..............................

534 534 534 535 535 536

Using Custom Fingerprinting ............................................................................ Fingerprinting Clients........................................................................... Fingerprinting Servers.......................................................................... Managing Fingerprints ......................................................................... Activating Fingerprints ......................................................................... Deactivating Fingerprints ..................................................................... Deleting Fingerprints ........................................................................... Editing Fingerprints..............................................................................

536 537 543 549 549 550 550 551

Detecting Custom Services.............................................................................. 552 Creating a Service Detector................................................................. 553 Managing Service Detectors ............................................................... 556 Importing Host Input Data ................................................................................ Enabling Use of Third-Party Data ......................................................... Managing Third-Party Product Mappings............................................. Mapping Third-Party Vulnerabilities ..................................................... Managing Custom Product Mappings .................................................

Chapter 14:

559 560 561 566 567

Configuring Active Scanning ................................................ 571 Selecting an Active Scanner ............................................................................. 572 Understanding Nmap Scans ............................................................................. 572 Creating an Nmap Scanning Strategy .................................................. 573 Sample Nmap Scanning Profiles.......................................................... 575 Setting up Nmap Scans .................................................................................... Creating an Nmap Scan Instance......................................................... Creating an Nmap Scan Target ............................................................ Creating an Nmap Remediation...........................................................

VERSION 4.7


578 578 580 581

11

Table of Contents

Managing Nmap Scanning................................................................................ Managing Nmap Scan Instances ......................................................... Managing Nmap Remediations ........................................................... Running an On-Demand Nmap Scan ...................................................

587 587 589 589

Understanding Nessus Scans........................................................................... Understanding Nessus Plugins............................................................ Understanding Nessus Plugin Families ............................................... Understanding Other Sourcefire Nessus Integration Settings ............ Creating a Nessus Scanning Strategy.................................................. Sample Scanning Profiles ....................................................................

591 592 592 597 601 605

Setting up Nessus Scans .................................................................................. Configuring a Local Nessus Server...................................................... Creating a Nessus Scan Instance ........................................................ Creating a Nessus Scan Target............................................................ Creating a Nessus Remediation ..........................................................

609 610 612 614 615

Managing Nessus Scanning ............................................................................. Managing Nessus Scan Instances....................................................... Managing Nessus Remediations ......................................................... Running an On-Demand Nessus Scan.................................................

618 619 621 622

Managing Scan Targets .................................................................................... 623 Editing a Scan Target ........................................................................... 624 Deleting a Scan Target......................................................................... 625 Working with Active Scan Results .................................................................... Monitoring Scans................................................................................. Importing Results ................................................................................ Searching for Scan Results.................................................................. Analyzing Nmap Results ...................................................................... Analyzing Nessus Results.................................................................... Enabling the Nessus Vulnerability Database........................................

Chapter 15:

625 626 626 627 629 630 630

Preparing the Defense Center for RNA Visualizer............. 631 Enabling Remote Database Access.................................................................. 632 Creating RNA Visualizer User Accounts............................................................ 632 Changing RNA Visualizer User Account Passwords ......................................... 634 Modifying RNA Visualizer User Accounts ......................................................... 635 Deleting RNA Visualizer User Accounts............................................................ 635 Deactivating RNA Visualizer User Accounts ..................................................... 636 Activating RNA Visualizer User Accounts ......................................................... 636

VERSION 4.7


12

Table of Contents

Chapter 16:

Introduction to Sourcefire IPS .............................................. 637 Understanding How Traffic Is Analyzed ............................................................ Capturing and Decoding Packets......................................................... Processing Packets.............................................................................. Generating Events ...............................................................................

640 641 642 644

Analyzing Intrusion Event Data ......................................................................... 644 Using Intrusion Event Responses..................................................................... 645 Understanding IPS Deployments...................................................................... 646 The Benefits of Custom Intrusion Policies........................................................ 649

Chapter 17:

Working with Intrusion Events.............................................. 651 Viewing Intrusion Event Statistics .................................................................... Host Statistics...................................................................................... Event Overview ................................................................................... Event Statistics ....................................................................................

653 655 655 656

Viewing Intrusion Event Graphs........................................................................ 657 Viewing Intrusion Events .................................................................................. 658 Understanding the Intrusion Events Table........................................... 659 Viewing Reviewed Intrusion Events.................................................................. 661 Understanding Workflow Pages for Intrusion Events ....................................... 662 Using Drill-Down and Table View Pages ........................................................... 667 Using the Packet View ...................................................................................... Viewing Event Information .................................................................. Viewing Packet Information................................................................. Viewing Data Link Layer Information................................................... Viewing Network Layer Information .................................................... Viewing Transport Layer Information................................................... Viewing Payload Information ...............................................................

673 676 680 681 681 684 686

Using Impact Flags to Evaluate Events ............................................................ 686 Searching for Intrusion Events .......................................................................... 689 Specifying Rule Classifications in Event Searches .............................. 693 Locating Whois Information for a Host ............................................................. 695 Using the Clipboard .......................................................................................... 695 Generating Clipboard Reports.............................................................. 696 Deleting Events from the Clipboard..................................................... 698 Sample Event Analysis ..................................................................................... Logging in and Setting the Time Frame............................................... Searching for High Priority Events ....................................................... Evaluating Events ................................................................................ Searching for Related Events ..............................................................

VERSION 4.7


698 699 700 703 705

13

Table of Contents

Chapter 18:

Handling Incidents .................................................................. 707 Incident Handling Basics................................................................................... Definition of an Incident....................................................................... Common Incident Handling Processes................................................ Incident Types in the Sourcefire 3D System .......................................

708 708 708 711

Creating an Incident.......................................................................................... 712 Editing an Incident ............................................................................................ 714 Generating Incident Reports............................................................................. 715 Creating Custom Incident Types....................................................................... 716

Chapter 19:

Configuring Intrusion Event Responses .............................. 718 Understanding Syslog Alerting ......................................................................... 719 Configuring Syslog Alerting ................................................................. 721 Understanding SNMP Alerting ......................................................................... 722 Configuring SNMP Alerting.................................................................. 724 Understanding Email Alerting ........................................................................... 726 Configuring Email Alerting ................................................................... 729 Responding to Events with a Check Point Firewall........................................... Creating the OPSEC SAM Application................................................. Connecting the 3D Sensor and the SAM Server ................................. Configuring Firewall Responses .......................................................... Enabling and Disabling the SAM Client ............................................... Viewing Sourcefire SAM Client System Information........................... Viewing OPSEC Debug Messages ......................................................

Chapter 20:

730 730 734 738 744 745 745

Creating Intrusion Policies .................................................... 747 Default Intrusion Policies .................................................................................. 749 Planning and Implementing an Intrusion Policy ................................................ 750 Creating an Inline Intrusion Policy..................................................................... 752 Creating a Passive Intrusion Policy ................................................................... 756 Managing Intrusion Policies .............................................................................. 760 Modifying Intrusion Policies................................................................. 760 Deleting Intrusion Policies ................................................................... 764 Applying an Intrusion Policy .............................................................................. 764 Limiting Intrusion Event Notification Per Policy ................................................ 766 Configuring Thresholding per Policy .................................................... 766 Configuring Suppression Per Intrusion Policy...................................... 771

VERSION 4.7


14

Table of Contents

Defining IP Addresses and Ports for Your Network .......................................... 773 Defining IP Addresses in Variables and Rules ..................................... 774 Defining Ports in Variables and Rules .................................................. 777 Configuring Variables ........................................................................................ Understanding Existing Variables ........................................................ Modifying Variables ............................................................................. Creating New Variables ....................................................................... Deleting Unused Variables...................................................................

778 779 781 784 786

Configuring Non-Standard Intrusion Policy Features......................................... 787

Chapter 21:

Configuring Rule States .................................................................................... Understanding Rule Categories ........................................................... Understanding Rule Groups................................................................. Enabling and Disabling Intrusion Rules................................................ Using the Drop Rule State ...................................................................

789 789 792 794 798

Using Latency Thresholding ............................................................................. Adjusting Latency Thresholds for Your Network ................................. Understanding Packet Latency Thresholdng ....................................... Understanding Rule Latency Thresholdng........................................... Configuring Latency Thresholding .......................................................

803 804 804 807 810

Using RNA Recommended Rules..................................................................... Understanding the Network to Examine ............................................. Configuring RNA Recommended Rules .............................................. Accepting Rule State Recommendations ............................................ Blacklisting RNA Rule Recommendations ...........................................

811 813 816 819 829

Importing SEUs and Rule Files ......................................................................... Manually Importing SEUs .................................................................... Automatically Importing SEUs ............................................................. Importing Local Rule Files ................................................................... Viewing the SEU Import Log ...............................................................

833 834 836 837 838

Tuning Preprocessors ............................................................ 846 Challenges to Inspecting Traffic ........................................................................ 848 Understanding Preprocessor Execution Order ................................................. 849 Reading Preprocessor Events........................................................................... 850 Understanding the Preprocessor Event Packet Display ...................... 850 Reading Preprocessor Generator IDs .................................................. 851 Understanding Packet Decoding....................................................................... Validating Checksums.......................................................................... Disabling Decoding Event Alerting ...................................................... Disabling Decode Drops ...................................................................... Detecting Invalid IP Options ................................................................ Detecting Uncommon TCP Options ....................................................

VERSION 4.7


864 864 865 865 865 866

15

Table of Contents

Understanding Network and Link-Layer Preprocessors.................................... 868 Defragmenting IP Packets ................................................................... 869 Understanding Transport-Layer Preprocessors ................................................. Comparing the Stream 4 and Stream 5 Preprocessors ....................... Performing Stateful Inspection on TCP Packets.................................. Reassembling TCP Streams ................................................................ Understanding the Stream 4 Preprocessor ......................................... Understanding the Stream 5 Preprocessor .........................................

873 874 875 876 877 882

Understanding Application-Layer Preprocessors .............................................. Decoding RPC Traffic........................................................................... Decoding HTTP Traffic......................................................................... Decoding SMTP Traffic........................................................................ Decoding FTP and Telnet Traffic.......................................................... Understanding DCE/RPC Traffic Reassembly...................................... Detecting Exploits in DNS Name Server Responses........................... Detecting Encrypted Traffic Using the SSL Preprocessor ...................

889 890 891 905 909 921 924 928

Reporting Decoding Errors ............................................................................... 932 Monitoring Performance ................................................................................... 932 Detecting Back Orifice ...................................................................................... 932 Detecting Portscans.......................................................................................... 933 Configuring Portscan Detection........................................................... 937 Understanding Portscan Events .......................................................... 939 Constraining Regular Expressions .................................................................... 942 Logging Multiple Events per Packet or Stream................................................. 943 Configuring Standard Preprocessor Options .................................................... 943

Chapter 22:

Understanding and Writing Intrusion Rules ....................... 948 Understanding Rule Anatomy........................................................................... 949 Understanding Rule Headers............................................................................ Specifying Rule Actions ....................................................................... Specifying Protocols ............................................................................ Specifying Source and Destination IP Addresses................................ Specifying Source and Destination Ports............................................. Specifying Direction.............................................................................

VERSION 4.7


951 952 953 953 954 956

16

Table of Contents

Understanding Keywords and Arguments in Rules .......................................... 956 Defining Intrusion Event Details .......................................................... 957 Searching for Content Matches........................................................... 962 Constraining Content Matches ............................................................ 964 Using Byte_Jump and Byte_Test ........................................................ 968 Searching for Content Using PCRE ..................................................... 973 Adding Metadata to a Rule .................................................................. 981 Inspecting IP Header Values................................................................ 982 Inspecting ICMP Header Values .......................................................... 986 Inspecting TCP Header Values and Stream Size ................................. 987 Extracting SSL Information from a Session ......................................... 993 Inspecting Application Layer Protocol Values ...................................... 996 Inspecting Packet Characteristics........................................................ 999 Closing Offending Connections with Flexible Response................... 1002 Limiting Event Notification................................................................. 1003 Evaluating Post-Attack Traffic ............................................................ 1005 Detecting Attacks That Span Multiple Packets.................................. 1006 Constructing a Rule ........................................................................................ Writing New Rules............................................................................. Modifying Existing Rules ................................................................... Adding Comments to Rules............................................................... Deleting Custom Rules......................................................................

1008 1008 1011 1013 1013

Searching for Rules .......................................................................................... 1014

Chapter 23:

Rule-Writing Examples and Tips......................................... 1018 Understanding the Rule Creation Process....................................................... 1019 Creating a Simple Rule: Sending Yahoo IM Messages................................... Planning the Rule............................................................................... Defining the Rule Header .................................................................. Defining Detection Options (Keywords) ............................................

1020 1021 1022 1026

Exploring a Complex Rule: Snort ID 1965 ....................................................... 1031 Header Options.................................................................................. 1032 Detection Options.............................................................................. 1034 Understanding Replace Rules......................................................................... 1044 Example: Replacing a Malicious String .............................................. 1045 Example: Replacing a Web Server Banner ........................................ 1048 Rule Writing and Tuning Recommendations................................................... 1051

VERSION 4.7


17

Table of Contents

Chapter 24:

Using Real-time User Awareness ...................................... 1053 Understanding RUA ........................................................................................ How Does RUA Work? ...................................................................... How Do I Choose an RUA Implementation? ..................................... What Information Does RUA Provide? .............................................. How Can You Use RUA? ................................................................... What are the Limitations of Sourcefire RUA?....................................

1054 1054 1063 1067 1068 1073

Configuring RUA .............................................................................................. 1074 Licensing RUA ................................................................................... 1074 Connecting to an LDAP Server .......................................................... 1075 Configuring an RUA Agent on an Active Directory Server................. 1080 Setting up 3D Sensors with RUA ...................................................... 1083

Chapter 25:

Working with RUA Users................................................................................ Viewing RUA Users ........................................................................... Understanding the RUA Users Table................................................. Understanding User Details and Host History ................................... Searching for RUA Users...................................................................

1084 1086 1088 1091 1092

Working with RUA Events .............................................................................. Viewing RUA Events.......................................................................... Understanding the RUA Events Table ............................................... Searching for RUA Events .................................................................

1095 1096 1099 1100

Building and Generating Reports ....................................... 1103 Creating Reports from Event Views ................................................................ 1105 Managing Generated Reports.......................................................................... 1107 Viewing Generated Reports............................................................... 1107 Downloading Generated Reports ...................................................... 1108 Deleting Generated Reports .............................................................. 1108 Understanding Report Profiles......................................................................... 1109 Understanding the Predefined Report Profiles .................................. 1109 Building a Report Profile .................................................................... 1112 Using a Report Profile........................................................................ 1116 Deleting Report Profiles..................................................................... 1119 Running Remote Reports ............................................................................... 1120 Understanding Summary Reports .................................................................. 1121 Adding Logos to the System .......................................................................... 1122

VERSION 4.7


18

Table of Contents

Chapter 26:

Searching for Events ............................................................ 1124 Performing and Saving Searches .................................................................... Performing a Search .......................................................................... Loading a Saved Search..................................................................... Deleting a Saved Search....................................................................

1125 1125 1128 1129

Using Wildcards and Symbols in Searches..................................................... 1129 Specifying Time Constraints in Searches........................................................ 1130 Specifying IP Addresses in Searches.............................................................. 1130 Specifying Subnets with CIDR Notation ............................................ 1131 Specifying Ports in Searches........................................................................... 1132 Specifying Detection Engine/Appliance Names.............................................. 1133

Chapter 27:

Using Custom Tables ............................................................ 1136 Understanding Custom Tables........................................................................ 1137 Understanding Possible Table Combinations .................................... 1137 Creating a Custom Table................................................................................. 1140 Modifying a Custom Table .............................................................................. 1142 Deleting a Custom Table................................................................................. 1143 Viewing a Workflow Based on a Custom Table .............................................. 1143 Searching Custom Tables ............................................................................... 1144

Chapter 28:

Understanding and Using Workflows................................ 1147 Components of a Workflow............................................................................ Comparing Predefined and Custom Workflows ................................ Comparing Workflows for Predefined and Custom Tables ............... Predefined Intrusion Event Workflows.............................................. Predefined RNA Workflows............................................................... Predefined Compliance and White List Workflows ........................... Predefined Flow Data Workflows...................................................... Predefined RUA Workflows............................................................... Additional Predefined Workflows ...................................................... Saved Custom Workflows .................................................................

VERSION 4.7


1148 1149 1150 1150 1154 1156 1156 1158 1159 1159

19

Table of Contents

Using Workflows ............................................................................................ Selecting Workflows.......................................................................... Understanding the Workflow Toolbar................................................ Using Workflow Pages ...................................................................... Setting Event Time Constraints ......................................................... Constraining Events........................................................................... Using Compound Constraints............................................................ Sorting Workflow Pages and Changing Their Layout ........................ Selecting Rows on a Workflow Page ................................................ Navigating to Other Pages in the Workflow ...................................... Navigating between Workflows ........................................................ Using Bookmarks...............................................................................

1161 1162 1165 1165 1169 1170 1173 1174 1174 1175 1175 1177

Using Custom Workflows................................................................................ 1179 Creating Custom Workflows ............................................................. 1179 Creating Custom Flow Data Workflows ............................................ 1181 Viewing Custom Workflows .............................................................. 1184 Editing Custom Workflows................................................................ 1185 Deleting Custom Workflows ............................................................. 1185

Chapter 29:

Managing the System........................................................... 1187 Using System Policies..................................................................................... Creating a System Policy ................................................................... Editing a System Policy ..................................................................... Applying a System Policy................................................................... Deleting System Policies ...................................................................

1189 1190 1191 1192 1192

Configuring the Access List for Your Appliance .............................................. 1193 Configuring Authentication Profiles ................................................................ 1194 Configuring Database Event Limits ................................................................ 1197 Configuring DNS Cache Properties................................................................. 1200 Configuring a Mail Relay Host and Notification Address ................................ 1201 Specifying a Different Language ..................................................................... 1202 Adding a Custom Login Banner ...................................................................... 1203 Configuring RNA Settings ............................................................................... 1204 Synchronizing Time......................................................................................... 1208 Serving Time from the Defense Center............................................. 1210 Configuring the System Settings .................................................................... 1211 Viewing and Modifying the Appliance Information ......................................... 1213 Managing Licenses......................................................................................... 1215 Verifying Your License ....................................................................... 1216 Managing Feature Licenses............................................................... 1217 Configuring Network Settings......................................................................... 1220

VERSION 4.7


20

Table of Contents

Shutting Down and Restarting the System..................................................... 1222 Configuring the Communication Channel ....................................................... 1223 Setting Up the Management Virtual Network ................................... 1224 Editing the Management Virtual Network ......................................... 1225 Configuring Remote Access to the Defense Center ...................................... 1226 Setting the Time Manually .............................................................................. 1229 Blacklisting Health Modules............................................................................ 1230 Specifying NetFlow Devices ........................................................................... 1231 Purging the RNA and RUA Databases ............................................................ 1232 Updating System Software ............................................................................. Installing Software Updates............................................................... Uninstalling Software Updates .......................................................... Updating Sensor Software from the Defense Center .......................

1233 1233 1235 1235

Installing the VDB Update .............................................................................. 1237 Using Backup and Restore.............................................................................. Creating Backup Files ........................................................................ Creating Backup Profiles.................................................................... Performing a Remote Backup with the Defense Center ................... Restoring the Appliance from a Backup File......................................

1239 1240 1243 1244 1245

Restoring the Defense Center to Factory Defaults......................................... 1247 Importing and Exporting Objects .................................................................... 1248 Exporting Objects .............................................................................. 1248 Importing Objects .............................................................................. 1252 Managing Event Streamer Clients .................................................................. 1256 Configuring Event Streamer Event Types.......................................... 1256 Adding Authentication for Event Streamer Clients ............................ 1258 Viewing the Status of Long-Running Tasks..................................................... 1259

Chapter 30:

VERSION 4.7

Managing Users .................................................................... 1261 Understanding Sourcefire User Authentication .............................................. Understanding Internal Authentication .............................................. Understanding External Authentication ............................................. Understanding User Privileges ..........................................................

1261 1263 1263 1264

Managing LDAP Authentication Objects ........................................................ Creating Authentication Objects........................................................ Authentication Object Examples ....................................................... Editing Authentication Objects .......................................................... Deleting Authentication Objects........................................................

1265 1266 1275 1280 1281


21

Table of Contents

Managing User Accounts ............................................................................... Viewing User Accounts ..................................................................... Adding New User Accounts .............................................................. Managing Externally Authenticated User Accounts .......................... Modifying User Privileges and Options ............................................. Modifying Restricted Data Access Properties ................................... Modifying User Passwords................................................................ Deleting User Accounts..................................................................... User Account Privileges.....................................................................

Chapter 31:

1281 1282 1283 1287 1287 1288 1290 1291 1291

Scheduling Tasks .................................................................. 1299 Configuring a Recurring Task .......................................................................... 1300 Automating Backup Jobs ................................................................................ 1302 Automating Software Updates ....................................................................... Automating Software Downloads...................................................... Automating Software Pushes............................................................ Automating Software Installs ............................................................

1304 1305 1306 1308

Automating Vulnerability Database Updates .................................................. Automating VDB Update Downloads ................................................ Automating VDB Update Pushes....................................................... Automating VDB Update Installs .......................................................

1310 1311 1312 1314

Automating SEU Updates............................................................................... 1315 Automating SEU Downloads ............................................................. 1316 Automating SEU Imports................................................................... 1317 Automating Intrusion Policy Applications........................................................ 1318 Automating Reports........................................................................................ 1320 Automating Nessus Scans.............................................................................. 1321 Preparing Your System to Run a Nessus Scan.................................. 1322 Scheduling a Nessus Scan................................................................. 1322 Synchronizing Nessus Plugins ........................................................................ 1324 Automating Nmap Scans ................................................................................ 1325 Preparing Your System for an Nmap Scan ........................................ 1325 Scheduling an Nmap Scan ................................................................. 1326 Automating Acceptance of Recommended Rule States ................................ 1327 Viewing Tasks ................................................................................................. 1329 Using the Calendar ............................................................................ 1329 Using the Task List ............................................................................ 1331 Editing Scheduled Tasks ................................................................................. 1331 Deleting Scheduled Tasks ............................................................................... 1332 Deleting a Recurring Task.................................................................. 1332 Deleting a One-Time Task ................................................................. 1333

VERSION 4.7


22

Table of Contents

Chapter 32:

Monitoring the System ......................................................... 1334 Viewing Host Statistics................................................................................... 1335 Monitoring System Status and Disk Space Usage ......................................... 1339 Viewing System Process Status ..................................................................... 1339 Understanding Running Processes................................................................. 1342 Understanding System Daemons...................................................... 1342 Understanding Executables and System Utilities .............................. 1344 Viewing IPS Performance Statistics................................................................ 1347 Generating IPS Performance Statistics Graphs ................................. 1348 Saving IPS Performance Statistics Graphs ........................................ 1349 Viewing RNA Performance Statistics.............................................................. 1349 Generating RNA Performance Statistics Graphs ............................... 1350 Saving RNA Performance Statistics Graphs ...................................... 1352

Chapter 33:

Using Health Monitoring ...................................................... 1353 Understanding Health Monitoring .................................................................. Understanding Health Policies........................................................... Understanding Health Modules ......................................................... Understanding Health Monitoring Configuration ...............................

1354 1355 1356 1359

Configuring Health Policies ............................................................................. Predefined Health Policies................................................................. Creating Health Policies..................................................................... Applying Health Policies .................................................................... Editing Health Policies ....................................................................... Deleting Health Policies.....................................................................

1360 1361 1364 1382 1384 1386

Using Health Monitor Blacklist........................................................................ 1386 Blacklisting Health Policies or Appliances.......................................... 1387 Blacklisting a Health Policy Module ................................................... 1389 Configuring Health Monitor Alerts .................................................................. Preparing to Create a Health Alert ..................................................... Creating Health Monitor Alerts .......................................................... Interpreting Health Monitor Alerts..................................................... Editing Health Monitor Alerts ............................................................ Deleting Health Monitor Alerts ..........................................................

1390 1391 1391 1392 1393 1394

Using the Health Monitor ............................................................................... 1395 Interpreting Health Monitor Status .................................................... 1396

VERSION 4.7


23

Table of Contents

Using Appliance Health Monitors ................................................................... Interpreting Appliance Health Monitor Status ................................... Viewing Alerts by Status.................................................................... Running All Modules for an Appliance............................................... Running a Specific Health Module..................................................... Generating Health Module Alert Graphs............................................ Generating Appliance Troubleshooting Files .....................................

1396 1398 1398 1399 1400 1401 1402

Working with Health Events ........................................................................... Understanding Health Event Views ................................................... Viewing Health Events....................................................................... Understanding the Health Events Table ............................................ Searching for Health Events ..............................................................

1404 1404 1404 1408 1410

Using the Status Dashboard ........................................................................... 1413 Understanding Status Indicators........................................................ 1414 Configuring the Status Dashboard..................................................... 1421

Chapter 34:

Auditing the System .............................................................. 1423 Managing Audit Records ................................................................................ Viewing Audit Records ...................................................................... Understanding the Audit Log Table ................................................... Searching Audit Records ...................................................................

1424 1424 1426 1426

Viewing the System Log ................................................................................. 1429 Filtering System Log Messages ........................................................ 1430

Appendix A:

...................... Detected Operating Systems and Services 1433 Detected Operating Systems ......................................................................... 1433 Detected Client Applications .......................................................................... 1436 Detected Services .......................................................................................... 1437

Glossary .................................................................................................................. 1439 Index ........................................................................................................................ 1458

VERSION 4.7


24

Chapter 1

Introduction to the Sourcefire 3D System

The Sourcefire 3D System™ provides you with real-time network intelligence for real-time network defense. Sourcefire 3D System has the tools you need to: •

discover the changing assets and vulnerabilities on your network

•

determine the types of attacks against your network and the impact they have to your business processes

•

defend your network in real time

IMPORTANT! Throughout this documentation, you will see references to 3D Sensors. For Nokia customers, this terms refers to the Sourcefire Sensor on Nokia. The topics that follow introduce you to the Sourcefire 3D System and describe some of the key components that contribute to its value as a part of any security strategy for your network.

Version 4.7

•

Components of the Sourcefire 3D System on page 26 provides descriptions of each of the components that may be in your Sourcefire 3D System.

•

Logging into the Appliance on page 30 explains how to access the web interface on your appliance and log in using one of the user accounts.

•

Logging into the Appliance to Set Up an Account on page 32 explains how to set up an association between a external user account and a set of credentials on the appliance.

•

Logging Out of the Appliance on page 33 explains how to log out of the web interface.


25

Introduction to the Sourcefire 3D System Components of the Sourcefire 3D System

Chapter 2

•

Specifying Your User Preferences on page 34 explains how to configure the preferences that are tied to a single user account, such as the account password, the time zone, and the event viewing preferences.

•

Using the Context Menu on page 39 explains how to display a context-specific menu of shortcuts on certain pages in the web interface.

•

Documentation Resources on page 40 explains where to locate specific information about using the Defense Center.

Components of the Sourcefire 3D System The topics that follow introduce you to the Sourcefire 3D System and describe some of the key components that contribute to its value as a part of any security strategy for your network. •

Real-time Network Awareness (RNA) on page 26

•

Intrusion Prevention System (IPS) on page 27

•

Real-time User Awareness (RUA) on page 28

•

Defense Centers on page 28

•

Master Defense Centers on page 29

•

Intrusion Agents on page 29

•

Estreamer on page 29

•

RNA Visualizer on page 29

Real-time Network Awareness (RNA) Sourcefire Real-time Network Awareness (also called RNA) is one of the components of the Sourcefire 3D System that you can use on your 3D Sensor. RNA monitors traffic on your network, using information from detected packets to build a comprehensive map of the devices on the network. You can set up compliance policies, compliance white lists, and traffic profiles to protect your company’s infrastructure by monitoring network traffic for unusual patterns or behavior and automatically responding as needed. You must use a Defense Center to manage a 3D Sensor if it is running RNA. As RNA passively observes traffic, listening to the network segments you specify, it compiles the following information:

Version 4.7

•

the number and types of network devices running on your network

•

the operating systems running on monitored network devices

•

the active services and open ports on monitored network devices


26


Chapter 2

•

the vulnerabilities and exploits to which monitored network devices may be susceptible

•

flow data, which are records of active sessions involving monitored network devices including the frequency and size of the session, as well as the service and protocol used and, if applicable, the client application and URL involved in the session

You can access event views and graphs to analyze this collected data. RNA builds a host profile for each host it detects, containing host details such as detected operating system, services, and protocols, and assigned host attributes. RNA assigns vulnerabilities to the host based on the operating system vendor and version detected for the host. You can access host profiles by browsing the network map or through one of the workflows Sourcefire provides to aid your analysis. 3D Sensors running RNA transmit the network map, event and flow data, and sensor statistics to the Defense Center so you can see a consolidated view of events. The Defense Center can also push health, system, and RNA detection policies to your sensors. You can push vulnerability database (VDB) and software updates from the Defense Center as well. For more information, see What Can Be Managed by a Defense Center? on page 45.

Intrusion Prevention System (IPS) The Sourcefire Intrusion Prevention System (also called IPS) is one of the components of the Sourcefire 3D System that you can run on the 3D Sensor. IPS allows you to monitor your network for attacks that might affect the availability, integrity, or confidentiality of hosts on the network. By placing 3D Sensors on key network segments, you can examine the packets that traverse your network for malicious activity. Each 3D Sensor uses rules, decoders, and preprocessors to look for the broad range of exploits that attackers have developed. 3D Sensors that are licensed to use IPS include a set of intrusion rules developed by the Sourcefire Vulnerability Research Team (VRT). You can choose to enable rules that would detect the attacks you think most likely to occur on your network. You can also create custom intrusion rules tuned to your environment. In addition, 3D Sensors with IPS run preprocessors against detected network traffic to normalize traffic and detect malicious packets. When a 3D Sensor identifies a possible intrusion, it generates an intrusion event, which is a record of the date, time, the type of exploit, and contextual information about the source of the attack and its target. For packet-based events, a copy of the packet or packets that triggered the event is also recorded. In a Sourcefire 3D System deployment that includes 3D Sensors with IPS and a Defense Center, the sensors transmit events and sensor statistics to the Defense Center where you can view the aggregated data and gain a greater understanding of the attacks against your network assets.The Defense Center can also push health, system, and intrusion policies to your sensors. You can push software

Version 4.7


27


Chapter 2

updates from the Defense Center to sensors as well. For more information, see What Can Be Managed by a Defense Center? on page 45. IMPORTANT! The web interface on the Sourcefire 3D Sensor on Nokia allows you to set up management with a Defense Center. All other tasks described in this documentation must be performed with the Defense Center’s web interface. If you deploy your 3D Sensor inline on your network and create what is called an inline detection engine, you can configure your 3D Sensor to drop or replace packets that you know to be harmful.

Real-time User Awareness (RUA) The Real-time User-Awareness component (also called RUA) allows you to create policies and response rules that are user-based. You can apply these policies and rules across the Sourcefire 3D System. As a result, RUA enables you to implement and enforce policies specific to individuals, departments, or other user characteristics. The network protocol used by your organization to provide user authentication largely determines the amount of data and efficiency of RUA. See Using Realtime User Awareness on page 1053 or more information about RUA.

Defense Centers The Defense Center provides a centralized management interface and database repository for the Sourcefire 3D System. You can analyze and respond to events from all your sensors consistently by doing the analysis through an interface where you can see all the data collected by the managed sensors. You can also push policies created on the Defense Center and software updates to managed sensors. If you have software sensors or Intrusion Agents on your network, you must use the Defense Center to manage them. Note that a 3D Sensor running the IPS component includes its own local web interface, but if you want to use RNA on the sensor, you must manage the sensor with a Defense Center. If you use your Defense Center to manage 3D Sensors that run RNA and IPS (either on the same sensor or different sensors that monitor the same network segments), the Defense Center correlates intrusion events from IPS with host vulnerabilities from RNA and assigns impact flags to the intrusion events. Impact correlation lets you focus in on attacks most likely to damage high priority hosts. IMPORTANT! Nokia customers must use the Defense Center to perform the tasks described throughout this documentation.

Version 4.7


28


Chapter 2

Master Defense Centers The Sourcefire Master Defense Center is a key component in the Sourcefire 3D System. You can use the Master Defense Center to aggregate and analyze, intrusion events, compliance events, and white list events from up to ten Defense Centers within your Sourcefire 3D System deployment. The Master Defense Center can also aggregate events related to the health of the Defense Centers it is managing. In this way, you can view the current status of the Defense Centers across your enterprise from a single web interface. See Working with the Master Defense Center on page 73 for more information about managing your Defense Centers with a Master Defense Center.

Intrusion Agents If you have an existing installation of Snort®, you can install an Intrusion Agent to forward intrusion events to a Defense Center. You can then analyze the events detected by Snort alongside your other data. Although you cannot manage policies or rules for an Intrusion Agent from the Defense Center, you can do analysis and reporting on those events. If the network map on the Defense Center has entries for the target host in a given event, the Defense Center assigns impact flags to the events. You can continue to manually tune Snort rules and preprocessors with the Intrusion Agent in place. IMPORTANT!

Intrusion Agents are not currently supported for Nokia customers.

Estreamer You can access event data within your own applications through the Estreamer Application Programming Interface (API). Estreamer integration requires custom programming, but allows you to request specific data from a Defense Center. If, for example, you display network host data within one of your network management applications, you could write a program to retrieve host criticality or vulnerability data from the Defense Center and add that information to your display.

RNA Visualizer When analyzing activity on your network, you can often more quickly identify patterns if you view a visual representation of collected data. The RNA Visualizer allows you to see a dynamic model of the network. IMPORTANT!

Version 4.7

The RNA Visualizer is not currently supported for Nokia customers.


29

Introduction to the Sourcefire 3D System Logging into the Appliance

Chapter 2

You can associate queries with shapes and colors so that you can visually identify the hosts that match the query within the model. For example, if you want to see the hosts running the Windows operating system and running an http service, you can create a query including those criteria, and then assign a ring shape to the query. The RNA Visualizer allows you to expand and collapse the model and zoom in and out to focus on the specific hosts you want to see. You can prune the model to only display those hosts of interest to you. RNA Visualizer also lets you generate graphs depicting traffic between specific hosts and ports. You can also view host information for a selected node or do a whois search on that node. If you configure an Estreamer connection on the Defense Center where you plan to connect the RNA Visualizer, you receive forwarded events in real time.

Logging into the Appliance Requires: Any

The Defense Center has a web-based interface that you can use to perform administrative, management, and analysis tasks. You can access the interface by logging into the Defense Center using a web browser. The current version of the web-based user interface supports the following browsers: •

Firefox version 2.0.x

•

Microsoft Internet Explorer version 6.0 with Service Pack 2

•

Microsoft Internet Explorer version 7.0

In addition, your browser must support JavaScript, cookies, and Secure Sockets Layer (SSL). Note that for Internet Explorer 7.0, you must enable the Active scripting option in the security settings. You must also ensure that SSL v3 and 128-bit encryption are enabled. 3D Sensors also have a web interface. If your 3D Sensor is not licensed for IPS, there is a limited web interface that you can use to perform the initial appliance setup and to register the sensor with a Defense Center. If your 3D Sensor is

Version 4.7


30

Introduction to the Sourcefire 3D System Logging into the Appliance

Chapter 2

licensed for IPS, you are presented with a more complete web interface that you can use to perform additional configuration and event analysis. IMPORTANT! The Nokia version of the 3D Sensor has its own web interface, Network Voyager, which provides you with options to enable the Sourcefire software packages and to configure the sensor’s side of the communications channel to the Defense Center. Otherwise, you must use the Defense Center’s web interface to manage policies and view events.

TIP! Some processes that take a significant amount of time may cause your web browser to display a message that a script has become unresponsive. If this occurs, make sure you allow the script to continue until it finishes.

IMPORTANT! If you are the first user to log into the appliance after it is installed, you must log in using the admin user account. The initial setup process is described in Performing the Initial Setup on page 46. After you log into the appliance, the features that you can access are controlled by the privileges granted to your user account. However, the procedures for logging into and out of the appliance remain the same. When the appliance was installed, the user who performed the installation created a single administrative user account and password. The first time you log into the appliance, you should use this account. After you create other user accounts as described in Adding New User Accounts on page 1283, you and other users should use those accounts to log into the appliance. IMPORTANT! Because the Defense Center and the 3D Sensor audit user activity based on user accounts, you should make sure that users log into the system with the correct account. To log into the appliance: Access: Any

1.

Direct your browser to https://hostname, where hostname corresponds to the host name of the appliance. The Login page appears.

2. In the Username and Password fields, type your user name and password.

Version 4.7


31

Introduction to the Sourcefire 3D System Logging into the Appliance to Set Up an Account

Chapter 2

3. Click Login. The default start page appears. If you selected a new home page for your user account, then that page is displayed instead. See Specifying Your Home Page on page 38 for more information. The menus and menu options that are available to you at the top of the page are based on the privileges for your user account. However, the links on the default home page include options that span the range of user account privileges. If you click a link that requires different privileges from those granted to your account, the following warning message is displayed: You are attempting to view an unauthorized page. This activity has been logged.

You can either select a different option from the available menus or click Back in your browser window.

Logging into the Appliance to Set Up an Account Requires: Any

Some user accounts may be authenticated through an external LDAP directory server. If this is the case, the first time you log into the Defense Center or 3D Sensor using your external user credentials, the appliance associates those credentials with a set of permissions by creating a local user record. The permissions for that local user record can then be modified. If the default role for LDAP user accounts is set to Data access or a higher level of permissions, externally authenticated users can log into the appliance without any additional configuration by the system administrator. However, if an account is externally authenticated and by default receives no access privileges, the login attempt will be denied, but an account will be created on the appliance. You (or your system administrator) can then change the permissions to grant the appropriate access to the appliance. Note that when a shell access user logs into the appliance, it does not create a local user account. Shell access is controlled entirely through the shell access filter or PAM login attribute set for the LDAP server. Shell users should log in using usernames with all lowercase letters. IMPORTANT! The Nokia version of the 3D Sensor has its own web interface, Network Voyager, which provides you with options to enable the Sourcefire software packages and to configure the sensor’s side of the communications channel to the Defense Center. Otherwise, you must use the Defense Center’s web interface to manage policies and view events. To create an externally authenticated account on the appliance:

Access: Any

1.

Direct your browser to https://hostname, where hostname corresponds to the host name of the appliance. The Login page appears.

Version 4.7


32

Introduction to the Sourcefire 3D System Logging Out of the Appliance

Chapter 2

2. In the Username and Password fields, type your user name and password. 3. Click Login. The page that appears depends on the default access role for external authentication: •

If the default access role is Data access or higher, the default start page appears. If you selected a new home page for your user account, then that page is displayed instead. See Specifying Your Home Page on page 38 for more information. The menus and menu options that are available to you at the top of the page are based on the privileges for your user account. However, the links on the default home page include options that span the range of user account privileges. If you click a link that requires different privileges from those granted to your account, the following warning message is displayed: You are attempting to view an unauthorized page. This activity has been logged.

You can either select a different option from the available menus or click Back in your browser window. •

If the default access role is No access, the Login page re-appears, with the following error message: Unable to authorize access. If you continue to have difficulty accessing this device, please contact the system administrator.

4. If you do not have access, contact your system administrator and ask them to modify your account privileges or login as a user with Admin access and modify the privileges for the account. For more information, see Modifying User Privileges and Options on page 1287.

Logging Out of the Appliance Requires: Any

Access: Any

Version 4.7

Make sure you log out of the appliance, even if you are only stepping away from your web browser for a short period of time. Logging out ends your web session and ensures that no one can use the appliance with your credentials. h

To log out of the Defense Center or 3D Sensor, click Logout on the toolbar.


33

Introduction to the Sourcefire 3D System Specifying Your User Preferences

Chapter 2

Specifying Your User Preferences Requires: Any

Users can specify certain preferences for their user account, including passwords, event viewing preferences, time zone settings, and home page preferences. See the following sections for more information: •

Changing Your Password on page 34 explains how to change the password for your user account.

•

Setting Event Preferences on page 35 describes how the event preferences affect what you see as you view events.

•

Setting Your Default Time Zone on page 37 explains how to set the time zone for your user account and describes how that affects the time stamp on the events that you view.

•

Specifying Your Home Page on page 38 explains how to use one of the existing pages as your default home page. After setting this value, this is the first page you see upon logging into the appliance.

Changing Your Password Requires: Any

All user accounts are protected with a password. You can change your password at any time. Note that if password strength-checking is enabled, passwords must be at least eight alphanumeric characters of mixed case and must include at least one numeric character. Passwords cannot be a word that appears in a dictionary or include consecutive repeating characters. IMPORTANT! If you are an LDAP user, you cannot change your password through the web interface. To change your password:

Access: Any

1.

In the toolbar, click Preferences. The User Preferences page appears.

2. Click Change Password. The Change Password page appears.

3. In the Current Password field, type your current password and click Change. 4. In the New Password and Confirm fields, type your new password.

Version 4.7


34


Chapter 2

5. Click Change. A success message appears on the page when your new password is accepted by the system.

Setting Event Preferences Requires: Any

You can configure characteristics of the event pages for intrusion, RNA, compliance, health, and audit events.

Event Display Preferences Preference

Description

Refresh Interval

Requires: Any Sets the refresh interval on event pages. Entering a non-zero value for this option refreshes the list of events. This value defaults to zero, which disables the refresh option.

Statistics Refresh Interval

Requires: IPS or DC/MDC Sets the refresh interval on event summary pages such as Intrusion Event Statistics and RNA Statistics.

Default Intrusion Event Workflow

Requires: IPS or DC/MDC + IPS Controls which of the workflows you use as you analyze intrusion events. You can also select None so that you are prompted to select a workflow each time. You can change your preferred workflow at any time. For more information about workflows, see Understanding and Using Workflows on page 1147.

Default RNA Workflows

Requires: DC + RNA Specifies the workflow you want to use by default for your investigations. You can also select None so that you are prompted to select a workflow each time. You can specify a preferred workflow for each of the following: • RNA Events • RNA Hosts • RNA Services • RNA Flow Data • RNA Client Applications • RNA Host Attributes • RNA Vulnerabilities You can change your workflow at any time. For more information about workflows, see Understanding and Using Workflows on page 1147.

Default Remediation Status Workflow

Version 4.7

Requires: DC + RNA Specifies the workflow you want to use by default to view the status of a remediation. You can also select None so that you are prompted to select a workflow each time. You can view these events by selecting Policy & Response > Responses > Remediations > Status.


35


Chapter 2

Event Display Preferences (Continued) Preference

Description

Default Audit Log Events Workflow

Requires: Any Specifies the workflow you want to use by default to view the events in the audit log. You can also select None so that you are prompted to select a workflow each time.

Default Health Events Workflow

Requires: DC/MDC Specifies the workflow you want to use by default to view health monitoring events. You can view these events by selecting Operations > Monitoring > Health, and then clicking Health Events in the toolbar.

Default Compliance Events Workflow

Requires: DC/MDC + RNA Specifies the workflow you want to use by default to view policy violations. You can also select None so that you are prompted to select a workflow each time. You can view these events by selecting Analysis & Reporting > Compliance > Compliance Events.

Default White List Events Workflow

Requires: DC/MDC + RNA Specifies the workflow you want to use by default to view white list events. You can view these events by selecting Analysis & Reporting > Compliance > White List Events.

Default IS Events with Destination Criticality Workflow

Requires: DC + IPS + RNA Specifies the workflow you want to use by default to view this custom table. You can view these events by selecting Analysis & Reporting > Custom Tables and then clicking View next to the name of the table.

Default IS Events with Source Criticality Workflow

Requires: DC + IPS + RNA Specifies the workflow you want to use by default to view this custom table. You can view these events by selecting Analysis & Reporting > Custom Tables and then clicking View next to the name of the table.

Default Hosts with Services Workflow

Requires: DC + RNA Specifies the workflow you want to use by default to view this custom table. You can view these events by selecting Analysis & Reporting > Custom Tables and then clicking View next to the name of the table.

Deactivate Rules

Requires: IPS or DC/MDC + IPS For events generated by standard text rules, this option controls which links appear on the packet view for intrusion events. • All Policies - a single link that deactivates the standard text rule in all the locally defined custom intrusion policies • Current Policy - a single link that deactivates the standard text rule in only the currently applied intrusion policy. Note that you cannot deactivate a rule in one of the default policies. • Ask - links for each of these options To see these option on the packet view, your user account must have both Data access and Rules access. To configure event preferences:

Access: Any

1.


Version 4.7


36


Chapter 2

2. Click Event View Settings. The Event Preferences page appears. The following graphic shows the Defense Center version of the page.

3. Modify the preferences as needed. 4. Click Save. Your changes are implemented.

Setting Your Default Time Zone Requires: Any

You can change the time zone used to display events from the standard UTC time that the appliance uses. When you configure a time zone, it applies only to your user account and is in effect until you make further changes to the time zone. WARNING! The Time Zone function assumes that the default system clock is set to UTC time. If you have changed the system clock on the appliance to use a local time zone, you must change it back to UTC time in order to view accurate local time on the appliance. For more information about time synchronization between the Defense Center and the sensors, see Synchronizing Time on page 1208.

Version 4.7


37


Chapter 2

To change your time zone: Access: Any

1.


2. Click Time Zone Settings. The Time Zone Preference page appears.

3. From the box on the left, select the continent or area that contains the time zone you want to use. For example, if you want to use a time zone standard to North America, South America, or Canada, select America. 4. From the box on the right, select the zone (city name) that corresponds with the time zone you want to use. For example, if you want to use Eastern Standard Time, you would select New York after selecting America in the first time zone box. 5. Click Save. The time zone is set.

Specifying Your Home Page Requires: Any

You can specify a page within the web interface as your home page for the appliance. To specify your home page:

Access: Any

1.


2. Click Home Page. The Home Page page appears.

Version 4.7


38

Introduction to the Sourcefire 3D System Using the Context Menu

Chapter 2

3. Select the page you want to use as your home page from the Opening Screen drop-down list. The options in the drop-down list are based on the access privileges for your user account. That is, user accounts with Rule Access have different options from accounts with Data Access, Maintenance Access, or Admin Access. TIP! To use the default home page, select None. 4. Click Save. Your home page preference is saved.

Using the Context Menu Requires: Any

For your convenience, certain pages in the web interface support a pop-up context menu that you can use as a shortcut for accessing other features in the Sourcefire 3D System. As the name implies, the contents of the menu depend on the context where you access it. For example, if you access the menu while viewing an RNA event, the context menu provides you with the option to view the event in a separate browser window. However, if you access the context menu while viewing an intrusion event that was triggered by an intrusion rule, you have a range of options that includes enabling, disabling, suppressing, and thresholding the rule. You can also view the rule documentation and edit the rule. You can access the context menu on the following pages. •

Event pages (drill-down pages and table views) contain hotspots over each event.

•

Intrusion policy pages, including the Alerting, Rule State, Suppression, and Threshold pages, contain hotspots over each listed intrusion rule.

•

The Rule Configuration page for intrusion rules contains a hotspot over each intrusion rule.

Note that if you try to access the context menu for a web page or location that doesn’t support the Sourcefire-specific menu, the normal context menu for your browser appears. To access the context menu: Access: Any

1.

On one of the hotspot-enabled pages in the web interface, hover your pointer over one of the hotspots. A “Right-click for menu” message appears.

Version 4.7


39

Introduction to the Sourcefire 3D System Documentation Resources

Chapter 2

2. Right-click your pointing device. A pop-up context menu appears with options that are appropriate for the hotspot. For example, the following menu appears if you right-click over an intrusion event generated by an inline intrusion policy.

3. Select one of the options by left-clicking the name of the option. A new browser window opens based on the option you selected.

Documentation Resources The Sourcefire 3D System documentation set includes online help and PDF files. You can reach the online help in two ways: •

by clicking the context-sensitive help links on each page

•

by selecting Operations > Help > Online.

The online help includes information about the tasks you can complete on the web interface, including procedural and conceptual information about user management, system management, and IPS and RNA analysis. The Documentation CD contains a PDF version of the Sourcefire 3D System User Guide, which includes the same content as the online help, but in an easy-to-print format. The Documentation CD also contains copies of the Defense Center Installation Guide and the 3D Sensor Installation Guide, which includes information about installing the appliance as well as hardware specifications and safety information. You can also access the most up-to-date versions of the documentation on the Nokia support web site (http://support.nokia.com/).

Version 4.7


40


Chapter 2

The following table describes some of the topics explained in the documentation and where to look for more information. For More Information

Version 4.7

To learn more about...

Look in...

late-breaking changes to the product

the release notes, which are available on the Nokia Support web site

installing your appliances

the Installation Guide for the appliance

setting up communication between the Defense Center and sensors

Managing Sensors on page 44

understanding real-time network awareness

Introduction to Sourcefire RNA on page 125

working with the network map

Using the Network Map on page 149

working with host profiles

Using Host Profiles on page 172

evaluating network discovery events

Working with RNA Events on page 210

working with flow data and traffic profiles

Working with Flow Data and Traffic Profiles on page 275

working with compliance white lists

Using RNA as a Compliance Tool on page 340

working with compliance policies and rules

Configuring Compliance Policies and Rules on page 392

creating and managing responses for compliance policies

Configuring Responses for Compliance Policies on page 456

working with RUA in your organization

Using Real-time User Awareness on page 1053

matching RUA information and event collection methods to your authentication environment

How Do I Choose an RUA Implementation? on page 1063

working with RUA information and events

How Can You Use RUA? on page 1068

working with Nessus servers to scan your network for vulnerabilities

Understanding Nessus Scans on page 591


41


Chapter 2

For More Information (Continued)

Version 4.7


Look in...

working with Nmap to scan your network hosts for operating system and service information

Understanding Nmap Scans on page 572

creating custom fingerprints to help identify unknown operating systems

Using Custom Fingerprinting on page 536

understanding IPS concepts

Introduction to Sourcefire IPS on page 637

analyzing intrusion events

Working with Intrusion Events on page 651

setting up a specific set of shared object rules and standard text rules, preprocessor configurations, and variables for one or more 3D Sensors with IPS

Creating Intrusion Policies on page 747

creating and managing incidents

Handling Incidents on page 707

configuring event thresholding and suppression

Limiting Intrusion Event Notification Per Policy on page 766

creating intrusion policies

Creating Intrusion Policies on page 747

customizing variables and configuring standard text rules and shared object rules, which govern how the system evaluates network traffic

Configuring Variables on page 778 and Configuring Rule States on page 789

configuring external notification, including email, syslog, and SNMP alerting, as well as configuring firewall responses to triggered rules

Configuring Intrusion Event Responses on page 718

configuring preprocessors, which normalize packet streams and report on anomalous packets

Tuning Preprocessors on page 846

the different parts of a standard text rule, rule keywords, and how to create your own standard text rules

Understanding and Writing Intrusion Rules on page 948


42


Chapter 2

For More Information (Continued)

Version 4.7


Look in...

using specific standard text rule keywords and to view some standard text rule examples

Rule-Writing Examples and Tips on page 1018

correlating threat, endpoint, and network intelligence with user identity information

Using Real-time User Awareness on page 1053

creating and managing reports

Building and Generating Reports on page 1103

administration tasks, such as managing the event database, creating backups, and performing software updates

Managing the System on page 1187

setting up user accounts and creating authentication objects

Managing Users on page 1261

scheduling tasks

Scheduling Tasks on page 1299

viewing system statistics and checking on system processes

Monitoring the System on page 1334

viewing the messages logged by the system

Auditing the System on page 1423

monitoring the health of your appliances

Using Health Monitoring on page 1353

operating systems and services detected by 3D Sensors with RNA

Detected Operating Systems and Services on page 1433


43

Chapter 2

Managing Sensors

The Sourcefire Defense Center for Nokia is a key component in the Sourcefire 3D System. You can use the Defense Center to manage the full range of sensors that are a part of the Sourcefire 3D System, and to aggregate, analyze, and respond to the threats they detect on your network. By using the Defense Center to manage sensors, you can configure policies for all your sensors from a single location, making it easier to change configurations. In addition, you can push various types of software updates to sensors. You can also push health policies to your managed sensors and monitor their health status from the Defense Center. The Defense Center aggregates and correlates intrusion events, network discovery information, and sensor performance data, allowing you to monitor the information that your sensors are reporting in relation to one another and to assess the overall activity occurring on your network. IMPORTANT! Because the Sourcefire Sensor on Nokia (called the 3D Sensor in this documentation) does not provide a web interface, you must use a Defense Center in your Sourcefire 3D System deployment.

Version 4.7


44

Managing Sensors Management Concepts

Chapter 3

See the following sections for more information about using the Defense Center to manage your sensors: •

Management Concepts on page 45 describes some of the features and limitations involved with managing your sensors with a Defense Center.

•

Working with Sensors on page 48 describes how to establish and disable connections between sensors and your Defense Center. It also explains how to add, delete, and change the state of managed sensors and how to reset management of a sensor.

•

Managing a Sourcefire Sensor on Nokia on page 50 explains how to add, license, and remove Sourcefire Sensors on Nokia and how to reset management for a Sourcefire Sensors on Nokia.

•

Managing Sensor Groups on page 56 describes how to create sensor groups as well as how to add and remove sensors from groups.

•

Editing a Managed Sensor’s System Settings on page 59 describes the sensor attributes you can edit and explains how to edit them.

•

Configuring High Availability on page 63 describes how to set up two Defense Centers as a high availability pair to help ensure continuity of operations.

Management Concepts Requires: DC

Requires: DC

You can use a Defense Center to manage nearly every aspect of a sensor’s behavior. The sections that follow explain some of the concepts you need to know as you plan your Sourcefire 3D System deployment. •

What Can Be Managed by a Defense Center? on page 45

•

Beyond Policies and Events on page 47

•

Using Redundant Defense Centers on page 48

There are several benefits to using a Defense Center to manage your sensors. First, you can use the Defense Center as a central point of management. Instead of managing each sensor using its own local web interface, you can use the Defense Center’s web interface to accomplish nearly any task on any sensor it manages. For example, you can create an intrusion policy on the Defense Center and apply it to all your managed 3D Sensors with IPS. This saves you from having to replicate the intrusion policy on each sensor, which can be a laborious task depending on how many of the thousands of intrusion rules you want to enable or disable. There is a similar savings when you create and apply RNA appliance and detection policies to managed 3D Sensors with RNA.

What Can Be Managed by a Defense Center? Requires: DC

Version 4.7

You must use your Defense Center to manage any Sourcefire Sensors on Nokia.


45


Chapter 3

When you manage a sensor (or a software sensor), information is transmitted between the Defense Center and the sensor over a secure, SSL-encrypted TCP tunnel. The following illustration lists what is transmitted between a Sourcefire Defense Center and its managed sensors. Note that the types of events and policies that are sent between the appliances are based on the sensor type.

Because Sourcefire Sensors on Nokia do not allow you to store configuration and event data the sensors themselves, certain features are not available with these

Version 4.7


46


Chapter 3

sensors. See the Supported Features for Sourcefire Sensors on Nokia table for more information. Supported Features for Sourcefire Sensors on Nokia Supported through the Defense Center • Compliance policy apply • Detection engine management • Health policy apply • High availability synchronization • Host Statistics • Interface set management • Intrusion policy apply • Licensing • Performance Statistics • RNA detection policy apply

Supported through Nokia Network Voyager

Not Supported

• Backup and restore

• Custom fingerprinting

• Network interface management

• Event storage on sensor

• Network settings

• Remote backup and restore

• Process management

• Remote reports

• Registration of remote manager

• System policy apply

• Time settings

• RNA, intrusion, and compliance event collection and management • Reports generated on the Defense Center • Sensor information management (System Settings) • SEU updates • Software updates • VDB updates

Beyond Policies and Events Requires: DC

Version 4.7

In addition to applying policies to sensors and receiving events from them, you can also perform other sensor-related tasks on the Defense Center.


47

Managing Sensors Working with Sensors

Chapter 3

Updating Sensors From time to time, Sourcefire releases updates to the Sourcefire 3D System, including: •

Security Enhancement Updates (SEUs), which can contain new and updated intrusion rules, as well as new and updated preprocessors and protocol decoders

•

vulnerability database updates

•

software patches and updates

You can use the Defense Center to push an update to the sensors it manages and then automatically install the update.

Using Redundant Defense Centers Requires: DC

You can set up two Defense Centers as a high availability pair. This ensures redundant functionality in case one of the Defense Centers fails. Policies, user accounts, and more are shared between the two Defense Centers. Events are automatically sent to both Defense Centers. See Configuring High Availability on page 63 or more information.

Working with Sensors Requires: DC + 3D Sensor

When you manage a sensor, you set up a two-way, SSL-encrypted communication channel between the Defense Center and the sensor. The Defense Center uses this channel to send information (in the form of policies) to the sensor about how you want to analyze your network traffic. As the sensor evaluates the traffic, it generates events and sends them to the Defense Center using the same channel. You can create the following policies on your Defense Center and apply them to managed sensors: •

health policies

•

RNA detection policies

•

intrusion policies

There are several steps to managing a sensor with a Defense Center: 1.

Begin by setting up a communications channel between the two appliances. This is a two-step process, with procedures that you need to perform on each side of the communications channel. See Adding a Sourcefire Sensor on Nokia to the Defense Center on page 51 for more information. (Deleting a Sourcefire Sensor on Nokia from a Defense Center on page 55 explains how to remove a sensor from the Defense Center.)

Version 4.7


48

Managing Sensors Working with Sensors

Chapter 3

2. Create the appropriate policies on the Defense Center and apply them to the sensor or to the appropriate detection engines on the sensor. •

IPS detection engines require an intrusion policy that determines which types of attacks 3D Sensor with IPS detect. See Creating Intrusion Policies on page 747 for more information.

•

RNA detection engines require an RNA detection policy, which controls the networks that 3D Sensors with RNA monitor. See Configuring RNA Detection Policies on page 134 for more information.

•

You can create and apply health policies that allow you to monitor the processes and status of your sensors. See Configuring Health Policies on page 1360 for more information.

3. Confirm that you are receiving the events generated by your sensors. See Viewing Intrusion Event Statistics on page 653 and Viewing RNA Event Statistics on page 211 for more information. Many sensor management tasks are performed on the Sensors page and are described in Understanding the Sensors Page on page 49.

Understanding the Sensors Page Requires: DC + 3D Sensor

The Sensors page (Operations > Sensors) provides you with a range of information and options that you can use to manage your sensors. The following sections describe some of the features on the Sensors page.

Sort-by Drop-Down List Use this drop-down list to sort the Sensors page according to your needs. You can sort by: •

Group (that is, sensor group; see Managing Sensor Groups on page 56)

•

Model (that is, the sensor model)

Sensor List The first column lists the hostname, sensor type, sensor model, and software version for each sensor. You can click the folder icon next to the name of the category to expand and contract the list of sensors.

Health Policy The next column lists the health policy for the sensor, if one has been applied. You can click the name of the health policy to view a read-only version of the policy. See Editing Health Policies on page 1384 for information about modifying an existing health policy.

Version 4.7


49

Managing Sensors Managing a Sourcefire Sensor on Nokia

Chapter 3

Status Icons The status icons indicate the state of a sensor. The green check mark icon indicates that the sensor and the Defense Center are communicating properly. The red exclamation point icon indicates that the Defense Center has not received communications from the sensor in the last three minutes. If you hover your cursor over the icon, a pop-up window indicates the amount of time (in hours, minutes, and seconds) since the last contact. If the Defense Center has not received a communication from a sensor within the last two minutes, it sends a two-byte heartbeat packet to establish contact and ensure that the communications channel is still running. If your network is constrained in bandwidth, you can contact technical support to change the default time interval.

Edit and Delete Icons Click the Edit icon next to a sensor if you want to change the sensor’s current system settings. The system settings include the storage settings for the sensor, the time, the remote management configuration, and access to the processes for stopping and restarting the sensor or its software. See Editing a Managed Sensor’s System Settings on page 59 for more information. If you sort your Sensors page by sensor group, you can click the Edit icon next to the name of a sensor group to modify the list of sensors that belong to the group. See Editing Sensor Groups on page 58 for more information. Click the Delete icon next to a sensor if you no longer want to manage the sensor with the Defense Center. See Deleting a Sourcefire Sensor on Nokia from a Defense Center on page 55 for more information. If you sort your Sensors page by sensor group, you can click the Delete icon next to the name of a sensor group to remove the sensor group from the Defense Center. See Deleting Sensor Groups on page 58 for more information. A message appears indicating that remote management is disabled.

Managing a Sourcefire Sensor on Nokia Requires: DC + 3D Sensor

Version 4.7

You must use a Sourcefire Defense Center for Nokia to manage a Sourcefire Sensor on Nokia. The Network Voyager web interface on the Sourcefire Sensor on Nokia provides you with the tools to enable the Sourcefire Sensor package and


50


Chapter 3

to configure one side of the communications channel to the Defense Center. You must use the Defense Center to complete the setup process including: •

adding the sensor to the Defense Center

•

adding the appropriate feature licenses

•

applying RNA and intrusion policies that control how network traffic is evaluated

•

reviewing the information generated by the sensors

The following diagram illustrates the process:

See the following sections for more information: •

Adding a Sourcefire Sensor on Nokia to the Defense Center on page 51

•

Adding Feature Licenses for a Sourcefire Sensor on Nokia on page 54

•

Deleting a Sourcefire Sensor on Nokia from a Defense Center on page 55

•

Resetting Management of a Sourcefire Sensor for Nokia on page 56

This procedure assumes you have installed and configured the Sourcefire Sensor on Nokia as described in the documentation that accompanies the appliance.

Adding a Sourcefire Sensor on Nokia to the Defense Center Requires: DC + 3D Sensor

To add a Sourcefire Sensor on Nokia to your Sourcefire Defense Center for Nokia, you must first complete steps on both the Sourcefire Sensor on Nokia and the Defense Center. IMPORTANT! This procedure assumes you have installed and configured the Sourcefire Sensor on Nokia as described in the Nokia documentation that accompanies the appliance.

Version 4.7


51


Chapter 3

To add the sensor to the Defense Center: Access: Admin

1.

Log into the Network Voyager web-based interface of the Sourcefire Sensor on Nokia that you want to add to the Defense Center.

2. In the tree view, expand the Sourcefire_Sensor_version_build node and click Sourcefire Sensor. IMPORTANT! If the Sourcefire_3D_version_build node is not available, select System Configuration > Packages > Manage Packages and check that the package is enabled. The Sourcefire Sensor Configuration page appears.

3. Use the Management Interface drop-down list to select the name of the ethernet interface currently set as the management interface on the sensor. 4. In the Management Host field, type the IP address or the host name of the Defense Center that you want to use to manage the sensor. WARNING! Make sure you use hostnames rather than IP addresses if your network uses DHCP to assign IP addresses. In addition, DNS should be configured to use hostnames. See the Network Voyager documentation for information on configuring DNS in Network Voyager. 5. Optionally, in the Registration ID field, type a unique alphanumeric registration ID that you want to use to identify the sensor. TIP! The Registration ID field is optional, but it is especially useful in a network environment that uses network address translation where more than one sensor could have the same IP address. Make sure you use a unique registration ID for each sensor. 6. In the Registration Key field, type the one-time use registration key that you want to use to set up a communications channel between the sensor and the Defense Center.

Version 4.7


52


7.

Chapter 3

In the Management Port field, type the TCP port number you want to use for communications between the Defense Center and the sensor. The default value is 8305/tcp. WARNING! If you change the management port during the initial setup for any appliance in your deployment, make sure you change the port on all the appliances. For more information on changing the management port on the Defense Center, see Configuring the Communication Channel on page 1223.

8. Click Submit. A success message appears indicating that the first part of the registration process is complete. 9. Log into the Defense Center’s web interface using a user account with Admin access, and select Operations > Sensors. The Sensors page appears. 10. Click New Sensor. The Add New Sensor page appears.

11. In the Host field, type the IP address or the hostname of the sensor you want to add. WARNING! Make sure you use hostnames rather than IP addresses if your network uses DHCP to assign IP addresses. 12. If you used an alphanumeric registration ID in step 5, type the same value in the Registration ID field. 13. In the Registration Key field, type the same one-time use registration key that you used in step 6. 14. Because you can store data on only the Defense Center and not the sensor, the Store Events and Packets Only on the Defense Center check box is selected automatically. You cannot change this setting for Sourcefire Sensors on Nokia.

Version 4.7


53


Chapter 3

15. You can prevent packet data from being stored on the Defense Center by checking the Prohibit Packet Transfer to the Defense Center check box. IMPORTANT! If you elect to prohibit sending packet data, it is not retained. Packet data is often important for forensic analysis. 16. To add the sensor to a group, select the group from the Add to Group list. For more information about groups, see Managing Sensor Groups on page 56. 17. Click Add. The sensor is added to the Defense Center. It can take up to two minutes for the Defense Center to verify the sensor’s heartbeat and establish communication. 18. You can view the sensor’s status on the Sensors page (Operations > Sensors). 19. The Defense Center will not receive events from the Sourcefire Sensor on Nokia until you add the appropriate feature licenses to the Defense Center. Continue with the next section, Adding Feature Licenses for a Sourcefire Sensor on Nokia.

Adding Feature Licenses for a Sourcefire Sensor on Nokia Requires: DC + 3D Sensor

Your Sourcefire Defense Center for Nokia will not receive any events from your Sourcefire Sensor on Nokia until you add the appropriate feature licenses: •

To use RNA functionality on the sensor, you must add an RNA host license to the Defense Center.

•

To use the IPS functionality on the sensor, you must add an IPS software license to the Defense Center.

Before beginning, you must have the 12-digit serial number provided by Nokia when you purchased the licensable feature. If you do not have the serial number, contact your Nokia representative. To add a feature license to your Defense Center: Access: Admin

1.

Log into the Defense Center and select Operations > System Settings. The Information page appears.

2. Click License. The License page appears. 3. Click Add New License. The Add Feature License page appears.

Version 4.7


54


Chapter 3

4. Click Get License. The Licensing Center web site appears. IMPORTANT! If your web browser cannot access the Internet, you must switch to a host that can access it. Copy the license key at the bottom of the page and browse to https://www.keyserver.nokia.sourcefire.com. 5. Follow the on-screen instructions for a feature license to obtain your license file, which will be sent to you in an email. 6. After you receive an email with the feature license file, copy the license file from the email, paste it into the License field, and click Submit License. If the license file is correct, the license is added to the appliance, and the licensed feature is available. 7.

Repeat this process for each license you need to add. For example, if you are managing three different Sourcefire Sensors on Nokia, with two of them with IPSs and all three with RNAs, then you must add two IPS software licenses and an RNA host license that is large enough to cover the number of hosts that the sensors will monitor. IMPORTANT! You must also use the Defense Center’s web interface to create interface sets and detection engines for each sensor. See Using Detection Engines and Interface Sets on page 102 for more information.

Deleting a Sourcefire Sensor on Nokia from a Defense Center Requires: DC + 3D Sensor

The following procedure explains how to delete a Sourcefire Sensor on Nokia from your Sourcefire Defense Center for Nokia. To delete a Sourcefire Sensor on Nokia:

Access: Admin

1.

Log into the Defense Center and select Operations > Sensors. The Sensors page appears.

Version 4.7


55

Managing Sensors Managing Sensor Groups

Chapter 3

2. Click Delete next to the Sourcefire Sensor on Nokia that you want to delete. Communication between the sensor and the Defense Center is discontinued and the sensor is removed from the Sensors page. TIP! When you log into the Network Voyager web interface on the Sourcefire Sensor for Nokia, the Defense Center should no longer appear in the Management Host field. However, if communications between the sensor and the Defense Center were interrupted the name or IP address of the Defense Center may continue to be displayed. Click Reset Management to reset the communications channel and delete the registration entry for the Defense Center on the sensor.

Resetting Management of a Sourcefire Sensor for Nokia Requires: DC + 3D Sensor

If communications between the Sourcefire Defense Center for Nokia and the Sourcefire Sensor for Nokia fail, you can reset management of the sensor. You must first submit the Reset Management command in Network Voyager and then supply new registration information. After you re-register the sensor, you need to re-add the sensor to the Defense Center. To reset management on the sensor:

Access: Admin

1.

Log into Network Voyager on the Sourcefire Sensor on Nokia.

2. In the tree view, expand the Sourcefire_3D_4.6_build node and click Sourcefire Sensor. The Sourcefire Sensor Configuration page appears. 3. Select Reset Management and click Submit. The communications configuration settings on the Defense Center and the sensor are deleted. To re-establish the communication tunnel between the sensor and Defense Center, follow the instructions in Adding a Sourcefire Sensor on Nokia to the Defense Center on page 51.

Managing Sensor Groups Requires: DC + 3D Sensor

Version 4.7

The Defense Center allows you to group sensors so that you can easily apply policies and install updates on multiple sensors.


56


Chapter 3


Creating Sensor Groups on page 57 explains how to create a sensor group on the Defense Center.

•

Editing Sensor Groups on page 58 explains how to modify the list of sensors in a sensor group.

•

Deleting Sensor Groups on page 58 explains how to delete a sensor group.

Creating Sensor Groups Requires: DC + 3D Sensor

Grouping managed sensors allows you to configure multiple sensors with a single policy, and update multiple sensors with new software updates at the same time. To create a sensor group and add sensors to it:

Access: Admin

1.

On the Defense Center, select Operations > Sensors. The Sensors page appears.

2. Click Create New Sensor Group. The Create Sensor Group page appears.

3. In the Group Name field, type the name of the group you want to create. 4. Click Save. The group is added. 5. To add sensors to the group, return to the Sensors page (Operations > Sensors) and click Edit next to the name of the sensor group. The Sensor Group Edit page appears.

6. Select the IP addresses or hostnames of the sensors you want to add from the Available Sensors list and click the arrow to move them into sensor group. 7.

Click Save. The sensors are added to the group.

Version 4.7


57


Chapter 3

Editing Sensor Groups Requires: DC + 3D Sensor

You can change the set of sensors that reside in any sensor group. TIP! You must remove a sensor from its current group before you can add it to a new group.

IMPORTANT! Moving a sensor to a new group does not change its policy to the policy previously applied to the group. To change the sensor’s policy, you must apply a new policy to the sensor or sensor group. See Applying an Intrusion Policy on page 764 for details. To edit a sensor group: Access: Admin

1.


2. Click Edit next to the sensor group you want to edit. The Sensor Group Edit page appears.

3. Select the sensor you want to move and click the arrow to add or remove it from the group. •

To add a sensor to the group, select it from the Available Sensors list and click the arrow pointing toward the group you are editing.

•

To remove a sensor from a group, select it from the list in the group you are editing and click the arrow pointing to the Available Sensors list.

4. Click Done.

Deleting Sensor Groups Requires: DC + 3D Sensor

Version 4.7

If you delete a group that contains sensors, the sensors are moved to Ungrouped on the Sensors page. They are not deleted from the Defense Center.


58

Managing Sensors Editing a Managed Sensor’s System Settings

Chapter 3

To delete a sensor group: Access: Admin

1.

Select Operations > Sensors. The Sensors page appears.

2. Click Delete next to the group you want to delete.

Editing a Managed Sensor’s System Settings Requires: DC or 3D Sensor

Each sensor has a number of system settings. When you manage one or more sensors with a Defense Center, you can modify their system settings through the Defense Center’s web interface. To edit the system settings for a managed sensor:

Access: Admin

1.


2. Click Edit next to the name of the sensor where you want to edit the system settings. The Appliance page appears and includes a list of links on the left side of the page that you can use to navigate between pages.

3. See the following sections for more information about setting individual system settings on a managed sensor:

Version 4.7

•

Viewing a Sensor’s Information Page on page 60

•

Stopping and Restarting a Managed Sensor on page 62

•

Managing Communication on a Managed Sensor on page 62

•

Resetting Management of a Sourcefire Sensor for Nokia on page 56

•

Setting the Time on a Managed Sensor on page 63


59


Chapter 3

Viewing a Sensor’s Information Page Requires: DC or 3D Sensor

The Information page for a managed sensor includes the fields described in the Sensor Information table. Sensor Information

Version 4.7

Field

Description

Name

The assigned name for the managed sensor. Note that is the name of the sensor in the Defense Center web interface, not the hostname.

Product Model

The model name for the managed sensor.

Software Version

The version of the software currently installed on the managed sensor.

Store Events Only on Defense Center

Enable this check box to store event data on the Defense Center, but not the managed sensor. Clear this check box to store event data on both appliances.

Prohibit Packet Transfer to the Defense Center

Enable this check box to prevent the managed sensor from sending packet data with the events. Clear this check box to allow packet data to be stored on the DC with events.

Operating System

The operating system currently running on the managed sensor.

Operating System Version

The version of the operating system currently running on the managed sensor.

VDB Version

The version level of the vulnerability database currently loaded on the managed sensor.

IP Address

The IP address of the managed sensor.

Current Policies

The name of the current health policy is listed under Health if you applied one from the Defense Center that manages the sensor. If a policy has been updated since it was last applied, the name of the policy appears in italics.


60


Chapter 3

Sensor Information (Continued) Field

Description

Status

An icon showing the current status of the managed sensor. If you hover your cursor over the icon, a pop-up message indicates how long it has been (in hours, minutes, and seconds) since the sensor communicated with the Defense Center. You can click Refresh to update the Status icon and its accompanying pop-up message.

Model Number

The model number for the sensor. This number can be important for troubleshooting.

Current Group

The sensor group that the sensor belongs to, if any. See Creating Sensor Groups on page 57 for more information.

To edit a managed sensor’s settings: Access: Admin

1.


2. Click Edit next to the name of the sensor whose system settings you want to edit. The Information page for that sensor appears. See the Sensor Information table on page 60 for a description of each field.

Version 4.7


61


Chapter 3

3. Change the sensor’s attributes as needed. You can edit the following: •

the sensor’s hostname

•

the group in which the sensor resides

WARNING! Sensor host names must be made up of a combination of alphanumeric characters and should not be made up of numeric characters only.

IMPORTANT! Changing the name of a Sourcefire Sensor on Nokia only changes the name of the sensor in the Defense Center interface. To change the appliance host name, you must do so through Network Voyager. 4. Click Save. The updated sensor attributes are saved.

Stopping and Restarting a Managed Sensor IMPORTANT! To stop processes on a Sourcefire Sensor for Nokia, use the Network Voyager interface rather than the Defense Center web interface. For more information, see the Nokia Intrusion Prevention Solution User’s Guide available on the CD that shipped with your Nokia IPS appliance.

Managing Communication on a Managed Sensor Requires: DC + 3D Sensor

For most 3D Sensors, you can manage communications between a managed sensor and the Defense Center managing it using the Defense Center’s web interface. To disable communications between the Defense Center and the sensor:

Access: Admin

1.


2. Click Edit next to the name of the sensor that you want to manage. The Information page for that sensor appears. 3. Click Remote Management in the list to the left of the page. The Remote Management page appears.

Version 4.7


62

Managing Sensors Configuring High Availability

Chapter 3

4. Click Disable next to the name of the sensor.

Communications between the two appliances are interrupted. TIP! To enable communications between the two appliances again, click Enable. For information about editing the remote management communications from a sensor refer to Configuring Remote Access to the Defense Center on page 1226.

Setting the Time on a Managed Sensor IMPORTANT! You cannot use the Time page to manage time on a Sourcefire Sensor on Nokia. For more information on managing time settings for a Nokia appliance, see your Nokia documentation.

Configuring High Availability Requires: DC

To ensure the continuity of operations, the high availability feature allows you to designate redundant Defense Centers to manage 3D Sensors. Event data streams from managed sensors to both Defense Centers and certain configuration elements are maintained on both Defense Centers. If one Defense Center fails, you can monitor your network for RNA events, intrusion events, and compliance events without interruption using the second Defense Center. The following configuration elements are shared between two Defense Centers in a high availability pair (also called an HA pair): •

user account attributes and authentication configurations WARNING! If you have user accounts with the same name on both Defense Centers, make sure you remove the user account from one of the Defense Centers before you establish a high availability link. Also, because both Defense Centers have an admin account, you must make sure that the admin account uses the same password on both Defense Centers.

Version 4.7

•

sensor attributes, such as the sensor’s host name, where events generated by the sensor are stored, and the group in which the sensor resides

•

host attributes

•

variable values and custom variables

•

intrusion policies and their associated rule states


63


Chapter 3

•

custom intrusion rule classifications

•

RNA detection policies

•

RNA user feedback, including notes and host criticality; the deletion of hosts, services, and networks from the network map; and the deactivation or modification of vulnerabilities

•

compliance policies and their associated rules

•

compliance white lists

•

traffic profiles

•

health monitoring configurations and policies

•

system policies

•

NetFlow devices (but not NetFlow licenses)

•

activated custom fingerprints

•

authentication objects

To avoid launching duplicate responses and remediations when compliance policies are violated, Defense Centers do not share the associations between the policies and their responses and remediations.You must upload and install any custom remediation modules and configure remediation instances on your secondary Defense Center before remediations are available to associate with compliance policies. If the primary Defense Center fails, you should quickly associate your compliance policies with the appropriate responses and remediations on the secondary Defense Center to maintain continuity of operations. For more information, see Creating Compliance Policies on page 439 and Configuring Remediations on page 471. IMPORTANT! When you restore your primary Defense Center after a failure, if you created associations between rules or white lists and their responses and remediations on the secondary Defense Center, make sure you remove the associations so responses and remediations will only be generated by the primary Defense Center. Note that although Defense Centers in high availability mode are named “primary” and “secondary,” you can make policy or other changes to either Defense Center. Defense Centers periodically update each other on changes to their configurations, and any change you make to one Defense Center should be applied on the other Defense Center within ten minutes. (Each Defense Center has a five-minute synchronization cycle, but the cycles themselves could be out of sync by as much as five minutes, so changes appear within two five-minute cycles.) However, during this ten-minute window, policies may appear incorrectly on the other Defense Center. For example, if you create a policy on your primary Defense Center and apply it to a sensor that is also managed by your secondary Defense Center, the sensor could contact the secondary Defense Center before the Defense Centers contact each other. Because the sensor has a policy applied to it that the secondary

Version 4.7


64


Chapter 3

Defense Center does not recognize, the secondary Defense Center displays a new policy with the name “unknown” until the Defense Centers synchronize. Also, if you make conflicting policy or other changes to both Defense Centers within the same window between Defense Centers syncs, the last change you make takes precedence, regardless of the designations of the Defense Center as primary and secondary. WARNING! Sourcefire recommends that you change configurations only on the primary Defense Center and that you keep your secondary Defense Center as a backup. Defense Centers configured as a high availability pair do not need to be on the same trusted management network, nor do they have to be in the same geographic location. For more information, see Guidelines for Implementing High Availability on page 66. WARNING! By default, Defense Centers use the 172.16.0.0/16 address space to transmit third-party communications such as NTP. If you use that address space within your network, make sure you change the Management Virtual Network setting on the Remote Management page. See Configuring the Communication Channel on page 1223 for more information. See the following sections for more information about setting up high availability.

Version 4.7

•

Guidelines for Implementing High Availability on page 66 outlines some guidelines you must follow if you want to implement high availability.

•

Setting Up High Availability on page 67 explains how to specify primary and secondary Defense Centers.

•

Monitoring the High Availability Status on page 69 explains how to check the status of your linked Defense Centers.

•

Disabling High Availability and Unregistering Sensors on page 70 explains how to permanently remove the link between linked Defense Centers.

•

Pausing Communication between HAed Defense Centers on page 71 explains how to pause communications between linked Defense Centers.

•

Restarting Communication between HAed Defense Centers on page 71 explains how to restart communications between linked Defense Centers.


65


Chapter 3

Guidelines for Implementing High Availability Requires: DC

To take advantage of high availability, you must follow these guidelines. •

You must designate one Defense Center as the primary Defense Center and one as the secondary. Regardless of their designations as primary and secondary, both Defense Centers can be configured with policies, rules, managed sensors, and so on before you set up high availability. TIP! To avoid confusion, start with the secondary Defense Center in its original state. That is, you have not created or modified any policies, nor created any new rules, nor have you previously managed any sensors with it. To make sure the secondary Defense Center is in its original state, use the Restore CD to remove changed settings. Note that this also deletes event and configuration data from the Defense Center.

Version 4.7

•

By default, the Defense Centers use port 8305/tcp for communications. You can change the port as described in Configuring the Communication Channel on page 1223.

•

Both Defense Centers must be running the same software version.

•

The Defense Center software version must be the same or newer than the software version of managed 3D Sensors.

•

3D Sensor health policies are managed from the active Defense Center. Ensure that 3D Sensor information about health policies, modules, blacklists, etc. is synchronized on a newly activated Defense Center.

•

All RNA software sensors managed by Defense Centers in high availability mode must be the same software version.

•

Both Defense Centers must have RNA host licenses if you want to manage 3D Sensors with RNA with the high availability pair.

•

Both Defense Centers must have RUA licenses if you want to manage 3D Sensors with RUA with the high availability pair.


66


•

Chapter 3

The two Defense Centers must have enough NetFlow licenses to merge the list of devices on each, if you want to use NetFlow data to supplement the data gathered by your 3D Sensors with RNA. TIP! Both Defense Centers in a high-availability pair must have NetFlow licenses for at least the number of NetFlow devices you are using. If one Defense Center does not have a NetFlow license, it will not receive data from your NetFlow devices.

•

The two Defense Centers do not need to be on the same network segment, but each of the Defense Centers must be able to communicate with the other and with the sensors they share. That is, the primary Defense Center must be able to contact the secondary Defense Center at the IP address on the secondary Defense Center’s own management interface, and vice versa. In addition, either each Defense Center must be able to contact the sensors it manages or the sensors must be able to contact the Defense Center.

IMPORTANT! Sourcefire strongly recommends that both Defense Centers in an HA pair be the same model. That is, do not attempt to set up high availability between a Defense Center 1000 and a Defense Center 3000.

Setting Up High Availability Requires: DC

To use high availability, you must designate one Defense Center as the primary and another Defense Center of the same model as the secondary. WARNING! Sourcefire recommends that you change configurations only on the primary Defense Center and that you use your secondary Defense Center as a backup. Before you configure high availability, make sure you synchronize time settings between the Defense Centers you want to link. For details on setting time, see Synchronizing Time on page 1208. To set up high availability for two Defense Centers:

Access: Admin

1.

Log into the Defense Center that you want to designate as the secondary Defense Center.

2. Select Operations > Configuration > High Availability. The High Availability page appears.

Version 4.7


67


Chapter 3

3. Click the secondary Defense Center option. The Secondary Defense Center Setup page appears.

4. Type the hostname or IP address of the primary Defense Center in the Primary DC Host text box. 5. Optionally, in the Registration ID field, type a unique alphanumeric registration ID that you want to use to identify the primary Defense Center. TIP! This is especially useful in a network environment that uses network address translation where more than one host could have the same IP address. 6. Type a one-time-use registration key in the Registration Key text box and click Register. A success message appears, and the Peer Manager page appears, showing the current state of the secondary Defense Center. 7.

Using an account with Admin access, log into the Defense Center that you want to designate as the primary.

8. Select Operations > Configuration > High Availability. The High Availability page appears. 9. Click the primary Defense Center option. The Primary Defense Center Setup page appears.

10. Type the hostname or IP address of the secondary Defense Center in the Secondary DC Host text box. 11. If you used a registration ID on the secondary Defense Center, in the Registration ID text box, type the same registration ID that you used before in the registration ID text box.

Version 4.7


68


Chapter 3

12. Type the same one-time-use registration key in the Registration Key text box and click Register. A success message appears, and the Peer Manager page appears, showing the current state of the primary Defense Center. Depending upon the number of policies and custom standard text rules they have, it may take up to 10 minutes before all the rules and policies appear on both Defense Centers. You can view the High Availability page to check the status of the link between the two Defense Centers. See Monitoring the High Availability Status on page 69.

Monitoring the High Availability Status Requires: DC

Once you have identified your primary and secondary Defense Centers, you can use one of them to view status information about the other, including: •

IP address

•

product model

•

operating system

•

operation system version

•

time the Defense Centers last synchronized

To check high availability status: Access: Admin

1.

Log into one of the Defense Centers that you linked using high availability.

2. Select Operations > Configuration > High Availability. The High Availability page appears. 3. Under High Availability Status, you can view the following information about the other Defense Center in the high availability pair:

Version 4.7

•

the IP address

•

the model name

•

the software version

•

the operating system

•

the length of time since the last contact between the two Defense Centers


69


Chapter 3

4. The two Defense Centers automatically synchronize within ten minutes (five minutes for each Defense Center) after any action that affects a shared feature. For example, if you create a new policy on one Defense Center, it is automatically shared with the other Defense Center within 5 minutes. However, if you want to synchronize the policy immediately, click Synchronize. IMPORTANT! If you delete a sensor from a Defense Center configured in a high availability pair and intend to re-add it, Sourcefire recommends that you wait at least five minutes before adding the sensor back. This interval ensures that the high availability pair re-synchronizes first. If you do not wait five minutes, it may take more than one synchronization cycle to add the sensor to both Defense Centers. 5. Click Peer Manager in the toolbar. The Peer Manager page appears.

You can view the following information: •

the IP address of the other Defense Center in the HA pair

•

the status, registered or unregistered, of the communications link

•

the state, enabled or disabled, of the HA pair

For information about editing the remote management communications between the two appliances, refer to Editing the Management Virtual Network on page 1225.

Disabling High Availability and Unregistering Sensors Requires: DC

If you want to remove one of the Defense Centers from a high availability pair, you must first disable the high availability link between them. To disable a high availability pair:

Access: Admin

1.

Log into one of the Defense Centers in the HA pair.

2. Select Operations > Configuration > High Availability. The High Availability page appears.

Version 4.7


70


Chapter 3

3. Select one of the following options from the Handle Registered Sensors dropdown list: •

To control all the managed sensors with the Defense Center where you are accessing this page, select Unregister sensors on the other peer.

•

To control all the managed sensors with the other Defense Center, select Unregister sensors on this peer.

•

To stop managing the sensors altogether, select Unregister sensors on both peers.

4. Click Disable HA. High availability is disabled and any managed sensors are deleted from the Defense Centers according to your selection. You can enable high availability with a different Defense Center as described in Setting Up High Availability on page 67.

Pausing Communication between HAed Defense Centers Requires: DC

If you want to temporarily disable high availability, you can disable the communications channel between the Defense Centers. To disable the communications channel for a high availability pair:

Access: Admin

1.

Click Peer Manager. The Peer Manager page appears.

2. Click Disable to disable the communications channel between the two Defense Centers. For information about editing the remote management communications between the two appliances, refer to Editing the Management Virtual Network on page 1225.

Restarting Communication between HAed Defense Centers Requires: DC

If you temporarily disabled high availability, you can enable the communications channel between the Defense Centers to restart high availability. To enable the communications channel for a high availability pair:

Access: Admin

1.

Click Peer Manager. The Peer Manager page appears.

Version 4.7


71


Chapter 3

2. Click Enable to disable the communications channel between the two Defense Centers. For information about editing the remote management communications between the two appliances, refer to Editing the Management Virtual Network on page 1225.

Version 4.7


72

Chapter 3

Working with the Master Defense Center

The Sourcefire Master Defense Center is a key component in the Sourcefire 3D System. You can use the Master Defense Center to aggregate and analyze intrusion events, compliance events, and white list events from up to ten Defense Centers within your Sourcefire 3D System deployment. You can use the Master Defense Center to build and dispatch global detection and intrusion policies. The Master Defense Center can also aggregate events related to the health of the

Version 4.7


73

Working with the Master Defense Center Understanding Event Aggregation

Chapter 4

Defense Centers it is managing. In this way, you can view the current status of the Defense Centers across your enterprise from a web interface.

The following sections explain more about using a Master Defense Center in your Sourcefire 3D System deployment. •

Understanding Event Aggregation on page 74 explains which types of events you can send from your managed Defense Centers to your Master Defense Center.

•

Understanding Global Policy Management on page 78 explains which policies you can send from your Master Defense Center to 3D Sensors and Defense Centers.

•

Adding and Deleting Defense Centers on page 81 explains how to configure a Defense Center to communicate with a Master Defense Center.

•

Editing Settings for a Managed Defense Center on page 91 explains how to change some of the settings for a Defense Center from the Master Defense Center’s web interface.

•

Managing Appliance Groups on page 96 explains how to use appliance groups to aid in managing 3D Sensors and Defense Centers.

Understanding Event Aggregation Requires: MDC

Version 4.7

A Master Defense Center can aggregate intrusion events and compliance events (including white list events) from up to ten Defense Centers. You can configure a Defense Center to send intrusion events based on their impact flag. You can also choose whether to include the packet data collected with the intrusion events.


74


Chapter 4

The settings on the Filter Configuration page determine which events are forwarded from the Defense Center to the Master Defense Center. You can set up a different configuration for each Defense Center, although most deployments will use the same configuration across the enterprise. See the following sections for more information: •

Aggregating Intrusion Events on page 75

•

Aggregating Compliance Events on page 76

•

Limitations on Event Aggregation on page 76

Aggregating Intrusion Events Requires: MDC

An intrusion event is generated by IPS when it analyzes network traffic and finds one or more packets that violate the currently applied intrusion policy. Packet decoders, preprocessors, and intrusion rules are all able to generate intrusion events. When you use the Filter Configuration page to specify which events are forwarded to the Master Defense Center, you can choose one of the following options: •

Do Not Send - Intrusion events are not forwarded to the Master Defense Center.

•

Events Only - The intrusion events specified in the Impact Flag section are forwarded to the Master Defense Center; however, any packets captured for the event are not sent.

•

Events and Packet Data - The intrusion events specified in the Impact Flag section, along with any related packets, are forwarded to the Master Defense Center.

You can use the Impact Flag section of the Filter Configuration page to forward only the intrusion events that are important to your analysis. For example, you may want to limit the intrusion events on the Master Defense Center to only those with the greatest impact, that is, the red impact flag. If your 3D Sensors are deployed inline and you are using intrusion rules in the Drop State, you may also want to send intrusion events with the black inline result flag. You can also use impact flag settings to reduce the number of intrusion events that are sent to the Master Defense Center in deployments where large numbers of intrusion events are being generated from your 3D Sensors. For example, you can greatly reduce the number of events sent from a Defense Center by excluding events with the blue or gray impact flags. IMPORTANT! You must deploy both RNA and IPS on your network to generate intrusion events with meaningful Impact flags. If you do not deploy 3D Sensors with RNA on your network, then intrusion events are limited to gray impact flags to indicate unknown impact.

Version 4.7


75


Chapter 4

Aggregating Compliance Events Requires: MDC

A compliance event is generated by a Defense Center when the conditions for a compliance rule in an active compliance policy are met. The conditions that can trigger a compliance rule include intrusion events, RNA events, flow data, and anomalous network traffic. When you use the Filter Configuration page to specify which events are forwarded to the Master Defense Center, you can choose to send or not send compliance events. See the following sections for more information: •

Adding a Defense Center on page 84

•

Editing the Event Filter Configuration on page 93

Limitations on Event Aggregation Requires: MDC

The Master Defense Center is a powerful tool for analyzing the potential malicious activity across your enterprise’s network. However, there are certain limitations that you should take into consideration when you design your Master Defense Center deployment. The Master Defense Center and Defense Center Functional Comparison table compares and contrasts Defense Center and Master Defense Center functional areas.

Master Defense Center and Defense Center Functional Comparison Function

Master Defense Center

Defense Center

License provisions

provides product license

provides product license, and NetFlow, RNA and RUA feature licenses

3D Sensor configuration

allows you to configure detection engines

allows you to configure detection engines, interface sets, network interfaces.

Analysis and reporting search

allows you to search for intrusion events, compliance events, white list events, SEU import log, audit log, health events.

allows you search for intrusion events, RNA events, hosts, host attributes, services, client applications, flow data, vulnerabilities, compliance events, white list events, white list violations, remediation status, SEU import log, audit log, health events, scan results, users, and RUA events.

Version 4.7


76


Chapter 4

Master Defense Center and Defense Center Functional Comparison (Continued) Function


Defense Center

Network scans

does not provide for Nessus and Nmap scans.

provides Nessus and Nmap scans and results.

Global policies

allows you to build intrusion policies and to distribute them through connected Defense Centers to their managed 3D Sensors throughout the enterprise

policies are normally downloaded only to their managed 3D Sensors

Event consolidation

allows for collection of events from up to ten Defense Centers

events are collected only from managed 3D Sensors

Data Generated by RNA The Master Defense Center cannot aggregate RNA events or flow data generated by RNA and forwarded to a Defense Center. In addition, the Master Defense Center does not build a network map or host data for the hosts on your network. However, because you can forward compliance events and white list events from your managed Defense Centers to your Master Defense Center, you can gain insight into RNA-detected activity across your enterprise. To take advantage of this, on your Defense Centers you need to build compliance rules and policies that are triggered by the RNA events that interest you and forward the resulting compliance events to the Master Defense Center.

Event Rate The event rate limit for the Master Defense Center is the same rate limit on Defense Centers. This means that if your Defense Centers are accepting events from their 3D Sensors up to the rate limit, you must adjust the event filter on the Master Defense Center so that only the most important events are forwarded from the Defense Centers. For example, in cases where the intrusion event rate is high, you might want to adjust the filter to send only intrusion events with red impact flags. You can also limit the amount of data transferred between a Defense Center and its Master Defense Center by sending only intrusion event data, and not sending the packet data.

Intrusion Agents Intrusion events generated by intrusion agents are not forwarded to the Master Defense Center.

Version 4.7


77

Working with the Master Defense Center Understanding Global Policy Management

Chapter 4

Understanding Global Policy Management Requires: MDC

You can use the Master Defense Center to generate global intrusion policies and coordinate them with potential vulnerabilities detected by RNA policies. Global intrusion policies are beneficial in rapid response scenarios and during enterprise-wide intrusion policy updates. The Master Defense Center sends the policy through a Defense Center to a 3D Sensor’s detection engine. Master Defense Center generated policies are not accessible on an intermediate Defense Center, however if a newer SEU resides on the Master Defense Center than on a Defense Center in the path, then the downstream SEU is updated. This ensures that a global intrusion policies utilize the latest SEU. RNA compares the data it collects and analyzes with its vulnerability database to determine the potential vulnerabilities on the detected host. You can build, apply edit, delete and export RNA on a Master Defense Center. Existing RNA policies are available for viewing so that you can determine: •

RNA policy name and description

•

Detection policy settings such as update interval, if banners and HTTP URLs are captured, if client application are being detected, and so on.

•

Which networks and ports are monitored by the RNA policy

•

If NetFlow is used to generate host information, which networks and NetFlow devices are monitored by NetFlow.

For information on creating and applying as well as deleting RNA policies, refer to Configuring RNA Detection Policies on page 134. You can also import and export compliance policies and rules, custom service decoders, as well as intrusion, system, and health policies. For information on import and export functions, refer to Importing and Exporting Objects on page 1248.

Managing Global Intrusion Policies Requires: MDC

Version 4.7

Refer to the following sections for information about managing intrusion policies: •

Creating an Inline Intrusion Policy on page 752 explains how to create an inline intrusion policy for inline IPS deployments.

•

Creating a Passive Intrusion Policy on page 756 explains how to create a custom passive intrusion policy for passive IPS deployments.

•

Managing Intrusion Policies on page 760 explains how to modify and delete existing intrusion policies.

•

Applying an Intrusion Policy on page 764 explains how to apply a new or updated intrusion policy to the appropriate IPS detection engines.

•

Defining IP Addresses and Ports for Your Network on page 773 provides the syntax used to specify IP addresses and port numbers within the variables and rules in your policy.


78


Chapter 4

•

Configuring Variables on page 778 explains how to create and manage variables that you can use within intrusion policies.

•

Configuring Rule States on page 789 explains how to enable and disable intrusion rules within an intrusion policy. This section also explains how to configure rules in inline intrusion policies so that they drop malicious packets.

•

Importing SEUs and Rule Files on page 833 explains how to download and import Security Enhancement Updates (SEUs) that contain new intrusion rules. Note that SEUs can also contain new and updated decoders and preprocessors.

Using RNA Detection Policies on a Master Defense Center Requires: MDC

You can create, edit, delete, export, and apply RNA detection policies from a Master Defense Center. Refer to the following, for information on the following RNA detection policy functions: •

Creating an RNA Detection Policy on page 138

•

Applying an RNA Detection Policy on page 146

•

Editing an RNA Detection Policy on page 147

•

Deleting an RNA Detection Policy on page 147

Using Health Policies on a Master Defense Center Requires: MDC

You can edit, delete, and apply default health policies to the Master Defense Center and to connected Defense Centers. For information about health policies see the following: •

Understanding Health Monitoring on page 1354

•

Configuring Health Policies on page 1360

•

Using Health Monitor Blacklist on page 1386

•

Configuring Health Monitor Alerts on page 1390

•

Using the Health Monitor on page 1395

•

Using Appliance Health Monitors on page 1396

•

Working with Health Events on page 1404

•

Using the Status Dashboard on page 1413

Refer to Health Policies on page 81 to distinguish the health policy modules that are useful on a Master Defense Center or Defense Center from those that are not, and for brief descriptions of those modules that are used.

Version 4.7


79


Chapter 4

Using System Policies on a Master Defense Center Requires: MDC

System policies allow you to manage the following functions on your Defense Centers or Master Defense Center: •

access configuration

•

authentication profiles (Defense Center only)

•

database limits

•

DNS cache settings

•

the mail relay host and a notification address for database prune messages

•

language selection (English or Japanese)

•

login banner

•

the kinds and amount of RNA data stored in the database (Defense Center only)

•

time synchronization settings

Refer to Using System Policies on page 1189 for information about system policy usage.

Master Defense Center Policy Management Limitations Requires: MDC

There are several types of policies including detection and prevention, RNA detection, RUA detection, and health policies. The Defense Center and Master Defense Center do not handle these policies in the same manner.

Detection and Prevention Policies You can create, edit, delete, export, and apply intrusion detection and prevention policies from a Master Defense Center. The Sourcefire 3D System bases intrusion policies on SEUs residing on the appliance where the policy is built. When you apply an intrusion policy to a 3D Sensor’s detection engines from a Master Defense Center, the Sourcefire 3D System checks for any older SEUs on Defense Center(s) managing those detection engines. If it finds SEUs older than those on the Master Defense Center, they are updated. Therefore, a warning message with a check box appears. After you acknowledge the message by clicking its check box, the Apply button activates.

RNA Detection Policies RNA analysis and reporting functions such as using the network map, listing RNA hosts and events, and listing client applications and vulnerabilities are performed on Defense Centers and not on Master Defense Centers.

Version 4.7


80

Working with the Master Defense Center Adding and Deleting Defense Centers

Chapter 4

RUA Detection Policies There are currently no Real-Time User Awareness functions on a Master Defense Center. RUA functions are available only on properly licensed Defense Centers.

Health Policies The Master Defense Center monitors its health and the health of connected Defense Centers. Master Defense Centers apply health policies only to Master Defense Centers and Defense Centers. Default 3D Sensor, Default IPS, Default IPS (3Dx800 only), and Default RNA Health Policies are not used on the Master Defense Center. Currently, only the generic Default Health Policy is available for editing and application to appliances. For a listing of the health policy modules that apply to Defense Centers, refer to the Enabled Defense Center Health Modules - Default Health Policy table on page 1362. For a listing of the health policy modules that apply to Master Defense Centers, refer to the Enabled MDC Health Modules Default Health Policy table on page 1362. Policies that are not applicable are implicitly disabled when there is an attempt to apply them to a Defense Center or an Master Defense Center. For details about editing appropriate health policies, refer to Editing Health Policies on page 1384.

System Policies System policies are applied only to Master Defense Centers and Defense Centers from a Master Defense Center.

Adding and Deleting Defense Centers Requires: MDC + DC

When you manage a Defense Center with your Master Defense Center, you set up a two-way, SSL-encrypted communication channel between the appliances. The Defense Center uses this channel to send events to the Master Defense Center. As the Defense Center receives events from its sensors, it evaluates which events, based on filter configuration, it should send to the Master Defense Center using the same channel. •

Adding a Defense Center on page 84

•

Deleting a Defense Center on page 87

•

Resetting Management of a Defense Center on page 88

Adding a Master Defense Center Requires: MDC + DC

Version 4.7

You can add a Master Defense Center connection to your Defense Center, however before you do, you must make sure that the network settings are configured correctly on both appliances. This is usually completed as part of the


81


Chapter 4

installation process, but you can refer to Configuring Network Settings on page 1220 for details. Three fields are provided for setting up communications between appliances: •

Management Host - for the hostname or IP address.

•

Registration ID (optional) - for a unique alphanumeric registration ID

•

Registration Key - one-time use registration key

TIP! Set up the managed appliance first. At a Defense Center, add the remote management, then at the managing Master Defense Center add the Defense Center. Valid combinations include: •

Management Host and Registration Key used on both appliances

•

Registration ID and Registration Key used on the Master Defense Center with Management Host, Registration ID and Registration Key used on the Defense Center

•

Management Host, Registration ID and Registration Key used on the Master Defense Center with Registration ID and Registration Key used on the Defense Center.

IMPORTANT! The Management Host field (hostname or IP address) must be used on at least one of the appliance. To add a Master Defense Center, you need to determine which events on the Defense Center you want to forward to the Master Defense Center. To add a Master Defense Center to a Defense Center: Access: Admin

1.

Log into the web interface of the Defense Center you want to add.

2. Select Operations > System Settings. The Information page appears. 3. Click Remote Management. The Remote Management page appears. 4. Click Add Manager. The Add Remote Management page appears.

Version 4.7


82


Chapter 4

5. In the Management Host field, type the IP address or the host name of the Master Defense Center that you want to use to manage the Defense Center. WARNING! Make sure you use hostnames rather than IP addresses if your network uses DHCP to assign IP addresses. 6. Optionally, in the Registration ID field, type a unique alphanumeric registration ID that you want to use to identify the Defense Center. TIP! Although the Registration ID field is marked “optional,” it is especially useful in a network environment that uses network address translation where more than one appliance could have the same IP address. Make sure you use a unique registration ID for each Defense Center. 7.

In the Registration Key field, type the one-time use registration key that you want to use to set up a communications channel between the Master Defense Center and the Defense Center.

8. Click Save. After the Defense Center confirms communication with the Master Defense Center, the Pending Registration status appears.

9. Log into the Master Defense Center’s web interface using a user account with Admin access, and select Operations > Appliances. The Defense Centers page appears. 10. Click New Defense Center. The New Defense Center page appears.

Version 4.7


83


Chapter 4

11. Type the IP address or the hostname of the Defense Center you want to add in the Host field. WARNING! Make sure you use hostnames rather than IP addresses if your network uses DHCP to assign IP addresses. 12. If you used an alphanumeric registration ID in step 6, type the same value in the Registration ID field. 13. In the Registration Key field, type the same one-time use registration key that you used in step 7. 14. Under Filter Configuration, identify the types of events you want to forward from the Defense Center to the Master Defense Center. Note that if you select intrusion events, you can send events or events and packet data. You can also filter which intrusion events are forwarded based on their impact flag. If you chose to send compliance events to the Master Defense Center, white list events are also sent. See Editing the Event Filter Configuration on page 93 for more information. IMPORTANT! You must select at least one type of impact flag if you want to send intrusion events. 15. Click Add. The Defense Center is added to the Master Defense Center. It can take up to two minutes for the Defense Center to establish communication with the Master Defense Center. You can view the status on the Defense Centers page (Operations > Appliances). 16. After communications between the two appliances are established, continue with the procedure in Adding a Defense Center.

Adding a Defense Center Requires: MDC + DC

Before you add a Defense Center to a Master Defense Center, you must make sure that the network settings are configured correctly on both appliances. This is usually completed as part of the installation process. For more information refer to Configuring Network Settings on page 1220. TIP! Set up the managed appliance first. At a Defense Center, add the remote management then at the managing Master Defense Center add the Defense Center.

Version 4.7


84


Chapter 4

Three fields are provided for setting up communications between appliances: •

Management Host - for the hostname or IP address

•


•


Valid combinations include: •


•

Registration ID and Registration Key used on a Defense Center with Management Host, Registration ID and Registration Key used on the Master Defense Center

•

Management Host, Registration ID and Registration Key used on the Master Defense Center with Registration ID and Registration Key used on the Defense Center.

IMPORTANT! The Management Host field (hostname or IP address) must be used on at least one of the appliances. To add a Defense Center, you need to predetermine which events on the Defense Center you want to forward to the Master Defense Center. To add a Defense Center to a Master Defense Center: Access: Admin

1.

Using a user account with Admin access, log into the web interface of the Defense Center you want to add.

2. Select Operations > System Settings. The Information page appears. 3. Click Remote Management. The Remote Management page appears. 4. Click Add Manager. The Add Remote Management page appears.

5. In the Management Host field, type the IP address or the host name of the Master Defense Center that you want to use to manage the Defense Center. WARNING! Make sure you use hostnames rather than IP addresses if your network uses DHCP to assign IP addresses.

Version 4.7


85


Chapter 4

6. Optionally, in the Registration ID field, type a unique alphanumeric registration ID that you want to use to identify the Defense Center. TIP! Although the Registration ID field is marked “optional,” it is especially useful in a network environment that uses network address translation where more than one appliance could have the same IP address. Make sure you use a unique registration ID for each Defense Center. 7.

In the Registration Key field, type the one-time use registration key that you want to use to set up a communications channel between the Master Defense Center and the Defense Center.

8. Click Save. After the Defense Center confirms communication with the Master Defense Center, the Pending Registration status appears.

9. Log into the Master Defense Center’s web interface using a user account with Admin access, and select Operations > Appliances. The Defense Centers page appears. 10. Click New Defense Center. The New Defense Center page appears.

11. Type the IP address or the hostname of the Defense Center you want to add in the Host field. WARNING! Make sure you use hostnames rather than IP addresses if your network uses DHCP to assign IP addresses.

Version 4.7


86


Chapter 4

12. If you used an alphanumeric registration ID in step 6, type the same value in the Registration ID field. 13. In the Registration Key field, type the same one-time use registration key that you used in step 7. 14. Under Filter Configuration, identify the types of events you want to forward from the Defense Center to the Master Defense Center. Note that if you select intrusion events, you can send events or events and packet data. You can also filter which intrusion events are forwarded based on their impact flag. If you chose to send compliance events to the Master Defense Center, white list events are also sent. See Editing the Event Filter Configuration on page 93 for more information. IMPORTANT! You must select at least one type of impact flag if you want to send intrusion events. 15. Click Add. The Defense Center is added to the Master Defense Center. It can take up to two minutes for the Defense Center to establish communication with the Master Defense Center. You can view the status on the Defense Centers page (Operations > Appliances).

Deleting a Defense Center Requires: MDC + DC

If you no longer want to manage a Defense Center, you can delete it from the Master Defense Center. Deleting a Defense Center severs all communication between the Defense Center and the Master Defense Center. To manage the Defense Center again at a later date, you must re-add it to the Master Defense Center. To keep the Defense Center from trying to reconnect to the Master Defense Center, you should also delete the manager on the Defense Center. To delete a Defense Center from the Master Defense Center:

Access: Admin

1.

Log into the Master Defense Center web interface, and select Operations > Appliances. The Defense Centers page appears.

2. Click Delete next to the Defense Center you want to delete. Communication between the Master Defense Center and the Defense Center is discontinued and the Defense Center is deleted from the Defense Centers page. 3. Log into the web interface of the Defense Center you want to delete. 4. Select Operations > System Settings. The Information page appears.

Version 4.7


87


Chapter 4

5. Click Remote Management. The Remote Management page appears. 6. Click Delete next to the Master Defense Center that was managing the Defense Center. The manager is removed.

Resetting Management of a Defense Center Requires: MDC + DC

If communications fail between the Master Defense Center and one of your Defense Centers, you can reset management of the Defense Center. If you want to manage a Defense Center with a different Master Defense Center, you must also reset management before adding the Defense Center to the another Master Defense Center. To do this, you must first delete the manager on the Defense Center and delete the Defense Center on the Master Defense Center. You can then re-add the Master Defense Center on the Defense Center and then add the Defense Center to a Master Defense Center. To reset management from a Master Defense Center:

Access: Admin

1.

Log into the web interface of the Master Defense Center where you want to reset communications.

2. Select Operations > Appliances. The Defense Centers page appears. 3. Click Delete next to the Defense Center you want to delete. Communication between the Defense Center and the Master Defense Center is discontinued and the Defense Center is deleted from the Defense Centers page. To delete management on the Defense Center: Access: Admin

1.

Log into the web interface of the Defense Center where you want to reset communications.

2. Select Operations > System Settings. The Information page appears. 3. Click Remote Management. The Remote Management page appears. 4. Click Delete next to the Master Defense Center where you want to reset management. The manager is removed.

Version 4.7


88


Chapter 4

To re-add the Defense Center to the Master Defense Center: Access: Admin

1.

Log into the web interface of the Defense Center where you want to reset communications and click Add Manager. The Remote Management page appears.

2. In the Management Host field, type the IP address or the host name of the Master Defense Center that you want to use to manage the Defense Center. WARNING! Make sure you use hostnames rather than IP addresses if your network uses DHCP to assign IP addresses. 3. Optionally, in the Registration ID field, type a unique alphanumeric registration ID that you want to use to identify the Defense Center. TIP! Although the Registration ID field is marked “optional,” it is especially useful in a network environment that uses network address translation where more than one appliance could have the same IP address. Make sure you use a unique registration ID for each Defense Center. 4. In the Registration Key field, type the one-time use registration key that you want to use to set up a communications channel between the Defense Center and the Master Defense Center. 5. Click Save. After the Defense Center confirms communication with the Master Defense Center, the Pending Registration status appears. 6. Log into the Master Defense Center’s web interface and select Operations > Appliances. The Defense Centers page appears. 7.

Click New Defense Center. The Add New Defense Center page appears.

8. Type the IP address or the hostname of the Defense Center you want to add in the Host field. WARNING! Make sure you use hostnames rather than IP addresses if your network uses DHCP to assign IP addresses.

Version 4.7


89

Working with the Master Defense Center Using the Appliances Page

Chapter 4

9. If you used an alphanumeric registration ID in step 3, type the same value in the Registration ID field. 10. In the Registration Key field, type the same one-time use registration key that you used in step 4. 11. To add the Defense Center to a group, select the group from the Add to Group list. For more information about Defense Center groups, see Managing Appliance Groups on page 96. 12. Click Add. The Defense Center is added to the Master Defense Center. It can take up to two minutes for the Master Defense Center to verify communication with the Defense Center. You can view the Defense Center’s status on the Defense Centers page (Operations > Appliances).

Using the Appliances Page Requires: MDC + DC

The Appliances page (Operations > Appliances) provides you with a range of information and options that you can use to manage your Defense Centers. The following sections describe the features on the Appliances page.

Sort-by Drop-Down List Use this drop-down list to sort the Appliances page according to your needs. You can sort by: •

Group, which sorts by Appliance group (see Managing Appliance Groups on page 96) TIP! High availability Defense Center pairs are automatically listed as an appliance group. An HA pair is listed as a group named with the name of the active Defense Center.

•

Manager, which sorts by the Defense Center then the 3D Sensor connected to it.

•

Model, which sorts by appliance model number, that is, the Defense Center 1000 and the Defense Center 3000, 3D Sensor 2100, and so on.

Status Icons The status icons indicate the state of a Defense Center. The green check mark icon indicates that the Master Defense Center and the Defense Center are communicating properly. The red exclamation point icon indicates that the Master

Version 4.7


90

Working with the Master Defense Center Editing Settings for a Managed Defense Center

Chapter 4

Defense Center has not received communications from the Defense Center in the last three minutes. If you hover your cursor over the icon, a pop-up window indicates the amount of time (in hours, minutes, and seconds) since the last contact. If the Master Defense Center has not received a communication from a Defense Center within the last two minutes, it sends a two-byte heartbeat packet to establish contact and ensure that the communications channel is still running. If your network is constrained in bandwidth, you can contact technical support to change the default time interval.

Edit and Delete Icons Click the Edit icon next to a sensor if you want to change the Defense Center’s current system settings. The system settings include the filter configuration for the Defense Center, the remote management configuration, the health blacklist settings, and the high availability settings. See Editing Settings for a Managed Defense Center on page 91 for more information. Click the Delete icon next to a Defense Center if you no longer want to manage the Defense Center with the Master Defense Center. See Deleting a Defense Center on page 87 for more information.

Editing Settings for a Managed Defense Center Requires: MDC + DC

After you configure management of a Defense Center by a Master Defense Center, you can use the Master Defense Center web interface to view and edit the configuration of the Defense Center. See the following sections for more information. •

Viewing the Defense Center Information Page on page 91

•

Editing the Event Filter Configuration on page 93

•

Editing or Disabling Remote Management Communications on page 94

•

Managing the Health Blacklist on page 95

•

Managing High Availability Defense Centers on page 95

Viewing the Defense Center Information Page Requires: MDC + DC

Version 4.7

To access the system settings information page for a managed Defense Center, select Appliances from the Operations menu, then click Edit next to the Defense


91


Chapter 4

Center. The Information page for a managed Defense Center includes the fields described in the Defense Center Information table. Defense Center Information Field

Description

Name

The assigned name for the Defense Center. Note that this is the name of the Defense Center in the Master Defense Center web interface, not the hostname.

Product Model

The model name for the managed Defense Center.

Software Version

The version of the software currently installed on the managed Defense Center.

Operating System

The operating system currently running on the managed Defense Center.


The version of the operating system currently running on the managed Defense Center.

VDB Version

The Vulnerability Database version on the managed Defense Center.

IP Address

The IP address of the managed Defense Center.

Status

An icon showing the current status of the managed Defense Center. If you hover your cursor over the icon, a pop-up message indicates how long it has been (in hours, minutes, and seconds) since the Defense Center communicated with the Master Defense Center. You can click Refresh to update the Status icon and its accompanying pop-up message.

Version 4.7

Model Number

The model number for the Defense Center. This number can be important for troubleshooting.

Current Group

The group that the Defense Center belongs to, if any.


92


Chapter 4

To edit a managed Defense Center’s settings: Access: Admin

1.

Change the Defense Center’s attributes as needed. You can edit the following: •

the name of the Defense Center

•

the group in which the Defense Center resides

WARNING! The name must be made up of a combination of alphanumeric characters and should not be made up of numeric characters only. 2. Click Save. The updated Defense Center attributes are saved.

Editing the Event Filter Configuration Requires: MDC

The settings on the Filter Configuration page control which events are sent from the Defense Center to the Master Defense Center that manages it. Your options are to send intrusion events, intrusion events and related packet data, and compliance events. If you want to send intrusion events (with or without packet data), you can also specify which intrusion events are sent based on their impact flag. See the Impact Flags table on page 687 for an explanation of what each impact flag means. Note that you must deploy both RNA and IPS as part of your Sourcefire 3D System deployment to generate meaningful impact flags. To modify the event filter configuration:

Access: Admin

1.

On the Master Defense Center’s web interface, select Operations > Appliances. The Appliances page appears.

2. Next to the Defense Center whose filter configuration you want to change, click Edit. The Filter Configuration page appears.

Version 4.7


93


Chapter 4

3. In the Intrusion Events area, use the drop-down list to indicate whether you want to forward intrusion events to the Master Defense Center. The options are Do Not Send, Events Only, and Events and Packet Data. 4. If you indicated that you want to send intrusion events, then you must specify which events you want to send based on their impact flag. The Impact Flag options are: •

All

•

Black (or Drop)

•

Red (or Vulnerable)

•

Orange (or Potentially Vulnerable)

•

Yellow (or Currently Not Vulnerable)

•

Blue (or Unknown Target)

•

Gray (or Unknown)

TIP! If you select All, then all the options are immediately selected. If you want to send intrusion events to the Master Defense Center, then you must select at least one impact flag option. 5. In the Compliance Events area, use the drop-down list to indicate whether you want to forward compliance events to the Master Defense Center. The options are Do Not Send and Send. 6. Click Save. Your settings are saved and the Defense Center begins forwarding the events you specified to the Master Defense Center that manages it.

Editing or Disabling Remote Management Communications Requires: MDC + DC

You can manage communications between a managed Defense Center and its Master Defense Center using the Master Defense Center’s web interface. For example, if a Defense Center is no longer responding, you can temporarily disable communications between the Defense Center and its Master Defense Center. IMPORTANT! Master Defense Centers do not currently use a Management Virtual Network. You cannot edit the Management Virtual Network field of a Master Defense Center. The field is filled with 0.0.0.0/24 to indicate that the Management Virtual Network is disabled on a Master Defense Center. To disable communications between the Defense Center and the Master Defense Center:

Access: Admin

h

Click Disable next to the name of the Defense Center. Communications between the two appliances are interrupted. To enable communications between the two appliances again, click Enable.

Version 4.7


94


Chapter 4

For more information about editing the Management Virtual Network, refer to Editing the Management Virtual Network on page 1225.

Managing the Health Blacklist Requires: MDC + DC

You can blacklist individual health policy modules on Defense Centers. You may want to do this to prevent events from the module from changing the status for the appliance to warning or critical. For information on using the blacklisting function, refer to Using Health Monitor Blacklist on page 1386.

Managing High Availability Defense Centers Requires: MDC + DC

You can configure, monitor, disable, pause and restart Defense Center High Availability from a Defense Center. See the following sections for more information: •

Using Redundant Defense Centers on page 48

•

Setting Up High Availability on page 67

•

Monitoring the High Availability Status on page 69

•

Disabling High Availability and Unregistering Sensors on page 70

•

Pausing Communication between HAed Defense Centers on page 71

•

Restarting Communication between HAed Defense Centers on page 71

If High Availability is configured, you can activate Defense Center High Availability from a Master Defense Center. To activate a redundant Defense Center: Access: Admin

1.

Select Operations > Appliances. The Appliances page appears.

2. Click Edit next to the appropriate Defense Center. The System Settings page for that Defense Center appears. 3. Click High Availability. The high availability page appears with the paired Defense Centers.

TIP! A light bulb icon shows which of the high availability paired Defense Centers is currently active.

Version 4.7


95

Working with the Master Defense Center Managing Appliance Groups

Chapter 4

4. Click Activate to activate the redundant Defense Center. The redundant Defense Center is activated.

Managing Appliance Groups Requires: MDC

The Master Defense Center allows you to group Appliances so that you can easily search for events based on whether they were forwarded by one of a specific group of Appliances. TIP! High availability Defense Center pairs are automatically listed as an appliance group. An HA pair is listed as a group with the name of the active Defense Center. See the following sections for more information: •

Creating Appliance Groups on page 96 explains how to create a Defense Center group on the Master Defense Center.

•

Editing Appliance Groups on page 97 explains how to modify the list of Defense Centers in a Defense Center group.

•

Deleting Appliance Groups on page 97 explains how to delete a Defense Center group.

Creating Appliance Groups Requires: MDC

Grouping managed appliances allows you to use the group name as a search criteria when you search for specific compliance or intrusion events. To create a appliance group and add appliances to it:

Access: Admin

1.

On the Master Defense Center, select Operations > Appliances. The Appliances page appears.

2. Click Create New Appliance Group. The Create Appliance Group page appears. 3. In the Group Name field, type the name of the group you want to create. 4. Click Save. The group is added. 5. To add appliances to the group, return to the Appliances page (Operations > Appliances) and click Edit next to the name of the group. The Appliance Group Edit page appears. 6. Select the IP addresses or hostnames of the appliances you want to add from the Available Appliances list and click the arrow to move them into the group.

Version 4.7


96

Working with the Master Defense Center Managing Appliance Groups

7.

Chapter 4

Click Save. The Appliances are added to the group and the Appliances page appears again.

Editing Appliance Groups Requires: MDC

You can change the set of appliances that reside in any appliance group. TIP! You must remove an appliance from its current group before you can add it to a new group.

IMPORTANT! Moving an appliance to a new group does not change any of its policies or configurations. To edit an Appliance group: Access: Admin

1.

On the Master Defense Center, select Operations > Appliances. The Appliances page appears.

2. Click Edit next to the Appliance group you want to edit. The Appliance Group Edit page appears. 3. Select the appliance you want to move and click the arrow to add or remove it from the group. •

To add an appliance to the group, select it from the Available Appliances list and click the arrow pointing toward the group you are editing.

•

To remove an appliance from a group, select it from the list in the group you are editing and click the arrow pointing to the Available Appliances list.

4. Click Save.

Deleting Appliance Groups Requires: MDC

If you delete a group that contains appliances, the appliances are moved to Ungrouped on the Appliances page. They are not deleted from the Master Defense Center. To delete as appliance group:

Access: Admin

1.

Select Operations > Appliances. The Appliances page appears.

2. Click Delete next to the group you want to delete. The appliances group is removed from the Master Defense Center.

Version 4.7


97

Working with the Master Defense Center Editing Master Defense Center System Settings

Chapter 4

Editing Master Defense Center System Settings Requires: MDC

With a few exceptions, the Master Defense Center system settings are the same as those of a Defense Center. See the following sections for information on each of the listed system settings: •

Listing Master Defense Center Information on page 98

•

Viewing a Master Defense Center License on page 98

•

Configuring Network Settings on page 1220

•

Shutting Down and Restarting the System on page 99

•

Setting System Time on page 100

•

Blacklisting Health Policies on page 100

•

NetFlow devices cannot currently be added to a Master Defense Center.

Listing Master Defense Center Information Requires: MDC

For details on information listed under the Master Defense Center system settings, see Defense Center Information on page 92. To edit a Master Defense Center’s settings: h

Change the name of the Master Defense Center attributes as needed. WARNING! The name must be made up of a combination of alphanumeric characters and should not be made up of numeric characters only. Click Save. The updated Master Defense Center attributes are saved.

Viewing a Master Defense Center License Requires: MDC

Unlike a Defense Center, a Master Defense Center cannot manage the licenses of Defense Centers or 3D Sensors. To view information about the Master Defense Center license:

Access: Admin

1.

Select Operations > System Settings. The Information page appears.

2. Click License. The License page appears.

Version 4.7


98


Chapter 4

Configuring Network Settings Requires: MDC

The network settings are identical to those of the Defense Center. For information on configuring the Master Defense Center network settings, see Configuring Network Settings on page 1220.

Shutting Down and Restarting the System Requires: MDC

You have several options for controlling the processes on your Master Defense Center. You can: •

shut down the appliance

•

reboot the appliance

•

restart the appliance

To shut down or restart your appliance: Access: Admin

1.


2. Click Process. The Appliance Process page appears.

3. Specify the command you want to perform:

Version 4.7

•

If you want to shut down the Master Defense Center, click Run Command next to Shutdown Master Defense Center.

•

If you want to reboot the system, click Run Command next to Reboot Master Defense Center.

•

If you want to restart the Defense Center, click Run Command next to Restart Master Defense Center Console. Note that restarting the Defense Center may cause deleted hosts to reappear.


99


Chapter 4

Configuring Remote Management Networking Requires: MDC

A Master Defense Center’s Management Virtual Network is disabled. IMPORTANT! Master Defense Centers do not currently use a Management Virtual Network. You cannot edit the Management Virtual Network field if the Defense Center is in the Master Defense Center operational mode. The field is filled with the address range 0.0.0.0/24 to disable the Management Virtual Network.

Setting System Time Requires: MDC

The system time is set and synchronized in accordance with the system policy. On the Time Synchronization page you can choose to serve time from the Master Defense Center by selecting Enabled in the Serve Time via NTP field. TIP! Because Master Defense Centers do not currently use Management Virtual Networks, their real IP network is used to serve time. To specify how the Master Defense Center clock is set:

Access: Admin

h

You have two options: •

To set the time manually, select Manually in the System Settings.

•

To receive time through NTP from a different server, select Via NTP Server from and, in the text box, type the IP address of the NTP server or, if DNS is enabled, type the fully qualified host and domain name.

WARNING! If the appliance is rebooted and your DHCP server sets an NTP server record different than the one you specify here, the DHCP-provided NTP server will be used instead. To avoid this situation, you should configure your DHCP server to set the same NTP server. For more information about setting system time, refer to Synchronizing Time on page 1208.

Blacklisting Health Policies Requires: MDC

Version 4.7

You can blacklist health policy modules when required. The Master Defense Center only supports the following health policy modules: •

Appliance Heartbeat

•

CPU Usage

•

Data Correlator Process


100


•

Defense Center Status

•

Disk Usage

•

Estreamer Process

•

Event Stream Status

•

Memory Usage

Chapter 4

For more information on blacklisting a health policy, refer to Blacklisting a Health Policy Module on page 1389.

Version 4.7


101

Chapter 4

Using Detection Engines and Interface Sets

To give you increased flexibility in your deployment choices, the Sourcefire 3D System provides a feature called the detection engine. You can think of a detection engine as a collection of one or more sensing interfaces (called an interface set) on a 3D Sensor plus a portion of the sensor’s computing resources (called a detection resource). 3D Sensors support three types of detection engines: •

IPS

•

RNA

•

RUA

The number of detection engines per sensor is limited by the number of detection resources that are available. Most 3D Sensor models have at least three detection resources available and can support at least three detection engines: one for IPS, one for RNA, and the third for RUA. The following sections describe the detection engines and interface set features and how you can use them in your Sourcefire 3D System deployment:

Version 4.7

•

Understanding Detection Engines on page 103 explains detection engines in more detail, including some of the limitations based on the sensor model. This section also describes how the default detection engine is configured.

•

Managing Detection Engines on page 105 explains how to create, edit, and delete detection engines.

•

Using Detection Engine Groups on page 109 explains how to create and use detection engine groups.


102

Using Detection Engines and Interface Sets Understanding Detection Engines

Chapter 5

•

Using Variables within Detection Engines on page 110 explains how to use detection engine-specific variables with intrusion policies.

•

Using Interface Sets on page 114 describes how to create interface sets and how to use them with detection engines.

•

Editing Network Interfaces on page 120 explains how to view and modify the settings for the network interfaces on your Sourcefire 3D System appliances.

•

Configuring Non-Standard Detection Engine Features on page 121 describes how to use a reserved variable to configure IPS features that are not accessible through the user interface.

Understanding Detection Engines Requires: DC or 3D Sensor

A detection engine is the mechanism on a 3D Sensor that is responsible for analyzing the traffic on the network segment where the sensor is connected. Depending on which components are licensed on the sensor, 3D Sensors can support three types of detection engines: IPS, RNA, and RUA. A detection engine has two main components: •

an interface set, which can include one or more sensing interfaces

•

a detection resource, which is a portion of the sensor’s computing resources

Depending upon the model, some 3D Sensors with IPS can use multiple detection resources per detection engine, which allows you to use more computing resources when network traffic is high. RNA and RUA detection engines are limited to single detection resources per detection engine. An interface set refers to a grouping of one or more sensing interfaces on a sensor, although a sensing interface can belong to only one interface set at a time. The Sourcefire 3D System supports three types of interface sets, but the interface options available to you depend on the type of sensor and the capabilities of its sensing interfaces. The three interface types are described in the Interface Set Types table. Interface Set Types

Version 4.7

Type

Description

Passive

Use a passive interface set if you deployed the sensor out of band from the flow of network traffic.


103

Using Detection Engines and Interface Sets Understanding Detection Engines

Chapter 5

Interface Set Types Type

Description

Inline

Use an inline interface set if you deployed the sensor inline on your network and the sensing interfaces do not support automatic fail-open capabilities. Note that you can use any two of the non-fail-open interfaces on the sensor’s network interface cards as part of an inline interface set.

Inline with Fail Open

Use an inline with fail open interface set if you deployed the sensor inline on your network and the sensing interfaces do support automatic fail-open capabilities. Note that you must use paired fail-open interfaces on the sensor’s network interface cards for an inline with fail open interface set.

You can use RNA or RUA to monitor the traffic that passes through any of the three types of interface sets. See Using Interface Sets on page 114 for more information about creating and editing interface sets. When you configure a new sensor, it has a predefined detection engine that you can choose to modify to meet your needs. See Understanding Default Detection Engines for more information.

Understanding Default Detection Engines Requires: DC or 3D Sensor

When you install a new 3D Sensor, a default IPS detection engine is created and applied to a passive interface set. This allows you to quickly begin evaluating network traffic.

Default IPS Detection Engine without RNA If you choose a passive interface set without RNA, then the default detection engine is configured with a single detection resource.

Default Detection Engine with IPS and RNA If a passive interface set with RNA is chosen then the two detection engines are configured with one IPS detection engine and one RNA detection engine, each with a single detection resource.

Default Detection Engine with Inline Fail Open IPS and without RNA If the hardware is capable and an inline fail open interface set without RNA is chosen then a detection engine is created for each interface pair .

Version 4.7


104

Using Detection Engines and Interface Sets Managing Detection Engines

Chapter 5

Default Detection Engine with Inline Fail Open IPS and with RNA If the hardware is capable and an inline fail open interface set with RNA is chosen then a detection engine is created for each interface pair and one is set aside for RNA. With this configuration, you can connect any of the non-management interfaces to your network and apply the appropriate policy to the detection engine (for IPS detection engines, apply a passive intrusion policy; for RNA, apply an RNA detection policy), and begin analyzing your network. If you want to change either the number of detection resources or the interfaces assigned to the default detection engine, see Editing a Detection Engine on page 107.

Managing Detection Engines Requires: DC/MDC or 3D Sensor

The following sections explain how to create, edit, and delete detection engines. See Understanding Detection Engines on page 103 and Using Interface Sets on page 114 for more information about the capabilities of detection engines and the interface sets they depend on. •

Creating a Detection Engine on page 105

•

Editing a Detection Engine on page 107

•

Deleting a Detection Engine on page 108

Creating a Detection Engine Requires: DC or 3D Sensor

Version 4.7

You can create a detection engine if you have an available interface set and at least one available detection resource.


105


Chapter 5

To create a detection engine: Access: Admin

1.

Select Operations > Configuration > Detection Engines > Detection Engines. The Detection Engines page appears. The figure below shows the Defense Center version of the page.

2. Click Create Detection Engine. The Create Detection Engine page appears.

3. In the Name and Description fields, enter a name and description for the new detection engine. You can use alphanumeric characters, punctuation, and spaces. 4. Select the type of detection engine that you want to create from the Type drop-down list, IPS, RNA, or RUA. 5. Optionally, add the detection engine to an existing detection engine group. See Using Detection Engine Groups on page 109 for information on creating and modifying detection engine groups. 6. Select the interface set that you want to assign to this detection engine. See Using Interface Sets on page 114 for information about creating and modifying interface sets.

Version 4.7


106


Chapter 5

Select the number of detection resources for this detection engine.

7.

8. Click Save. The detection engine is created.

Editing a Detection Engine Requires: DC or 3D Sensor

In some circumstances, editing an interface set or detection engine can cause the detection engines on the sensor to restart, which can cause a short pause in processing. IMPORTANT! For 3D Sensors with inline interface sets, a software bridge is automatically set up to transport packets when the sensor restarts. Although some packets are transmitted without inspection during this time, no packets are lost. The following are cases where a detection engine is affected by changes to the detection engines and interface sets: •

If you change which network interfaces are used by an interface set, all the detection engines on the sensor are restarted.

•

If you change an interface set’s transparent mode setting or interface set type, all detection engines assigned to that interface set are restarted.

•

If you change a detection engine’s interface set, all detection engines on the sensor are restarted.

•

If you change the number of detection resources allocated to a detection engine, all the detection engines on the sensor are restarted.

•

If you change the detection engine type for a detection engine, that detection engine is restarted.

•

When you create a detection engine, all the detection engines on the sensor are restarted because the total number of allocated resources has changed.

•

If you delete a detection engine or interface set, all detection engines on the sensor are restarted.

•

If you create an interface set, nothing is restarted. A restart occurs only when you assign a detection engine to the interface set.

•

If you change the name or description of an interface set or detection engine, nothing is restarted.

Make sure you plan these actions for times when they will have the least impact on your deployment.

Version 4.7


107


Chapter 5

To edit an existing detection engine: Access: Admin

1.

Select Operations > Configuration > Detection Engines > Detection Engines. The Detection Engines page appears.

2. Click Edit next to the detection engine you want to modify. The Edit Detection Engine page appears.

3. You can modify the name, description, type, group, and number of detection resources for the detection engine. 4. Click Save. Your changes are saved.

Deleting a Detection Engine Requires: DC or 3D Sensor

You cannot delete a detection engine that is used as a constraint in one or more compliance rules; you must first delete the constraint from all rules in which it is used. For information on modifying compliance rules, see Modifying a Rule on page 437. WARNING! Do not delete a detection engine that is in use. To delete a detection engine:

Access: Admin

1.


2. Click Delete next to the detection engine you want to delete. 3. At the prompt, confirm that you want to delete the detection engine. The detection engine is deleted; however, a record of the detection engine is retained so that events generated by that detection engine are viewable.

Version 4.7


108

Using Detection Engines and Interface Sets Using Detection Engine Groups

Chapter 5

Using Detection Engine Groups Requires: DC/MDC or 3D Sensor

You can use detection engine groups to combine similar detection engines. These groups make it easier to apply policies to detection engines that have similar purposes. See the following sections for more information: •

Creating Detection Engine Groups on page 109

•

Deleting Detection Engine Groups on page 109

Creating Detection Engine Groups Requires: DC/MDC or 3D Sensor Access: Admin

The following procedure explains how to create a detection engine group. To create a detection engine group: 1.


2. Click Create Detection Engine Group. The Create Detection Engine Group page appears.

3. Type a name for the detection engine group in the Group Name field. 4. Click Save. The Detection Engine page appears again. You can add detection engines to this group by clicking Edit next to a detection engine name and, on the Edit Detection Engine page, adding the detection engine to the group and clicking Update.

Deleting Detection Engine Groups Requires: DC/MDC or 3D Sensor

When you delete a detection engine group, any detection engines in the group are automatically ungrouped; they are not deleted. To delete a detection engine group:

Access: Admin

1.


2. Click Delete next to the name of the detection engine group. The detection engine group is deleted.

Version 4.7


109

Using Detection Engines and Interface Sets Using Variables within Detection Engines

Chapter 5

Using Variables within Detection Engines Requires: IPS or DC/MDC + IPS

When you create an intrusion policy, you can include variable definitions as part of the policy. When you apply the intrusion policy to a detection engine, those variables are used in conjunction with the detection engine to monitor network traffic and generate events. For example, the intrusion rules in an intrusion policy take advantage of certain variables such as HOME_NET and EXTERNAL_NET to look for exploits that originate outside your network and are targeted against hosts within your network. You can define HOME_NET to encompass your internal address range, for example, 10.10.0.0/16. However, if you have created your detection engines so that one detection engine monitors one class of hosts (in this example, hosts in your network’s DMZ in the range 10.10.30.0/24) and another monitors a different class (for example, hosts in your accounting department in the address range 10.10.90.0/24), you can use detection engine-based variables to tailor your detection capabilities to more closely match your infrastructure. In the intrusion policy: HOME_NET = 10.10.0.0/16

In the detection engine named DE_DMZ: HOME_NET = 10.10.30.0/16

In the detection engine named DE_ACCT: HOME_NET = 10.10.90.0/16

If you later create another detection engine that monitors the rest of your network, which includes a mixed address space, you can use the policy-defined value rather than creating another detection engine-based value for HOME_NET. You can also create new variables or modify existing variables for use only within the context of the detection engine. Variables can be policy-specific or detection engine-specific, but creating a variable in an intrusion policy or detection engine also adds the same variable to all other intrusion policies with the value set to any, and to all other detection engines with the value set to Policy Defined, which means that the value specified in the policy will be used when you apply the policy. Optionally, you can modify the variable in the intrusion policies and detection engines where it is added automatically to give it a specific definition. A variable defined in the detection engine takes precedence over a definition in the intrusion policy. If you disable the variable definition in the detection engine by resetting the variable, the definition reverts to the definition in the intrusion policy the next time you apply the policy. Variables use the same syntax and must follow the same guidelines regardless of whether you create or define them in intrusion policies or detection engines. See

Version 4.7


110


Chapter 5

Creating New Variables on page 784 and Modifying Variables on page 781 for more information. IMPORTANT!

You cannot use variables with RNA detection engines.

For more information, see the following sections: •

Assigning Values to a Variable in Detection Engines on page 111

•

Creating New Variables for Detection Engines on page 112

•

Deleting and Resetting Variables on page 113

Assigning Values to a Variable in Detection Engines Requires: IPS or DC/MDC + IPS

When you create an intrusion policy, you can include variable definitions as part of the policy. For an explanation refer to Using Variables within Detection Engines on page 110. To assign a detection engine-specific value to a variable:

Access: Admin

1.


2. Click Variables next to the detection engine where you want to define a variable value. The Variable List page appears. The value for each of the variables defaults to the value within the intrusion policy that is applied to the detection engine.

Version 4.7


111


Chapter 5

3. Click Edit next to the variable you want to define. The Variable Binding page appears.

4. Enter a value for the variable and click Save. See Creating New Variables on page 784 for information about variable syntax. The Variable List page appears again and shows the new value for the variable. The variable takes effect the next time you apply an intrusion policy to the detection engine, as described in Applying an Intrusion Policy on page 764.

Creating New Variables for Detection Engines Requires: IPS or DC/MDC + IPS

When you create an intrusion policy, you can include variable definitions as part of the policy. For an explanation refer to Using Variables within Detection Engines on page 110. To create a new variable for a detection engine:

Access: Admin

1.


Version 4.7


112


Chapter 5

2. Click Variables next to the detection engine where you want to define a variable value. The Variable List page appears. 3. Click Add Variable. The Variable page appears.

4. In the Variable Name field, enter a name for the variable. 5. In the Variable Binding field, enter a value for the variable and click Save. See Creating New Variables on page 784 for information about the syntax for variables. The Variable List page appears again and shows the new variable and its value. The variable is created and added to all policies and detection engines. The variable takes effect the next time you apply an intrusion policy to the detection engine, as described in Applying an Intrusion Policy on page 764. IMPORTANT! Variable values can be policy-specific or detection engine-specific, but each new variable is added to all your intrusion policies and IPS detection engines. In any intrusion policy where you do not explicitly set the value for your custom variable, the value is set to any. In any detection engine where you do not explicitly set the value for your custom variable, the value is set to Policy Defined, which means that the value specified in the policy will be used when you apply the policy.

Deleting and Resetting Variables Requires: IPS or DC/MDC + IPS

Version 4.7

You can reset the value of any variable and it reverts to the value defined in the intrusion policy the next time you apply the intrusion policy to the detection engine. You can also delete variables that you created within the context of the detection engine.


113

Using Detection Engines and Interface Sets Using Interface Sets

Chapter 5

To delete or reset variables on a detection engine: Access: Admin

1.


2. Click Variables next to the detection engine where you want to delete or reset a variable value. The Variable List page appears.

3. You have two options: To disable the variable value defined in the IPS detection engine and revert to the variable value defined in the policy, click Reset next to the name of the variable.

•

The variable is reset and Policy Defined appears in the Value column. To delete a locally created variable, click Delete next to the name of the variable.

•

The variable is deleted from the detection engine the next time you apply an intrusion policy to the detection engine. WARNING! Deleting USER_CONF from any intrusion policy or detection engine deletes it from all intrusion policies and detection engines. You can disable a single USER_CONF variable by setting it to any within an individual intrusion policy, or by resetting it in the detection engine.

Using Interface Sets Requires: DC or 3D Sensor

Version 4.7

An interface set is a collection of one or more sensing interfaces on your appliance.


114


Chapter 5

Types of Interface Sets When you create an interface set, you can choose one of three types: •

Passive A passive interface set can encompass any number of the available sensing interfaces on a sensor.

•

Inline An inline interface set can include any two interfaces on the sensor. The interfaces do not have to be on the same network cards, but you should avoid using an on-board interface.

•

Inline with Fail Open An inline with fail open interface set must include exactly one interface pair.

You can set up multiple detection engines to use a single interface set. For example, you could create a single passive interface set and create two detection engines, one for an IPS and the other for RNA, then apply different policies to the detection engines.

Transparent Inline Mode Transparent inline mode is a feature for inline interface sets and is not available for Passive interface sets. If you choose the Inline or Inline with Fail Open option, the Transparent Inline Mode option is enabled by default. This allows the sensor to act as a “bump in the wire” and means that the sensor forwards all the network traffic it sees regardless of its source and destination. If you disable this option, a sensor acts as a bridge. Over time, the sensor learns which hosts are on which side of the inline interface, and forwards packets accordingly. For example, consider the following diagram.

If your sensor is deployed inline (or more precisely, if your sensor includes a detection engine with an inline interface set) and the Transparent Inline Mode option is selected, then if the sensor sees network traffic from Host A to Host B,

Version 4.7


115


Chapter 5

it allows the traffic to pass through the interface even though Host A and Host B are on the same side of the sensor. If the sensor is inline and you are not using transparent inline mode, when the sensor sees traffic from Host A to Host B, it does not allow the traffic to pass through the interface to the side of the network with Host C. Only traffic between Host A and Host C or between Host B to Host C is allowed to pass. Keep in mind that if you create an inline interface set but do not use transparent inline mode, you must be especially careful not to create loops in your network infrastructure.

Link State Propagation Mode Link state propagation mode is a feature for inline interface sets and is not available for passive interface sets. Link state propagation mode automatically brings down the second interface in the interface pair when one of the interfaces in an inline interface set goes down. When the downed interface comes back up, the second interface automatically comes back up, too. In other words, if the link state of one interface changes, the link state of the other interface is changed automatically to match it. Link state propagation mode is not available for fiber fail open network cards. It is available only for copper fail open network cards. Link state propagation is especially useful in resilient network environments where routers are configured to reroute traffic automatically around network devices that are in a failure state. See the following sections for more information about interface sets: •

Creating an Interface Set on page 116

•

Editing an Interface Set on page 118

•

Deleting an Interface Set on page 119

Creating an Interface Set Requires: DC or 3D Sensor

An interface set is a collection of one or more sensing interfaces on your appliance. For information about their use, refer to Using Interface Sets on page 114. To create an interface set:

Access: Admin

1.

Select Operations > Configuration > Detection Engines > Interface Sets. The Interface Sets page appears.

Version 4.7


116


Chapter 5

2. Click Create Interface Set. The Create Interface Set page appears.

3. Type a name and description for the new interface set in the Name and Description fields. You can use alphanumeric characters and spaces. 4. Select the type of interface you want to create, Passive, Inline, or Inline with Fail Open, from the Interface Set Type drop-down list. TIP! Some sensors do not support every interface set type. 5. Optionally, if you selected the Inline or Inline with Fail Open option, clear the Transparent Inline Mode check box to disable transparent mode. 6. If you selected either the Inline or Inline with Fail Open option, then optionally, select Link State Propagation Mode. This option is especially useful if the routers on your network are able to re-route traffic around a network device that is down. On the Defense Center only, a list of sensor groups appears, including a list of ungrouped sensors.

7.

Defense Center Only Select the sensor group containing the sensors where you want to create the interface set. You can also select the ungrouped sensors. A list of sensors appears.

Version 4.7


117


Chapter 5

8. Defense Center Only Select one of the sensors from the list. A list of network interfaces on the sensor appears. 9. Select the interfaces that you want to add from the Available Interfaces list and click the arrow button to add the interface to the Selected Interfaces list. You can use the Shift and Ctrl keys to select multiple interfaces at once. To determine which interface name corresponds with a physical interface on your appliance, log into the console and disconnect the network cable from the interface. A message appears on the console indicating the name of the interface (eth1, eth2, and so on). Remember to reconnect the network cable when you are finished. Different types of interface sets have different requirements. For example, you can include all of the available interfaces in a passive interface set, but inline interface sets must contain exactly two interfaces. Inline with fail open interface sets must contain one pair of interfaces from the same fail-open network card. IMPORTANT! If you select an on-board interface rather than an interface on a network card, your sensor may not provide optimum performance. 10. Click Save. The interface set is created. TIP! After you create an interface set, make sure you reapply intrusion policies to the IPS detection engines on the affected sensor.

Editing an Interface Set Requires: DC or 3D Sensor

In some circumstances, editing an interface set or detection engine can cause the detection engines on the sensor to restart, which can cause a short pause in processing. IMPORTANT! For 3D Sensors with inline interface sets, a software bridge is automatically set up to transport packets when the sensor restarts. Although some packets are transmitted without inspection during this time, no packets are lost.

Version 4.7


118


Chapter 5

The following are cases where a detection engine is affected by changes to the detection engines and interface sets: •

If you change which network interfaces are used by the interface set, all the detection engines on the sensor are restarted.

•

If you change an interface set’s transparent mode setting or interface set type, all detection engines assigned to that interface set are restarted.

•

If you change a detection engine’s interface set, all detection engines on the sensor are restarted.

•

If you change the number of detection resources allocated to a detection engine, all the detection engines on the sensor are restarted.

•

If you change the detection engine type for a detection engine, that detection engine is restarted.

•

When you create a detection engine, all the detection engines on the sensor are restarted because the total number of allocated resources has changed.

•

If you delete a detection engine or interface set, all detection engines on the sensor are restarted.

•

If you create an interface set, nothing is restarted. A restart occurs only when you assign a detection engine to the interface set.

•

If you change the name or description of an interface set or detection engine, nothing is restarted.

Make sure you plan these actions for times when they will have the least impact on your deployment. To edit an interface set: Access: Admin

1.


2. Click Edit next to the interface set that you want to modify. The Create Interface Set page appears. 3. Make any changes to the interface set and click Update. Your changes are saved. TIP! After you edit an interface set used by an IPS detection engine, make sure you reapply your intrusion policy on the affected sensor.

Deleting an Interface Set Requires: DC or 3D Sensor

Version 4.7

You cannot delete an interface set that is being used by a detection engine. You must delete the detection engine before you can delete the interface set.


119

Using Detection Engines and Interface Sets Editing Network Interfaces

Chapter 5

To delete an interface set: Access: Admin

1.


2. Click Delete next to the interface set that you want to delete, and, at the prompt, confirm that you want to delete the interface set. The interface set is deleted.

Editing Network Interfaces Requires: DC or 3D Sensor

You can use the Network Interface page to modify the default settings for each network interface on your appliance. Note that any changes you make to the Auto Negotiate value are ignored for Gigabit interfaces. WARNING! Do not modify the settings for the management interface unless you have physical access to the appliance. It is possible to select a setting that makes it difficult to access the web interface.

IMPORTANT! When you use the Defense Center web interface to view the network interface information for a Sourcefire Sensor on Nokia, you can modify only the interface name; you cannot change the Link Mode and Auto Negotiate settings. Instead, use the sensor’s Network Voyager web interface to modify the network interface settings. To edit a network interface: Access: Admin

1.

Select Operations > Configuration > Detection Engines > Network Interface. The Network Interface page appears, listing the current settings for each interface on your appliance. On a Defense Center, the list includes the interfaces on managed sensors.

Version 4.7


120

Using Detection Engines and Interface Sets Configuring Non-Standard Detection Engine Features

Chapter 5

2. Click Edit next to the interface that you want to modify. The values for the interface appear, including: •

the interface

•

the sensor name

•

the interface type, either Sensing or Management

•

the current name for the interface

•

the current description

•

the current link mode, including the bandwidth and duplex setting (Full or Half); note that N/A indicates that there is no link for the interface

You can modify the interface name, the link mode, and the description, as needed. 3. In the Auto Negotiate field, select Off so that the interface does not automatically reset itself. Note that any changes you make to the Auto Negotiate value are ignored for Gigabit interfaces. 4. Click Save. The Network Interface page appears again.

Configuring Non-Standard Detection Engine Features Requires: IPS or DC/MDC + IPS

You can use a variable with the reserved named USER_CONF to configure one or more IPS features not otherwise available via the web interface. The configurations in USER_CONF take effect when you apply an intrusion policy to the IPS detection engine. WARNING! Do not use the reserved variable USER_CONF to configure an IPS feature unless you are instructed to do so in the feature description or by Sourcefire Support. Conflicting or duplicate configurations will halt IPS.

Version 4.7


121


Chapter 5

You can create USER_CONF as an intrusion policy variable or as an IPS detection engine variable. Creating it either way adds a disabled copy of USER_CONF to all other intrusion policies and IPS detection engines on the appliance where you created it. Optionally, you can define USER_CONF in each intrusion policy or detection engine by adding specific feature configurations. Regardless of whether you create or define USER_CONF in an intrusion policy or detection engine, IPS recognizes only one definition of USER_CONF for each detection engine, and that definition takes effect when you apply an intrusion policy to the detection engine. As with other variables, a definition of USER_CONF in the detection engine takes precedence over a USER_CONF definition in the intrusion policy. If you disable USER_CONF in a detection engine by resetting it, the definition of USER_CONF reverts to the definition in the intrusion policy the next time you apply the policy. For more information see Configuring Non-Standard Intrusion Policy Features on page 787. IMPORTANT! In a policy-defined variable, any might mean, for example, any port or any address, but any disables USER_CONF. You can include any number of valid directives or lines and configure any number of features in USER_CONF until you reach a physical limit such as disk space. You can modify USER_CONF to remove or add directives as needed. The syntax for each directive is provided in the feature description or by Sourcefire Support. You can modify USER_CONF the same as you would any other variable. You cannot delete USER_CONF from an IPS detection engine where it is disabled unless it is disabled in all detection engines, and IPS warns you before letting you delete it from an detection engine where it is not disabled. For more information, see Modifying Variables on page 781 and Deleting and Resetting Variables on page 113. WARNING! Deleting USER_CONF from any intrusion policy or detection engine deletes it from all intrusion policies and detection engines. You can disable a single USER_CONF variable by setting it to any within an individual intrusion policy, or by resetting it in the detection engine.

Version 4.7


122


Chapter 5

To create a new USER_CONF variable for a detection engine: Access: Admin

1.

Select Operations > Configuration > Detection Engines > Detection Engines. The Detection Engines page appears. The figure below shows the Defense Center version of the page.

2. Click Variables next to the detection engine where you want to add the variable. The Variable List page appears. 3. Click Add Variable. The Variable page appears.

4. Enter USER_CONF in the Variable Name field. The system automatically precedes each variable name with a dollar sign ($), and you receive an error if you use $ in a variable name.

Version 4.7


123


Chapter 5

5. In the Variable Binding field, enter directives provided to you by Sourcefire Support or provided in the feature description, and click Save. The Variable List page appears again and shows the new variable and its content. The USER_CONF variable is created for the detection engine you are editing, and a disabled USER_CONF is added to all other intrusion policies and IPS detection engines. The variable takes effect the next time you apply an intrusion policy to the detection engine, as described in Applying an Intrusion Policy on page 764. IMPORTANT! Variable values can be policy-specific or detection engine-specific, but each new variable is added to all your intrusion policies and IPS detection engines. In any intrusion policy where you do not explicitly set the value for your custom variable, the value is set to any. In any detection engine where you do not explicitly set the value for your custom variable, the value is set to Policy Defined, which means that the value specified in the policy will be used when you apply the policy.

Version 4.7


124

Chapter 5

Introduction to Sourcefire RNA

Sourcefire RNA allows your organization to confidently monitor and protect your network using a combination of forensic analysis, behavioral profiling, and built-in alerting and remediation. 3D Sensors with RNA passively observe your organization’s network traffic and analyze it to provide you with a complete profile of your network. By default, RNA is installed on 3D Sensors. However, to control how network intelligence is gathered and to view the resulting information, you must manage the sensor with a Defense Center. In addition, to enable RNA functionality, that Defense Center must have an RNA host license installed. IMPORTANT!

You cannot forward RNA data to a Master Defense Center.

If your organization uses NetFlow devices to collect IP traffic information, you can use the NetFlow records generated by those devices to supplement the data gathered by RNA. For example, if you have NetFlow devices deployed on networks that your 3D Sensors with RNA cannot see, you can use the data exported by those devices to monitor those networks. You can also use active scanning tools like Nessus and Nmap to augment detection of operating system, service, and vulnerability information. The host input feature allows you to supplement the information that RNA gathers with your own host attributes and notes to provide additional contextual information; to set the operating system or information for services yourself; and to delete services, protocols, host attributes and client applications from a host profile. If you have a third party application such as a patch management system,

Version 4.7


125

Introduction to Sourcefire RNA Understanding RNA

Chapter 6

you can set up a host input API interaction to feed data from that application into the network, or you can run manual imports of data from the command line. Settings in two policies—the system policy and the RNA detection policy— specify not only the kind of information that RNA collects and stores, but also other kinds of RNA behavior. The following sections explain how to set up RNA for your network, and how to configure RNA detection policies: •

Understanding RNA on page 126

•

Configuring RNA Detection Policies on page 134

For information on the system policy, see Using System Policies on page 1189.

Understanding RNA Requires: DC + RNA

RNA allows your organization to confidently monitor and protect your network using a combination of forensic analysis, behavioral profiling, and built-in alerting and remediation. RNA passively observes your organization’s network traffic and analyzes it to provide you with a complete, up-to-the-minute profile of your network. If your organization uses NetFlow devices to collect IP traffic information, you can use the NetFlow records generated by those devices to supplement the data gathered by RNA. For example, if you have NetFlow devices deployed on networks that your 3D Sensors with RNA cannot see, you can use the data exported by those devices to monitor those networks. Although 3D Sensors with RNA are not NetFlow collectors, they can gather information from packets that are sent to Netflow collectors. RNA uses what are called detection engines to passively analyze the traffic that travels through your network. Detection engines tie together computing resources and a set of network interfaces on the sensor to act as a virtual sensor. A detection engine on a 3D Sensor provides you with a complete, persistent view of your network. For more information, see the following sections:

Version 4.7

•

What Data Does RNA Collect? on page 127

•

What Information Does RNA Provide? on page 127

•

How Can You Use RNA? on page 132

•

What are the Prerequisites for RNA Data Collection? on page 133


126


Chapter 6

What Data Does RNA Collect? Requires: DC + RNA

RNA passively monitors the traffic that travels through your network, including data exported by the NetFlow devices in your deployment. RNA collects and reports various information about your network, including: •

the number and types of network devices running on your network

•

the operating systems and client applications running on monitored network devices

•

the active services and open ports on monitored network devices

•

the vulnerabilities and exploits to which monitored network devices may be susceptible

•

flow data, which are records of active sessions involving monitored network devices

What Information Does RNA Provide? Requires: DC + RNA

RNA analyzes the data it collects, comparing specific packet header values and other unique data from network traffic against established definitions (called fingerprints) to determine what types of hosts are communicating on the network and which operating systems and services are running on the hosts. You can also use Nessus and Nmap active scans to add information about operating systems, services, and vulnerabilities. You can also input third party data manually using the host input feature. RNA events, which are triggered by the changes detected on your network, and flow events, which are records of sessions involving monitored hosts, alert you to the activity on your network and provide you with the information you need to respond appropriately. You can also use the flow data that your 3D Sensors with RNA and your NetFlow devices collect to create and view a profile of your normal network traffic. When you install sensors with IPS and RNA on the same network segment and then view the intrusion events on a Defense Center that manages both sensors, you can gain more insight into the risk, or impact, that the events have on your network. RNA compares the data it collects and analyzes with its vulnerability database to determine the potential vulnerabilities on the detected host, and also maps and displays network and vulnerability data that is easily viewable and searchable from the Defense Center web interface. In addition, you can purchase a client-side application called Sourcefire RNA Visualizer that generates a three-dimensional model of your network architecture based on accumulated RNA data.

Version 4.7


127


Chapter 6


Network Map on page 128

•

Host Profiles and Host Attributes on page 128

•

RNA Events on page 129

•

Flow Data and Traffic Profiles on page 129

•

Impact Flags on page 131

•

Host Vulnerabilities on page 131

•

RNA Visualizer on page 132

Network Map RNA aggregates data for each host and service into the network map, which is an up-to-date representation of your network assets. The network map is continuously updated as network traffic indicates a change or a new host. RNA performs its analysis passively, which means that, unlike active scanners, it does not interact with or scan your hosts directly. It continuously evaluates your network traffic to ensure that your network map stays current. You can quickly navigate through the network map to access other information relevant to your analysis. Note that although you can configure the RNA detection policy to add hosts and services to the network map based on data exported by NetFlow devices, the available information about these hosts and services is limited. For hosts added to the network map based on NetFlow data, RNA does not provide operating system data. Without this information, you cannot perform certain types of analyses that correlate those hosts’ operating systems with potential vulnerabilities, unless you use the host input feature to manually set their operating system identity. Also, these hosts do not have NetBIOS data, nor can RNA identify whether the host is a bridge or a router. For services added to the network map based on NetFlow data, RNA is unable to identify the versions and vendors of services running on hosts detected by your NetFlow devices. Further, it uses /etc/sf/services to determine the names of the services added to the network map based on NetFlow data. This means that if someone is running a service on a non-standard port, and the session is detected by a NetFlow device rather than a 3D Sensor, the Sourcefire 3D System could misidentify the service. For more information, see Using the Network Map on page 149.

Host Profiles and Host Attributes RNA also provides host profiles for the hosts it detects. A host profile provides a complete view of all the information available for a single host. You can access general host information, such as the host name and operating system, through the profile. If you need to quickly find the MAC address for a host, for example, you can look in the host profile.

Version 4.7


128


Chapter 6

Host attributes for that host are also listed in the profile. Host attributes are user-defined descriptions that you can apply to a host, and include annotations you can make for any monitored host, as well as an indicator of business criticality (called host criticality) that establishes the host’s importance. This allows you to easily track changes to servers that are of the highest importance to your organization. You can also create, modify, or delete your own host attributes and apply them either manually or automatically (based on IP address). You can also set host attribute values in response to compliance rule violations. For more information, see Using Host Profiles on page 172.

RNA Events RNA events are triggered by changes detected in your monitored network. The events generated by RNA can alert you to the activity on your network and provide you with the information you need to respond appropriately. As a simple example, you may have conference rooms or a series of spare work spaces where visiting employees connect to your network. You would expect to see New Host events generated by the detection engines monitoring these segments on a regular basis, and you would not suspect malicious intent. However, if you see a New Host event on a network segment that is locked down, you can escalate your response accordingly. RNA events provide you with much greater depth of insight into the activity on your network and with much more granularity than this simple example shows. You can also set up RNA to detect the services, network protocols, client applications, and potential vulnerabilities running on your network hosts. In addition, you can track RNA-specific features such as changes to host criticality, user-defined host attributes, and user-initiated interactions with host vulnerabilities. Host input events, a subset of RNA events, allow you track changes to your network map made using the host input feature. RNA provides a set of predefined workflows that you can use to analyze the events that are generated for your network. You can use these predefined workflows, or you can create custom workflows that display only the information that matches your specific needs. For more information, see Working with RNA Events on page 210.

Flow Data and Traffic Profiles RNA generates flow events when connections between monitored hosts and any other hosts are terminated. Flow events include information about the collected traffic, including:

Version 4.7

•

the type of flow (whether the flow was detected by a 3D Sensor with RNA, or by a NetFlow device), and if the flow was detected by a NetFlow device, the IP address of the device

•

the timestamps of the first and last packet of the transaction


129


Chapter 6

•

the source IP address, destination IP address, and the ports and protocol used by the flow

•

any TCP flags detected in the flow (for flows exported by NetFlow devices)

•

the user logged into the source and destination hosts (if RUA is enabled and the hosts are on the monitored network)

•

the number of packets and bytes sent and received by the monitored host

•

the client application and URL involved in the transaction, if applicable

For flows detected by 3D Sensors, RNA generates one bidirectional record, called a flow event. On the other hand, NetFlow devices export unidirectional flow data, so RNA generates at least two flow events for each flow detected by NetFlow devices, depending on whether you configured the device to output records at a fixed interval even if a flow is still ongoing. Note that if you are monitoring the same network segment with NetFlow devices and 3D Sensors with RNA, RNA generates at least three flow events for each detected flow—one that represents the flow as detected by the sensor, and at least two for the flow as detected by NetFlow device. In addition, NetFlow records do not contain information about which host in the flow is the initiator and which is the responder. When RNA processes NetFlow records, it uses an algorithm to determine this information based on the ports each host is using, and whether those ports are well-known. If both or neither port being used is a well-known port, RNA considers the host using the lowernumber port to be the responder. If only one of the hosts is using a well-known port, RNA considers that host to be the responder. For this purpose, a well-known port is any port that is either numbered from 1 to 1023, or that contains service information in /etc/sf/services on the 3D Sensor or software sensor. Finally, flows exported by NetFlow devices do not contain NetBIOS information, nor do they include any information on client applications and URLs involved in the monitored session. However, NetFlow data includes information on any TCP flags set for the flow, while flow data collected by 3D Sensors with RNA does not. When you configure your RNA detection policy, you must choose how flow data is collected. You can choose one of three flow data modes: •

You can disable flow data collection entirely, which will reduce the traffic between your 3D Sensors and your Defense Center, but will also prevent you from taking advantage of any feature that relies on flow data.

•

You can configure your Defense Center to transmit individual flows to the Defense Center.

•

You can configure your 3D Sensors to transmit flow data to the Defense Center as aggregated data over five-minute intervals, called flow summaries.

As with RNA events, you can view flow data using a set of predefined workflows, or you can create custom workflows. You can choose to view flow data in a table

Version 4.7


130


Chapter 6

format or as graphs. You can also use the flow data to create and view a profile of your normal network traffic, called a traffic profile. For more information, see Working with Flow Data and Traffic Profiles on page 275.

Impact Flags When you install sensors with IPS and RNA on the same network segment and then view the intrusion events on a Defense Center that manages both sensors, you can gain more insight into the risk, or impact, that the events have on your network. To help you evaluate the impact an event has on your network, the Defense Center displays an impact flag in the table view of intrusion events. For each event, the Defense Center adds an impact flag whose color indicates the correlation between intrusion detection data, RNA events, and vulnerability information. Note that because there is no operating system information available for hosts added to the network map based on NetFlow data, the Defense Center cannot assign red (Vulnerable) impact flags for intrusion events involving those hosts, unless you use the host input feature to manually set the hosts’ operating system identity. For more information, see Using Impact Flags to Evaluate Events on page 686

Host Vulnerabilities RNA also correlates the operating system and services detected on each host with a vulnerability database to help you determine whether changes to a particular host increase your risk of network compromise. When host information changes, RNA updates the vulnerability assessment. For example, if you upgrade a host’s operating system to a new version, RNA detects the change by analyzing the network traffic the host produces, and automatically generates an updated list of known vulnerabilities specific to the new operating system. You can manage vulnerabilities individually on a host, mark vulnerabilities as invalid by applying a patch that addresses the vulnerabilities, or configure fixes for an operating system to mark all addressed vulnerabilities as invalid on all hosts where you add that fix. Note that because there is no operating system information available for hosts added to the network map based on NetFlow data, you cannot use RNA to evaluate the vulnerabilities for those hosts, unless you use the host input feature to manually set the hosts’ operating system identity. For more information, see:

Version 4.7

•

Working with Detected Vulnerabilities in the Host Profile on page 195

•

Working with the Vulnerabilities Network Map on page 158

•

Working with Vulnerabilities on page 267


131


Chapter 6

RNA Visualizer The Sourcefire RNA Visualizer is a client-side application you can purchase that generates a three-dimensional model of your network architecture based on accumulated RNA data and, when using an Event Streamer connection to a Defense Center, updates to reflect real-time variations to your network, such as impact changes and compliance events. You can use RNA Visualizer’s graphing capability to generate custom or preconfigured charts that provide additional insight into the traffic patterns and behavior of hosts on your network. For more information on setting up your Defense Center to communicate with RNA Visualizer, see Preparing the Defense Center for RNA Visualizer on page 631 IMPORTANT!

Nokia does not include support for the RNA Visualizer.

How Can You Use RNA? Requires: DC + RNA

You can use RNA not only to view a complete, up-to-the-minute profile of your network, but you can also use the powerful policy and response feature to build compliance policies that let your Defense Center respond in real time to threats on your network. Compliance policies use the data and events gathered and generated by 3D Sensors with RNA, with IPS, or with both to describe the type of activity that constitutes a policy violation. Policy violations can occur when: •

a specific intrusion event, RNA event, host input event, flow event, or RUA event occurs that meets specific criteria as characterized in a compliance rule

•

your network traffic deviates from your normal network traffic pattern as characterized in an existing traffic profile

•

RNA detects that a host on your network is running a forbidden operating system, client application, service, protocol, or combination thereof, as characterized in a compliance white list

Using policy and response, you can configure RNA to respond to suspicious activity in real-time by using compliance policies to send alerts, which can include email, syslog, and SNMP notifications. You can also configure the Defense Center to respond to policy violations by launching remediations, which are programs that the Defense Center runs. The Defense Center ships with predefined remediations, which allow you to block suspicious traffic using a Cisco PIX firewall, a Cisco IOS router, Check Point FireWall-1, or use Nessus or Nmap to scan hosts producing or receiving suspicious traffic. You can also write custom remediations to perform actions that are more specific to your organization’s remediation or integration requirements.

Version 4.7


132


Chapter 6

For more information, see: •

Configuring Compliance Policies and Rules on page 392

•


•

Using RNA as a Compliance Tool on page 340

•

Configuring Responses for Compliance Policies on page 456

What are the Prerequisites for RNA Data Collection? Requires: DC + RNA

You must configure various settings to specify not only the kind of information that RNA collects and stores, but also other kinds of RNA behavior. First, to collect and store RNA data for analysis using 3D Sensors, you must make sure that you use the system settings to apply a host license to your Defense Center. If you are planning to use NetFlow data to supplement the data gathered by 3D Sensors with RNA, you must also use the system settings to apply a NetFlow feature license to your Defense Center and to specify the NetFlow devices in your deployment. These NetFlow devices must use NetFlow version 5. IMPORTANT! If you plan to use only NetFlow devices to monitor your network, you do not need to apply host license to the Defense Center (although you still need a NetFlow feature license). However, because RNA will not build the network map or store information about the hosts on your monitored network, your analysis will be limited to working with the flow data exported by your NetFlow devices. Because the Sourcefire 3D System uses RNA detection engines on 3D Sensors to analyze the flow data exported by your NetFlow devices, you must have at least one 3D Sensor with RNA in your deployment that can communicate with your NetFlow devices. Second, use the system policy to control the kinds and amount of RNA data stored in the database, and therefore determine the data that other parts of the Sourcefire 3D System can use. Third, use the RNA detection policy to specify the kinds of data RNA collects, as well as the monitored network segments. You must configure your detection policy to monitor networks whose traffic your managed 3D Sensors and NetFlow devices can see. For more information, see:

Version 4.7

•

Configuring the System Settings on page 1211.

•

Configuring RNA Settings on page 1204

•

Configuring RNA Detection Policies on page 134


133

Introduction to Sourcefire RNA Configuring RNA Detection Policies

Chapter 6

Configuring RNA Detection Policies Requires: DC + RNA

RNA detection policies control: •

how RNA events and flow data are collected

•

whether traffic that travels from or to specific ports is excluded from monitoring

•

which IP addresses on your network are monitored by 3D Sensors with RNA, and which IP address are monitored with NetFlow devices

Note that although you can use NetFlow devices exclusively to monitor your network, your deployment must include at least one 3D Sensor with RNA that can see the traffic exported by the NetFlow devices, so that the RNA detection engines on the sensor can analyze the NetFlow data. Note that the 3D Sensor is not a NetFlow collector itself, but instead generates data based on packets flowing to collectors. When you create a detection policy, it is important to keep several points in mind, as described in the sections that follow.

Create and Apply One RNA Detection Policy Rather than creating a separate detection policy for each detection engine or network segment, create one policy that maps all the detection engines in your deployment to the appropriate network segments. When you apply a single RNA detection policy to multiple detection engines, the reporting detection engine for a particular network segment is responsible for reporting most of the information about the hosts on that network, for example, the operating systems and services running on the hosts. Any other detection engines where you apply the same RNA detection policy report secondary information about the host, such as MAC address data and the number of hops away from the sensor where the detection engine is running. This secondary information can help RNA better determine the topology of your network. If you were to apply multiple detection policies to multiple detection engines, you would lose this secondary information. In addition, and more important, applying one detection policy to all of your detection engines can significantly reduce the load on your Defense Center if you enable flow data collection. For example, if you have two policies, each of which is monitoring a separate network segment using separate detection engines, each detection engine generates a flow event when RNA detects that a connection is terminated between a monitored host on one of the networks and a monitored host on the other network. On the other hand, if you use one policy to monitor both networks, only the reporting detection engine for the flow initiator generates a flow event. If for any reason you need to use two RNA detection policies, and thus RNA generates duplicate flow events, you can configure the RNA settings in the system policy so that the Defense Center drops these events. However, this can

Version 4.7


134


Chapter 6

degrade performance. For more information, see Configuring RNA Settings on page 1204.

Configure One Detection Engine per 3D Sensor You should configure only one RNA detection engine per 3D Sensor, unless you are using separate detection engines to monitor separate network interfaces, or are dedicating a detection engine to processing NetFlow data. Most sensors have only one detection resource to use for RNA and therefore support only one RNA detection engine, although certain models can support more.

Do Not Overlap Detection Engine Coverage Make sure that you do not assign more than one detection engine as the reporting detection engine for the same network segment. For example, consider a pair of 3D Sensors deployed in different physical locations. Now, assume that the RNA detection policy on the sensors’ managing Defense Center has configured the detection engines on both sensors to monitor the same network segment. If there is some kind of device between a host and one of the sensors that modifies the fingerprint of the packets transmitted by a host, but not between the host and the other sensor, the sensors can gather conflicting information about the host. This can degrade performance as the Defense Center attempts to resolve the conflicts. In addition, overlapping detection engine coverage can result in duplicate flow events. Although you can configure the RNA settings in the system policy so that the Defense Center drops these duplicate events, this can also degrade performance. For more information, see Configuring RNA Settings on page 1204. IMPORTANT! The system policy allows you to drop duplicate flow events for flows detected by 3D Sensors with RNA. It also allows you to drop duplicate flows that are exported by NetFlow devices. However, if you are monitoring the same network segment with NetFlow devices and 3D Sensors with RNA, RNA will generate flow events for flows detected by both devices. You cannot drop these duplicate events.

Monitor the Appropriate Network Segments Know where your 3D Sensors and NetFlow devices are physically deployed so that you can make sure that your detection engines monitor the appropriate network segments.

Version 4.7


135


Chapter 6

For example, consider a pair of 3D Sensors named maple and oak, where: •

maple’s network interface is physically connected to the 10.0.0.0/8 network

•

oak’s network interface is physically connected to the 192.168.0.0/16

network

In this scenario, the detection policy is configured such that under Networks to Monitor: •

the reporting detection engine for the 10.0.0.0/8 network is the detection engine on maple

•

the reporting detection engine for the 192.168.0.0/16 network is the detection engine on oak

In a more complex scenario, you might want to use a NetFlow device to monitor the 10.4.0.0/16 network, instead of a 3D Sensor with RNA. In this case, you would configure your detection policy such that: •

under Networks to Monitor, the reporting detection engine for the 10.0.0.0/8 network is the detection engine on maple, except that you would also exclude the 10.4.0.0/16 network from monitoring by that detection engine

•

under Networks to Monitor, the reporting detection engine for the 192.168.0.0/16 network is the detection engine on oak

•

under NetFlow Networks to Monitor, you configure your NetFlow device (in this example, 10.4.12.12) to monitor the 10.4.0.0/16 network, using the detection engine on maple to process the exported NetFlow data

Exclude Load Balancers, NAT Devices, and Specific Ports as Needed You should exclude load balancers (or specific ports on load balancers) and NAT devices from monitoring. These devices can create excessive and misleading events, filling the database and overloading the Defense Center.

Version 4.7


136


Chapter 6

A host that exhibits multiple updates of its operating system in a short period of time may be a NAT device that you should exclude from monitoring. In addition, if you need to create a custom server fingerprint, you should temporarily exclude from monitoring the IP address that you are using to communicate with the host you are fingerprinting. Otherwise, the network map and RNA event views will be cluttered with inaccurate information about the host represented by that IP address. After you create the fingerprint, you can configure your detection policy to monitor that IP address again. For more information, see Fingerprinting Servers on page 543. The following graphic shows an RNA detection policy that excludes the host with an IP address of 10.1.2.3 from monitoring. This host does not appear in the network map and no events are reported for it.

TIP! Note that you can also exclude hosts on networks monitored by NetFlow devices. A host that exhibits multiple services on the same port in a short period of time may be a load balancer. You can configure your RNA detection policy so that it excludes that port from monitoring. For example, you might want to exclude port 80 on a load balancer that handles a web farm.

As another scenario, your organization may use a custom application that uses a specific range of ports. If the traffic from this application generates excessive and misleading events, you can exclude those ports from monitoring. Similarly, you may decide that you do not want to use RNA to monitor DNS traffic. In that case, you could configure your detection policy so that it does not monitor port 53. TIP! For help with and strategies for identifying load balancers and NAT devices on your network, contact Sourcefire Support. For more information on RNA detection policies, see the following sections:

Version 4.7

•

Creating an RNA Detection Policy on page 138

•



137


•

Editing an RNA Detection Policy on page 147

•

Deleting an RNA Detection Policy on page 147

Chapter 6

Creating an RNA Detection Policy Requires: DC + RNA

Use the Create Policy page to create an RNA detection policy. TIP! Instead of creating a new policy, you can export an RNA detection policy from another Defense Center and then import it onto your Defense Center. You can then edit the imported policy to suit your needs before you apply it. For more information, see Importing and Exporting Objects on page 1248. To create an RNA detection policy:

Access: Admin

1.

Select Policy & Response > RNA > Detection Policy. The Detection Policy page appears.

Version 4.7


138


Chapter 6

2. Click Create Policy. The Create Policy page appears.

3. Provide basic policy information, such as the policy name and description, and configure the detection policy options. See Configuring RNA Detection Policy Options on page 140. 4. Optionally, specify the networks you want to monitor with 3D Sensors. See Specifying Networks to Monitor with 3D Sensors on page 142. Note that if you choose not to monitor your network with 3D Sensors, you must use NetFlow devices. 5. Optionally, exclude traffic that travels from or to specific ports from monitoring by RNA. See Specifying Which Ports to Exclude on page 143. 6. Optionally, specify the networks you want to monitor with NetFlow devices. See Specifying Networks to Monitor with NetFlow Devices on page 145. Note that if you choose not to monitor your network with NetFlow devices, you must use 3D Sensors.

Version 4.7


139


Chapter 6

Click Save Policy.

7.

The RNA detection policy is saved. You must apply the policy to start monitoring the hosts in the networks you specified. See Applying an RNA Detection Policy on page 146 for more information.

Configuring RNA Detection Policy Options Requires: DC + RNA

You must give each RNA detection policy a name, and, optionally, a short description. You must also configure the detection policy settings, which control how RNA events and flow data are collected by RNA. The RNA Detection Policy Settings table describes the options you can configure in an RNA detection policy.

RNA Detection Policy Settings Field

Description

Update Interval

The interval at which RNA updates information (such as when a host was last seen, when a service was used, or the number of hits for a service). The default setting is 3600 seconds (1 hour). IMPORTANT! Setting a lower interval for update timeouts provides more accurate information in the host display, but generates more network events.

Flow Data Mode

Indicates how flow data is collected, including NetFlow data, because RNA detection engines on your 3D Sensors analyze NetFlow data and transmit it to the Defense Center. Flow data shows information about sessions for monitored hosts. • Select Enabled to configure your 3D Sensors to transmit individual flows to the Defense Center. • Select Summary to configure your 3D Sensors to transmit flow summaries, which are sets of flow data aggregated over five-minute intervals, to the Defense Center. This is useful if you want to either reduce the number of events sent to the Defense Center or reduce the amount of space required to store flow data. For more information on flow summaries, see Understanding Flow Summary Data on page 282. • Select Disabled to disable the collection of flow data. The flow summary, traffic profiles, compliance rules based on flows or traffic profile changes, and flow trackers in compliance rules all depend on flow data. if you disable flow data collection, you will not be able to take advantage of these features.

Save Unknown OS Data

Enable this check box if you want to save data related to unidentified operating systems. This data is saved in packet capture (pcap) format on the appliance should you need to send this information to Sourcefire Support.

Save Unknown Service Data

Enable this check box if you want to save events related to unidentified services. This data is saved in packet capture (pcap) format on the appliance should you need to send this information to Sourcefire Support.

Version 4.7


140


Chapter 6

RNA Detection Policy Settings Field

Description

Capture Banners

Enable this check box if you want RNA to should store header information from network traffic that advertises service vendors and versions (“banners”). This information can provide additional context to the information gathered by RNA. You can access service banners collected for hosts by accessing service details.

Client Application Detection

Enable this check box if you want RNA to generate events related to client application detection. Note that flows exported by NetFlow devices do not contain any information on client applications involved in the monitored session.

Capture HTTP URLs

Enable this check box if you want RNA to capture HTTP URLs and include them in flow events, where applicable. Note that flows exported by NetFlow devices do not contain any URL information.

Generate Hosts from NetFlow Data

Enable this check box if you want RNA to add hosts to the network map based on flow data exported by NetFlow devices. Note that there is no operating system information available for hosts added to the network map based on NetFlow data, unless you use the host input feature to manually set the hosts’ operating system identity.

Generate Services from NetFlow Data

Enable this check box if you want RNA to add services to the network map based on flow data exported by NetFlow devices. Note that the Sourcefire 3D System is unable to identify the names, version, and vendors of services running on hosts detected by your NetFlow devices, unless you use the host input feature to manually set those values.

Combine Flows for Out-Of-Network Responders

Enable this check box if you want to treat flow summary data from IP addresses that are not in your list of monitored networks (as defined by your RNA detection policy) as coming from a single host. Enabling this option forces your 3D Sensors to combine flow summaries involving external hosts before they transmit the data to the Defense Center. Flow summaries involving a host on your monitored network and one or more hosts not on your monitored network are combined if they use the same port, protocol, service, and if they were detected by the same detection engine (for flows detected by 3D Sensor) or were exported by the same NetFlow device and were processed by the same detection engine. This can be useful if you want to reduce the number of events sent to the Defense Center or the space required to store flow data; it can also speed up the rendering of flow data graphs. Event views, graphs, and reports use external to indicate the hosts outside your monitored network, instead of an individual IP address. IMPORTANT! This option has no effect unless you set the flow data mode to Summary. TIP! You can use the system policy to set a similar option on the Defense Center to compress flow summary data after your 3D Sensors transmit the data. For more information, see Configuring RNA Settings on page 1204.

Version 4.7


141


Chapter 6

To configure detection policy options: Access: Admin

1.

On the Create Policy page, in the Policy Name field, type a name for the policy.

2. Optionally, in the Policy Description field, type a description for the policy. 3. Configure the policy options under Detection Policy Settings. See the RNA Detection Policy Settings table on page 140 for more information. TIP! If you want to use the settings from an existing RNA detection policy, click Copy Settings and, in the pop-up window, select the policy you want to use and click Load. 4. Continue with the procedure in the next section, Specifying Networks to Monitor with 3D Sensors.

Specifying Networks to Monitor with 3D Sensors Requires: DC + RNA

RNA detection policies control which IP addresses on your network are monitored with 3D Sensors with RNA. Note that if you choose not to monitor your network with 3D Sensors, you must use NetFlow devices, although you can also use both NetFlow devices and 3D Sensors. For more information, see Specifying Networks to Monitor with NetFlow Devices on page 145. You must configure specific detection engines to monitor specific network segments. The detection engine that monitors a network segment is called the reporting detection engine for that segment. For example, the following graphic shows that the detection engine named A, running on the sensor named maple, is the reporting detection engine for the 10.0.0.0/8 subnet. In addition, the detection engine named B, running on the sensor named oak, is the reporting detection engine for the 192.168.0.0/16 subnet.

To specify networks to monitor with 3D Sensors: Access: Admin

Version 4.7

1.

Under Networks to Monitor, click Add Network.


142


Chapter 6

2. In the IP Address and Netmask fields, enter the IP address and network mask (in CIDR notation) that represents the IP addresses you want to monitor or exclude from monitoring. For more information about using netmasks, see Specifying IP Addresses in Searches on page 1130. 3. If you want to exclude the network from monitoring, select Exclude. IMPORTANT!

For example, if you monitor 10.0.0.0/8, exclude 10.4.0.0/16, and monitor 10.4.12.0/24, then the actual IP address ranges that you monitor are 10.0.0.0 through 10.3.255.255, 10.4.12.0 through 10.4.12.255, and 10.5.0.0 through 10.255.255.255. 4. Under Reporting Detection Engine, select the detection engine that you want to monitor this network. 5. To add additional networks, repeat steps 1 through 4. TIP! To remove networks, click Delete next to the network and then Save Policy. 6. Continue with the procedure in the next section, Specifying Which Ports to Exclude, to (optionally) exclude traffic that travels from or to specific ports from monitoring by RNA.

Specifying Which Ports to Exclude Requires: DC + RNA

You can configure the RNA detection policy to exclude ports from monitoring for specific IP addresses. For example, a host that exhibits multiple services on the same port in a short period of time may be a load balancer. Similarly, you might want to exclude TCP traffic on port 80 on a load balancer that handles a web farm.

IMPORTANT! The port exclusion feature only affects data collected by 3D Sensors with RNA. You cannot configure NetFlow devices to exclude ports from monitoring.

Version 4.7


143


Chapter 6

To exclude ports from monitoring: Access: Admin

1.

Under Ports to Exclude, click Add Port.

2. In the Port(s) field, enter the ports you want to exclude from monitoring. You can specify a single port, a range of ports using the dash (-), or a comma-separated list of ports and port ranges. 3. In the Protocol field, specify the protocol of the traffic you want to exclude. You can exclude either TCP or UDP traffic. 4. In the Src/Dest Port field, specify how you want to exclude traffic based on its direction. •

Select Source to exclude traffic on the port where the hosts you specify are the source of the traffic.

•

Select Destination to exclude traffic on the port where the hosts you specify are the destination of the traffic.

•

Select Source/Destination to exclude all traffic on the port for the hosts you specify.

5. In the IP Address and Netmask fields, enter the IP address and network mask (in CIDR notation) that represents the IP addresses where you want to exclude port traffic. For more information about using netmasks, see Specifying IP Addresses in Searches on page 1130. WARNING! If you use the port exclusion feature to exclude from monitoring the ports on a NetFlow devices (that is, you enter the IP address of one of your NetFlow devices in the IP Address field), RNA will not process any data exported by that device. 6. To exclude additional ports, repeat steps 1 through 5. TIP! To remove ports to exclude, click Delete next to the port and then Save Policy. 7.

Version 4.7

Continue with the procedure in the next section, Specifying Networks to Monitor with NetFlow Devices, to (optionally) specify the networks you want to monitor with NetFlow devices.


144


Chapter 6

Specifying Networks to Monitor with NetFlow Devices Requires: DC + RNA

RNA detection policies control which IP addresses on your network are monitored with NetFlow devices. Note that if you choose not to monitor your network with NetFlow devices, you must use 3D Sensors, although you can use both NetFlow devices and 3D Sensors. For more information, see Specifying Networks to Monitor with 3D Sensors on page 142. You must configure at least one of your RNA detection engines on a 3D Sensor with RNA to analyze the data exported by your NetFlow devices. The detection engine that analyzes the NetFlow data for a network segment is called the reporting detection engine for that segment. For example, the following graphic shows that the detection engine named A, running on the sensor named maple, is the reporting detection engine for the 10.4.0.0/16 and 10.5.0.0/16 subnets, which are being monitored by two separate NetFlow devices: 10.4.12.12 and 10.5.45.45, respectively.

When you are determining which detection engines to use as reporting detection engines for NetFlow data, it is helpful to know where your sensors and NetFlow devices are physically deployed. The 3D Sensors where the reporting detection engines reside must be able to see the data exported by your NetFlow devices. If they cannot, they will have no NetFlow data to process and thus they will not transmit any NetFlow-based flows to the Defense Center for your analysis. To specify networks to monitor with NetFlow devices: Access: Admin

1.

Under NetFlow Networks to Monitor, click Add Network.

IMPORTANT! On the Defense Center, you cannot add NetFlow networks to monitor unless you have first applied a NetFlow feature license to your Defense Center and used the system settings to specify the NetFlow devices you plan to use. On the Master Defense Center, the NetFlow devices you added to your managed Defense Centers appear in the NetFlow Device dropdown list. For more information, see Managing Licenses on page 1215 and Specifying NetFlow Devices on page 1231.

Version 4.7


145


Chapter 6

2. In the IP Address and Netmask fields, enter the IP address and network mask (in CIDR notation) that represents the IP addresses you want to monitor or exclude from monitoring. For more information about using netmasks, see Specifying IP Addresses in Searches on page 1130. 3. If you want to exclude the network from monitoring, select Exclude. IMPORTANT!

For example, if you monitor 10.0.0.0/8, exclude 10.4.0.0/16, and monitor 10.4.12.0/24, then the actual IP address ranges that you monitor are 10.0.0.0 through 10.3.255.255, 10.4.12.0 through 10.4.12.255, and 10.5.0.0 through 10.255.255.255. 4. Under NetFlow Device, select the NetFlow device that you want to use to monitor the network you specified. The NetFlow devices listed are those you specified in the system settings. 5. Under Reporting Detection Engine, select the RNA detection engine that you want to use to analyze the data exported by the NetFlow device you chose. You must make sure that the 3D Sensor where the detection engine resides can see the data exported by the NetFlow device. 6. To add additional networks, repeat steps 1 through 5. TIP! To remove networks, click Delete next to the network and then Save Policy. 7.

Continue with step 7 of the procedure in Creating an RNA Detection Policy on page 138 to save the policy.

Applying an RNA Detection Policy Requires: DC + RNA

You can determine which RNA detection policy is currently applied by viewing the Available Detection Engines page (Operations > Configuration > Detection Engines > Detection Engines). The following procedure explains how to apply a different policy or an existing policy that has been modified. To apply an RNA detection policy:

Access: Admin

1.


2. Click Apply next to the RNA detection policy that you want to apply. The Apply Policy page appears.

Version 4.7


146


Chapter 6

3. Under Available Detection Engines, select the detection engines where you want to apply the policy, and click Apply. TIP! You can list the detection engines by detection engine group, sensor, current policy, interface set type, or detection engine type. The policy is applied and the Detection Policy page appears again.

Editing an RNA Detection Policy Requires: DC + RNA

You can edit an RNA detection policy, but you must be logged into the web interface where you created the policy. To edit an existing RNA detection policy:

Access: Admin

1.


2. Click Edit next to the RNA detection policy that you want to modify. The Create Policy page appears. 3. Modify the policy options and monitored networks to suit your needs. See the RNA Detection Policy Settings table on page 140 for more information. TIP! If you want to use the settings from an existing RNA discovery policy, click Copy Settings and, in the pop-up window, select the policy you want to use and click Load. 4. Click Update Policy. The RNA detection policy is saved and the Detection Policy page appears. IMPORTANT! Your changes to the policy do not take effect until you reapply the policy on the detection engines that use it. See Applying an RNA Detection Policy on page 146 for more information.

Deleting an RNA Detection Policy Requires: DC + RNA

You can delete an RNA detection policy that you no longer want to use. IMPORTANT! You can delete a policy that is currently in use, so make sure you first apply a different policy to any detection engines that use it.

Version 4.7


147


Chapter 6

To delete an existing RNA detection policy: Access: Admin

1.


2. Click Delete next to the RNA detection policy that you want to remove. The policy is deleted and the Detection Policy page appears again.

Version 4.7


148

Chapter 6

Using the Network Map

3D Sensors with the RNA component passively collect traffic traveling over the network, decode data, and then compare it to established operating system and service fingerprints. As RNA collects this information, it builds a network map, which is a detailed representation of your network. If your organization has the appropriate scripting capabilities, you can augment the data collected by RNA by adding operating system, service, client application, protocol, or host attribute information from a third party application through the host input feature. You can actively scan hosts in the network map using Nessus or Nmap and add the scan results to your network map. The network map allows you to use the Defense Center to view your network topology in terms of the hosts, bridges, and routers running on your network as well as their associated host attributes, services, and vulnerabilities. In other words, you can select different views of the network map depending on the kind of analysis you are performing. You can also use the custom topology feature to help you organize and identify subnets in the hosts and bridges view of the network map. For example, if each department within your organization uses a different subnet, you can label those subnets using the custom topology feature. TIP! The network map is a useful tool for a quick, overall view of your network. For more detailed information on RNA events, as well as hosts and their attributes, the services and client applications running on your network, vulnerability data, and sessions sustained by monitored hosts (flow data), see Working with RNA Events on page 210 and Working with Flow Data and Traffic Profiles on page 275.

Version 4.7


149

Using the Network Map Understanding the Network Map

Chapter 7


Understanding the Network Map on page 150

•

Working with the Hosts Network Map on page 152

•

Working with the Bridges Network Map on page 155

•

Working with the Services Network Map on page 157

•

Working with the Vulnerabilities Network Map on page 158

•

Working with the Host Attributes Network Map on page 161

•

Working with Custom Network Topologies on page 162

Understanding the Network Map Requires: DC + RNA

Each view of the network map has the same format: a hierarchical tree with expandable categories and sub-categories. When you click one of the top-level categories, it expands to show you the categories beneath it. You can select different views of the network map depending on the kind of analysis you are performing.

The Defense Center gathers data from all the 3D Sensors with RNA that it manages (including those that process NetFlow data) and correlates the data into a composite network map. IMPORTANT! Although you can configure the RNA detection policy to add hosts and services to the network map based on data exported by NetFlow devices, the available information about these hosts and services is limited. For example, there is no operating system data available for these hosts, unless you provide it using the host input feature. For more information, see What Information Does RNA Provide? on page 127. If multiple 3D Sensors generate events for the same host or service, the Defense Center combines the information from each sensor into a composite representation of that host or service. When the Defense Center creates the

Version 4.7


150

Using the Network Map Understanding the Network Map

Chapter 7

network map and composite host profiles using data from multiple sensors, it follows the guidelines described in the Defense Center Data Collection table. Defense Center Data Collection For these values...

The Defense Center displays...

Operating System

Either the operating system identification taken from the sensor that scores the highest confidence value or the operating system information imported through the host input API or an Nmap scan. If multiple sensors have the same high confidence value, the Defense Center displays the operating system identification from the sensor that is closest to the host (that is, that has the fewest hops to the host).

Services

Either the services taken from the sensor with the highest confidence score or the service information imported through the host input API or through an Nmap scan.

Hops

The lowest hop value from any sensor.

Last Seen

The most recent date and time the host was last detected by any of your managed sensors. For hosts with host input data, the last seen time reflects the time that the input originally occurred.

MAC Addresses/ TTL

All MAC Addresses and TTLs, regardless of which sensor reported them.

From any network map, you can view any host’s host profile, which provides a complete view of all the information collected by RNA for a single host. The host profile contains general host information, such as the host name and operating system, as well as more specific information including RNA-detected protocols, services, and client applications that are running on the host. For more information on host profiles, see Using Host Profiles on page 172. You can delete an item from the network map if you are no longer interested in investigating it. You can delete hosts and services from the network map; you can also delete or deactivate vulnerabilities. Note that if RNA detects activity associated with the host after you delete it from the network map, it re-adds the host to the network map. Similarly, deleted services are re-added to the services network map if RNA detects a change in the service (for example, if an Apache web server is upgraded to a new version). Vulnerabilities are reactivated on specific hosts if RNA detects a change in the host’s vulnerable operating system or service.

Version 4.7


151

Using the Network Map Working with the Hosts Network Map

Chapter 7

You can also use the network map to deactivate vulnerabilities network-wide, which means that you deem that none of the hosts that RNA has detected on your network are vulnerable to that particular attack or exploit. TIP! If you want to permanently exclude a host or subnet from the network map, modify the RNA detection policy. See Configuring RNA Detection Policies on page 134 for more information.

Working with the Hosts Network Map Requires: DC + RNA

Use the hosts network map to view the hosts on your network, organized by subnet in a hierarchical tree, as well as to drill down to the host profiles for specific hosts.

.

IMPORTANT! Although you can configure the RNA detection policy to add hosts to the network map based on data exported by NetFlow devices, the available information about these hosts is limited. For example, there is no operating system data available for hosts added to the network map using NetFlow data, unless you provide it using the host input feature. In addition, note that without a RNA host license applied to the Defense Center, RNA will not build the network map or store information about the hosts on your monitored network, even if you are using only NetFlow devices to monitor your network. For more information, see What Information Does RNA Provide? on page 127 and Managing Feature Licenses on page 1217.

Version 4.7


152


Chapter 7

Note that if you create a custom topology for your network, the labels you assign to your subnets appear in the hosts network map.

You can also view the hosts network map according to the organization you specified in the custom topology.

For information on configuring custom topologies, see Working with Custom Network Topologies on page 162. You can delete entire networks, subnets, or individual hosts from the hosts network map. For example, if you know that a host is no longer attached to your network, you can delete it from the network map to simplify your analysis. Note that if RNA detects activity associated with the host after you delete it from the network map, it re-adds the host to the network map. If you want to permanently exclude a host or subnet from the network map, modify the RNA detection policy. See Configuring RNA Detection Policies on page 134 for more information. IMPORTANT! Sourcefire strongly recommends that you do not delete bridges or routers from the network map, because RNA uses bridge and router information to determine network topology (including generating network hops and TTL values for monitored hosts). Although you cannot delete bridges and routers from the bridges network map, make sure you do not delete them from the hosts network map.

Version 4.7


153


Chapter 7

To view the hosts network map: Access: Data or Admin

1.

Select Analysis & Reporting > RNA > Network Map > Hosts. The Hosts page appears, displaying a list of host IP addresses and, for those hosts without IP addresses, MAC addresses. Each address or partial address is a link to the next level.

2. Drill down to the specific IP address or MAC address of the host you want to investigate. For example, to view a host with the IP address 192.168.40.11, click 192, then 192.168, then 192.168.40, then 192.168.40.11. When you click 192.168.40.11, the host profile appears. For more information on host profiles, see Using Host Profiles on page 172. TIP! If multiple entries do not exist for a specific subnet, you can click the address to access the host profile directly.

3. Optionally, to delete a subnet, IP address, or MAC address, click the Delete icon ( ) next to the element you want to delete, then confirm that you want to delete the host or subnet. The host is deleted. Note that if RNA rediscovers the host, it is re-added to the network map.

Version 4.7


154

Using the Network Map Working with the Bridges Network Map

Chapter 7

4. Optionally, switch between the hosts view and the topology view of the hosts network map. •

To switch to a view of the hosts network map organized by your custom topology, on the hosts view (the default), click (topology) at the top of the network map.

•

To switch to a view of the hosts network map organized by subnet, on the topology view, click (hosts) at the top of the network map.

For information on configuring custom topologies, see Working with Custom Network Topologies on page 162.

Working with the Bridges Network Map Requires: DC + RNA

Use the bridges network map to view the bridges and routers that connect one segment of your network to another, as well as to drill down to the host profiles of those bridges and routers. The bridges network map is separated into two sections: IP and MAC. The IP section lists bridges and routers identified by an IP address; the MAC section lists bridges and routers that do not have an IP address and are identified only by a MAC address.

Note that if you create a custom topology for your network, the labels you assign to your subnets appear in the bridges network map.

The methods RNA uses to distinguish bridges, switches, and routers include: •

the analysis of Cisco Discovery Protocol (CDP) messages, which can identify network devices and their types (Cisco devices only)

•

the detection of the Spanning Tree Protocol (STP), which identifies a device as a switch or bridge

•

the detection of multiple hosts using the same MAC address, which identifies the MAC address as belonging to a router

If a network device communicates using CDP, it may have an IP address. If it communicates using STP, it may only have a MAC address. You cannot delete bridges or routers from the network map because RNA uses bridge and router information to determine network topology (including generating network hops and TTL values for monitored hosts).

Version 4.7


155

Using the Network Map Working with the Bridges Network Map

Chapter 7

To view the bridges network map: Access: Data or Admin

1.

Select Analysis & Reporting > RNA > Network Map > Bridges. The Bridges page appears.

2. Drill down to the specific IP address or MAC address of the bridge or router you want to investigate. If you used an IP address, the host profile appears. For more information on host profiles, see Using Host Profiles on page 172.

If you used a MAC address, a different kind of host profile appears that provides more limited information.

Version 4.7


156

Using the Network Map Working with the Services Network Map

Chapter 7

Working with the Services Network Map Requires: DC + RNA

Use the services network map to view the services on your network, organized in a hierarchical tree by service name, vendor, version, and finally by the hosts running each service.

IMPORTANT! Although you can configure the RNA detection policy to add services to the network map based on data exported by NetFlow devices, the available information about these services is limited. For more information, see What Information Does RNA Provide? on page 127. From the services network map, you can view the host profile of each host that runs a specific service as well as delete any service category, any service running on all hosts, or any service running on a specific host. For example, you can delete a service from the network map if you know it is disabled on the host and you want to make sure it is not used for impact flag qualification. Note that deleting a service from the network map does not remove it from your network. A deleted service reappears in the network map if RNA detects a change in the service (for example, if an Apache web server is upgraded to a new version) or if you restart RNA. Depending on what you delete, the behavior differs: •

If you delete a service category, the service category is removed from the network map. All services that reside beneath the category are removed from any host profile that contains the services. For example, if you delete http, all services identified as http are removed from all host profiles and http no longer appears in the Services view of the network map.

Version 4.7


157

Using the Network Map Working with the Vulnerabilities Network Map

•

Chapter 7

If you delete a specific service, vendor, or version, the affected service is removed from the network map and from any host profiles that contain it. For example, if you expand the http category and delete Apache, all services listed as Apache with any version listed beneath Apache are removed from any host profiles that contain them. Similarly, if instead of deleting Apache, you delete a specific version (1.3.17, for example), only the version you selected will be deleted from affected host profiles.

•

If you delete a specific IP address, the IP address is removed from the service list and the service itself is removed from the host profile of the IP address you selected. For example, if you expand http, Apache, 1.3.17 (Win32), and then delete 172.16.1.50:80/tcp, the Apache 1.3.17 (Win32) service is deleted from the host profile of IP address 172.16.1.50.

To view the services network map: Access: Data or Admin

1.

Select Analysis & Reporting > RNA > Network Map > Services. The Services page appears.

2. Drill down to the specific service you want to investigate. For example, if you want to view a specific type of web server like Apache, click http, then click Apache, and then click the version of the Apache web server you want to view. 3. Click a specific IP address under the service you selected. The host profile of the host running the service appears with the Services section expanded. For more information about the Services section of the host profile, see Working with Services in the Host Profile on page 185.

4. Optionally, to delete any service category, any service running on all hosts, or any service running on a specific host, click the Delete icon ( ) next to the element you want to delete, then confirm that you want to delete it. The service is deleted. Note that if RNA rediscovers the service, it is re-added to the network map.

Working with the Vulnerabilities Network Map Requires: DC + RNA

Version 4.7

Use the vulnerabilities network map to view the vulnerabilities that RNA has detected on your network, organized by RNA ID, Bugtraq ID, CVE ID, Nessus ID,


158


Chapter 7

or Snort ID. The vulnerabilities are arranged by identification number, with affected hosts listed beneath each vulnerability.

From the vulnerabilities network map, you can view the details of specific vulnerabilities; you can also view the host profile of any host subject to a specific vulnerability. This can help you evaluate the threat posed by that vulnerability to specific affected hosts. If you deem that a specific vulnerability is not applicable to the hosts on your network (for example, you have applied a patch), you can deactivate the vulnerability. Deactivated vulnerabilities still appear on the network map, but the IP addresses of their previously affected hosts appear in gray italics. The host profiles for those hosts show deactivated vulnerabilities as invalid, though you can manually mark them as valid for individual hosts; see Setting Vulnerabilities for Individual Hosts on page 200 for more information. The numbers next to a vulnerability ID (or range of vulnerability IDs) represent two counts: •

Version 4.7

The first number is a count of non-unique hosts that are affected by a vulnerability or vulnerabilities. In other words, for each host that is affected by each vulnerability in the range, the count is incremented by one. If a host is affected by more than one vulnerability, it is counted multiple times. Therefore, it is possible that the count can be higher than the number of hosts on your network. Deactivating a vulnerability decrements this count


159


Chapter 7

by the number of hosts that are potentially affected by the vulnerability. If you have not deactivated any vulnerabilities for any of the potentially affected hosts for a vulnerability or range of vulnerabilities, this count is not displayed. •

The second number is a similar count of the total number of non-unique hosts that RNA has determined are potentially affected by a vulnerability or vulnerabilities.

Note that any host that was not affected when a vulnerability was deactivated but that becomes affected due to an operating system or service change shows the vulnerability as valid in its host profile. In addition, the Defense Center no longer uses deactivated vulnerabilities for intrusion impact correlation. To view the vulnerabilities network map: Access: Data or Admin

1.

Select Analysis & Reporting > RNA > Network Map > Vulnerabilities. The Vulnerabilities page appears.

2. From the Type drop-down list, select the class of vulnerability you want to view. By default, vulnerabilities are displayed by RNA ID. 3. Drill down to the specific vulnerability you want to investigate. The vulnerability details appear. For details on the information provided, see Viewing Vulnerability Details on page 197.

In addition, on the network map, the Defense Center displays the IP addresses of affected hosts. You can click any IP address to display the host profile for that host.

Version 4.7


160

Using the Network Map Working with the Host Attributes Network Map

Chapter 7

4. Optionally, deactivate the vulnerability. •

To deactivate the vulnerability for all hosts affected by the vulnerability, click the Delete icon ( ) next to the vulnerability number.

•

To deactivate the vulnerability for an individual host, click the Delete icon ( ) next to the host’s IP address.

The vulnerability is deactivated. The applicable hosts’ IP addresses appear in gray italics in the network map. In addition, host profiles for those hosts show deactivated vulnerabilities as invalid. TIP! See Setting Vulnerabilities for Individual Hosts on page 200 for more information on reactivating vulnerabilities.

Working with the Host Attributes Network Map Requires: DC + RNA

Use the host attributes network map to view the hosts on your network organized by their host attributes. When you select the host attribute you want to use to organize your hosts, the Defense Center lists the possible values for that attribute in the network map and groups hosts based on their assigned values. You can also view the host profile of any host assigned a specific host attribute value. The host attributes network map can organize hosts based on user-defined host attributes. For any of these attributes, the network map displays hosts that do not have a value assigned as Unassigned.

For more information, see Working with User-Defined Host Attributes on page 202. In addition, the host attributes network map can organize hosts based on the host attributes that correspond to any compliance white lists you have created. Each

Version 4.7


161

Using the Network Map Working with Custom Network Topologies

Chapter 7

compliance white list that you create automatically creates a host attribute with the same name as the white list.

Possible white list host attribute values are: •

Compliant, for hosts that are compliant with the white list

•

Non-Compliant, for hosts that violate the white list

•

Not Evaluated, for hosts that are not valid targets of the white list or have not been evaluated for any reason

For more information on compliance white lists, see Using RNA as a Compliance Tool on page 340. IMPORTANT! You cannot organize hosts using predefined host attributes, such as host criticality, on the host attributes network map. To view the host attributes network map: Access: Data or Admin

1.

Select Analysis & Reporting > RNA > Network Map > Host Attributes. The Host Attributes page appears.

2. From the Attribute drop-down list, select a host attribute. The Defense Center lists the values for the host attribute and indicates, in parentheses, the number of hosts assigned that value. 3. Click any host attribute value to view hosts assigned the value. 4. Click a host IP address to view the host profile for that host.

Working with Custom Network Topologies Requires: DC + RNA

Use the custom topology feature to help you organize and identify subnets in your hosts and bridges network maps. For example, if each department within your organization uses a different subnet, you can label those subnets using the custom topology feature. Then, when you

Version 4.7


162


Chapter 7

view the hosts or bridges network map, the labels you assign to your subnets appear, as shown in the following graphic.

You can also view the hosts network map according to the organization you specified in the custom topology.

For more information about the hosts and bridges network maps, see Working with the Hosts Network Map on page 152 and Working with the Bridges Network Map on page 155. When you create a custom topology, you must identify the networks in your organization. You can do this using any or all of three strategies: •

by importing the Sourcefire-discovered topology, which adds networks using a “best guess” at how your network is deployed based on the hosts, bridges, and routers the Sourcefire 3D System has detected

•

by importing networks from an RNA detection policy, which adds the networks that you configured the Sourcefire 3D System to monitor in an RNA detection policy

•

by adding networks to your topology manually, if the other two methods create an inaccurate or incomplete representation of your deployment

After you identify your networks, you can name them so that when you view the network map, the organization imparted by the custom topology is meaningful to you. Optionally, you can link networks in your custom topology by indicating how the subnets connect to each other by specifying the IP address of your routers. Link networks if you want to provide RNA Visualizer with an accurate representation of your network topology so that it can better render its model of your network. Note that linking networks has no effect on the network map.

Version 4.7


163


Chapter 7


Creating Custom Topologies on page 164

•

Managing Custom Topologies on page 169

Creating Custom Topologies Requires: DC + RNA

To create a custom topology, you must specify its networks. You can do this using any or all of three strategies: •

by importing the Sourcefire-discovered topology

•

by importing networks from an RNA detection policy

•

by adding networks to your topology manually

Optionally, you can link the networks in your topology so that RNA Visualizer provides you a more accurate view of your overall network. Finally, you must save and activate the topology to start using it with the network map and RNA Visualizer. To create a custom topology: Access: Admin

1.

Select Policy & Response > RNA > Network Map > Custom Topology. The Custom Topology page appears.

2. Click Create Topology. The Edit Topology appears. 3. Provide basic topology information, such as the topology name and description. See Providing Basic Topology Information on page 165. 4. Add networks to your topology. You can use any or all of the following strategies:

Version 4.7

•

To add networks to your topology by importing the Sourcefirediscovered topology, follow the procedure in Importing a Discovered Topology on page 165.

•

To add networks to your topology by importing them from an RNA detection policy, follow the procedure in see Importing Networks from an RNA Detection Policy on page 166.

•

To add networks to your topology manually, follow the procedure in Manually Adding Networks to Your Custom Topology on page 167.


164


Chapter 7

5. Refine your topology. •

To remove a network from your custom topology, click Delete next to the network you want to remove.

•

To rename a network, click Rename next to the network. In the pop-up window that appears, type the new name in the Name field and click Rename. Note that this name labels the network in the network map.

•

To affect the way that RNA Visualizer displays your network topology by linking or unlinking your networks, follow the procedure in Linking Networks within a Custom Topology on page 168.

6. Click Save. The topology is saved. IMPORTANT! You must activate the topology before you can use it in the network map or to affect RNA Visualizer. For more information, see Managing Custom Topologies on page 169.

Providing Basic Topology Information Requires: DC + RNA

You must give each custom topology a name, and, optionally, a short description.

To provide basic topology information: Access: Admin

1.

On the Edit Topology page, in the Name field, type a name for the topology.

2. Optionally, in the Description field, type a description for the topology. 3. Optionally, continue with the procedures in the following sections, depending on how you want to build your custom topology: •

Importing a Discovered Topology on page 165

•

Importing Networks from an RNA Detection Policy on page 166

•

Manually Adding Networks to Your Custom Topology on page 167

Importing a Discovered Topology Requires: DC + RNA

Version 4.7

One way you can add networks to your custom topology is to import the topology discovered by your Sourcefire 3D System. This discovered topology is the system’s “best guess” at how your network is deployed based on the hosts, bridges, and routers it has detected.


165


Chapter 7

To import a discovered topology: Access: Admin

1.

On the Edit Topology page, click Import Discovered Topology.

2. The discovered networks and any discovered links (routers) populate the page.

3. Optionally, continue with the procedures in the following sections, depending on how you want to build your custom topology: •


•


•


•

Linking Networks within a Custom Topology on page 168

Importing Networks from an RNA Detection Policy Requires: DC + RNA

One way you can add networks to your custom topology is to import the networks that you configured the Sourcefire 3D System to monitor in an RNA detection policy. For information on RNA detection policies, see Configuring RNA Detection Policies on page 134. To import networks from an RNA Detection Policy:

Access: Admin

1.

On the Edit Topology page, click Import Policy Networks. A pop-up window appears.

2. From the drop-down list, choose the RNA detection policy you want to use and click Load.

Version 4.7


166


Chapter 7

3. The monitored networks in your RNA detection policy populate the page. For example, if you configured your RNA detection policy to monitor the 10.0.0.0/8, 192.168.0.0/16, and 172.12.0.0/16 networks, those networks appear on the page.

4. To add networks from a different RNA detection policy, repeat steps 1 and 2. 5. Optionally, follow the procedures in the following sections, depending on how you want to build your custom topology: •


•


•


Manually Adding Networks to Your Custom Topology Requires: DC + RNA

If importing networks from your RNA detection policy and importing discovered topology is insufficient creates an inaccurate or incomplete representation of your network deployment, you can add networks to your custom topology manually. To add a network to a custom topology manually:

Access: Admin

1.

On the Edit Topology page, click Add Network. A pop-up window appears.

Version 4.7


167


Chapter 7

2. Optionally, name the network by typing a name in the Name field. This name labels the networks in the hosts and bridges network maps after you activate the topology.

3. For more information, see Working with the Hosts Network Map on page 152 and Working with the Bridges Network Map on page 155. 4. In the IP Address and Netmask fields, enter the IP address and network mask (in CIDR notation) that represent the network you want to add to your topology. For more information about using netmasks, see Specifying IP Addresses in Searches on page 1130. 5. Click Add. The network is added to your topology. 6. To add additional networks to your topology, repeat steps 1 through 5. TIP! To delete a network from your topology, click Delete next to the network you want to delete, and confirm that you want to delete the network, as well as all links to the network. 7.

Optionally, follow the procedures in the following sections, depending on how you want to build your custom topology: •


•


•


Linking Networks within a Custom Topology Requires: DC + RNA

Version 4.7

You can link networks in your custom topology if you want to provide RNA Visualizer with an accurate representation of your network so that it can better render its model of your network. Note that linking networks has no effect on the network map. For full instructions on how to install and use RNA Visualizer, refer to the RNA Visualizer User Guide.


168


Chapter 7

To link networks within a custom topology: Access: Admin

1.

On the Edit Topology page, next to the network where you want to add a link, click Add Network Link.

2. From the Connection to Network drop-down list that appears, select the network to which you want to link. 3. In the Through Router field, enter the IP address of the router that connects the two networks. 4. To add additional network links to your topology, repeat steps 1 through 3. From each network, you can add one link to each of the other networks.

TIP! To delete a network link, click Delete next to the link you want to delete, and confirm that you want to delete it. When you are finished linking networks, continue with step 6 of the procedure in Creating Custom Topologies on page 164 to save the topology.

Managing Custom Topologies Requires: DC + RNA

Version 4.7

Use the Custom Topology page to manage custom topologies. You can create, modify, and delete topologies.


169


Chapter 7

A topology’s status appears with its name. If the light bulb icon next to the policy name is lit, the topology is active and affects your network map and RNA Visualizer models your network. If it is dark, the topology is inactive. Only one custom topology can be active at any time. For more information on managing custom topologies, see: •

Activating and Deactivating Custom Topologies on page 170

•

Modifying a Custom Topology on page 170

•

Deleting a Custom Topology on page 170

Activating and Deactivating Custom Topologies Requires: DC + RNA

Use the following procedure to either activate or deactivate a custom topology. Note that only one custom topology can be active at any time. If you have created multiple topologies, activating one automatically deactivates the currently active topology. To activate or deactivate a custom topology:

Access: Admin

1.


2. You have two options: •

To activate a topology, click Activate next to the policy.

•

To deactivate a topology, click Deactivate next to the policy.

Modifying a Custom Topology Requires: DC + RNA

Use the following procedure to modify a custom topology. To modify a custom topology:

Access: Admin

1.


2. Click Edit next to the topology. The Edit Topology page appears. See Creating Custom Topologies on page 164 for information on the various configurations you can change. 3. Make changes as needed and click Save. The topology is changed. If the topology is active, the changes you made take effect in the network map immediately.

Deleting a Custom Topology Requires: DC + RNA

Version 4.7

Use the following procedure to delete a custom topology. If you delete the active topology, your changes take effect immediately, that is, your network map and RNA Visualizer no longer display your custom topology.


170


Chapter 7

To delete a custom topology: Access: Admin

1.


2. Click Delete next to the topology you want to delete. If the topology is active, confirm that you want to delete it. The topology is deleted.

Version 4.7


171

Chapter 7

Using Host Profiles

A host profile provides a complete view of all the information for a single host that was collected by a 3D Sensor with RNA (including sensors that process NetFlow data) and sent to the Defense Center that manages it. You can access general host information, such as the host name and operating system, through the profile. If you need to quickly find the MAC address for a host, for example, you can look in the host profile. User History information is provided when the Real-Time User Awareness (RUA) feature is licensed and at least one User ID is registered as logging in to the host within the last twenty-four hours. If there have been multiple users then multiple IDs are listed. Login intervals are indicated by a bar graph for each user. Host attributes for that host are also listed in the profile. Host attributes are user-defined descriptions that you can apply to a host. For example, you might assign a host attribute that indicates the building where the host is located. From a host profile, you can view the existing host attributes applied to that host and can modify the host attribute values. As another example, you can use the host criticality attribute to designate the business criticality of a given host and to tailor compliance policies and alerts based on host criticality. Host profiles also provide you with detailed information about the services, protocols, and client applications running on a particular host, including whether they are in compliance with a compliance white list. You can view flow data events for services, remove services from the services list, and view service details. Flow data events are events generated at the end of a connection that contain information about the transaction. You can also view application details and flow data events for client applications and delete client applications or host

Version 4.7


172

Using Host Profiles

Chapter 8

protocols from the host profile. In addition, host profiles list any compliance white list violations associated with a particular host. IMPORTANT! Although you can configure the RNA detection policy to add hosts and services to the network map based on data exported by NetFlow devices, the available information about these hosts and services is limited. For example, there is no operating system data available for these hosts, unless you provide it using the host input feature. For more information, see What Information Does RNA Provide? on page 127. You can modify the list of vulnerabilities for the host from the host profile. You can use this capability to track which vulnerabilities have been addressed for the host. After you address a vulnerability on a host, you can move that vulnerability to the Not Vulnerable list in the host profile. For example, if a Windows host has vulnerabilities that can be remediated by applying a service pack, you can then mark those vulnerabilities as Not Vulnerable. You can also apply fixes to the operating system for a host, causing all vulnerabilities addressed by the fix to be automatically marked invalid. Optionally, you can perform an Nmap scan from the host profile, to augment the service and operating system information in your host profile. The Nmap scanner actively probes the host to obtain information about the operating system and services running on the host. The results of the scan appear in the host profile, and RNA no longer updates operating system or service information if the operating system or service information has been replaced by Nmap. The confidence for an operating system or service data from Nmap is always 100%. Note that a host profile may not be available for every host on your network. Possible reasons include:

Version 4.7

•

the host was deleted from the network map because it timed out

•

you have reached your host license limit

•

the host resides in a network segment that is not monitored by your RNA detection policy

•

you do not have RNA as part of your deployment


173

Using Host Profiles

Chapter 8

The following graphic shows an example of a host profile.

For more information about each section of the host profile, see the following:

Version 4.7

•

Viewing Host Profiles on page 175 explains how to access a host profile.

•

Working with Basic Host Information in the Host Profile on page 176 describes the information provided in the Host section of a host profile.

•

Working with VLAN Tags in the Host Profile on page 180 describes the information provided in the VLAN Tag section of a host profile.

•

Working with User History in the Host Profile on page 181 describes the information provided in the User History section of a host profile.

•

Working with Host Attributes in the Host Profile on page 181 describes the information provided in the Attributes section of a host profile.

•

Working with Host Protocols in the Host Profile on page 182 describes the information provided in the Host Protocols section of a host profile.

•

Working with White List Violations in the Host Profile on page 183 describes the information provided in the White List Violations section of a host profile.

•

Working with Services in the Host Profile on page 185 describes the information provided in the Services, Service Detail, and Service Banner sections of a host profile.

•

Working with Client Applications in the Host Profile on page 193 describes the information provided in the Client Applications section of a host profile.


174

Using Host Profiles Viewing Host Profiles

Chapter 8

•

Working with Detected Vulnerabilities in the Host Profile on page 195, which describes the information provided in the Vulnerabilities and Vulnerability Detail sections of a host profile.

•

Working with the Predefined Host Attributes on page 201 explains how to set the host criticality attribute and how to add notes to a host profile.

•

Working with User-Defined Host Attributes on page 202, which provides information about creating and using user-defined host attributes.

Viewing Host Profiles Requires: DC + RNA

You can access a host profile from any network map or from any event view that includes the IP addresses of hosts on monitored networks. For example, the table view of RNA events includes a link to the host profile next to every entry in the IP Address column. To view a host profile from an event view:

Access: Data or Admin

h

On any event view, click the host profile icon ( host whose profile you want to view.

) next to the IP address of the

The host profile appears in a pop-up window. To view a host profile from a network map: Access: Data or Admin

h

On any network map, drill down to the IP address of the host whose profile you want to view. The host profile appears. See Working with the Hosts Network Map on page 152 for an example of how to access a host profile from a network map.

Version 4.7


175

Using Host Profiles Working with Basic Host Information in the Host Profile

Chapter 8

Working with Basic Host Information in the Host Profile Requires: DC + RNA

Each host profile provides basic information about a detected host. Note that the fields displayed in a host profile may vary according to the type of host (bridge, router, or host) and the information available about the host.

IMPORTANT! Although you can configure the RNA detection policy to add hosts and services to the network map based on data exported by NetFlow devices, the available information about these hosts and services is limited. For example, there is no operating system data available for these hosts, unless you provide it using the host input feature. For more information, see What Information Does RNA Provide? on page 127. The Basic Host Profile Information table describes each field. Basic Host Profile Information Field

Description

Hostname

The fully qualified domain name of the host, if known.

NetBIOS Name

The NetBIOS name of the host, if available. Microsoft Windows hosts, as well as Macintosh, Linux, or other platforms configured to use NetBIOS, can have a NetBIOS name. For example, Linux hosts configured as Samba servers have NetBIOS names.

Reporting Detection Engine

The name of the detection engine and sensor that detected the host, or, for hosts added to the network map based on NetFlow data, the detection engine that processed the NetFlow data.

Hops from Sensor

The number of network hops between the sensor that detected the host and the host itself, which provides information about the physical location of the host. If multiple 3D Sensors with RNA detected the host, the Defense Center displays the lowest hops value.

Version 4.7


176


Chapter 8

Basic Host Profile Information (Continued) Field

Description

Operating System

The operating system that RNA detects is running on the host. If this field is blank, RNA has not yet identified an operating system. If this field is listed as unknown, RNA cannot identify the OS. If multiple 3D Sensors with RNA detected the host, the Defense Center displays the operating system detected by the sensor that reports the highest confidence. If multiple sensors report the same confidence, the Defense Center uses the operating system determined by the sensor that is the fewest hops away from the host. If the host is running a operating system that violates a compliance white list in an activated compliance policy, the Defense Center marks the operating system information with the white list violation icon ( ). If the host’s operating system is not included in the list of operating systems RNA is able to detect (see Detected Operating Systems and Services on page 1433), you may want to use one of the following strategies: • create a custom fingerprint for the host, as described in Using Custom Fingerprinting on page 536 • run an Nmap scan against the host, as described in Scanning a Host from the Host Profile on page 208 • manually enter operating system information, as described in Working with Operating Systems in the Host Profile on page 179 For more information on working with operating system information, see Working with Operating Systems in the Host Profile on page 179

Source Type

One of the following values: • User: user_name • Application: app_name • Scanner: scanner_type • RNA, for services detected by 3D Sensors with RNA • NetFlow, for services added to the network map based on NetFlow data The RNA database can only retain information from one source for the operating system or for a particular service. If a source with a higher priority adds data, that data replaces the existing data. The new source retains control of the data and is responsible for updating it until the host is deleted and re-added to the network map or a higher priority source takes control of the data. The sources have the following priority order: user and application (equal), scanner, RNA, and finally NetFlow.

Version 4.7


177


Chapter 8

Basic Host Profile Information (Continued) Field

Description

OS Confidence

For hosts detected by 3D Sensors with RNA, the percentage of confidence (between 0% and 100%) that RNA has in the identification of the operating system running on the host. For example, if RNA detects a Microsoft Windows 2000 server running Apache for Windows and other Windowsrelated services, the confidence field displays a high percentage. If multiple sensors detected the host, the Defense Center displays the highest confidence reported among the sensors. For hosts added to the network map based on NetFlow data, confidence is always 0%. If you used the host input feature or the Nmap scanner to identify the operating system, the confidence is always 100%.

MAC Addresses (TTL)

The host’s detected MAC address or addresses, with the current time-to-live (TTL) value in parentheses. If the MAC address is displayed in a bold font, the MAC address is the actual MAC address of the host, detected by RNA through ARP and DHCP traffic. If multiple sensors detected the host, the Defense Center displays all MAC addresses and TTL values associated with the host, regardless of which sensor reported them. You can click the MAC address to view a list of hosts with the same MAC address. Router host profiles typically show the hosts (IP addresses) in the network segments they route in this list, and the IP addresses of monitored routers frequently appear in this list for monitored workstations and servers. The true IP address for the MAC address is displayed in bold.

Host Type

The type of device that RNA detected: bridge, router, or host. The methods RNA uses to distinguish bridges, switches, and routers include: • the analysis of Cisco Discovery Protocol (CDP) messages, which can identify network devices and their type (Cisco devices only) • the detection of the Spanning Tree Protocol (STP), which identifies a device as a switch or bridge • the detection of multiple hosts using the same MAC address, which identifies the MAC address as belonging to a router If a device is not identified as a bridge or a router, it is categorized as a host.

Last Seen

The date and time the host was last detected.

Last User

The user most recently logged into this host.

Viewing Events Associated with a Host Profile Requires: DC + RNA

Version 4.7

You can view all the RNA network discovery events associated with the host within the current time range.


178


Chapter 8

To view associated RNA events: Access: Data or Admin

h

In the Events field, click View. The table view of RNA events appears, showing the events associated with the host.

If your Defense Center also manages 3D Sensors with IPS, to view intrusion events where the host is the source IP address: Access: Data or Admin

h

Requires: DC + IPS + RNA In the Intrusion Events field, click Source. The first page of your preferred workflow for intrusion events appears, showing the events where the host is the source IP address. If you do not have a preferred workflow for intrusion events, you must select one.

If your Defense Center also manages 3D Sensors with IPS, to view intrusion events where the host is the destination IP address: Access: Data or Admin

h

Requires: DC + IPS + RNA In the Intrusion Events field, click Destination. The first page of your preferred workflow for intrusion events appears, showing the events where the host is the destination IP address. If you do not have a preferred workflow for intrusion events, you must select one.

Working with Operating Systems in the Host Profile Requires: DC + RNA

RNA passively detects the operating system running on a host by analyzing the network stack in traffic generated by the host. However, sometimes RNA supplies a general operating system definition rather than a specific one because the traffic does not provide sufficient information for a more focused identity. Because the vulnerabilities list for the host and the event impact correlation for events targeting the host depend on the operating system, you may want to manually supply more specific operating system information. In addition, you can indicate that fixes have been applied to the operating system, such as service packs and updates, and invalidate any vulnerabilities addressed by the fixes. For example, if RNA identifies a host’s operating system as Microsoft Windows 2003, but you know that the host is actually running Microsoft Windows XP Professional with Service Pack 2, you can set the operating system identity accordingly. Setting a more specific operating system identity refines the list of vulnerabilities for the host, so your impact correlation for that host is more focused and accurate. Although you can configure the RNA detection policy to add hosts to the network map based on data exported by NetFlow devices, there is no operating system data available for these hosts, unless you set the operating system identity. For more information, see What Information Does RNA Provide? on page 127.

Version 4.7


179

Using Host Profiles Working with VLAN Tags in the Host Profile

Chapter 8

Note that if a host is running a operating system that violates a compliance white list in an activated compliance policy, the Defense Center marks the operating system information with the white list violation icon ( ).

You can set a custom display string for the host’s operating system identity. That display string is then used in that host profile. IMPORTANT! If you replace the operating system information detected by RNA with Nmap scan results or user input, RNA does not update the operating system information. If the host is deleted from the network map and re-detected by RNA, RNA resumes monitoring of operating system information for the host. Also note that changing the operating system information for a host can change its compliance with a compliance white list. To change the operating system identity: Access: Data or Admin

1.

In a host profile, click Operating System in the basic host information. A pop-up window appears where you can set the operating system identity.

2. Optionally, select a new operating system from the OS Definition drop-down list. 3. Optionally, select Use Custom Display String and type the custom strings you want to display in the Vendor String, Product String, and Version String fields. 4. Optionally, to configure fixes for the specified operating system identity, click Configure Fixes. 5. Add the patches you want to apply for that operating system to the fixes list. 6. Click Finish to complete the operating system identity configuration.

Working with VLAN Tags in the Host Profile Requires: DC + RNA

Version 4.7

The VLAN TAG section of the host profile appears if the host is a member of a Virtual LAN (VLAN). Physical network equipment often uses VLANs to create logical network segments from different network blocks. RNA detects 802.1q VLAN tags and displays the following information for each: •

VLAN ID identifies the VLAN where the host is a member. This can be any integer between zero and 4095 for 802.1q VLANs.

•

Type identifies the encapsulated packet containing the VLAN tag, which can be either Ethernet or Token Ring.

•

Priority identifies the priority in the VLAN tag, which can be any integer from zero to 7, where 7 is the highest priority.


180

Using Host Profiles Working with User History in the Host Profile

Chapter 8

If VLAN tags are nested within the packet, RNA processes and the Defense Center displays the innermost VLAN tag. RNA collects and the Defense Center displays VLAN tag information only for MAC addresses that it identifies through ARP and DHCP traffic. VLAN tag information can be useful, for example, if you have a VLAN composed entirely of printers and RNA detects a Microsoft Windows 2000 operating system in that VLAN. VLAN information also helps RNA generate more accurate network maps.

Working with User History in the Host Profile Requires: RNA and Defense Center

The user history portion of the host profile provides a graphic representation of the last twenty-four hours of user activity. A typical user would log off in the evening and may share the host resource with another user. Periodic login requests such as those made to check email are indicated by short regular bars. A list of the user identities is provided with bar graphs to approximate the login and logout times.

Working with Host Attributes in the Host Profile Requires: DC + RNA

You can use host attributes to classify hosts in ways that are important to your network environment. Host attribute values can be positive integers, strings, or URLs. You can also create a list of string values and assign them automatically based on host IP addresses. For information about creating and managing userdefined host attributes, see Working with User-Defined Host Attributes on page 202. The Sourcefire 3D System includes two predefined host attributes: Host Criticality and Notes. See Working with the Predefined Host Attributes on page 201 for information about working with these predefined host attributes. In addition, each compliance white list that you create automatically creates a host attribute with the same name as the white list. Its possible values are Compliant (for hosts that are compliant with the white list), Non-Compliant (for hosts that violate the white list), or Not Evaluated (for hosts that are not valid targets of the white list or have not been evaluated for any reason). You cannot

Version 4.7


181

Using Host Profiles Working with Host Protocols in the Host Profile

Chapter 8

manually change the value of a white list host attribute. For more information on white lists, see Using RNA as a Compliance Tool on page 340.

Assigning Host Attribute Values Requires: DC + RNA

You can specify positive integers, strings, or URLs as values for existing host attributes. TIP! You can quickly assign host attributes for a host by clicking the Edit link in the Attributes section of the host profile page. This launches a pop-up window containing fields for all the host attributes. To assign a host attribute value:


1.

Open a host profile.

2. Under Attributes, click the name of the host attribute to which you want to assign a value. A pop-up window appears. 3. Enter a value for the attribute or select a value from the drop-down list. 4. Click Save. The host attribute value is saved.

Working with Host Protocols in the Host Profile Requires: DC + RNA

You can view the protocols running on a host through the host profile. If needed, you can also delete host protocols for a particular host from the profile. Each host profile contains information about the protocols detected in the network traffic associated with the host.

Version 4.7


182

Using Host Profiles Working with White List Violations in the Host Profile

Chapter 8

The host profile displays protocol and network layer information as described in the Protocol Information table. Protocol Information Column

Description

Protocol

The name of a protocol used by the host.

Layer

The network layer where the protocol runs (Network or Transport).

Note that if the host is running a protocol that violates a compliance white list in an activated compliance policy, the Defense Center marks the noncompliant protocol with the white list violation icon ( ).

You can delete a protocol from a host profile to remove protocols you know are not running on the host. Note that deleting a protocol from a host can bring a host into compliance with a compliance white list. IMPORTANT! If RNA detects the protocol again, it re-adds it to the network map and the host profile. To delete a protocol from a host profile: Access: Data or Admin

h

In the Protocols section of the host profile, click the Delete icon next to the protocol you want to delete. The protocol is deleted for that host.

Working with White List Violations in the Host Profile Requires: DC + RNA

A compliance white list (or white list) is a set of criteria that allows you to specify the operating systems, client applications, services, and protocols that are allowed to run on a specific subnet. If you add a white list to an active compliance policy, when RNA detects that a host is violating the white list, the Defense Center logs a white list event—which is a special kind of compliance event— to the database. Each of these white list events is associated with a white list violation, which indicates how and why a particular host is violating a white list. If a host violates one or more white lists, you can view these violations in its host profile in two ways.

Version 4.7


183

Using Host Profiles Working with White List Violations in the Host Profile

Chapter 8

First, the host profile lists all of the individual white list violations associated with the host.

The host profile displays white list violation information as described in the White List Violation Information table. White List Violation Information Column

Description

Type

The type of the violation, that is, whether the violation occurred as a result of a non-compliant operating system, service, client application, or protocol.

Reason

The specific reason for the violation. For example, if you have a white list that allows only Microsoft Windows hosts, the host profile displays the current operating system running on the host (such as Linux Linux 2.4, 2.6)

White List

The name of the white list associated with the violation.

Second, in the sections associated with operating systems, services, protocols, and client applications, the Defense Center marks noncompliant elements with the white list violation icon ( ). For example, for a white list that allows only Microsoft Windows hosts, the host profile displays the white list violation icon next to the operating system information for that host.

Note that you can use a host’s profile to create a shared host profile for compliance white lists. For more information, see the next section, Creating a White List Host Profile from a Host Profile.

Version 4.7


184

Using Host Profiles Working with Services in the Host Profile

Chapter 8

Creating a White List Host Profile from a Host Profile Requires: DC + RNA

Shared host profiles for compliance white lists specify which operating systems, client applications, services, and protocols are allowed to run on target hosts across multiple white lists. That is, if you create multiple white lists but want to use the same host profile to evaluate hosts running a particular operating system across the white lists, use a shared host profile. You can use a host profile of any host whose IP address is known to create a shared host profile that your compliance white lists can use. To create a shared host profile for compliance white lists based on a host profile:

Access: Admin

1.

Access a host profile from any network map or from any event view. For more information, see Viewing Host Profiles on page 175.

2. Click Generate White List Profile. The Edit Shared Profiles page appears. The fields on the page are prepopulated based on the information in the host profile you accessed. 3. Modify and save the shared host profile according to your specific needs. For more information on creating shared host profiles for compliance white lists, see Working with Shared Host Profiles on page 371.

Working with Services in the Host Profile Requires: DC + RNA

If RNA detects services running on a host, the Defense Center lists them in the Services section of the host profile.

IMPORTANT! Although you can configure the RNA detection policy to add services to the network map based on data exported by NetFlow devices, the available information about these services is limited. For more information, see What Information Does RNA Provide? on page 127. If you scan the host using Nmap, Nmap adds the results of previously undetected services running on open TCP ports to the Services list. If you perform an Nmap scan on a host or import Nmap results, an expandable Scan Results section also appears in the host profile, listing the service information detected on the host by the Nmap scan. See Working with Scan Results in a Host Profile on page 207 and

Version 4.7


185


Chapter 8

Setting up Nmap Scans on page 578 for more information. Note that once you replace the information for a particular service with Nmap scan results or user input, RNA does not update that information. If the host is deleted from the network map and re-detected, RNA resumes monitoring of that service for the host. The process for working with services in the host profile differs depending on how you accessed the profile. •

If you accessed the host profile by drilling down through the Services network map, the details for that service appears with the service name highlighted in bold. If you want to view the details for any other service on the host, click View next to that service name.

•

If you accessed the host profile in any other way, expand the Services section and click View next to the service whose details you want to see.

You can also perform the following actions: •

To analyze the flow events associated with a particular service on the host, click Flow next to the service. The first page of your preferred workflow for flow events appears, showing flow events constrained by the port and protocol of the service, as well as the IP address of the host. If you do not have a preferred workflow for flow events, you must select one. For more information about flow data, see Working with Flow Data and Traffic Profiles on page 275.

•

To delete a service from the host profile, click Delete next to the service. The service is deleted from the host profile, but will appear again if RNA detects traffic from the service again. Note that deleting a service from a host can bring the host into compliance with a white list.

The columns in the Services list are described in the Service Information table. Service Information

Version 4.7

Column

Description

Protocol

The name of the protocol the service uses.

Port

The port where the service runs.


186


Chapter 8

Service Information (Continued) Column

Description

Service

One of: • the service name as identified by RNA or Nmap, or, for services added to the network map based on NetFlow data, the service name identified by the port-service correlation in /etc/sf/services • the service name you specified using the host input feature • unknown, if RNA detected the service but cannot identify it based on known service fingerprints • unidentified, if the service was created using NetFlow data but could not be identified by the port-service correlation in /etc/sf/services, or if RNA detected the service but does not yet have enough information to identify it

Version

The service version that either: • was detected by RNA or Nmap • you specified using the host input feature If RNA or Nmap cannot identify the version of a running service, and you do not specify the version, this field remains blank.

Source


Version 4.7


187


Chapter 8

Service Information (Continued) Column

Description

Confidence

For services detected by 3D Sensors with RNA, the percentage of confidence (between 0% and 100%) that RNA has in its service identification. For services added to the network map based on NetFlow data, and for unidentified services, the confidence is always 0%. For services with the host input feature or the Nmap scanner, the confidence is always 100%

Last Used

The time and date the service was last detected.

Note that if the host is running a service that violates a compliance white list in an activated compliance policy, the Defense Center marks the noncompliant service with the white list violation icon ( ).

See the following sections for more information:

Version 4.7

•

Service Detail on page 189

•

Service Banner on page 190

•

Editing Service Identities on page 191


188


Chapter 8

Service Detail Requires: DC + RNA

The Service Detail appears in a pop-up window when you click View next to a service in the Services list section of a host profile. Any sub-service information known about the selected service is also displayed.

The Service Detail displays the information described in the Service Detail Information table. Service Detail Information

Version 4.7

Row

Description

Protocol

The name of the protocol the service uses.

Port

The port where the service runs.

Service

The name of the service, if known.

Vendor

The service vendor. This field does not appear if the vendor is unknown.

Version

The service version. This field does not appear if the version is unknown.


189


Chapter 8

Service Detail Information (Continued) Row

Description

Source Type


Confidence

For services detected by 3D Sensors with RNA, the percentage of confidence (between 0% and 100%) that RNA has in its service identification. For services added to the network map based on NetFlow data, and for unidentified services, the confidence is always 0%. For services with the host input feature or the Nmap scanner, the confidence is always 100%.

Hits

The number of times the service was detected by RNA or Nmap. Note that the number of hits is 0 for services imported through host input, unless RNA detects traffic for that service.

Last Used

The time and date the service was last detected. Note that the last used time for host input data reflects the initial data import time, unless RNA detects traffic for that service. Note also that host input data does not time out.

Service Banner Requires: DC + RNA

Service banners provide additional information about a service that may help you identify a service. RNA cannot identify or detect a misidentified service when an attacker purposely alters the service banner string. IMPORTANT! Note that you must select the Capture Banners check box in the RNA detection policy to view service banners. This option is disabled by default.

Version 4.7


190


Chapter 8

The service banner appears below the service details when you view a service from the host profile.

The service banner displays the first 256 bytes of the first packet detected for the service. It is collected only once, the first time the service is detected by RNA. Banner content is listed in two columns, with a hexadecimal representation on the left and a corresponding ASCII representation on the right.

Editing Service Identities Requires: DC + RNA

You can manually update the identity settings for a service on a host and configure any fixes that you have applied to the host to remove the vulnerabilities addressed by the fixes. To modify the service identity:


Version 4.7

1.

Click Edit next to the service in the Services list. The Service Identity pop-up window appears.


191


Chapter 8

2. Select the type of service from the Select Service Type drop-down list. 3. Optionally, to only list vendors and products for that service type, select the Restrict by Service Type check box. 4. Optionally, to customize the name and version of the service, select the Use Custom Display String and type a Vendor String and Version String. 5. In the Product Mappings section, select the operating system, product, and versions you want to use from the following lists (if applicable): •

Vendor

•

Product

•

Major Version

•

Minor Version

•

Revision Version

•

Build

•

Patch

•

Extension

For example, if you want the service to map to Redhat Linux 9, select Redhat, Inc. as the vendor, Redhat Linux as the product, and 9 as the version. 6. If you want to indicate that fixes for the service have been applied, click Configure Fixes. Otherwise, skip to step 8. The Available Package Fixes page appears.

7.

Add the patches you want to apply for that service to the fixes list.

8. Click Finish to complete the service identity configuration.

Version 4.7


192

Using Host Profiles Working with Client Applications in the Host Profile

Chapter 8

Working with Client Applications in the Host Profile Requires: DC + RNA

You can see the client applications running on a host in the host profile. If you want to remove a client application from a host profile, you can delete that client application. For more information on managing client applications in the host profile, see: •

Viewing Client Applications in the Host Profile on page 193

•

Deleting Client Applications from the Host Profile on page 194

IMPORTANT! The host profile of a host added to the network map based on NetFlow data does not include any information on the client applications running on the host. For more information, see What Information Does RNA Provide? on page 127.

Viewing Client Applications in the Host Profile Requires: DC + RNA

RNA can detect a variety of client applications running on the hosts on your network. For a list of the applications that RNA recognizes, see Detected Client Applications on page 1436. IMPORTANT! Note that you must select the Client Application Detection check box in your RNA detection policy for RNA to detect client applications on the hosts in your monitored network. This option is enabled by default. The host profile displays the product and version of the detected client applications on a host, as well as the time that the application was last detected in use.

The Client Application Information table describes the client application information that appears in a host profile. Client Application Information

Version 4.7

Column

Description

Type

Displays the category of application (HTTP browser, SMTP agent, and so on).

Product

Displays the vendor and product name of the client application.


193

Using Host Profiles Working with Client Applications in the Host Profile

Chapter 8

Client Application Information (Continued) Column

Description

Version

Displays the version of the client application.

Last Used

Shows the last time the host used the client application or the last time the client application was detected. If the client application was added through the host input API or command line import, the last used time indicates the time the client application data was originally imported for the host.

Note that if the host is running a client application that violates a compliance white list in an activated compliance policy, the Defense Center marks the noncompliant application with the white list violation icon ( ).

To analyze the flow events associated with a particular client application on the host, click Flow next to the application. The first page of your preferred workflow for flow events appears, showing flow events constrained by the type, product, and version of the application, as well as the IP address of the host. If you do not have a preferred workflow for flow events, you must select one. For more information about flow data, see Working with Flow Data and Traffic Profiles on page 275.

Deleting Client Applications from the Host Profile Requires: DC + RNA

You can delete a client application from a host profile to remove client applications that you know are not running on the host. Note that deleting a client application from a host can bring the host into compliance with a white list. IMPORTANT! If RNA detects the client application again, it re-adds it to the network map and the host profile. To delete a client application from a host profile:


h

In the Client Applications section of the host profile, click the Delete icon next to the client application you want to delete. The client application is deleted for that host.

Version 4.7


194

Using Host Profiles Working with Detected Vulnerabilities in the Host Profile

Chapter 8

Working with Detected Vulnerabilities in the Host Profile Requires: DC + RNA

The RNA Vulnerabilities section of the host profile lists the vulnerabilities that affect that host; the Defense Center compiles this list based on the operating system and services that RNA detected on the host.

IMPORTANT! Because there is no operating system information available for hosts added to the network map based on NetFlow data, the Defense Center cannot determine which vulnerabilities might affect those hosts, unless you use the host input feature to manually set the hosts’ operating system identity. The Vulnerability Information table describes the columns in the Vulnerabilities section of the host profile. Vulnerability Information

Version 4.7

Column

Description

Name

The name of the vulnerability.

Remote

Indicates whether the vulnerability can be remotely exploited.

Service

Lists the service name if the vulnerability is associated with a specific existing service.

Port

Lists the port number if the vulnerability is associated with a service running on a specific port.


195


Chapter 8

When viewing vulnerabilities, you can: •

view technical details about a vulnerability, including known solutions, by clicking the name of the vulnerability. See Viewing Vulnerability Details on page 197 for more information. TIP! You can also access vulnerability details from the vulnerability event views (Analysis & Reporting > RNA > Vulnerabilities) or the Vulnerabilities network map (Analysis & Reporting > RNA > Network Map > Vulnerabilities).

•

prevent a vulnerability from being used to evaluate impact flag correlations. See Setting the Vulnerability Impact Qualification on page 199 for more information.

•

download patches to mitigate the vulnerabilities discovered on the hosts on your network. See Downloading Patches for Vulnerabilities on page 199 for more information.

•

mark hosts as not vulnerable to individual vulnerabilities if you know that the hosts have been patched. See Setting Vulnerabilities for Individual Hosts on page 200 for more information.

If you perform a Nessus scan on a host or import Nessus results, an expandable Nessus Vulnerabilities section also appears in the host profile, listing the vulnerabilities detected on the host by the Nessus scan. See Configuring Nessus Scan Remediations on page 506 and Understanding Nessus Scans on page 591 for more information. The number of RNA and Nessus vulnerabilities for a host is listed in parentheses in the section heading. Host profiles for bridges and routers can also include vulnerability information.

Version 4.7


196


Chapter 8

Viewing Vulnerability Details Requires: DC + RNA

Vulnerability details include a technical description of the vulnerability and known solutions.

The Vulnerability Detail Information table describes the fields on the Vulnerability Detail page. Vulnerability Detail Information Row

Description

RNA Vulnerability ID

The RNA Vulnerability identification number that RNA uses to track vulnerabilities.

Snort ID

The identification number associated with the vulnerability in the Snort ID (SID) database. That is, if an intrusion rule can detect network traffic that exploits a particular vulnerability, that vulnerability is associated with the intrusion rule’s SID. Note that a vulnerability can be associated with more than one SID (or no SIDs at all). If the vulnerability does not have an associated SID, this field does not appear.

BugTraq ID

Version 4.7

The identification number associated with the vulnerability in the Bugtraq database (http://www.securityfocus.com/bid).


197


Chapter 8

Vulnerability Detail Information (Continued) Row

Description

CVE ID

The identification number associated with the vulnerability in MITRE’s Common Vulnerabilities and Exposures (CVE) database (http://www.cve.mitre.org/).

Title

The title of the vulnerability.

Impact Qualification

Use the drop-down list to enable or disable a vulnerability. The Defense Center ignores disabled vulnerabilities in its impact flag correlations. The setting you specify here determines how the vulnerability is treated on a system-wide basis and is not limited to the host profile where you select the value. See Setting the Vulnerability Impact Qualification on page 199 for information about using this feature to enable and disable a vulnerability.

Date Published

The date that the vulnerability was published.

Vulnerability Impact

The severity assigned to the vulnerability in the Bugtraq database on a scale of 1 to 10, with 10 being the most severe. The vulnerability impact is determined by the writer of the Bugtraq entry, who determines the vulnerability impact level based on his or her best judgment, guided by SANS Critical Vulnerability Analysis (CVA) criteria.

Remote

Indicates whether the vulnerability is remotely exploitable.

Available Exploits

Indicates whether there are known exploits for the vulnerability.

Description

Summary description of the vulnerability.

Technical Description

Detailed technical description of the vulnerability.

Solution

Information about repairing the vulnerability.

Additional Information

Click the arrow to view additional information (if available) about the vulnerability, such as known exploits and their availability, exploit scenarios, and mitigation strategies.

Fixes

Provides links to downloadable patches for the selected vulnerability. TIP! If direct links to fix or patch downloads appear, rightclick the link and save it to your local computer.

Version 4.7


198


Chapter 8

Setting the Vulnerability Impact Qualification Requires: DC + RNA

If RNA reports a vulnerability that is not applicable to your network, you can prevent it from being used to evaluate impact flag correlations. Note that if you deactivate a vulnerability in a host profile, it deactivates it for all hosts on your network. You can, however, reactivate it at any time. Note also that RNA does not recommend a rule state for an intrusion rule that is based on a vulnerability that you disable using the Impact Qualification feature. For more information, see Using RNA Recommended Rules on page 811. TIP! You can also deactivate vulnerabilities from the network map and from vulnerability event views. For more information, see Working with the Vulnerabilities Network Map on page 158 and Deactivating Vulnerabilities on page 271. To change the use of a vulnerability across the system:


1.

Access the host profile of a host affected by the vulnerability you want to deactivate.

2. Expand the RNA Vulnerabilities section. 3. Click the name of the vulnerability you want to enable or disable. A pop-up window appears with the vulnerability details. For more information, see Viewing Vulnerability Details on page 197. 4. Select Disabled or Enabled from the Impact Qualification drop-down list to specify how the vulnerability is used. 5. Confirm that you want to change the Impact Qualification for all hosts on the network map. The vulnerability is enabled or disabled. 6. Click Done to close the vulnerability details pop-up window.

Downloading Patches for Vulnerabilities Requires: DC + RNA

If they are available, you can download patches to mitigate the vulnerabilities discovered on the hosts on your network. To download a patch for a vulnerability:


1.

Access the host profile of a host for which you want to download a patch.

2. Expand the RNA Vulnerabilities section. 3. Click the name of the vulnerability you want to patch. The Vulnerability Detail page appears.

Version 4.7


199


Chapter 8

4. Expand the Fixes section. The list of downloadable patches for the vulnerability appears.

5. Click Download next to the patch you want to download. A download page from the patch vendor appears. 6. Download the patch and apply it to your affected systems.

Setting Vulnerabilities for Individual Hosts Requires: DC + RNA

You can use the host vulnerability editor to activate or deactivate vulnerabilities on a host-by-host basis. When you deactivate a vulnerability for a host, it is still used for impact flag correlations for that host, but the impact flag is automatically reduced one level. To activate or deactivate a vulnerability for a single host:


1.

Open a host profile.

2. Next to RNA Vulnerabilities, click Edit. The Host Vulnerabilities editor page appears.

TIP! To view details about a vulnerability, select it and click View. For more information, see Viewing Vulnerability Details on page 197.

Version 4.7


200

Using Host Profiles Working with the Predefined Host Attributes

Chapter 8


To deactivate a vulnerability, select it from the Valid Vulnerabilities list, then click the down arrow.

•

To activate a vulnerability, select it from the Invalid Vulnerabilities list, then click the up arrow.

TIP! Use Ctrl or Shift while clicking to select multiple vulnerabilities. You can click and drag to select multiple adjacent vulnerabilities; you can also doubleclick any vulnerability to move it from list to list. 4. Click Save.

Working with the Predefined Host Attributes Requires: DC + RNA

There are two predefined host attributes that you can assign to each host: host criticality and host-specific notes. The following sections describe these host attributes and explain how to use them: •

Assigning a Host Criticality Value to a Host on page 201

•

Adding Notes to a Host on page 202

Assigning a Host Criticality Value to a Host Requires: DC + RNA

Use the host criticality attribute to designate the business criticality of a given host and to tailor compliance policies and alerts based on host criticality. For example, if you consider your organization’s mail servers more critical to your business than a typical user workstation, you can assign a value of High to your mail servers and other business-critical devices and Medium or Low to other hosts. You can then create a compliance policy that launches different alerts based on the criticality of an affected host. To set host criticality in the host profile:


1.

Open the host profile for the host for which you want to set a business criticality.

2. Under Attributes, click Host Criticality. The Host Attributes pop-up window appears.

3. Form the Host Criticality drop-down list, select the value you want to apply: None, Low, Medium, or High.

Version 4.7


201

Using Host Profiles Working with User-Defined Host Attributes

Chapter 8

4. Click Save. Your selection is saved.

Adding Notes to a Host Requires: DC + RNA

Use the Notes feature to record information about the host that you want other analysts to view. For example, if you have a computer on the network that has an older, unpatched version of an operating system that you use for testing, you can use the Notes feature to indicate that the system is intentionally unpatched. To add a note to a host profile:


1.

Open the host profile for the host for which you want to set a business criticality.

2. Under Attributes, click Notes. The Notes pop-up window appears.

3. Enter up to 255 alphanumeric characters, special characters, and spaces in the text box. 4. Click Save. Your notes are saved and associated with the host.

Working with User-Defined Host Attributes Requires: DC + RNA

The Sourcefire 3D System includes two predefined host attributes, host criticality and host notes, that you can use to indicate the business criticality of the hosts on your network. If you have other criteria that you would like to use to identify your hosts, you can create user-defined host attributes. User-defined host attributes appear in the host profile page, where you can assign values on a per-host basis. You can then use those attributes in compliance policies and searches. You can also view the attributes on the host attribute table view of events and generate reports based on them. Some examples of user-defined host attributes include:

Version 4.7

•

assigning physical location identifiers to hosts, such as a facility code, city, or room number.

•

assigning a Responsible Party Identifier that indicates which system administrator is responsible for a given host. You can then craft compliance rules and policies to send alerts to the correct system administrator when problems related to a host are detected.


202


Chapter 8

Host attributes can be text strings or values selected from predefined lists of text or ranges of numbers. You can also automatically assign values to hosts from a predefined list based on the hosts’ IP addresses. You can use this feature to automatically assign values to new hosts when they appear on your network for the first time. Host attributes can be one of the following types: Host Attribute Types Type

Description

Text

Allows you to manually assign a text string up to 255 characters to a host.

Integer

Allows you to specify the first and last number of a range of positive integers and then manually assign one of these numbers to a host.

List

Allows you to create a list of string values and then manually assign one of the values to a host. You can also automatically assign values to hosts based on the host’s IP address.

URL

Allows you to manually assign a URL value to a host.

Note that each compliance white list that you create automatically creates a host attribute with the same name as the white list. Its possible values are “Compliant” (for hosts that are compliant with the white list), “Non-Compliant” (for hosts that violate the white list) or “Not Evaluated” (for hosts that are not valid targets of the white list or have not been evaluated for any reason). You cannot manually change the value of a white list host attribute. For more information on white lists, see Using RNA as a Compliance Tool on page 340. See the following sections for more information: •

Restrictions on User-Defined Host Attributes on page 203

•

Creating User-Defined Host Attributes on page 203

•

Editing a User-Defined Host Attribute on page 206

•

Deleting a User-Defined Host Attribute on page 207

Restrictions on User-Defined Host Attributes Requires: DC + RNA

Host attributes are defined globally rather than per policy. After you create a host attribute, it is available regardless of the policy applied.

Creating User-Defined Host Attributes Requires: DC + RNA

Version 4.7

The following procedure explains how to create a user-defined host attribute.


203


Chapter 8

To create a new host attribute: Access: Rules or Admin

1.

Select Policy & Response > RNA > Host Attributes. The Host Attributes page appears.

2. Click Create Attribute. The New Host Attribute page appears.

3. In the Name field, type a name for the host attribute using alphanumeric characters and spaces. 4. Select the type of attribute that you want to create from the Type drop-down list, as described in the Host Attribute Types table on page 203. •

If you are creating a Text or URL host attribute, continue with step 5.

•

If you are creating an Integer host attribute, see Creating Integer Host Attributes on page 204.

•

If you are creating a List host attribute, see Creating List Host Attributes on page 205.

5. Click Save. The new user-defined host attribute is saved.

Creating Integer Host Attributes Requires: DC + RNA

When you define an integer-based host attribute, you must specify the minimum and maximum values of the range of numbers that the attribute accepts.

To create an integer-based host attribute: Access: Rules or Admin

1.

In the Min field, enter the minimum integer value that can be assigned to a host.

2. In the Max field, enter the maximum integer value that can be assigned to a host.

Version 4.7


204


Chapter 8

Creating List Host Attributes Requires: DC + RNA

When you define a list-based host attribute, you must supply each of the values for the list. These values can contain alphanumeric characters, spaces, and symbols. When you create a value for the host attribute, you can also auto-assign it to a range of IP addresses so that when a new host is discovered, it is automatically assigned a value for the host attribute.

To create a list-based host attribute: Access: Rules or Admin

1.

To add a value to the list, click Add Value. The List Values section appears.

2. In the Name field, enter the first value you want to add using alphanumeric characters, symbols, and spaces.

Version 4.7


205


Chapter 8

3. Optionally, to auto-assign your hosts to the value you just added, click Add Networks. The Auto-Assign Networks section appears.

4. Select the value you added from the Value drop-down list. In the IP Address and Netmask fields, specify the subnet where you want to auto-assign this value. Use CIDR notation without the forward slash in the Netmask field. For example, to auto-assign the value to the 192.168.100.0 to 192.168.100.255 address range, enter 192.168.100.0 in the IP Address field and 24 in the Netmask field. 5. Repeat steps 1 through 4 to add additional values to the list and assign them automatically to new hosts that fall within an IP address range. TIP! If you do not want to auto-assign list values to the hosts in specific IP ranges, you can manually assign them as described in Assigning a Host Criticality Value to a Host on page 201.

Editing a User-Defined Host Attribute Requires: DC + RNA

Version 4.7

When you modify an existing user-defined host attribute, you can change the definition of a value, but you cannot change the attribute type (text, list, integer, URL). In addition, you cannot modify compliance white list host attributes.


206

Using Host Profiles Working with Scan Results in a Host Profile

Chapter 8

To edit an existing user-defined host attribute: Access: Rules or Admin

1.

Select Policy & Response > RNA > Host Attributes. The User-Defined Host Attribute page appears, displaying a list of the userdefined Host Attributes.

2. Click Edit next to the host attribute you want to edit. The Host Attribute page appears with the selected attribute’s settings. 3. Modify any of the settings that you want and click Save. See Creating User-Defined Host Attributes on page 203 for more information about the attribute types that you can edit and the values those attributes can contain.

Deleting a User-Defined Host Attribute Requires: DC + RNA

Delete a user-defined host attribute to remove it from every host profile where it is used. Note that you cannot delete compliance white list host attributes. To delete a host attribute:

Access: Rules or Admin

1.

Select Policy & Response > RNA > Host Attributes. The User-Defined Host Attribute page appears.

2. Click Delete next to the host attribute you want to delete. The selected host attribute is removed from the system.

Working with Scan Results in a Host Profile Requires: DC + RNA

When you scan a host using Nmap, or when you import results from an Nmap scan, those results appear in the host profile for any hosts included in the scan. Nmap adds information about the host operating system and any services running on open unfiltered ports directly into the Operating System and Services

Version 4.7


207


Chapter 8

sections of the host profile, respectively. In addition, Nmap adds a list of the scan results for that host in the Scan Results section.

Each result indicates the source of the information, the number and type of the scanned port, the name of the service running on the port, and any additional information detected by Nmap, such as the state of the port or the vendor name for the service. If you scan for UDP ports, services detected on those ports only appear in the Scan Results section. Note that you can run an Nmap scan from the host profile. For more information, see the next section, Scanning a Host from the Host Profile.

Scanning a Host from the Host Profile Requires: DC + RNA

You can perform a Nessus or Nmap scan against a host from the host profile. Once the scan completes, service and operating system information for that host are updated in the host profile. Any additional scan results are added to the Scan Results section of the host profile. WARNING! Once Nmap replaces a host’s operating system or services detected by RNA with the results from an Nmap scan, RNA no longer updates the information replaced by Nmap for the host. Nmap-supplied service and operating system data remains static until you run another Nmap scan. If you plan to scan a host using Nmap, you may want to set up regularly scheduled scans to keep any Nmap-supplied operating system and service data up to date. For more information, see Automating Nmap Scans on page 1325.

Version 4.7


208


Chapter 8

To scan a host from the host profile: Access: Admin

1.

In the host profile, click Scan Host. The Scan Host pop-up window appears.

2. Click Scan next to the scan remediation you want to use to scan the host. The host is scanned and the results are added to the host profile.

Version 4.7


209

Chapter 8

Working with RNA Events

RNA events are triggered by the changes that your 3D Sensors with RNA detect in the network segments they monitor. Settings in two policies specify the kinds of information RNA collects and stores. •

The system policy controls the kinds and amount of RNA data stored in the database, and therefore determines the data that other parts of the Sourcefire 3D System can use.

•

The RNA detection policy specifies the kinds of data RNA collects, as well as the monitored network segments.

Note that these policies also control other aspects of sensor behavior. For more information, see Using System Policies on page 1189 and Configuring RNA Detection Policies on page 134. RNA events alert you to the activity on your network and provide you with the information you need to respond appropriately. As a simple example, you may have conference rooms or a series of spare work spaces where visiting employees attach to your network. You would expect to see New Host events generated by RNA on these segments on a regular basis, and you would not suspect malicious intent. However, if you see a New Host event on a network segment that is locked down, then you can escalate your response accordingly. RNA events provide you with much greater depth of insight into the activity on your network and with much more granularity than this simple example shows. You can also set up RNA to detect the services, network protocols, client applications, and potential vulnerabilities running on your network hosts. In addition, you can track RNA-specific features such as changes to host criticality, user-defined host attributes, and user-initiated interactions with host vulnerabilities.

Version 4.7


210

Working with RNA Events Viewing RNA Event Statistics

Chapter 9

RNA provides a set of predefined workflows that you can use to analyze the events that are generated for your network. You can use these predefined workflows, or you can create custom workflows that display only the information that matches your specific needs. To collect and store RNA data for analysis, make sure that: •

you apply a host license to your Defense Center. For more information, see Managing Licenses on page 1215.

•

your RNA detection policy is configured to monitor networks whose traffic your managed 3D Sensors with RNA and NetFlow devices can see. For more information, see Configuring RNA Detection Policies on page 134.

IMPORTANT! You must use a Defense Center with an RNA host license to view RNA events. You cannot view RNA events on a Master Defense Center. For more information, see: •

Viewing RNA Event Statistics on page 211

•

Understanding RNA Event Workflows on page 217

•

Working with Network Discovery and Host Input Events on page 218

•

Working with Hosts on page 231

•

Working with Host Attributes on page 244

•

Working with Services on page 251

•

Working with Client Applications on page 261

•

Working with Vulnerabilities on page 267

IMPORTANT! When a connection between a monitored host and any other host is terminated, RNA generates a flow event. For more information on flow events, see Understanding Flow Data on page 279.

Viewing RNA Event Statistics Requires: DC + RNA

The RNA Statistics page displays a summary of the hosts, events, protocols, services, and operating systems detected by RNA. It lists statistics for the last hour and the total accumulated statistics. You can select statistics for a particular detection engine, a particular sensor, or all detection engines on all sensors. You can also view events that match the entries on the page by clicking the event, service, operating system, or operating system vendor listed within the summary. To view RNA Statistics:


Version 4.7

1.

Select Analysis & Reporting > Event Summary > RNA Statistics. The RNA Statistics page appears.


211


Chapter 9

2. From the Select a Target list, select the detection engine whose statistics you want to view. Select All to view statistics for all RNA detection engines on any sensors managed by the Defense Center. TIP! Click Refresh to refresh the display with current data. The RNA Statistics page has multiple sections that allow you to view detailed information about the following: •

Statistics Summary, which provides general statistics about the total events, services, hosts, routers, bridges, and information about your host limit usage. See Statistics Summary on page 212 for more information.

•

Event Breakdown, which provides statistics about the types of events occurring on the system. See Event Breakdown on page 214 for more information.

•

Protocol Breakdown, which provides statistics about the protocols that detected hosts are using. See Protocol Breakdown on page 215 for more information.

•

Service Breakdown, which provides statistics about the services running on the network. See Service Breakdown on page 215 for more information.

•

OS Breakdown, which lists the operating systems that are running on the network and how many hosts are using each operating system. See OS Breakdown on page 216 for more information.

Statistics Summary Requires: DC + RNA

Version 4.7

The statistics summary provides general statistics about the total events, services, hosts, routers, bridges, and information about your host limit usage.


212


Chapter 9

The Statistics Summary table describes the rows of the Statistics Summary section of the RNA Statistics page. Statistics Summary Row

Description

Total Events

Total number of RNA events stored on the Defense Center.

Total Events Last Hour

Total number of RNA events generated in the last hour.

Total Events Last Day

Total number of RNA events generated in the last day.

Total Services

Total number of services running on detected hosts.

Total IP Hosts

Total number of detected hosts RNA has identified by unique IP address.

Total MAC Hosts

Total number of detected hosts not identified by IP address. Note that this number will be the same for all detection engines connected to the same network, since the RNA detection policy is targeted to detection engines by IP address and this field totals all hosts not identified by an IP address.

Total Routers

Total number of detected nodes identified as routers.

Total Bridges

Total number of detected nodes identified as bridges.

Host Limit Usage

Total percentage of the host limit currently in use. The host limit is defined by the RNA host license. Note that the host limit usage only appears if you are viewing statistics for all detection engines. IMPORTANT! If the host limit is reached and a host is deleted, the host will not reappear on the network map until you restart RNA.

Version 4.7

Last Event Received

The date and time that the most recent RNA event occurred.

Last Flow Received

The date and time that the most recent RNA flow was completed.


213


Chapter 9

Event Breakdown Requires: DC + RNA

The Event Breakdown section lists a count of each type of network discovery and host input event that occurred within the last hour, as well as a count of the total number of each event type stored in the database. For full descriptions of each event type, see the RNA Network Discovery Event Types table on page 220 and the RNA Host Input Event Types table on page 224.

You can also use the Events Breakdown section to view details on network discovery and host input events. To view network discovery and host input events by type: Access: Data or Admin

h

Click the type of event you want to view. The first page of your default RNA events workflow appears, constrained by the event type you picked. For information on working with RNA events, see Working with Network Discovery and Host Input Events on page 218. If you created a custom RNA events workflow and did not specify a default, you must first select one. For information on specifying a default workflow, see Setting Event Preferences on page 35.

Version 4.7


214


Chapter 9

Protocol Breakdown Requires: DC + RNA

The Protocol Breakdown section lists the protocols currently in use by detected hosts. It displays each detected protocol name, its “layer” in the protocol stack, and the total number of hosts that communicate using the protocol.

Service Breakdown Requires: DC + RNA

Version 4.7

The Service Breakdown section lists the services that are currently in use by detected hosts. It lists the service name, the total number of hosts running the service in the past hour, and the total number of hosts that have been detected running the service at any point.


215


Chapter 9

You can also use the Service Breakdown section to view details on the services detected by RNA. To view service events that match a listed service name: Access: Data or Admin

h

Click the name of the service you want to view. The first page of your default services workflow appears, constrained by the service you picked. For information on working with services, see Working with Services on page 251. If you created a custom services workflow and did not specify a default, you must first select one. For information on specifying a default workflow, see Setting Event Preferences on page 35.

OS Breakdown Requires: DC + RNA

The OS Breakdown section lists the operating systems currently running on the monitored network, along with their vendors and the total number of hosts running each operating system.

You can also use the OS Breakdown section to view details on the operating systems detected by RNA. To view hosts by operating system or vendor: Access: Data or Admin

h


To view all hosts running a specific operating system, under OS Name, click the operating system name.

•

To view all hosts running any operating system from a specific vendor, under OS Vendor, click the vendor name.

The first page of your default hosts workflow appears, constrained by the operating system or vendor you picked. For information on working with the RNA hosts workflow, see Working with Hosts on page 231. If you created a custom hosts workflow and did not specify a default, you must first select one. For information on specifying a default workflow, see Setting Event Preferences on page 35.

Version 4.7


216

Working with RNA Events Understanding RNA Event Workflows

Chapter 9

Understanding RNA Event Workflows Requires: DC + RNA

Defense Center provides a set of workflows that you can use to analyze the RNA events that are generated for your network. The RNA workflows are, along with the network map, a key source of information about your network assets. These workflows contain tables that are populated with data generated by RNA. Access RNA workflows from the Analysis & Reporting > RNA menu. The Defense Center provides predefined workflows for network discovery events (also called simply RNA events), as well as for detected hosts and their host attributes, services, client applications, and vulnerabilities. You can also create custom workflows. For more information on workflows, see Understanding and Using Workflows on page 1147. TIP! Select Analysis & Reporting > Custom Tables to access workflows based on custom tables. When you are using an RNA workflow, you can perform many common actions, whatever the type of event. These common functions are described in the Common RNA Event Actions table.

Common RNA Event Actions To...

You can...

view the host profile for an IP address

click the host profile icon (

view the user profile information

click the users icon ( )that appears next to the User identity. For a list of the details refer to Understanding User Details and Host History on page 1091.

sort and constrain events on the current workflow page

find more information in Sorting Workflow Pages and Changing Their Layout on page 1174.

navigate within the current workflow page

find more information in Navigating to Other Pages in the Workflow on page 1175.

navigate between pages in the current workflow, keeping the current constraints

click the appropriate page link at the top left of the workflow page. For more information, see Using Workflow Pages on page 1165.

Version 4.7

)that appears next to the IP address.


217

Working with RNA Events Working with Network Discovery and Host Input Events

Chapter 9

Common RNA Event Actions (Continued) To...

You can...

delete items from the system, including: • network discovery and host input events from RNA events workflows

use one of the following methods: • To delete some items, select the check boxes next to items you want to delete, then click Delete.

• hosts and bridges from hosts workflows • host attributes from host attributes workflows • services from services workflows

• To delete all items in the current constrained view, click Delete All, then confirm you want to delete all the items. These items remain deleted until RNA is restarted, when they may be detected again. Note that you cannot delete vulnerabilities; you can, however, mark them reviewed. For more information, see Working with Vulnerabilities on page 267. Also, see Purging the RNA and RUA Databases on page 1232 for information on deleting all RNA events from the database.

• client applications from client application workflows navigate to other event views to view associated events

find more information in Navigating between Workflows on page 1175.

temporarily use a different workflow

click Workflows. For more information, see Selecting Workflows on page 1162.

bookmark the current page so that you can quickly return to it

click Bookmark This Page. For more information, see Using Bookmarks on page 1177.

navigate to the bookmark management page

click View Bookmarks. For more information, see Using Bookmarks on page 1177.

generate a report based on the data in the current view

click Report Designer. For more information, see Creating Reports from Event Views on page 1105.

Working with Network Discovery and Host Input Events Requires: DC + RNA

A 3D Sensor with RNA generates network discovery events that communicate the details of changes in your monitored network segments. New events are generated for newly discovered network features, and change events are generated for any change in previously identified network assets. During its initial network discovery phase, RNA generates new events for each host and any TCP or UDP services discovered running on each host. Optionally, you can configure RNA to use data exported by NetFlow devices to generate these new host and service events.

Version 4.7


218


Chapter 9

In addition, RNA generates new events for each network and transport protocol running on each discovered host. Optionally, you can configure RNA to generate new events when it detects specific applications running on a host (by default, this option is enabled in RNA detection policies). After the initial network mapping is complete, RNA continuously records network changes by generating change events. Change events are generated whenever the configuration of a previously discovered host, or service changes. When an RNA event is generated, it is logged to the database. You can use the Defense Center web interface to view, search, and delete RNA events.You can also use RNA events in compliance rules. Based on the type of RNA event generated as well as other criteria that you specify, you can build compliance rules that, when used in a compliance policy, launch remediations and syslog, SNMP, and email alert responses when network traffic meets your criteria. You can add data to the RNA network map using the host input feature. You can add, modify, or delete operating system information, which causes RNA to stop updating that information for that host. You can also manually add, modify, or delete services, client applications, and host attributes or modify vulnerability information. When you do this, RNA generates host input events. See the following sections for more information: •

Understanding RNA Network Discovery Event Types on page 219

•

Understanding RNA Host Input Event Types on page 223

•

Viewing RNA Network Discovery and Host Input Events on page 225

•

Understanding the RNA Events Table on page 226

•

Searching for RNA Network Discovery Events on page 228

Understanding RNA Network Discovery Event Types Requires: DC + RNA

There are many types of RNA network discovery events. For example, RNA generates and logs a New Host event when it detects a new host on your monitored network segment. When you view a table of RNA events, the event type is listed in the Event column. For more information, see Viewing RNA Network Discovery and Host Input Events on page 225. Contrast RNA network discovery events, which are generated when RNA detects a change in your monitored network (such as detecting traffic from a previously undetected host), with RNA host input events, which are generated when a user takes a specific action (such as manually adding a host). For more information on host input events, see Understanding RNA Host Input Event Types on page 223. You can configure the types of network discovery events that RNA logs by modifying your system policy. By default, RNA logs all types of network discovery events. For more information, see Configuring Database Event Limits on page 1197. If you understand the information the different types of network discovery events provide, you can more effectively determine which events you want to log and

Version 4.7


219


Chapter 9

alert on, and how to use these alerts in compliance policies. In addition, knowing the names of the event types can help you craft more effective event searches. The RNA Network Discovery Event Types table describes all the different types of network discovery events. RNA Network Discovery Event Types Event Name

Description

Additional MAC Detected for Host

This event is generated when RNA detects a new MAC address for a previously discovered host. This event is often generated when RNA detects hosts passing traffic through a router. While each host has a different IP address, they all appear to have the MAC address associated with the router. When RNA detects the actual MAC address associated with the IP address, it displays the MAC address in bold text within the host profile and displays an “ARP/DHCP detected” message within the event description in the event view.

Client Application Timeout

This event is generated when RNA drops a client application from the database due to inactivity.

DHCP: IP Address Changed

This event is generated when RNA detects that a host IP address has changed due to DHCP address assignment.

DHCP: IP Address Reassigned

This event is generated when a host is reusing an IP address; that is, when a host obtains an IP address formerly used by another physical host due to DHCP IP address assignment.

Hops Change

This event is generated when RNA detects a change in the number of network hops between a host and the sensor running the detection engine that detects the host. This may happen if the detection engine sees host traffic through different routers and is able to make a better determination of the host’s location. This may also happen if the detection engine detects an ARP transmission from the host, indicating that the host is on a local segment.

Host Deleted: Host Limit Reached

This event is generated when the host limit on the Defense Center is exceeded and a monitored host is deleted from the Defense Center’s network map. IMPORTANT! If the host limit is reached and a host is deleted, the host does not re-appear on the network map until you restart RNA on all registered sensors with RNA. For more information on restarting RNA, see Purging the RNA and RUA Databases on page 1232.

Version 4.7


220


Chapter 9

RNA Network Discovery Event Types (Continued) Event Name

Description

Host Dropped: Host Limit Reached

This event is generated when the host limit on the Defense Center is reached and a new host is dropped. Compare this with the previous event where old hosts are deleted from the network map when the host limit is reached. New hosts are dropped if you enable the Drop New Hosts When Host Limit Reached option in the RNA Settings section of the system policy. See Configuring RNA Settings on page 1204 for more information.

Host Timeout

This event is generated when a host is dropped from the network map because the host has not produced traffic within the interval defined in the RNA Settings section of the system policy. See Configuring RNA Settings on page 1204 for information about configuring the host timeout value. If you change the networks you want to monitor in your RNA detection policy, you may want to manually delete any old hosts from the network map so that they do not count against your host license. For more information, see Working with the Hosts Network Map on page 152.

Host Type Changed to Router/Bridge

This event is generated when RNA detects that a detected host is actually a router or bridge.

MAC Information Change

This event is generated when RNA detects a change in the information associated with a specific MAC address or TTL value. This event often occurs when RNA detects hosts passing traffic through a router. While each host has a different IP address, they will all appear to have the MAC address associated with the router. When RNA detects the actual MAC address associated with the IP address, it displays the MAC address in bold text within the host profile and displays an “ARP/DHCP detected” message within the event description in the event view. The TTL may change because the traffic may pass through different routers or if RNA detects the actual MAC address of the host.

NETBIOS Name Change

This event is generated when RNA detects a change to a host’s NetBIOS name. This event will only be generated for hosts using the NetBIOS protocol.

New Client Application

This event is generated when RNA detects a new client application.

New Host

IMPORTANT! To collect and store client application data for analysis, make sure that you enable client application detection in your RNA detection policy. For more information, see Configuring RNA Detection Policies on page 134. This event is generated when RNA detects a new host running on the network. If you enabled the Generate Hosts from NetFlow Data option in your RNA detection policy, this event is also generated when an RNA detection engine processes NetFlow data that involves a new host.

Version 4.7


221


Chapter 9


Description

New Network Protocol

This event is generated when RNA detects that a host is communicating with a new network protocol (IP, ARP, etc.).

New TCP Service

This event is generated when RNA detects a new TCP service port (for example, a port used by SMTP or web services) active on a host. Note that this event is not used to identify the service; that information is transmitted in the TCP Service Information Update event. If you enabled the Generate Services from NetFlow Data option in your RNA detection policy, this event is also generated when an RNA detection engine processes NetFlow data involving a service on your monitored networks that does not already exist in the network map.

New Transport Protocol

This event is generated when RNA detects that a host is communicating with a new transport protocol, such as TCP or UDP.

New UDP Service

This event is generated when RNA detects a new UDP service running on a host. If you enabled the Generate Services from NetFlow Data option in your RNA detection policy, this event is also generated when an RNA detection engine processes NetFlow data involving a service on your monitored networks that does not already exist in the network map.

OS Confidence Update

This event is generated when RNA updates its confidence level in the correct identification of an operating system it detected running on a host.

OS Information Update

This event is generated when RNA detects a change in a host’s operating system.

TCP Port Closed

This event is generated when RNA detects that a TCP port has closed on a host.

TCP Port Timeout

This event is generated when RNA has not detected activity from a TCP port within the interval defined in RNA Settings section of the system policy. See Configuring RNA Settings on page 1204 for information about configuring the service timeout value.

TCP Service Confidence Update

This event is generated when RNA updates its confidence level in the correct identification of a TCP service it detected running on a host.

TCP Service Information Update

This event is generated when RNA detects a change in a discovered TCP service running on a host. This event may be generated if a TCP service is upgraded.

UDP Port Closed

Version 4.7

This event is generated when RNA detects that a UDP port has closed on a host.


222


Chapter 9


Description

UDP Port Timeout

This event is generated when RNA has not detected activity from a UDP port within the interval defined in RNA Settings section of the system policy. See Configuring RNA Settings on page 1204 for information about configuring the service timeout value.

UDP Service Confidence Update

This event is generated when RNA updates its confidence level in the correct identification of a UDP service it detected running on a host.

UDP Service Information Update

This event is generated when RNA detects a change in a discovered UDP service running on a host. This event may be generated if a UDP service is upgraded.

VLAN Tag Information Update

This event is generated when RNA detects a change in the VLAN tag attributed to a host. For more information about VLAN tags, see Working with VLAN Tags in the Host Profile on page 180.

Understanding RNA Host Input Event Types Requires: DC + RNA

There are many types of RNA host input events. For example, RNA generates and logs an Add Host event when a user adds a host using the host import feature. When you view a table of RNA events, the event type is listed in the Event column. For more information, see Viewing RNA Network Discovery and Host Input Events on page 225. Contrast RNA host input events, which are generated when a user takes a specific action (such as manually adding a host), with RNA network discovery events, which are generated when RNA itself detects a change in your monitored network (such as detecting traffic from a previously undetected host). For more information on host input events, see Understanding RNA Network Discovery Event Types on page 219. You can configure the types of host input events that RNA logs by modifying your system policy. By default, RNA logs all types of host input events. For more information, see Configuring Database Event Limits on page 1197. If you understand the information the different types of host input events provide, you can more effectively determine which events you want to log and alert on, and how to use these alerts in compliance policies. In addition, knowing the names of the event types can help you craft more effective event searches. The

Version 4.7


223


Chapter 9

RNA Host Input Event Types table describes all the different types of host input events. RNA Host Input Event Types Event Name

Description

Add Client Application

This event is generated when a user adds a client application.

Add Host

This event is generated when a user adds a host.

Add Protocol

This event is generated when a user adds a protocol.

Add Service

This event is generated when a user adds a service.

Delete Client Application

This event is generated when a user deletes a client application from the system.

Delete Host/Network

This event is generated when a user deletes an IP address or subnet from the system.

Delete Protocol

This event is generated when a user deletes a protocol from the system.

Delete Service

This event is generated when a user deletes a service or group of services from the system.

Host Attribute Add

This event is generated when a user creates a new host attribute.

Host Attribute Delete

This event is generated when a user deletes a user-defined host attribute.

Host Attribute Delete Value

This event is generated when a user deletes a value assigned to a host attribute.

Host Attribute Set Value

This event is generated when a user sets a host attribute value for a host.

Host Attribute Update

This event is generated when a user changes the definition of a user-defined host attribute.

Add Scan Result

This event is generated when RNA adds the results of a Nessus or an Nmap scan to a host.

Set Host Criticality

This event is generated when a user sets or modifies the host criticality value for a host.

Set Operating System Definition

This event is generated when a user sets the operating system for a host.

Version 4.7


224


Chapter 9

RNA Host Input Event Types (Continued) Event Name

Description

Set Service Definition

This event is generated when a user sets the vendor and version definitions for a service.

Set Vulnerability Impact Qualification

This event is generated when a vulnerability impact qualification is set.

Vulnerability Set Invalid

This event is generated when a user invalidates (or reviews) a vulnerability or vulnerabilities.

Vulnerability Set Valid

This event is generated when a user validates a vulnerability that was previously marked as invalid.

When a vulnerability is disabled at a global level from being used for impact qualifications, or when a vulnerability is enabled at a global level, this event is generated.

Viewing RNA Network Discovery and Host Input Events Requires: DC + RNA

You can use the Defense Center to view a table of RNA events. Then, you can manipulate the event view depending on the information you are looking for. The page you see when you access RNA events differs depending on the workflow you use. You can use the predefined workflow, which includes the table view of RNA events and a terminating host view page. You can also create a custom workflow that displays only the information that matches your specific needs. For information on creating a custom workflow, see Creating Custom Workflows on page 1179. The RNA Event Actions table below describes some of the specific actions you can perform on an RNA events workflow page. You can also perform the tasks described in the Common RNA Event Actions table on page 217. RNA Event Actions

Version 4.7

To...

You can...

modify the time and date range for displayed events

find more information in Setting Event Time Constraints on page 1169.

learn more about the contents of the columns in the table

find more information in Understanding the RNA Events Table on page 226.


225


Chapter 9

RNA Event Actions (Continued) To...

You can...

drill down to the next page in the workflow

use one of the following methods: • To drill down to the next workflow page constraining on a specific value, click a value within a row. Note that this only works on drill-down pages. Clicking a value within a row in a table view constrains the table view and does not drill down to the next page. • To drill down to the next workflow page constraining on some events, select the checkboxes next to the events you want to view on the next workflow page, then click View. • To drill down to the next workflow page keeping the current constraints, click View All. TIP! Table views always include “Table View” in the page name. For more information, see Constraining Events on page 1170.

search for RNA events

click Search. For more information, see Searching for RNA Network Discovery Events on page 228.

To view RNA events: Access: Data or Admin

h

Select Analysis & Reporting > RNA > Events. The first page of the default RNA events workflow appears. If you created a custom RNA events workflow and did not specify a default, you must first select one. For information on specifying a default workflow, see Setting Event Preferences on page 35. If no events appear, you may need to adjust the time range. See Setting Event Time Constraints on page 1169 for more information.

Understanding the RNA Events Table Requires: DC + RNA

Version 4.7

RNA generates network discovery events (also called RNA events) that communicate the details of changes in your monitored network segments. New events are generated for newly discovered network features, and change events are generated for any change in previously identified network assets.


226


Chapter 9

During its initial network discovery phase, RNA generates new events for each host and any TCP or UDP services it discovers on each host. In addition, RNA generates new events for each network and transport protocol running on each discovered host. Optionally, you can configure RNA to generate new events when it detects specific applications running on a host. After the initial network mapping is complete, RNA continuously records network changes by generating change events. Change events are generated whenever the configuration of a previously discovered host, service, or client application changes. The fields in the RNA events table are described in the RNA Event Fields table. RNA Event Fields Field

Description

Time

The time that RNA generated the event.

Event

The event type. See Understanding RNA Network Discovery Event Types on page 219 for a description of each available event.

IP Address

The IP address of the host involved in the event

User

The User ID of the last login to the host involved in the event

MAC Address

The MAC address used by the network traffic that triggered the network discovery event. This MAC address can be either the actual MAC address of the host involved in the event, or the MAC address of a bridge or router that the traffic passed through.

Port

The port used by the traffic that triggered the event, if applicable.

Description

The text description of the event.

Confidence

For hosts detected by 3D Sensors with RNA, the percentage of confidence (between 0% and 100%) that RNA has in the identification of the operating system or service. For hosts or services added to the network map based on NetFlow data, confidence is always 0%. If you used the host input feature or the Nmap scanner to identify the operating system or service, the confidence is always 100%.

Version 4.7


227


Chapter 9

RNA Event Fields (Continued) Field

Description

Detection Engine

The name of the detection engine that generated the event. For new host and new service events based on NetFlow data, this is the detection engine that processed the NetFlow data.

Count

The number of events that match the constraints described in the row. The count field appears only after you apply a constraint to the data.

Searching for RNA Network Discovery Events Requires: DC + RNA

Version 4.7

You can search for specific RNA events by using one of the predefined searches, or by using your own search criteria. The predefined searches serve as examples and can provide quick access to important information about your network. The default searches are: •

NetSky.S Worm Search, which searches for TCP activity on port 6789, a port commonly used by the NetSky.S worm.

•

New Events, which searches for any kind of new event.

•

Sasser Worm Search, which searches for TCP activity on ports 9996 and 5554, ports commonly used by the Sasser worm.

•

Subseven Trojan Search, which searches for TCP activity on a number of ports used by the Subseven Trojan and a Subseven description.

•

Timeout Events, which searches for host timeout events.

•

Update Events, which searches for any kind of update event.


228


Chapter 9

You may want to modify specific fields within the default searches to customize them for your network environment, then save them to reuse later. The search criteria you can use are described in the RNA Event Search Criteria table. RNA Event Search Criteria Field

Search Criteria Rules

Event

Enter a complete or partial event name. For example, you could enter New to search for all new events, Change to search for all change events, or Update to search for update events. You could also enter Host to view host events, or Host IP address changed to view all IP address change events. The event names you can use are listed in Understanding RNA Network Discovery Event Types on page 219.

MAC Address

Specify the MAC address of a host whose events you want to view. Enter MAC addresses in the standard format, for example, 0A:BB:CD:AF:5F:07. You can use an asterisk (*) as a wildcard character in this field.

IP Address

Type a specific IP address or use CIDR notation to specify a range of IP addresses for the hosts whose events you want to view. See Specifying IP Addresses in Searches on page 1130 for a full description of the syntax allowed for IP addresses.

User

Specify the user identity (username) for the user whose events you want to view. This search field is case-insensitive. You can use an partial IDs, for example, a search like: smith would return both jsmith and sallysmith.

Port

Specify the port used by the traffic that triggered the event. Note that you cannot: • enter a port/protocol combination as you can when searching for other kinds of events • use spaces when specifying port numbers or ranges. For more information, see Specifying Ports in Searches on page 1132.

Version 4.7


229


Chapter 9

RNA Event Search Criteria (Continued) Field


Description

Specify the description of the events you want to view. For example, enter HTTP to view any web server-related events, IIS to view IIS-related events, or PHP to view PHP-related events. This search field is case-insensitive. You can use an asterisk (*) as a wildcard character in this field.

Confidence

Specify the level of confidence that RNA has in its assessment of the host operating system for the hosts you want to view. You can precede the confidence with greater than (>), greater than or equal to (>=), less than ( RNA > Hosts. If you did not specify a default hosts workflow, click RNA Hosts to view the table view of hosts. For information on specifying a default workflow, see Setting Event Preferences on page 35. TIP! If you are using a custom workflow that does not include the table view of hosts, click Workflows. On the Select Workflow page, click RNA Hosts.

Understanding the Hosts Table Requires: DC + RNA

When RNA discovers a host, it collects data about that host. That data can include the host’s IP address, the operating system it is running, and more. You can view some of that information in the table view of hosts. For more information on the data that RNA collects about detected hosts, see Using Host Profiles on page 172. The fields in the hosts table are described in the Host Fields table. IMPORTANT! Although you can configure the RNA detection policy to add hosts to the network map based on data exported by NetFlow devices, the available information about these hosts is limited. For example, there is no operating system data available for these hosts, unless you provide it using the host input feature. For more information, see What Information Does RNA Provide? on page 127. Host Fields Field

Description

Last Seen

The date and time the host was last detected by RNA. The last seen value is updated at least as often as the update interval you configured in the RNA detection policy, as well as when RNA generates a new host event for the host’s IP address. For information on setting the update interval, see Configuring RNA Detection Policies on page 134. For hosts with operating system data updated using the host input feature, the Last Seen value indicates the date and time when the data was originally added.

Version 4.7

IP Address

The IP address of the host.

Current User

The user identity (username) of the currently logged in user on the host.


234

Working with RNA Events Working with Hosts

Chapter 9

Host Fields (Continued) Field

Description

MAC Address

The host’s detected MAC address. The MAC Address field appears on the Table View of Hosts with MAC page of the default workflow.

Host Criticality

The user-specified criticality value assigned to the host. See the description of the Host Criticality column in the the Host Attribute Search Criteria table on page 249 for more information about this field.

NetBIOS Name

The NetBIOS name of the host. Only hosts running the NetBIOS protocol will have a NetBIOS name.

VLAN ID

VLAN ID used by the host. For more detailed information about VLAN IDs, see Working with VLAN Tags in the Host Profile on page 180.

Hops

The number of network hops from the sensor running the detection engine that detected the host to the host.

OS Vendor

The vendor of the operating system detected on the host or updated using Nmap or the host input feature. In this field, a value of unknown means that the operating system does not match any of RNA's known fingerprints. If the field is blank, RNA has not yet gathered enough information to identify the operating system.

OS Name

The detected operating system running on the host or updated using Nmap or the host input feature. In this field, a value of unknown means that the operating system does not match any of RNA's known fingerprints. If the field is blank, RNA has not yet gathered enough information to identify the operating system.

OS Version

The version of the operating system detected on the host or updated using Nmap or the host input feature. In this field, a value of unknown means that the operating system does not match any of RNA's known fingerprints. If the field is blank, RNA has not yet gathered enough information to identify the operating system.

Version 4.7


235


Chapter 9


Description

Source Type

One of the following values: • User: user_name • Application: app_name • Scanner: scanner_type (currently Nmap or Nessus) • RNA, for services detected by 3D Sensors with RNA • NetFlow, for services added to the network map based on NetFlow data The RNA database can only retain information from one source for the operating system or for a particular service. If a source with a higher priority adds data, that data replaces the existing data. The new source retains control of the data and is responsible for updating it until the host is deleted and re-added to the network map or a higher priority source takes control of the data. The sources have the following priority order: user and application (equal), scanner, RNA, and finally NetFlow.

Confidence

For hosts detected by 3D Sensors with RNA, the percentage of confidence (between 0% and 100%) that RNA has in the identification of the operating system running on the host. For hosts added to the network map based on NetFlow data, confidence is always 0%. If you used the host input feature or the Nmap scanner to identify the operating system, the confidence is always 100%.

Notes

Version 4.7

The user-defined content of the Notes host attribute.


236


Chapter 9


Description

Detection Engine

The names of the detection engines that either detected the host or processed the NetFlow data that added the host to the network map. The reporting detection engine appears in plain text. This is the detection engine that is responsible for reporting the primary information about the host, for example, operating system and services. Any other detection engines in the column appear in italics. These are the detection engines that report secondary information about the host, such as MAC address data and the number of hops away from the sensor where the detection engine is running. For more information, see Configuring RNA Detection Policies on page 134.

Count


Creating a Traffic Profile for Selected Hosts Requires: DC + RNA

A traffic profile is a profile of the traffic on your network, based on flow data collected by RNA over a timespan that you specify. Once you create a traffic profile, you can detect abnormal network traffic by evaluating new traffic against your profile, which presumably represents normal network traffic. You can use the Hosts page to create a traffic profile for a group of hosts that you specify. The traffic profile will be based on flows detected where one of the hosts you specify is the initiating host. Use the sort and search features to isolate the hosts for which you want to create a profile. To create a traffic profile for selected hosts:

Access: Admin

1.

Select the check boxes next to the hosts for which you want to create a traffic profile.

2. At the bottom of the page, click Create Traffic Profile. The Create Profile page appears, populated with the IP addresses of the hosts you specified as the hosts to be monitored. 3. Modify and save the traffic profile according to your specific needs. For more information on creating traffic profiles, see Creating Traffic Profiles on page 319.

Version 4.7


237


Chapter 9

Creating a Compliance White List Based on Selected Hosts Requires: DC + RNA

Compliance white lists allow you to specify which operating systems, services, client applications, and protocols are allowed on your network. You can use the Hosts page to create a compliance white list based on the host profiles of a group of hosts that you specify. Use the sort and search features to isolate the hosts that you want to use to create a white list. To create a compliance white list based on selected hosts:

Access: Admin

1.

Select the check boxes next to the hosts for which you want to create a white list.

2. At the bottom of the page, click Create White List. The Create White List page appears, populated with the information in the host profiles of the hosts you specified. 3. Modify and save the white list according to your specific needs. For more information on creating compliance white lists, see Creating Compliance White Lists on page 350.

Locating WhoisInformation for a Host Requires: IPS or MDC/DC

If your Defense Center is connected to the Internet, you can use the Whois feature to look up ARIN information about an external host. To use the Whois feature:

Access: Any

1.

Select Operations > Tools > Whois. The Whois page appears.

Version 4.7


238


Chapter 9

2. Type the IP address you want to look up and click Search. The results of the lookup appear.

Searching for Hosts Requires: DC + RNA

You can search for specific hosts by using one of the predefined searches or by using your own search criteria. The predefined searches serve as examples and can provide quick access to important information about your network. The default searches are: •

Local Systems search, which searches for local systems less than two network hops away from the sensor running the detection engine that detected the host.

•

Remote Systems search, which searches for remote systems farther than one network hop away from the sensor running the detection engine that detected the host.

•

Unidentified Systems search, which searches for systems whose operating system has not yet been identified by RNA. IMPORTANT! Unidentified hosts are not the same as unknown hosts. Unidentified hosts are hosts about which RNA has not yet gathered enough information to identify their operating systems. Unknown hosts are hosts whose traffic has been analyzed by RNA, but whose operating systems do not match any of RNA’s known fingerprints.

Version 4.7


239


•

Chapter 9

Unknown Systems search, which searches for hosts whose operating systems do not match any operating system fingerprints in the RNA database.

You may want to modify specific fields within the default searches to customize them for your network environment, then save them to reuse later. The search criteria you can use are described in the Host Search Criteria table. IMPORTANT! When searching for hosts, you should keep in mind that although you can configure the RNA detection policy to add hosts to the network map based on data exported by NetFlow devices, the available information about these hosts is limited. For example, there is no operating system data available for these hosts, unless you provide it using the host input feature. For more information, see What Information Does RNA Provide? on page 127. Host Search Criteria Field


Host Type

Type the kind of device you want to search for: bridge, router, or host. The methods RNA uses to distinguish bridges, switches, and routers include: • the analysis of Cisco Discovery Protocol (CDP) messages, which can identify network devices and their type (Cisco devices only) • the detection of the Spanning Tree Protocol (STP), which identifies a device as a switch or bridge • the detection of multiple hosts using the same MAC address, which identifies the MAC address as belonging to a router If a device is not identified as a bridge or a router, it is categorized as a host.

IP Address

Type a specific IP address or use CIDR notation to specify a range of IP addresses for the hosts you want to view. See Specifying IP Addresses in Searches on page 1130 for a full description of the syntax allowed for IP addresses.

Current User

Specify the user identity (user name) of any currently logged in user on the host. This search field is case-insensitive. You can use a partial names, for example, a search like smith would return both jsmith and sallysmith.

MAC Address

Specify the MAC address of a host whose events you want to view. Enter MAC addresses in the standard format, for example, 0A:BB:CD:AF:5F:07. Type blank or none to search for events where the MAC address is blank.

NetBIOS Name

Specify the NetBIOS name of the host you want to view. You can use an asterisk (*) as a wildcard character in this field.

Version 4.7


240


Chapter 9

Host Search Criteria (Continued) Field


Host Criticality

Specify the host criticality of the hosts you want to view by typing None, Low, Medium, or High. For more information on host criticality, see Setting Host Attributes for Specific Hosts on page 247.

VLAN ID

Specify the VLAN ID of the host or hosts you want to view. For example, if you have a VLAN with an ID of 5 and want to view all hosts in that VLAN, type 5 in the VLAN ID field. For more information about VLAN tags, see Working with VLAN Tags in the Host Profile on page 180.

Hops

Specify the number of network hops from the hosts you want to view to the sensor that detected them.

Last Seen

Specify the date and time the host was last detected by RNA or scanned by Nmap, or when operating system data was originally updated using the host input feature. See Specifying Time Constraints in Searches on page 1130 for the syntax for entering time. Note that the last seen value is updated at least as often as the update interval you configured in the RNA detection policy, as well as when any instance of RNA managed by the Defense Center generates a new host event for the host’s IP address. For information on setting the update interval, see Configuring RNA Detection Policies on page 134.

OS Vendor

Specify the vendor of the operating system that is running on the hosts you want to view. You can use an asterisk (*) as a wildcard character in this field. TIP! Type unknown to search for hosts where the operating system vendor is unknown. Type blank or none to search for hosts where the operating system vendor has not yet been identified.

OS Name

Specify the name of the operating system that is running on the hosts you want to view. You can use an asterisk (*) as a wildcard character in this field. TIP! Type unknown to search for hosts where the operating system name is unknown. Type blank or none to search for hosts where the operating system name has not yet been identified.

OS Version

Specify the version of the operating system that is running on the hosts you want to view. You can use an asterisk (*) as a wildcard character in this field.

Confidence

Specify the level of confidence that RNA has in its assessment of the host operating system for the hosts you want to view. You can precede the confidence with greater than (>), greater than or equal to (>=), less than ( RNA > Host Attributes. The first page of the default host attributes workflow appears. If you created a custom host attributes workflow and did not specify a default, you must first select one. For information on specifying a default workflow, see Setting Event Preferences on page 35.

Understanding the Host Attributes Table Requires: DC + RNA

RNA collects information about the hosts it detects and uses that information to build host profiles. However, there may be additional information about the hosts on your network that you want to provide to your analysts. You can add notes to a host profile, set the business criticality, or provide any other information that you choose. Each piece of information is called a host attribute. You can use host attributes in host profile qualifications, which constrain the data you collect while building a traffic profile, and also can limit the conditions under which you want to trigger a compliance rule. For more information on host attributes, see Working with the Predefined Host Attributes on page 201 and Working with User-Defined Host Attributes on page 202. The fields in the host attributes table are described in the Host Attribute Fields table. Host Attribute Fields Field

Description

IP Address

The IP address of a host.

Current User


Host Criticality

The user-assigned importance of a host to your enterprise. You can use the host criticality in compliance rules and policies to tailor policy violations and their responses to the importance of a host involved in an event. You can assign a host criticality of low, medium, high, or none. For information on setting a host’s criticality, see Assigning a Host Criticality Value to a Host on page 201 and Setting Host Attributes for Specific Hosts on page 247.

Notes

Version 4.7

Information about the host that you want other analysts to view. For information on how to add note, see Adding Notes to a Host on page 202.


246

Working with RNA Events Working with Host Attributes

Chapter 9

Host Attribute Fields (Continued) Field

Description

any user-defined host attribute, including those for compliance white lists

The value of the user-defined host attribute.

Count


The host attributes table contains a field for each user-defined host attribute. For more information, see Working with User-Defined Host Attributes on page 202.

Setting Host Attributes for Specific Hosts Requires: DC + RNA

There are two predefined host attributes that you can assign to each host: host criticality and host-specific notes. Use the host criticality to designate the business criticality of a given host. You can tailor compliance policies and alerts based on host criticality. For example, your organization’s mail servers are more critical to your business than a typical user workstation. You can assign a high host criticality value to your mail servers and other business-critical servers and medium or low values to other hosts. You could then create a compliance policy that launches different alerts based on the criticality of an affected host. Use notes to record information about a host that you want other analysts to view. For example, if you have a computer on the network that has an older, unpatched version of an operating system that you use for testing, you can use the notes feature to indicate that the system is intentionally unpatched. You can also create user-defined host attributes. For example, you could create a host attribute that assigns physical location identifiers to hosts, such as a facility code, city, or room number. For more information on created user-defined host attributes, see Creating User-Defined Host Attributes on page 203. TIP! You can also set the host criticality of selected hosts in a host workflow, and from within a host profile, or set it through a remediation. For more information, see Assigning a Host Criticality Value to a Host on page 201 or Configuring Set Attribute Remediations on page 520.

Version 4.7


247


Chapter 9

To set host attributes for selected hosts: Access: Data or Admin

1.

Select the checkboxes next to the hosts to which you want to add a host attribute. TIP! Use the sort and search features to isolate the hosts to which you want to assign particular attributes.

2. At the bottom of the page, click Set Attributes. A pop-up window appears.

3. Optionally, set the host criticality for the hosts you selected. You can select None, Low, Medium, or High. 4. Optionally, add notes to the host profiles of the hosts you selected by entering up to 255 alphanumeric characters, special characters, and spaces in the text box. 5. Optionally, set any user-defined host attributes you have configured. 6. Click Save. The host attributes you specified are assigned to the selected hosts.

Searching for Host Attributes Requires: DC + RNA

Version 4.7

You can search for hosts that have specific host attributes. For example, if your company has several regional offices, you could configure a host attribute that tells you which city any one host resides in. You could then search for hosts in specific regions. For more information on host attributes, see Working with UserDefined Host Attributes on page 202.


248


Chapter 9

You may want to create searches customized for your network environment, then save them to reuse later. The search criteria you can use are described in the Host Attribute Search Criteria table. Host Attribute Search Criteria Search Field

Description

IP Address

Type a specific IP address or use CIDR notation to specify a range of IP addresses for the hosts you want to view. See Specifying IP Addresses in Searches on page 1130 for a full description of the syntax allowed for IP addresses.

Host Criticality

Specify the host criticality of the hosts you want to view by typing None, Low, Medium, or High. For more information on host criticality, see Setting Host Attributes for Specific Hosts on page 247.

Notes

Specify text in the host’s profile notes. You can use an asterisk (*) as a wildcard character in this field. For more information, see Adding Notes to a Host on page 202.

Current User


any user-defined host attribute

Specify the appropriate value, which depends on the type of host attribute you select: • If the host attribute type is Integer, enter an integer in the range defined for the attribute. • If the host attribute type is Text, enter a text value. • If the host attribute type is List, select a valid string from the drop-down list. • If the host attribute type is URL, enter a URL. For more information on host attributes, see Working with User-Defined Host Attributes on page 202. For more information on searching, including how to load and delete saved searches, see Searching for Events on page 1124.

Version 4.7


249


Chapter 9

To search for host attributes: Access: Data or Admin

1.

Select Analysis & Reporting > Searches > Host Attributes. The Host Attributes search page appears.

TIP! To search the database for a different kind of event, select it from the Table list. 2. Optionally, if you want to save the search, enter a name for the search in the Name field. If you do not enter a name, the Defense Center automatically creates one when you save the search. 3. Enter your search criteria in the appropriate fields, as described in the Host Attribute Search Criteria table. If you enter multiple criteria, the Defense Center returns only the records that match all the criteria. 4. If you want to save the search so that other users can access it, clear the Save As Private check box. Otherwise, leave the check box selected to save the search so that only you can use it. TIP! If you want to save a search as a restriction for restricted data users, you must save it as a private search. 5. You have the following options: •

Click Search to start the search. Your search results appear in the default host attributes workflow. If you created a custom host attributes workflow and did not specify a preferred workflow, you must select one. For information on specifying a preferred workflow, see Setting Event Preferences on page 35.

Version 4.7


250

Working with RNA Events Working with Services

Chapter 9

•

Click Save if you are modifying an existing search and want to save your changes.

•

Click Save as New Search to save the search criteria. The search is saved (and associated with your user account if you selected Save As Private), so that you can run it at a later time.

Working with Services Requires: DC + RNA

RNA collects information about all services run by hosts on monitored network segments. The information that RNA collects includes the name of the service, the protocol used by the service, the IP address of the host running a service, and the port on which the service is running. See Detected Services on page 1437 for a full list of available services that RNA detects. When RNA detects a running service, it generates a service event and logs it to the database. You can use the Defense Center web interface to view, search, and delete RNA service events. You can also base compliance rules on service events. For example, you could trigger a compliance rule when RNA detects a chat service, such as ircd, running on one of your hosts. IMPORTANT! Although you can configure the RNA detection policy to add services to the network map based on data exported by NetFlow devices, the available information about these services is limited. For more information, see What Information Does RNA Provide? on page 127. See the following sections for more information. •

Viewing Services on page 251

•

Understanding the Services Table on page 254

•

Searching for Services on page 256

•

Editing Service Identities

Viewing Services Requires: DC + RNA

Version 4.7

You can use the Defense Center to view a table of detected services. Then, you can manipulate the event view depending on the information you are looking for.


251


Chapter 9

The page you see when you access RNA services differs depending on the workflow you use. There are three predefined workflows: •

The Network Services by Count workflow provides a series of pages that constrain the detected services based on how many hosts are running particular services, and further constrain by the vendor and version of those services.

•

The Network Service by Hit workflow provides a series of pages that constrain the detected services based on how often they are accessed, and further constrain by the vendor and version of those services.

•

The RNA Services workflow includes a table view of RNA services. The table view contains a row for every service discovered on each detected host, organized by IP address and port. Each row contains data from a single service discovery event.

All the predefined workflows terminate in a host view, which contains a host profile for every host that meets your constraints. You can also create a custom workflow that displays only the information that matches your specific needs. For more information, see Creating Custom Workflows on page 1179.

Version 4.7


252


Chapter 9

The RNA Service Actions table below describes some of the specific actions you can perform on an RNA services workflow page. You can also perform the tasks described in the Common RNA Event Actions table on page 217. RNA Service Actions To...

You can...


find more information in Understanding the Services Table on page 254.


use one of the following methods: • To drill down to the next workflow page constraining on a specific value, click a value within a row. Note that this only works on drill-down pages. Clicking a value within a row in a table view constrains the table view and does not drill down to the next page. • To drill down to the next workflow page constraining on some events, select the checkboxes next to the events you want to view on the next workflow page, then click View. • To drill down to the next workflow page keeping the current constraints, click View All. TIP! Table views always include “Table View” in the page name. For more information, see Constraining Events on page 1170.

Version 4.7

search for services

click Search. For more information, see Searching for Services on page 256.

edit service identities

select the checkboxes next to the events for services you want to edit, then click Set Service Identity. For more information, see Editing Service Identities on page 191.


253


Chapter 9

To view services: Access: Data or Admin

h

Select Analysis & Reporting > RNA > Services. If you did not specify a default services workflow, click RNA Services to view the table view of services. For information on specifying a default workflow, see Setting Event Preferences on page 35. TIP! If you are using a custom workflow that does not include the table view of services, click Workflows. On the Select Workflow page, click RNA Services.

Understanding the Services Table Requires: DC + RNA

RNA collects information about services run by hosts on monitored network segments. See Detected Services on page 1437 for a list of services that RNA detects. The fields in the services table are described in the Service Fields table. IMPORTANT! Although you can configure the RNA detection policy to add services to the network map based on data exported by NetFlow devices, the available information about these services is limited. For more information, see What Information Does RNA Provide? on page 127. Service Fields

Version 4.7

Field

Description

Last Used

The date and time the service was last used on the network or the date and time that the service was originally updated using the host input feature. The Last Used value is updated at least as often as the update interval you configured in the RNA detection policy, as well as when RNA detects a service information update. For information on setting the update interval, see Configuring RNA Detection Policies on page 134.

IP Address

The IP address of the host running the service.

Current User


Port

The port where the service is running.

Protocol

The protocol used by the service.


254


Chapter 9

Service Fields (Continued) Field

Description

Hits

The number of times the service was accessed. For services added using the host input feature, this value is always 0.

Service

One of: • the service name as identified by RNA or Nmap, or, for services added to the network map based on NetFlow data, the service name identified by the portservice correlation in /etc/sf/services • the service name you specified using the host input feature • unknown, if RNA detected the service but cannot identify it based on known service fingerprints • unidentified, if the service was created using NetFlow data but could not be identified by the portservice correlation in /etc/sf/services, or if RNA detected the service but does not yet have enough information to identify it

Vendor

The service vendor that either: • was detected by RNA or Nmap • you specified using the host input feature If RNA or Nmap cannot identify the vendor of a running service, and you do not specify the vendor, this field remains blank.

Version

The service version that either: • was detected by RNA or Nmap • you specified using the host input feature If RNA or Nmap cannot identify the version of a running service, and you do not specify the version, this field remains blank.

Version 4.7


255


Chapter 9

Service Fields (Continued) Field

Description

Source Type

One of the following values: • User: user_name • Application: app_name • Scanner: scanner_type (currently Nmap or Nessus) • RNA, for services detected by 3D Sensors with RNA • NetFlow, for services added to the network map based on NetFlow data The RNA database can only retain information from one source for the operating system or for a particular service. If a source with a higher priority adds data, that data replaces the existing data. The new source retains control of the data and is responsible for updating it until the host is deleted and re-added to the network map or a higher priority source takes control of the data. The sources have the following priority order: user and application (equal), scanner, RNA, and finally NetFlow.

Confidence

For services detected by 3D Sensors with RNA, the percentage of confidence (between 0% and 100%) that RNA has in its service identification. For services added to the network map based on NetFlow data, and for unidentified services, the confidence is always 0%. For service data supplied by the host input feature or the Nmap scanner, the confidence is always 100%

Detection Engine

The names of the detection engine that either detected the service or processed the NetFlow data that added the service to the network map.

Count


Searching for Services Requires: DC + RNA

Version 4.7

You can search for specific services that are running on monitored hosts by using one of the predefined searches or by using your own search criteria. The


256


Chapter 9

predefined searches serve as examples and can provide quick access to important information about your network. The default searches are: •

Non-standard searches for each service detected by RNA (see Detected Services on page 1437 for a full list of available services), which searches for services running on non-standard ports.

•

Possible MSSQL search, which searches for TCP traffic on port 1433, indicating possible Microsoft SQL Server activity.

•

Possible MySQL search, which searches for TCP traffic on port 3306, indicating possible MySQL activity.

You may want to modify specific fields within the default searches to customize them for your network environment, then save them to reuse later. The search criteria you can use are described in the Service Search Criteria table. IMPORTANT! When searching for services, you should keep in mind that although you can configure the RNA detection policy to add services to the network map based on data exported by NetFlow devices, the available information about these service is limited. For more information, see What Information Does RNA Provide? on page 127. Service Search Criteria Field


IP Address

Type a specific IP address or use CIDR notation to specify a range of IP addresses for the services whose events you want to view. See Specifying IP Addresses in Searches on page 1130 for a full description of the syntax allowed for IP addresses.

Current User


Port

Specify the port on which the service is running. For more information, see Specifying Ports in Searches on page 1132.

Protocol

Specify the protocol for which you want to view service events.

Hits

Specify the minimum number of times the service has been accessed, or for services added using the host input feature, type 0.

Version 4.7


257


Chapter 9

Service Search Criteria (Continued) Field


Last Used

Specify the date and time the service was last detected by RNA or the date and time the service was originally updated using the host input feature. See Specifying Time Constraints in Searches on page 1130 for the syntax for entering time. Note that the Last Used value is updated at least as often as the update interval you configured in the RNA detection policy, as well as when RNA detects a service information update. For information on setting the update interval, see Configuring RNA Detection Policies on page 134.

Service

Specify the service whose events you want to view. Use blank or none to search for unidentified services. Use unknown to search for unknown services. For a full list of the values you can enter here, see Detected Services on page 1437.

Vendor

Specify the vendor of the service whose events you want to view. You can use an asterisk (*) as a wildcard character in this field. TIP! Type unknown to search for hosts where the service vendor is unknown. Type blank or none to search for hosts where the service vendor has not yet been identified.

Version

Version 4.7

Specify the version of the service whose events you want to view. You can use an asterisk (*) as a wildcard character in this field.


258


Chapter 9

Service Search Criteria (Continued) Field


Confidence

Specify the level of confidence that RNA has in its assessment of the service you want to view. You can precede the confidence with greater than (>), greater than or equal to (>=), less than ( RNA > Client Applications. If you did not specify a default client applications workflow, click RNA Client Applications to view the table view of client applications. For information on specifying a default workflow, see Setting Event Preferences on page 35. TIP! If you are using a custom workflow that does not include the table view of client applications, click Workflows. On the Select Workflow page, click RNA Client Applications.

Version 4.7


263

Working with RNA Events Working with Client Applications

Chapter 9

Understanding the Client Applications Table Requires: DC + RNA

When a monitored host connects to another host, RNA can, in many cases, determine what application was used. RNA detects the use of many mail and web clients including Microsoft Internet Explorer, Microsoft Outlook and Outlook Express, Lotus Notes, Mozilla Thunderbird, Ximian Evolution, and more. For a full list of the client applications RNA detects, see Detected Client Applications on page 1436. When RNA detects traffic for a known client application, RNA logs information about the application and the host running it. The fields in the client applications table are described in the Client Application Fields table. Client Application Fields

Version 4.7

Field

Description

Last Used

The time that the application was last used or the time that the client application data was updated using the host input feature. The Last Used value is updated at least as often as the update interval you configured in the RNA detection policy, as well as when RNA detects a client application information update. For information on setting the update interval, see Configuring RNA Detection Policies on page 134.

IP Address

The IP address of the host using the application.

Current User


Application Type

The type of application. RNA detects various web browsers, email clients, and instant-messaging clients.

Product

The name of the application.

Version

The version of the application.

Hits

The number of times RNA detected the application in use. For applications added using the host input feature, this value is always 0.

Detection Engine

The detection engine that generated the client application event.

Count



264


Chapter 9

Searching for Client Applications Requires: DC + RNA

You can search for hosts that are running specific client applications. You may want to create searches customized for your network environment, then save them to reuse later. The search criteria you can use are described in the Client Application Search Criteria table.

Client Application Search Criteria Search Field

Description

Last Used

Specify the date and time the application was last detected by RNA or the date and time when the client application was originally added using the host input feature. See Specifying Time Constraints in Searches on page 1130 for the syntax for entering time. Note that the Last Used value is updated at least as often as the update interval you configured in the RNA detection policy, as well as when RNA detects a client application information update. For information on setting the update interval, see Configuring RNA Detection Policies on page 134.

IP Address

Type a specific IP address or use CIDR notation to specify a range of IP addresses for the hosts whose client applications you want to view. See Specifying IP Addresses in Searches on page 1130 for a full description of the syntax allowed for IP addresses.

Current User


Application Type

Specify the type of application that is running on the hosts you want to view.

Product

Specify the name of the application that is running on the hosts you want to view. You can use an asterisk (*) as a wildcard character in this field.

Version

Specify the version of the application that is running on the hosts you want to view. You can use an asterisk (*) as a wildcard character in this field.

Hits

Specify the minimum number of times the application has been accessed, or for applications added using the host input feature, type 0.

Detection Engine

Specify the name of the detection engine that detected the client application you want to view. For more information, see Specifying Detection Engine/Appliance Names on page 1133.

Version 4.7


265


Chapter 9

To search for client applications: Access: Data or Admin

1.

Select Analysis & Reporting > Searches > Client Applications. The Client Applications search page appears.

TIP! To search the database for a different kind of event, select it from the Table list. 2. Optionally, if you want to save the search, enter a name for the search in the Name field. If you do not enter a name, the Defense Center automatically creates one when you save the search. 3. Enter your search criteria in the appropriate fields, as described in the Client Application Search Criteria table. If you enter multiple criteria, the Defense Center returns only the records that match all the criteria. 4. If you want to save the search so that other users can access it, clear the Save As Private check box. Otherwise, leave the check box selected to save the search so that only you can use it. TIP! If you want to save a search as a restriction for restricted data users, you must save it as a private search. 5. You have the following options: •

Click Search to start the search. If you specified a preferred client applications workflow, your search results appear. Otherwise, you must select a workflow. For information on specifying a preferred workflow, see Setting Event Preferences on page 35.

Version 4.7


266

Working with RNA Events Working with Vulnerabilities

Chapter 9

•


•


Working with Vulnerabilities Requires: DC + RNA

RNA includes its own vulnerability tracking database which is used, in conjunction with RNA’s operating system fingerprinting capability, to identify the known vulnerabilities of each fingerprinted host in a monitored network. Different operating systems have different sets of vulnerabilities. Each host with an identified operating system has a set of associated vulnerabilities. You can deactivate vulnerabilities for a host after you patch the host or otherwise judge it immune to a vulnerability. You can use the Defense Center to track and review the vulnerabilities for each host. For more information on vulnerabilities, see Working with the Vulnerabilities Network Map on page 158 and Working with Detected Vulnerabilities in the Host Profile on page 195. For more information, see: •

Viewing Vulnerabilities on page 267

•

Understanding the Vulnerabilities Table on page 269

•

Deactivating Vulnerabilities on page 271

•

Searching for Vulnerabilities on page 272

Viewing Vulnerabilities Requires: DC + RNA

You can use the Defense Center to view a table of vulnerabilities. Then, you can manipulate the event view depending on the information you are looking for. The page you see when you access RNA vulnerabilities differs depending on the workflow you use. You can use the predefined workflow, which includes a table view of RNA vulnerabilities. The table view contains a row for each vulnerability in the database, regardless of whether any of your detected hosts exhibit the vulnerabilities. The second page of the predefined workflow contains a row for each vulnerability (that you have not deactivated) that applies to detected hosts on your network. The predefined workflow terminates in a vulnerability detail

Version 4.7


267


Chapter 9

view, which contains a detailed description for every vulnerability that meets your constraints. TIP! If you want to see the vulnerabilities that apply to a single host or set of hosts, perform a search for vulnerabilities, specifying an IP address or range of IP addresses for the hosts. For more information on searching for vulnerabilities, see Searching for Vulnerabilities on page 272. You can also create a custom workflow that displays only the information that matches your specific needs. For information on creating a custom workflow, see Creating Custom Workflows on page 1179. The RNA Vulnerability Actions table below describes some of the specific actions you can perform on an RNA services workflow page. You can also perform the tasks described in the Common RNA Event Actions table on page 217. RNA Vulnerability Actions To...

You can...


find more information in Understanding the Vulnerabilities Table on page 269.


use one of the following methods: • To drill down to the next workflow page constraining on a specific value, click a value within a row. Note that this only works on drill-down pages that you created in a custom workflow. Clicking a value within a row in a table view constrains the table view and does not drill down to the next page. • To drill down to the next workflow page constraining on some events, select the checkboxes next to the events you want to view on the next workflow page, then click View. • To drill down to the next workflow page keeping the current constraints, click View All. TIP! Table views always include “Table View” in the page name. For more information, see Constraining Events on page 1170.

Version 4.7


268


Chapter 9

RNA Vulnerability Actions (Continued) To...

You can...

deactivate selected vulnerabilities so they are no longer used for intrusion impact correlation for currently vulnerable hosts

find more information in Deactivating Vulnerabilities on page 271.

search for vulnerabilities

click Search. For more information, see Searching for Vulnerabilities on page 272.

To view vulnerabilities: Access: Data or Admin

h

Select Analysis & Reporting > RNA > Vulnerabilities. The first page of the default vulnerabilities workflow appears. If you created a custom vulnerabilities workflow and did not specify a default, you must first select one. For information on specifying a default workflow, see Setting Event Preferences on page 35.

Understanding the Vulnerabilities Table Requires: DC + RNA

RNA includes its own vulnerability tracking database which is used in conjunction with RNA’s operating system fingerprinting capability to identify the known vulnerabilities of each fingerprinted host in a monitored network. Different operating systems have a different sets of vulnerabilities. Each host with an identified operating system has a set of associated vulnerabilities. You can deactivate vulnerabilities for a host when you patch the host or otherwise judge it immune. You can also use the Defense Center to track and review the vulnerabilities for each host. The first page of the default vulnerabilities workflow displays every vulnerability in the database, regardless of whether it applies to any of your hosts. The second page of the default workflow provides you with a table view of vulnerabilities that do apply to detected hosts on your network. For more information on vulnerabilities, see Working with the Vulnerabilities Network Map on page 158 and Working with Detected Vulnerabilities in the Host Profile on page 195.

Version 4.7


269


Chapter 9

The fields in the vulnerabilities table are described in the Vulnerabilities Table Fields table. Vulnerabilities Table Fields Field

Description

RNA ID

The RNA Vulnerability identification number that RNA uses to track vulnerabilities

Bugtraq ID

The identification number associated with the vulnerability in the Bugtraq database. (http://www.securityfocus.com/bid/)

Snort ID

The identification number associated with the vulnerability in the Snort ID (SID) database. That is, if an intrusion rule can detect network traffic that exploits a particular vulnerability, that vulnerability is associated with the intrusion rule’s SID. Note that a vulnerability can be associated with more than one SID (or no SIDs at all). If a vulnerability is associated with more than one SID, the vulnerabilities table includes a row for each SID.

Version 4.7

Title

The title of the vulnerability.

Date Published

The date the vulnerability was published.


Displays the severity assigned to the vulnerability in the Bugtraq database on a scale of 0 to 10, with 10 being the most severe. The vulnerability impact is determined by the writer of the Bugtraq entry based on his or her best judgment and guided by SANS Critical Vulnerability Analysis (CVA) criteria.

Remote

Indicates whether the vulnerability is remotely exploitable.

Available Exploits

Indicates whether there are known exploits for the vulnerability.

Description

A brief description of the vulnerability.

IP Address

The IP address of host affected by the vulnerability.


A detailed technical description of the vulnerability.


270


Chapter 9

Vulnerabilities Table Fields (Continued) Field

Description

Solution

Information about repairing the vulnerability.

Count


Deactivating Vulnerabilities Requires: DC + RNA

Deactivate a vulnerability after you patch the hosts on your network or otherwise judge them immune. Deactivated vulnerabilities are not used for intrusion impact correlation. Note that if RNA discovers a new host that is affected by that vulnerability, the vulnerability is considered valid (and is not automatically deactivated) for that host. You can deactivate vulnerabilities within the vulnerabilities workflow only on a workflow page that shows vulnerabilities for specific hosts on your network, that is: •

on the second page of the default vulnerabilities workflow, Vulnerabilities on the Network, which shows only the vulnerabilities that apply to the hosts on your network

•

on any page in a vulnerabilities workflow, custom or predefined, that you constrained based on IP address using a search.

Deactivating a vulnerability within a vulnerabilities workflow that is not constrained on IP addresses deactivates the vulnerability for all detected hosts on your network. To deactivate a vulnerability for a single host, you have three options: •

Use the network map. For more information, see Working with the Vulnerabilities Network Map on page 158.

•

Use the host’s host profile. For more information, see Setting Vulnerabilities for Individual Hosts on page 200.

•

Constrain the vulnerabilities workflow based on the IP address of the host or hosts for which you want to deactivate vulnerabilities.

TIP! To constrain the Vulnerabilities view based on IP address, perform a search for vulnerabilities, specifying an IP address or range of IP addresses for the hosts for which you want to deactivate vulnerabilities. For more information on searching for vulnerabilities, see Searching for Vulnerabilities on page 272.

Version 4.7


271


Chapter 9

To deactivate vulnerabilities: Access: Data or Admin

h

Select the check boxes next to vulnerabilities you want to deactivate, then click Review.

Searching for Vulnerabilities Requires: DC + RNA

You can search for vulnerabilities that affect the hosts on your network. You may want to create searches customized for your network environment, then save them to reuse later. The search criteria you can use are described in the Vulnerabilities Search Criteria table.

Vulnerabilities Search Criteria Search Field

Description

RNA ID

Specify one or more RNA vulnerability identification numbers to match. Specify multiple RNA IDs in a comma-separated list.

Bugtraq ID

Specify one or more Bugtraq identification numbers to match. Specify multiple Bugtraq IDs in a comma-separated list. Find Bugtraq ID numbers at http://www.securityfocus.com/bid.

Snort ID

Specify one or more Snort IDs (SIDs) to match. Specify multiple SIDs in a comma-separated list.

Title

Specify one or more words to search for in the vulnerability title. The search is case-insensitive. You can use an asterisk (*) as a wildcard character in this field.

IP Address

Specify the IP address of the host or hosts whose vulnerabilities you want to view. See Specifying IP Addresses in Searches on page 1130 for information about entering IP addresses.

Date Published

Specify the date the vulnerability was published. See Specifying Time Constraints in Searches on page 1130 for the syntax for entering time.


Specify a vulnerability impact, from 0 to 10, with 10 being the most severe. Vulnerability impact is the severity assigned to the vulnerability in the Bugtraq database.

Remote

Enter TRUE to search for vulnerabilities that are exploited over a network, or FALSE to exclude such vulnerabilities.

Available Exploits

Enter TRUE to search for vulnerabilities for which an exploit is known to exist, or FALSE to exclude such vulnerabilities.

Description

Specify one or more words to search for in the general description of the vulnerability. The search is case-insensitive. You can use an asterisk (*) as a wildcard character in this field.

Version 4.7


272


Chapter 9

Vulnerabilities Search Criteria (Continued) Search Field

Description

Solution

Specify one or more words to search for in the solution of the vulnerability. You can use an asterisk (*) as a wildcard character in this field.


Specify one or more words to search for in the detailed technical description of the vulnerability. The search is case-insensitive. You can use an asterisk (*) as a wildcard character in this field. To search for vulnerabilities:


1.

Select Analysis & Reporting > Searches > Vulnerabilities. The Vulnerabilities search page appears.

TIP! To search the database for a different kind of event, select it from the Table list. 2. Optionally, if you want to save the search, enter a name for the search in the Name field. If you do not enter a name, the Defense Center automatically creates one when you save the search. 3. Enter your search criteria in the appropriate fields, as described in the Vulnerabilities Search Criteria table. If you enter multiple criteria, the Defense Center returns only the records that match all the criteria.

Version 4.7


273


Chapter 9

4. If you want to save the search so that other users can access it, clear the Save As Private check box. Otherwise, leave the check box selected to save the search so that only you can use it. TIP! If you want to save a search as a restriction for restricted data users, you must save it as a private search. 5. You have the following options: •

Click Search to start the search. Your search results appear in the default vulnerabilities workflow. If you created a custom vulnerabilities workflow and did not specify a preferred workflow, you must select one. For information on specifying a preferred workflow, see Setting Event Preferences on page 35.

Version 4.7

•


•



274

Chapter 9

Working with Flow Data and Traffic Profiles

If your Sourcefire 3D System deployment includes 3D Sensors with RNA, you can continuously monitor traffic generated by each host on your network. If your organization uses NetFlow devices to collect IP traffic information, you can use the NetFlow records generated by those devices to supplement the data gathered by RNA. RNA generates flow events when connections between monitored hosts and any other hosts are terminated. Flow events include information about the collected traffic, including:

Version 4.7

•


•


•


•


•


•


•



275

Working with Flow Data and Traffic Profiles

Chapter 10

When you configure your RNA detection policy, you must specify how flow data is collected. You can choose one of three modes: •

You can disable flow data collection entirely.

•

You can configure your 3D Sensors to transmit individual flows to the Defense Center.

•

You can configure your 3D Sensors to transmit flow summaries, which are sets of flow data aggregated over five-minute intervals, to the Defense Center.

You can view flow data in a table view of events or in graphs. You can also view the Flow Summary page, which provides graphs of the activity on your monitored network segment organized by different criteria quick understanding of the state of your network. You can also use flow data to create a profile of your normal network traffic. After you establish parameters for normal traffic, you can detect abnormal network traffic by evaluating new traffic against that profile within a compliance policy. For more information, see Creating Rules for Compliance Policies on page 394. IMPORTANT! You must use a Defense Center with an RNA host license to view flow data. You cannot view flow data on a Master Defense Center. For more information on flow data and traffic profiles, see the following sections:

Version 4.7

•

Viewing the Flow Summary Page on page 277

•

Understanding Flow Data on page 279

•

Manipulating Flow Data Graphs on page 305

•

Creating Traffic Profiles on page 319

•

Viewing Traffic Profiles on page 337


276

Working with Flow Data and Traffic Profiles Viewing the Flow Summary Page

Chapter 10

Viewing the Flow Summary Page Requires: DC + RNA

The Flow Summary page provides graphs of the activity on your monitored network segment organized by different criteria. Use the Flow Summary page to get a quick understanding of the state of your network.

IMPORTANT! Contrast the Flow Summary page with flow summaries, which are comprised of flow data aggregated over five-minute intervals. RNA uses flow summaries to create the graphs on the Flow Summary page. For more information on flow summaries, see Understanding Flow Summary Data on page 282.

Version 4.7


277

Working with Flow Data and Traffic Profiles Viewing the Flow Summary Page

Chapter 10

The Flow Summary Graphs table describes the information displayed on the Flow Summary page. Flow Summary Graphs

Version 4.7

Title

Description

Flows over Time

Displays a graph of the total number of flows on the monitored network segment over the interval that you select.

Flows by Initiator

Displays a graph of the 10 most active hosts on the monitored network segment based on the number of flow events where the host initiated the flow transaction.

Flows by Responder

Displays a graph of the 10 most active hosts on the monitored network segment based on the number of flow events where the host was the responder in the flow transaction.

Flows by Port

Displays a graph of the 10 most active ports on the monitored network segment based on the number of detected flow events.

Flows by Service

Displays a graph of the 10 most active services on the monitored network segment based on the number of detected flow events.

Traffic over Time

Displays a graph of the total kilobytes transmitted on the monitored network segment over the interval that you select.

Traffic by Initiator

Displays a graph of the 10 most active hosts on the monitored network segment based on the number of kilobytes transmitted by the host.

Traffic by Responder

Displays a graph of the 10 most active hosts on the monitored network segment based on the number of kilobytes received by the host.

Traffic by Port

Displays a graph of the 10 most active ports on the monitored network segment based on the number of kilobytes transmitted.

Traffic by Service

Displays a graph of the 10 most active services on the monitored network segment based on the number of kilobytes transmitted.


278

Working with Flow Data and Traffic Profiles Understanding Flow Data


Chapter 10

The Flow Summary Page Functions table describes the different actions you can perform on the Flow Summary page. Flow Summary Page Functions To...

You can...

modify the time and date range for the Flow Summary page


learn more about flow graphs

find more information in Understanding Flow Data on page 279.

manipulate flow graphs

find more information in Manipulating Flow Data Graphs on page 305.

detach one of the flow graphs from the page

click View on the graphs you want to detach. For more information on detached graphs, see Detaching Flow Data Graphs on page 318.

IMPORTANT! You can perform almost all the same actions on flow summary graphs that you can perform on flow data graphs. However, because the graphs on the Flow Summary page are based on aggregated data, you cannot examine the individual flow events on which the graphs are based. In other words, you cannot drill down to a flow data table view from a flow summary graph. To view the flow summary graphs for your monitored network segment: Access: Data or Admin

1.

Select Analysis & Reporting > Event Summary > Flow Summary. The Flow Summary page appears for the default time range on your Defense Center.

2. From the Select Detection Engine list, select the detection engine whose summary you want to view, or select All to view a summary of all detection engines.

Understanding Flow Data Requires: DC + RNA

Version 4.7

If your Sourcefire 3D System deployment includes 3D Sensors with RNA, you can continuously monitor traffic generated by each host on your network. If your organization uses NetFlow devices to collect IP traffic information, you can use the NetFlow records generated by those devices to supplement the data gathered by RNA. For example, if you have NetFlow devices deployed on networks that your 3D Sensors with RNA cannot see, you can use the data


279


Chapter 10

exported by those devices to monitor those networks. Note that even if you plan to use only NetFlow devices to monitor your network, you must include at least one 3D Sensor with RNA in your deployment to process the records exported by the NetFlow devices. RNA generates flow events when connections between monitored hosts and any other hosts are terminated. For flows detected by 3D Sensors, RNA generates one bi-directional flow event. On the other hand, NetFlow devices generate two records for each flow, one for each direction, so RNA generates two flow events for each flow detected by NetFlow devices. If you are monitoring the same network segment with NetFlow devices and 3D Sensors with RNA, RNA will generate three flow events for each detected flow -- one that represents the flow as detected by the sensor, and two for the flow as detected by NetFlow device. Flow events include information about the collected traffic, including: •


•


•


•


•


•


•


Note that some of the information in a flow event depends on the flow type, that is, on whether the flow was detected by a 3D Sensor with RNA or by a NetFlow device. Flows reported by NetFlow devices do not contain NetBIOS information, information on the client applications and URLs involved in the monitored session, or the names, version, and vendors of services involved in the session. However, NetFlow data includes information on any TCP flags set for the flow, while flow data collected by 3D Sensors with RNA does not. In addition, NetFlow records do not contain information about which host in the flow is the initiator and which is the responder. When RNA processes NetFlow records, it uses an algorithm to determine this information based on the ports each host is using, and whether those ports are well-known. If both or neither port being used is a well-known port, RNA considers the host using the lowernumber port to be the responder. If only one of the hosts is using a well-known port, RNA considers that host to be the responder. For this purpose, a well-known port is any port that is either numbered from 1 to 1023, or that contains service information in /etc/sf/services on the 3D Sensor or software sensor. Similarly, the Sourcefire 3D System is unable to identify the versions and vendors of services running on hosts detected by your NetFlow devices. Further, it uses /etc/sf/services to determine the names of the services added to the

Version 4.7


280


Chapter 10

network map based on NetFlow data. This means that if someone is running a service on a non-standard port, and the session is detected by a NetFlow device rather than a 3D Sensor, the Sourcefire 3D System could misidentify the service. When you configure your RNA detection policy (see Configuring RNA Detection Policies on page 134), you must choose how flow data is collected. This includes NetFlow data, because RNA detection engines on your 3D Sensors analyze NetFlow data and transmit it to the Defense Center. You can choose one of three flow data modes: •

You can disable flow data collection entirely, which will reduce the traffic between your 3D Sensors and your Defense Center, but will also prevent you from taking advantage of any feature that relies on flow data.

•

You can configure your 3D Sensors to transmit individual flows to the Defense Center.

•

You can configure your 3D Sensors to transmit flow summaries, which are sets of flow data aggregated over five-minute intervals, to the Defense Center.

You can view flow data in a table view of events, or in graphs. TIP! You can treat flow summary data from IP addresses outside your monitored networks as coming from a single host named “external.” You can enable this feature on your 3D Sensors so that they combine flow summaries before they transmit the data to the Defense Center, which is useful if you want to reduce the number of events sent to the Defense Center. For more information, see Creating an RNA Detection Policy on page 138. You also can use the system policy to set a similar option on the Defense Center to compress flow summary data on the Defense Center itself. This can reduce the amount of space required to store flow summary data, and can also speed up the rendering of flow data graphs. For more information, see Configuring RNA Settings on page 1204. You can view flow data in different ways depending on the workflow you select. Many flow data workflows contain graphs; for example, the Flows over Time workflow contains a graph of the total number of detected flows over time, as well as table views of flow summaries and of flow events. Predefined flow data workflows are described in Predefined Flow Data Workflows on page 1156. For more information on flow data, including the specific actions you can perform on flow data graph and table workflow pages, see:

Version 4.7

•

Understanding Flow Summary Data on page 282

•

Understanding Flow Data Graphs on page 283

•

Understanding Flow Data Tables on page 291

•

Viewing Flow Data on page 299

•

Searching for Flow Data on page 299


281


Chapter 10

Understanding Flow Summary Data Requires: DC + RNA

When you configure your RNA detection policy, you must choose how flow data is collected. This includes NetFlow data, because RNA detection engines on your 3D Sensors also analyze NetFlow data and transmit it to the Defense Center. One of your options is to configure your 3D Sensors to transmit flow data to the Defense Center as aggregated data over five-minute intervals, called flow summaries, instead of transmitting flow data in individual flows. This reduce the number of events sent to the Defense Center, as well as reduce the amount of space required to store flow data. IMPORTANT! Contrast a flow summary, which is aggregated flow data, and the Flow Summary page, which provides graphs of the activity on your monitored network segment organized by different criteria so that you can get a quick understanding of the state of your network. For more information on the Flow Summary page, see Viewing the Flow Summary Page on page 277. Note that if you choose to configure your 3D Sensors to transmit flow data as individual flows, the Defense Center performs its own data aggregation, so that you can view flow data both as individual flows and as flow summaries. Within a flow summary, RNA aggregates flows based on several criteria. Aggregated flows must: •

have the same source and destination IP addresses, and use the same port on the responder (destination) host Keep in mind that because NetFlow records do not contain information about which host in the flow is the initiator and which is the responder, when RNA processes NetFlow records, it uses an algorithm to determine this information based on the ports each host is using, and whether those ports are well known.

•

use the same protocol (TCP or UDP)

•

use the same service For flows detected by 3D Sensors with RNA, this is the service as detected by RNA. For flows exported by NetFlow devices, this is the service identified by the port-service correlation in /etc/sf/services.

•

either be detected by the same detection engine (for flows detected by 3D Sensors with RNA) or be exported by the same NetFlow device and processed by the same detection engine

If multiple flows detected meet the above criteria, RNA aggregates them at the 3D Sensor before it sends the data to the Defense Center. The aggregated data in a flow summary includes the total number of packets and bytes send by the initiator and responder hosts, as well as the number of flows in the summary. Note that because NetFlow devices generate unidirectional flows, a summary’s flow count is incremented by two for every flow based on NetFlow data. For more information on the data that a flow summary contains as contrasted to the

Version 4.7


282


Chapter 10

data that an individual flow contains, see Understanding Flow Data Tables on page 291. If a monitored session spans two or more five-minute intervals over which flow data is aggregated, the flow is considered a long-running flow. When calculating the number of flows in a flow summary, RNA increments the count only for the five-minute interval in which a long-running flow was initiated. Also, when calculating the number of packets and bytes transmitted by the initiator and responder in a long-running flow, RNA does not report the number of packets and bytes that were actually transmitted during each five-minute interval. Instead, RNA assumes a constant rate of transmission and calculates estimated figures based on the total number of packets and bytes transmitted, the length of the flow, and what portion of the flow occurred during each five minute interval. Where possible, the Sourcefire 3D System treats individual flows and flow summaries identically. Therefore, even if you configure your 3D Sensors to transmit flow data to the Defense Center as flow summaries only, you can still view flow data graphs and create traffic profiles, create compliance rules that trigger when a flow summary meets criteria that you specify, and add flow trackers to compliance rules. However, you must remember that this configuration prevents both you and the Sourcefire 3D System from accessing data on individual flows. This has several important consequences. First, table views of flow data (for example, the RNA Flows workflow) contain no information. Second, you cannot examine the individual flow events on which flow data graphs are based. In other words, you cannot drill down to the flow data table view from a graph based on flow summaries. Finally, you should make sure that when you build compliance rules or flow trackers based on flow summaries, you use data that the flow summaries contain. For compliance rules, a trigger criterion based on information that is not included in a flow summary automatically evaluate to true. As an example, flow summaries do not include information on the initiator port. Therefore, if you build a compliance rule that requires that the initiator must be using a specific port, the rule will trigger for every flow summary that meets the other criteria in the rule. If that is the only criterion in the rule, the rule will trigger for every flow summary that the Defense Center receives. Similarly, if you use information that is not contained in a flow summary when you are building a flow tracker, the Defense Center will track all flow summaries that meet the other criteria in the flow tracker.

Understanding Flow Data Graphs Requires: DC + RNA

Version 4.7

One of the ways the Defense Center can present flow data is graphically. There are three different types of flow data graphs: line graphs, bar graphs, and pie charts. Bar graphs and line graphs can display multiple datasets; that is, they can display several values on the y-axis for each x-axis data point.


283


Chapter 10

You can manipulate flow data graphs in various ways, including: •

changing the type of data that the graph displays

•

switching between graph types

•

constraining the graph so it shows data for specific time ranges, hosts, services, ports, and detection engines

Because traffic profiles are based on flow data (see Creating Traffic Profiles on page 319), you can view traffic profiles as line graphs. You can manipulate these graphs in the same way as you would any other flow graph, with some restrictions. Note, however, that to view traffic profile graphs you must have either Rules or Admin access. Compare this with other flow graphs, which you can view with either Data or Admin access. For more information on flow graphs, see: •

Understanding Graph Types on page 284

•

Understanding Datasets on page 286

•

Understanding Flow Data Graph Functions on page 289

Understanding Graph Types Requires: DC + RNA

There are three different flow data graphs: line graphs, bar graphs, and pie charts. Line graphs plot data over time. For example, the following line graph displays the total number of flows detected on a monitored network segment over a one-hour time span. Traffic profiles are always displayed as line graphs.

By default, line graphs appear in standard view. A standard line graph aggregates data over five minute intervals, plots the aggregated data points, and connects the points. For example, in the standard graph above, the first data point shows 76 flows at the starting point. The second data point shows 57 flows at five minutes, which means that 57 flows were detected between minute zero and minute five.

Version 4.7


284


Chapter 10

However, you can change a line graph from standard view to velocity view. A velocity line graph shows the rate of change between those data points. If you change the above graph to a velocity graph, the y-axis changes from indicating the number of flows to indicating the change in the number of flows over time. In the example below, the velocity graph shows that the number of flows increased by 19.

Bar graphs display data grouped into discrete categories. For example, a bar graph could show the number of flows detected on a monitored network segment for the 10 most active ports over a one-hour time span.

Version 4.7


285


Chapter 10

Pie charts, like bar graphs, also display data grouped into discrete categories. The following pie chart shows the same information as the bar graph above.

Access: Data, Rules, or Admin

Follow the directions in the Changing Graph Types table to switch between standard and velocity line graphs, and to switch between bar graphs and pie charts. Note that to view traffic profile graphs you must have either Rules or Admin access. Compare this with other flow graphs, which you can view with either Data or Admin access. Changing Graph Types To change...

You can...

a bar graph to a pie chart

click Switch to Pie. Note that pie charts cannot display multiple datasets. For more information, see Understanding Datasets on page 286.

a pie chart to a bar graph

click Switch to Bar.

a line graph from a standard graph to a velocity graph

click Velocity and select Velocity.

a line graph from a velocity graph to a standard graph

click Velocity and select Standard.

Understanding Datasets Requires: DC + RNA

Version 4.7

Both bar graphs and line graphs can display multiple datasets; that is, they can display several values on the y-axis for each x-axis data point. For example, you could display the total number of unique initiators and the total number of unique responders detected on a monitored network segment over a one-hour interval.


286


Chapter 10

On line graphs, multiple datasets appear as multiple lines, each with a different color. For example, the following graphic displays the total number of unique initiators and the total number of unique responders detected on a monitored network segment over a one hour interval.

On bar graphs, multiple datasets appear as a set of colored bars for each x-axis data point. For example, the following bar graph displays the total packets transmitted on a monitored network segment, packets transmitted by initiators, and packets transmitted by responders.

You cannot display multiple datasets on a pie chart. If you switch to a pie chart from a bar graph that has multiple datasets, the pie chart shows only one dataset, which is selected automatically. When selecting which dataset to display, the Defense Center favors total statistics over initiator and responder statistics, and favors initiator statistics over responder statistics. For example, if you switch the

Version 4.7


287


Chapter 10

preceding bar graph to a pie chart, the chart displays only the total number of packets by responder.

Contrast this with the case where you view a bar graph that displays the number of unique initiating hosts and the number of unique responding hosts on a monitored network segment.

Version 4.7


288


Chapter 10

In this case, if you switch to a pie chart, the chart displays only the unique initiating hosts.

For information on how to display multiple datasets on a graph, see Selecting Datasets on page 316.

Understanding Flow Data Graph Functions Requires: DC + RNA

The Flow Data Graph Functions table describes the different actions you can perform on a flow data workflow page that contains a graph.


Note that to view traffic profile graphs you must have either Rules or Admin access. Compare this with other flow graphs, which you can view with either Data or Admin access. Flow Data Graph Functions

Version 4.7

To...

You can...

modify the time and date range for the flow data graph


view a host’s profile

on a graph displaying flow data by initiator or responder, click either a bar on a bar graph or a wedge on a pie chart and select View Host Profile.

learn more about the different kinds of graphs

see Understanding Graph Types on page 284.

change between bar graphs and pie chart, and between standard line graphs and velocity graphs

find more information in Changing the Graph Type on page 313.


289


Chapter 10

Flow Data Graph Functions (Continued)

Version 4.7

To...

You can...

change the kinds of data displayed on the graph

find more information in Selecting Data to Graph on page 313 and Selecting Datasets on page 316.

get more information about the aggregated flow data used to construct individual data points

see Viewing Aggregated Flow Data on page 306.

manipulate and constrain a flow data graph

find more information in Manipulating a Flow Data Graph on a Workflow Page on page 307.

navigate between pages in the current workflow

find more information in Using Workflow Pages on page 1165.

constrain flow data by drilling down through the workflow

find more information in Drilling Down through a Flow Data Workflow on page 309.

detach a flow graph to a popup window so that you can further manipulate it

find more information in Detaching Flow Data Graphs on page 318.

export the aggregated data used in a flow data graph as a comma-separated values (CSV) file

find more information in Exporting Flow Data on page 318.

navigate to other event views to view associated events






generate a report based on the data in the flow data view


search for flow data

click Search. For more information, see Searching for Flow Data on page 299.


290


Chapter 10

Understanding Flow Data Tables Requires: DC + RNA

As with all other event types, the Defense Center can present flow data in tables.


See the Flow Data Table Functions table on page 292 for some of the actions you can perform on a flow data workflow page that contains a table. You should keep several points in mind when viewing flows exported by NetFlow devices.

Version 4.7

•

For flows detected by 3D Sensors, RNA generates one bidirectional record, called a flow event. On the other hand, NetFlow devices export unidirectional flow data, so RNA generates at least two flow events for each flow detected by NetFlow devices, depending on whether you configured the device to output records at a fixed interval even if a flow is still ongoing. If you are monitoring the same network segment with NetFlow devices and 3D Sensors with RNA, RNA generates at least three flow events for each detected flow—one that represents the flow as detected by the sensor, and at least two for the flow as detected by NetFlow device.

•

NetFlow records do not contain information about which host in the flow is the initiator and which is the responder. When RNA processes NetFlow records, it uses an algorithm to determine this information based on the ports each host in using, and whether those ports are well-known. If both or neither port being used is a well-known port, RNA considers the host using the lower-number port to be the responder. If only one of the hosts is using a well-known port, RNA considers that host to be the responder. For this purpose, a well-known port is any port that is either numbered from 1 to 1023, or that contains service information in /etc/sf/services on the 3D Sensor that is analyzing your NetFlow data.


291


Chapter 10

•

The Sourcefire 3D System uses /etc/sf/services to determine the names of the services used in a flows exported by a NetFlow device. This means that if someone is running a service on a non-standard port, and the session is detected by a NetFlow device rather than a 3D Sensor, the Sourcefire 3D System could misidentify the service.

•

Flows exported by NetFlow devices do not contain NetBIOS information, nor do they include any information on client applications and URLs involved in the monitored session. However, NetFlow data includes information on any TCP flags set for the flow, while flow data collected by 3D Sensors with RNA does not.

Flow Data Table Functions To...

You can...


depending on whether you are viewing individual flows or flow summaries, see either: • the Flow Data Fields table on page 294 •

the Flow Summary Fields table on page 297


click the time range link. For more information, see Setting Event Time Constraints on page 1169.

view a host’s host profile

click the host profile icon ( ) that appears next to the IP address. For more information, see Using Host Profiles on page 172.

view user profile information

click the user icon (

sort flow data

click the column title. Click the column title again to reverse the sort order.

constrain the columns that appears

click the close icon ( ) in the column heading that you want to remove. Click the column name under Disabled Columns to add a disabled column back to the view.

)that appears next to the user

identity. For more information, see Understanding User Details and Host History on page 1091.

IMPORTANT! When you constrain flow events or flow summaries in a table, the packets and bytes from identical events are summed. However, if you are using a custom workflow and did not add a Count column, the events or summaries are listed individually and packets and bytes are not summed.

Version 4.7


292


Chapter 10

Flow Data Table Functions (Continued) To...

You can...

drill down to the next page in the workflow, constraining on a specific value

on a drill-down page that you created in a custom workflow, click a value within a row. Note that clicking a value within a row in a table view constrains the table view and does not drill down to the next page. TIP! Table views always include “Table View” in the page name. For more information, see Constraining Events on page 1170.

delete flow data from the system

use one of the following methods: • To delete some flow events or summaries, select the check boxes next to the events or summaries you want to delete, then click Delete. • To delete all flow events or summaries in the current constrained view, click Delete All, then confirm you want to delete all the events of summaries.

Version 4.7

navigate within and between workflow pages



click the name of the event view you want to see. For more information, see Navigating between Workflows on page 1175.





generate a report based on the data in the flow data view


search for flow data

click Search. For more information, see Searching for Flow Data on page 299.


293


Chapter 10

Flow Data Fields For any drill-down pages based on individual flows that you created in a custom workflow, and for the table view of flow data, the fields that can appear are described in the the Flow Data Fields table on page 294. IMPORTANT! To view data on individual flows, you must set the flow data mode to Enabled in your RNA detection policy. For more information, see Configuring RNA Detection Policies on page 134. Flow Data Fields

Version 4.7

Field

Description

First Packet

The date and time the first packet of the session was seen.

Last Packet

The date and time the last packet of the session was seen.

Initiator IP

The IP address (and host name, if DNS resolution is enabled) of the host that initiated the session.

Responder IP

The IP address (and host name, if DNS resolution is enabled) of the host that responded to the session initiator.

Initiator User

The ID of a user logged to the host that initiated the session.

Responder User

The ID of a user logged in to the host that responded to the session initiator.

Protocol

The protocol used during the detected session.

Initiator Port

The port used by the host that initiated the session.

Responder Port

The port used by the host that responded to the session initiator.

TCP Flags

The TCP flags detected in the flow.

Flow Type

Whether the flow was detected by a 3D Sensor with RNA, or was exported by a NetFlow device.


294


Chapter 10

Flow Data Fields (Continued) Field

Description

Service

One of: • the name of the service used in the flow, or, for services used in flows exported by NetFlow devices, the service name identified by the portservice correlation in /etc/sf/services • unidentified, if the flow was exported by a NetFlow device and the service could not be identified by the port-service correlation in /etc/sf/services, or if RNA does not have enough information to identify the service • blank, if the server is not on a monitored network IMPORTANT! Only services on monitored networks are tracked. For example, if an internal host accesses an FTP server on a remote site that you are not monitoring, the Service field is blank, indicating that the service is unknown. If a remote or internal host accesses an FTP server on a host you are monitoring, however, ftp appears in the Service field for the flow.

Version 4.7

NetBIOS Domain

The name of the NetBIOS domain used in the flow transaction.

Application Type

The type of client application used in the flow, if applicable.

Application

The name of the application used by the client in the flow, if applicable.

Version

The version of the application used by the client in the flow, if applicable.

Initiator Pkts

The total number of packets transmitted by the host that initiated the session.

Responder Pkts

The total number of packets transmitted by the host that responded to the session initiator.

Initiator Bytes

The total number of bytes transmitted by the host that initiated the session.

Responder Bytes

The total number of bytes transmitted by the host that responded to the session initiator.


295


Chapter 10

Flow Data Fields (Continued) Field

Description

URL

If the service is http and Capture HTTP URLs is enabled in the configuration for the sensor tracking the flow, this column displays the URL accessed during the session.

Source Device

The IP address of the NetFlow device that exported the flow data for the flow. If the flow was detected by a 3D Sensor with RNA, this field contains a value of RNA.

Detection Engine

The detection engine that collected the flow event, or, for flows exported by NetFlow devices, the detection engine that processed the NetFlow data.

Count

The number of flows that match the constraints described in the row. The count field appears on the table view only after you apply a constraint to the data. IMPORTANT! If you create a custom workflow and do not add the Count column to it, each flow is listed individually and packets and bytes are not summed.

Flow Summary Fields Requires: DC + RNA

For any drill-down pages based on flow summary data that you created in a custom workflow, and for the table view of flow summary data, the fields that can appear are described in the Flow Summary Fields table on page 297. Flow summaries are based on flow data aggregated over five-minute intervals. If a session spans two or more intervals, the flow is considered a long-running flow. When calculating the number of flows in a flow summary, RNA increments the count only for the five-minute interval in which a long-running flow was initiated. Also, when calculating the number of packets and bytes transmitted by the initiator and responder in a long-running flow, RNA does not report the number of packets and bytes that were actually transmitted during each five-minute interval. Instead, RNA assumes a constant rate of transmission and calculates estimated figures based on the total number of packets and bytes transmitted, the length of the flow, and what portion of the flow occurred during each five minute interval. Note that because NetFlow devices generate unidirectional flows, a summary’s flow count is incremented by two for every flow based on NetFlow data. For

Version 4.7


296


Chapter 10

more information on flow summary data see Understanding Flow Summary Data on page 282. Flow Summary Fields

Version 4.7

Field

Description

Time

The ending time of the five-minute interval that RNA used to aggregate the flows in the summary.

Initiator IP

The IP address (and host name, if DNS resolution is enabled) of the host that initiated the sessions aggregated in the summary.

Responder IP

The IP address (and host name, if DNS resolution is enabled) of the host that responded to the session initiator.

Initiator User

The ID of the user logged in to the host that initiated the sessions aggregated in the summary.

Responder User

The ID of the user logged in to the host that responded to the session initiator.

Protocol

The protocol used during the detected sessions aggregated in the summary.

Responder Port

The port used by the host that responded to the session initiator.

Flow Type

Whether the flows aggregated in the summary were detected by a 3D Sensor with RNA, or were exported by a NetFlow device.


297


Chapter 10

Flow Summary Fields (Continued) Field

Description

Service

One of: • the name of the service used in the flow, or, for services used in flows exported by NetFlow devices, the service name identified by the portservice correlation in /etc/sf/services • unidentified, if the flow was exported by a NetFlow device and the service could not be identified by the port-service correlation in /etc/sf/services, or if RNA does not have enough information to identify the service • blank, if the server is not on a monitored network IMPORTANT! Only services on monitored networks are tracked. For example, if an internal host accesses an FTP server on a remote site that you are not monitoring, the Service field is blank, indicating that the service is unknown. If a remote or internal host accesses an FTP server on a host you are monitoring, however, ftp appears in the Service field for the flow.

Version 4.7

Initiator Pkts

The total number of packets transmitted by the host that initiated the sessions aggregated in the summary.

Responder Pkts

The total number of packets transmitted by the host that responded to the session initiator.

Initiator Bytes

The total number of bytes transmitted by the host that initiated the sessions aggregated in the summary.

Responder Bytes

The total number of bytes transmitted by the host that responded to the session initiator.

Source Device

The IP address of the NetFlow device that exported the flow data for the flow. If the flow was detected by a 3D Sensor with RNA, this field contains a value of RNA.

Detection Engine

The detection engine that collected the flow event, or, for flows exported by NetFlow devices, the detection engine that processed the NetFlow data.


298


Chapter 10

Flow Summary Fields (Continued) Field

Description

Flows

The number of flows contained in the flow summary you are viewing. For long running flows, that is, flows that span multiple flow summary intervals, only the first flow summary interval is incremented.

Count

The number of flow summaries that match the constraints described in the row. The count field appears on the table view only after you apply a constraint to the data. IMPORTANT! If you create a custom workflow and do not add the Count column to it, each flow summary is listed individually and packets and bytes are not summed.

Viewing Flow Data Requires: DC + RNA

The page you see when you access flow data differs depending on the workflow you use. You can use one of the predefined workflows or create a custom workflow that displays only the information that matches your specific needs. For information on creating a custom flow data workflow, see Creating Custom Flow Data Workflows on page 1181. To view flow data:


h

Select Analysis & Reporting > RNA > Flow Data. The first page of your preferred workflow appears on the Flow Data page. There are two possibilities: •

The workflow page displays a graph. See Understanding Flow Data Graphs on page 283 for information on the actions you can perform.

•

The workflow page displays a table. See Understanding Flow Data Tables on page 291 for information on the actions you can perform.

If you did not specify a preferred workflow, you must select one. For more information, see Setting Event Preferences on page 35.

Searching for Flow Data Requires: DC + RNA

Version 4.7

You can search for specific flows by using one of the predefined searches delivered with the Defense Center or by using your own search criteria. The


299


Chapter 10

predefined searches serve as examples and can provide quick access to important information about your network. Default searches are: •

Possible Database Access, which searches for TCP traffic flows to ports that are commonly used by database servers.

•

Standard HTTP, which searches for TCP traffic flows to standard web server ports.

•

Standard Mail, which searches for TCP traffic flows to standard mail server ports.

•

Standard SSL, which searches for TCP traffic flows to the standard SSL port (443).

•

Unauthorized SMTP, which searches for traffic to the standard SMTP port (25) on hosts that are not authorized SMTP servers from hosts inside the network. This search must be customized for your network before you can run it. Configure the Initiator IP with the address you want to use for the internal network (for example, 172.16.1.1/24) and the Responder IP as the negated values of your SMTP servers (for example, !172.16.1.28,!172.16.1.27).

Version 4.7


300


Chapter 10

You may want to modify specific fields within the default searches to customize them for your network environment, then save them to re-use later. The search criteria you can use are described in the Flow Data Search Criteria table. IMPORTANT! When searching for flows, you should keep in mind that flows detected by 3D Sensors with RNA and flows exported by NetFlow devices contain different information. For example, flows detected by 3D Sensors with RNA do not contain TCP flag information. In addition, your search tactics may change depending on whether you configured your 3D Sensors to transmit flow data to the Defense Center as individual flows or as flow summaries. For more information, see Understanding Flow Data Tables on page 291. Flow Data Search Criteria Field


First Packet or Last Packet

Type either: • the date and time that the first packet of the session was seen (First Packet) • the date and time that the last packet of the session was seen (Last Packet) See Specifying Time Constraints in Searches on page 1130 for the syntax for entering time.

Initiator IP, Responder IP, or Initiator/Responder IP

Type the IP address (or host name, if DNS resolution is enabled) of either: • the host that initiated the session (Initiator IP) • the host that responded to the session initiator (Responder IP) • either host involved in the session (Initiator/Responder IP) Use a specific IP address or CIDR notation to specify a range of IP addresses. See Specifying IP Addresses in Searches on page 1130 for a full description of the syntax allowed for IP addresses.

Initiator User, Responder User, or Initiator/Responder User

Type the User ID of either: • the user of the host that initiated the session (Initiator User) • the user of the host that responded to the session initiator (Responder User) • the user of either host involved in the session (Initiator/Responder User) Use the full User ID or a partial User ID during searches. Note that partial name recognition is permitted (for example, smith yields jsmith, msmith for John Smith and Mary Smith).

Protocol

Version 4.7

Type the name or number of the transport protocol used in the flow as listed in http://www.iana.org/assignments/protocol-numbers.


301


Chapter 10

Flow Data Search Criteria (Continued) Field


Initiator Port or Responder Port

Type either: • the port used by the host that initiated the session (Initiator Port) • the port used by the host that responded to the session initiator (Responder Port) See Specifying Ports in Searches on page 1132 for information about specifying ports.

TCP Flags

Type a list of comma-separated TCP flags to view all flows that have at least one of those flags. You can also select the Only checkbox to search for flows that have any of the flags you specify as their only TCP flag.

Flow Type

Type either: • RNA to search for flows detected by 3D Sensors with RNA • NetFlow to search for flows exported by a NetFlow device

Service

Specify the name of the service used in the flow. You can only search for services within flows where the host running the service resides on a monitored network segment. For a list of services detected by RNA, see Detected Services on page 1437.

NetBIOS Domain

Specify the name of the NetBIOS domain used in the flow transaction. You can use an asterisk (*) as a wildcard character in this field.

Application Type

Specify the type of client application used in the flow.

Application

Specify the name of the client application used by the host involved in the flow. For a list of applications detected by RNA, see Detected Client Applications on page 1436. You can use an asterisk (*) as a wildcard character in this field.

Version

Specify the version of the client application used by the host involved the flow. You can use an asterisk (*) as a wildcard character in this field.

Initiator Pkts or Responder Pkts

Type either: • the number of packets transmitted by the hosts on the monitored network segment (Initiator Pkts) • the number of packets received by the hosts on the monitored network segment (Responder Pkts) You can precede the number with greater than (>), greater than or equal to (>=), less than (=), less than (=), less than ( Flow Data. The Flow Data search page appears.

TIP! To search the database for a different kind of event, select it from the Table list. 2. Optionally, if you want to save the search, enter a name for the search in the Name field. If you do not enter a name, the Defense Center automatically creates one when you save the search.

Version 4.7


304

Working with Flow Data and Traffic Profiles Manipulating Flow Data Graphs

Chapter 10

3. Enter your search criteria in the appropriate fields, as described in the Flow Data Search Criteria table. If you enter multiple criteria, the Defense Center returns only the records that match all the criteria. IMPORTANT! Fields marked with an asterisk (*) constrain flow data graphs and flow summaries. That is, flow data graphs and flow summary even views do not display information on, for example, the client applications that are running on a host. So if you search for flow events based on the detected client application in the flow, then view your search results in a graph or flow summary event view, the graph displays flow data as if you had not constrained it at all. 4. If you want to save the search so that other users can access it, clear the Save As Private check box. Otherwise, leave the check box selected to save the search so that only you can use it. TIP! If you want to save a search as a restriction for restricted data users, you must save it as a private search. 5. You have the following options: •

Click Search to start the search. If you specified a preferred flow data workflow, your search results appear, constrained by the current time range on the Defense Center. Otherwise, you must select a workflow. For information on specifying a preferred workflow, see Setting Event Preferences on page 35.

•


•


Manipulating Flow Data Graphs Requires: DC + RNA

You can manipulate flow data graphs in various ways including: •

changing the type of data that the graph displays

•

switching between graph types

•

constraining the graph so it shows data for specific time ranges, hosts, services, ports, and detection engines

Because traffic profiles are based on flow data (see Creating Traffic Profiles on page 319), you can view traffic profiles as line graphs. You can manipulate these graphs in the same way as you would any other flow graph, with some restrictions. Note, however, that to view traffic profile graphs you must have

Version 4.7


305


Chapter 10

either Rules or Admin access. Compare this with other flow graphs, which you can view with either Data or Admin access. For more information, see: •

Viewing Aggregated Flow Data on page 306 explains how to get more information about the data points on the graph, or to display the host profile of a host whose statistics are being graphed.

•

Manipulating a Flow Data Graph on a Workflow Page on page 307 explains how to constrain the data that appears on a flow data graph without advancing the workflow to the next page.

•

Drilling Down through a Flow Data Workflow on page 309 explains how to constrain the data that appears on a flow data graph while advancing the workflow to the next page.

•

Recentering and Zooming on Line Graphs on page 312 explains how to recenter a line graph around any point in time.

•

Changing the Graph Type on page 313 explains how to change between bar graphs and pie chart, and between standard line graphs and velocity graphs.

•

Selecting Data to Graph on page 313 explains how to change the data displayed on a flow data graph by changing its x- or y-axis.

•

Selecting Datasets on page 316 explains how to display several values on the y-axis for each x-axis data point on line graphs and bar graphs.

•

Detaching Flow Data Graphs on page 318 explains how you can detach a flow data graph into a new browser window and perform further analysis without affecting the default time range for the Defense Center.

•

Exporting Flow Data on page 318 explains how to export the flow data used to construct a graph as a CSV (comma-separated values) file.

Viewing Aggregated Flow Data Requires: DC + RNA

Flow data graphs are based on aggregated data over five-minute intervals, also called flow summaries. You can get more information about the specific flow summaries used to construct a flow data graph. For example, on a graph of flows over time, you may want to know exactly how many flows were detected over a specific interval. Note that to view traffic profile graphs you must have either Rules or Admin access. Compare this with other flow graphs, which you can view with either Data or Admin access.

Version 4.7


306


Chapter 10

To get detailed information on aggregated flow data: Access: Data, Rules or Admin

h

Position your cursor over a point on a line graph (as shown in the following graphic), a bar in a bar graph, or a wedge in a pie chart. A tool tip appears with detailed information about the data used to construct that portion of the graph.

TIP! To see all the aggregated data used to build the flow data graph, view the table view of flow summary data; if you are using one of the workflows delivered with the Defense Center, click Table View of Flow Summary Data at the top of the page. You can also export the graph as a CSV file, as described in Exporting Flow Data on page 318.

Manipulating a Flow Data Graph on a Workflow Page Requires: DC + RNA

When you open a flow data workflow, the data is initially constrained only by a time range. You can constrain flow data graphs with additional criteria without advancing the workflow to the next page. TIP! Constraining flow data in this manner changes the x-axis (also called the independent variable) when viewing a pie chart) of the graph. To change the independent variable without constraining the flow data, use the X-Axis and Y-Axis menus. For more information, see Selecting Data to Graph on page 313. Note that to view traffic profile graphs you must have either Rules or Admin access. Compare this with other flow graphs, which you can view with either Data or Admin access.

Version 4.7


307


Chapter 10

To constrain flow data: Access: Data, Rules or Admin

1.

Click a point on a line graph, a bar on a bar graph, or a wedge on a pie chart.

2. Select a View by... option. You can constrain flow data based on time, initiating host, responding host, service, port, and detection engine. For example, consider a graph of flows over time. If you constrain a point on the graph by port:

A bar graph appears, showing the 10 most active ports based on the number of detected flow events, but constrained by the ten-minute time span that is centered on the point you clicked.

If you further constrain the graph by clicking on one of the bars and selecting View by Initiator, a new bar graph appears, constrained by not only the same ten-minute time span as before, but also by the port represented by the bar you clicked.

Version 4.7


308


Chapter 10

IMPORTANT! Note that unless you are working with a detached graph, constraining flow data in this manner changes the time range. For more information on detached graphs, see Detaching Flow Data Graphs on page 318.

Drilling Down through a Flow Data Workflow Requires: DC + RNA

Version 4.7

When you open a flow data workflow, the data is initially constrained only by a time range. You can constrain flow data graphs while advancing the workflow to the next page.


309


Chapter 10

To drill down in a flow data workflow: Access: Data or Admin

1.

Click a point on a line graph, a bar on a bar graph, or a wedge on a pie chart.

2. Select Drill-down. For example, consider the following custom workflow.

This workflow has three pages: •

Flows over Time, which is a line graph of the total number of flows over time

•

Top Ten Ports by Flow, which is a bar graph of the 10 most active ports based on the number of detected flow events

•

the table view of flow data

If you drill down from the first page to the second page of the workflow, the time span for the Flows by Port bar graph is now a 10 minute range, centered on the point you clicked.

Version 4.7


310


Chapter 10

If you drill down again, the workflow advances to the table view. The time span is still constrained to the same 10 minute range, and the table view shows only those flow events on the port represented by the bar you clicked.

IMPORTANT! If you used the RNA detection policy to configure your 3D Sensors to transmit flow data to the Defense Center as flow summaries only, you cannot examine the individual flow events on which flow data graphs are based. In other words, you cannot drill down to the flow data table view from a graph based on flow summaries. For more information, see Understanding Flow Summary Data on page 282.

Version 4.7


311


Chapter 10

Recentering and Zooming on Line Graphs Requires: DC + RNA

You can recenter line graphs around any point in time. You can recenter using either the default time range, or you can choose a different time range. IMPORTANT! Unless you are working with a detached graph, recentering changes the default time range. For more information on detached graphs, see Detaching Flow Data Graphs on page 318. Note that to view traffic profile graphs you must have either Rules or Admin access. Compare this with other flow graphs, which you can view with either Data or Admin access. To recenter using the default time range:


h

Click the point on the line graph where you want to recenter the graph, and click recenter. The graph is redrawn, centered on the point you clicked, with a time span that is the same length as your default time range.

To recenter using a different time range: Access: Data, Rules or Admin

1.

Click the point where you want to recenter the graph and click Zoom.

2. Select the time span for the new graph, which can be as short as one hour or as long as one week. The graph is redrawn, centered on the point you clicked, with the time span you selected.

Version 4.7


312


Chapter 10

Changing the Graph Type Requires: DC + RNA

You can switch between standard and velocity line graphs, and between bar graphs and pie charts. For more information, see Understanding Graph Types on page 284.


Follow the directions in the Changing Graph Types table to change the graph type. Note that to view traffic profile graphs you must have either Rules or Admin access. Compare this with other flow graphs, which you can view with either Data or Admin access. Changing Graph Types To change...

You can...

a bar graph to a pie chart

click Switch to Pie. Note that pie charts cannot display multiple datasets. For more information, see Understanding Datasets on page 286.

a pie chart to a bar graph

click Switch to Bar.

a line graph from a standard graph to a velocity graph

click Velocity and select Velocity.

a line graph from a velocity graph to a standard graph

click Velocity and select Standard.

Selecting Data to Graph Requires: DC + RNA

You can display different data on a flow data graph by changing either the x-axis, the y-axis, or both. Note that on a pie chart, changing the x-axis changes the independent variable and changing the y-axis changes the dependent variable. For example, consider a pie chart that graphs kilobytes per port. In this case, the x-axis is Port and the y-axis is KBytes. This pie chart represents the total kilobytes of data transmitted over a

Version 4.7


313


Chapter 10

monitored network segment during a certain interval. The wedges of the pie represent the percent of the data that was detected on each port.

If you change the x-axis of the chart to Detection Engine, the pie chart still represents the total kilobytes of data transmitted, but the wedges of the pie represent the percentage of the data that was detected by each detection engine.

However, if you change the y-axis of the first pie chart to Packets, the pie chart represents the total number of packets transmitted over the monitored network

Version 4.7


314


Chapter 10

segment during a certain interval, and the wedges of the pie represent the percentage of the total number of packets that was detected on each port.


Follow the directions in the X-Axis Functions table to change the x-axis of a flow data graph. Note that to view traffic profile graphs you must have either Rules or Admin access. Compare this with other flow graphs, which you can view with either Data or Admin access. X-Axis Functions

Version 4.7

To graph flow data...

You can...

over time

click X-Axis and select Time.

by the 10 most active hosts on the monitored network segment based on the number of flow events where the host initiated the flow transaction

click X-Axis and select Initiator.

by the 10 most active hosts on the monitored network segment based on the number of flow events where the host was the responder in the flow transaction

click X-Axis and select Responder.

by the 10 most active services on the monitored network segment based on the number of detected flow events

click X-Axis and select Service.

by the 10 most active ports on the monitored network segment based on the number of detected flow events

click X-Axis and select Port.

by the 10 most active detection engines on the monitored network segment based on the number of detected flow events

click X-Axis and select Detection Engine.


315



Chapter 10

Follow the directions in the Y-Axis Functions table to change the y-axis of a flow data graph. Note that to view traffic profile graphs you must have either Rules or Admin access. Compare this with other flow graphs, which you can view with either Data or Admin access. Y-Axis Functions To...

You can...

graph the number of flows on the monitored network segment by the criterion you chose for the x-axis

click Y-Axis and select Flows.

graph the total kilobytes transmitted on the monitored network segment by the criterion you chose for the x-axis

click Y-Axis and select KBytes.

graph the total number of packets transmitted on the monitored network segment by the criterion you chose for the x-axis

click Y-Axis and select Packets.

graph the total number of unique hosts detected on the monitored network segment by the criterion you chose for the x-axis

click Y-Axis and select Unique Hosts.

Selecting Datasets Requires: DC + RNA

Version 4.7

On line and bar graphs you can display several values on the y-axis for each x-axis data point. Pie graphs can only display one dataset. For more information, see Understanding Datasets on page 286.


316


Chapter 10

The Dataset Options table describes the datasets you can display on the x-axis of a flow data graph. Dataset Options If the y-axis displays...

You can select as datasets...

Flows

the default only, which is the number of flows detected on the network segment (Flows). This is the only option for traffic profile graphs.

KBytes

combinations of: • the total kilobytes transmitted on the monitored network segment (Total KBytes) • the number of kilobytes transmitted by the hosts on the monitored network segment (Initiator KBytes) • the number of kilobytes received by the hosts on the monitored network segment (Responder KBytes)

Packets

combinations of: • the total packets transmitted on the monitored network segment (Total Packets). • the number of packets transmitted by the hosts on the monitored network segment (Initiator Packets) • the number of packets received by the hosts on the monitored network segment (Responder Packets)

Unique Hosts

combinations of: • the number of unique hosts that initiated sessions that were detected on the monitored network segment (Unique Initiators). • the number of unique hosts that responded to flow transaction that were detected on the monitored network segment (Unique Responders).

To select the datasets displayed on a flow data graph: Access: Data or Admin

Version 4.7

h

Click Datasets and select the datasets you want to graph. The datasets you can select are described in the Dataset Options table.


317


Chapter 10

Detaching Flow Data Graphs Requires: DC + RNA

If you want to perform further analysis on a flow data graph, without affecting the default time range, you can detach the graph into a new browser window. You can perform all the same actions on detached flow data graphs that you can on embedded flow data graphs. You can also print a detached graph by clicking Print. Note that traffic profile graphs are, by default, detached graphs. TIP! If you are viewing a detached graph, click New Window to create another copy of the detached graph in a new browser window. You can then perform different analyses on each of the detached graphs. To detach a graph:


h

Click Detach.

Exporting Flow Data Requires: DC + RNA

You can easily share flow data with others by exporting it as a CSV (commaseparated values) file. Note that to view traffic profile graphs you must have either Rules or Admin access. Compare this with other flow graphs, which you can view with either Data or Admin access. TIP! You can also save a flow data graph as an image by right-clicking on the graph and selecting Save Image As (Firefox and Netscape) or Save Picture As (Internet Explorer).

Version 4.7


318

Working with Flow Data and Traffic Profiles Creating Traffic Profiles

Chapter 10

To export flow data: Access: Data, Rules, or Admin

1.

Click Export Data. A pop-up appears, displaying a table view of the data on your graph.

2. Click Download CSV File and save the file.

Creating Traffic Profiles Requires: DC + RNA

A traffic profile is just that—a profile of the traffic on your network, based on flow data collected over a time span that you specify. You can use flow data collected by your 3D Sensors with RNA, flow data exported by any or all of your NetFlow devices, or both. After you create a traffic profile, you can detect abnormal network traffic by evaluating new traffic against your profile, which presumably represents normal network traffic. The time span used to collect data to build your traffic profile is called the profiling time window (PTW). The PTW is a sliding window; that is, if your PTW is one week (the default), your traffic profile includes flow data collected over the last week. You can change the PTW to be as short as an hour or as long as several weeks. When you first activate a traffic profile, it collects and evaluates flow data according to the criteria you have set, for a learning period equal in time to the PTW. The Defense Center does not evaluate rules you have written against the traffic profile until the learning period is complete. You can create profiles using all the traffic on a monitored network segment, or you can create more targeted profiles using criteria based on the data in the flow events. For example, you could set the profile conditions so that the traffic profile only collects data where the detected session uses a specific port, protocol, or

Version 4.7


319


Chapter 10

application. Or, you could add a host profile qualification to the traffic profile to collect data only for hosts that exhibit a host criticality of high. Finally, when you create a traffic profile, you can specify inactive periods—periods in which flow data do not affect profile statistics and rules written against the profile do not trigger. You can also change how often the traffic profile aggregates and calculates statistics on collected flow data. The following graphic shows a traffic profile with a PTW of one week, a sampling rate of five minutes, and a daily half-hour inactive period from midnight to 12:30AM.

After you create and activate a traffic profile and its learning period is complete, you can create compliance rules that trigger when you detect anomalous traffic. For example, you could write a rule that triggers if the amount of data traversing your network (measured in packets, KBytes, or number of flows) suddenly spikes to three standard deviations above the mean amount of traffic, which could indicate an attack or other security policy violation. Then, you could include that rule in a compliance policy to alert you of the traffic spike or to perform a remediation in response. For information on using traffic profiles to detect abnormal network traffic, see Creating Rules for Compliance Policies on page 394. You create traffic profiles on the Traffic Profiles page.

The light bulb icon next to each profile indicates whether the profile is active. If you want to base a compliance rule on a traffic profile change, you must activate

Version 4.7


320


Chapter 10

the profile. If the light bulb icon is lit, the profile is active. If it is dark, the profile is inactive. For more information, see Activating and Deactivating Traffic Profiles on page 330. The progress bar shows the status of the traffic profile’s learning period. When the progress bar reaches 100%, compliance rules written against the profile will trigger. TIP! You can sort traffic profiles by state (active versus inactive) or alphabetically by name using the Sort by drop-down list.

Version 4.7


321


Chapter 10

The following diagram illustrates the process for creating a traffic profile.

For more information, see:

Version 4.7

•

Providing Basic Profile Information on page 323

•

Specifying Traffic Profile Conditions on page 324


322


•

Adding a Host Profile Qualification on page 325

•

Setting Profile Options on page 328

•

Saving a Traffic Profile on page 329

•

Activating and Deactivating Traffic Profiles on page 330

•

Editing a Traffic Profile on page 330

•

Understanding Condition-Building Mechanics on page 331

Chapter 10

Providing Basic Profile Information Requires: DC + RNA

When you create a traffic profile, you must give it a name and, optionally, a short description. To begin creating a traffic profile:


1.

Select Policy & Response > Compliance > Traffic Profiles. The Traffic Profiles page appears.

2. Click New Profile. The Create Profile page appears.

Version 4.7


323


Chapter 10

3. In the Profile Name field, type a name of up to 255 characters for the new traffic profile. 4. In the Profile Description field, type a short description of up to 255 characters of the new traffic profile. 5. Continue with Specifying Traffic Profile Conditions.

Specifying Traffic Profile Conditions Requires: DC + RNA

Profile conditions constrain the kinds of flow data you want the traffic profile to track. A simple traffic profile that profiles all the traffic on a monitored network segment has no conditions. In contrast, traffic profiles can be complex, with multiple nested conditions. For example, the traffic profile conditions in the following graphic collects HTTP flows on the 10.4.x.x subnet.

You build traffic profile conditions in the Profile Conditions section of the Create Profile page. See Understanding Condition-Building Mechanics on page 331 for information on building conditions. Also, the syntax you can use to build conditions is fully described in Syntax for Traffic Profile Conditions on page 324. TIP! If you want to use the settings from an existing traffic profile, click Copy Settings and, in the pop-up window, select the traffic profile you want to use and click Load.

Syntax for Traffic Profile Conditions Requires: DC + RNA

The Syntax for Profile Conditions table describes how to build a traffic profile condition. Keep in mind that NetFlow records do not contain information about which host in the flow is the initiator and which is the responder. When RNA processes NetFlow records, it uses an algorithm to determine this information based on the

Version 4.7


324


Chapter 10

ports each host is using, and whether those ports are well-known. For more information, see Understanding Flow Data Tables on page 291. Syntax for Profile Conditions If you specify...

Select an operator, then...


Use a specific IP address or CIDR notation to specify a range of IP addresses. See Specifying IP Addresses in Searches on page 1130 for a description of the syntax allowed for IP addresses. Note, however, that you cannot use the local or remote keywords to specify IP addresses that are or are not in the networks you are monitoring.

Responder Port

Type the port number.

Protocol

Type the name or number of the transport protocol as listed in http://www.iana.org/assignments/protocol-numbers.

Flow Type

Select whether you want to use flow data collected by 3D Sensors with RNA or by NetFlow devices in the traffic profile. If you do not specify a flow type, the traffic profile includes both.

NetFlow Device

Select the NetFlow device whose data you want to use to create the traffic profile. If you did not add any NetFlow devices to your deployment (using the system settings), the NetFlow Device drop-down list is blank.

Service Name

Select one or more service names from the list of available services.

Adding a Host Profile Qualification Requires: DC + RNA

You can constrain any traffic profile with information from the host profile of the tracked hosts. This constraint is called a host profile qualification. For example, as shown in the following graphic, you could collect flow data only for hosts that are assigned a host criticality of high.

To use a host profile qualification, the host must exist in the database and the host profile property you want to use as a qualification must already be included in the host profile. For example, if you configure a compliance policy rule to trigger when an intrusion event is generated on a host running Windows, the rule only triggers if the host is already identified as Windows when the intrusion event is generated.

Version 4.7


325


Chapter 10

To add a host profile qualification: Access: Rules or Admin

1.

On the Create Rule page, click Add Host Profile Qualification. The Host Profile Qualification section appears.

2. Build the host profile qualification’s conditions. You can create a single, simple condition, or you can create more elaborate constructs by combining and nesting conditions. See Understanding Condition-Building Mechanics on page 331 for information building conditions. The syntax you can use to build conditions is described in Syntax for Host Profile Qualifications on page 326. TIP! To remove a host profile qualification, click Remove Host Profile Qualification.

Syntax for Host Profile Qualifications Requires: DC + RNA

When you build a host profile qualification condition, you must first select the host you want to use to constrain your traffic profile. You can select either Responder Host or Initiator Host. After you select the host type, continue building your host profile qualification condition, as described in the Syntax for Host Profile Qualifications table. Although you can configure the RNA detection policy to add hosts to the network map based on data exported by NetFlow devices, the available information about these hosts is limited. For example, there is no operating system data available for these hosts, unless you provide it using the host input feature. In addition, if your traffic profile uses flow data exported by NetFlow devices, keep in mind that NetFlow records do not contain information about which host in the flow is the initiator and which is the responder. When RNA processes NetFlow records, it uses an algorithm to determine this information based on the ports each host is using, and whether those ports are well-known. For more information, see What

Version 4.7


326


Chapter 10

Information Does RNA Provide? on page 127 and Understanding Flow Data Tables on page 291. Syntax for Host Profile Qualifications If you specify...


Host Type

Select one or more host types from the drop-down list. You can select Bridge, Host, or Router.

NETBIOS Name

Type the NetBIOS name of the host.

Operating System > OS Name

Select one or more operating system names from the drop-down list.

Operating System > OS Vendor

Select one or more operating system vendor names from the drop-down list.

Operating System > OS Version

Select one or more operating system versions from the drop-down list.

Network Protocol

Type the network protocol number as listed in http://www.iana.org/assignments/ethernet-numbers.

Transport Protocol


Host Criticality

Select the host criticality from the list that appears. You can select None, Low, Medium, or High. For more information on host criticality, see Assigning a Host Criticality Value to a Host on page 201.

VLAN ID

Type the VLAN ID number of the host.

Service > Service Name

Select one or more services from the drop-down list.

Service > Service Port

Type the service port number.

Service > Service Protocol

Select one or more protocols from the drop-down list.

Client Application > Application Type

Select one or more application types from the drop-down list.

Client Application > Application

Select one or more applications from the drop-down list.

Client Application > Application Version

Type the application version.

Version 4.7


327


Chapter 10

Syntax for Host Profile Qualifications (Continued) If you specify...


MAC Address > MAC Address

Type all or part of the MAC address of the host.

MAC Address > MAC Type

Select whether the MAC type is ARP/DHCP Detected.

any available host attribute, including the default compliance white list host attribute

That is, select whether RNA positively identified the MAC address as belonging to the host (is ARP/DCHCP Detected), whether RNA is seeing many hosts with that MAC address because, for example, there is a router between the sensor and the host (is not ARP/DHCP Detected), or whether the MAC type is irrelevant (is any). Specify the appropriate value, which depends on the type of host attribute you select: • If the host attribute type is Integer, enter an integer value in the range defined for the attribute. • If the host attribute type is Text, and enter a text value. • If the host attribute type is List, select a valid list string from the dropdown list. • If the host attribute type is URL, enter a URL value. For more information on host attributes, see Working with User-Defined Host Attributes on page 202.

Setting Profile Options Requires: DC + RNA

The profiling time window (PTW) is the sliding time window, equal in length to the learning period, that the Sourcefire 3D System uses to calculate statistics for the traffic profile. The default PTW is one week, but you can change it to be as short as an hour or as long as several weeks. Also, traffic profiles are based on aggregated flow data. By default, traffic profiles generate statistics on flow events generated RNA over five-minute intervals. However, you can set this sampling rate anywhere between the default five minutes and one hour. Keep in mind that you should set your PTW and sampling rate so that your traffic profiles contain enough data to be statistically meaningful. For example, a PTW of one day with a sampling rate of one hour would only contain 24 data points, which may not be enough for accurate analysis of network traffic patterns. TIP! Your PTW should include at least 100 data points. You can also set up inactive periods in traffic profile. For example, consider a network infrastructure where all the workstations are backed up at midnight every night. The backup takes about 30 minutes and spikes the network traffic. In

Version 4.7


328


Chapter 10

that case, you might want to set up a recurring inactive period for your traffic profile to coincide with the scheduled backups. During inactive periods, the traffic profile collects data (so you can see the traffic on the traffic profile graphs), but that data is not used when calculating profile statistics. You can set up inactive periods to recur daily, weekly, or monthly. Inactive periods can be as short as five minutes or as long as one hour. Traffic profile graphs plotted over time show inactive periods as a shaded region, as displayed in the following graphic.


Follow the directions in the Profile Options table to set profile options. Profile Options To...

You can...

change the profiling time window

in the Profiling Time Window field, type the number of hours, days, or weeks. Then choose hour(s), day(s), or week(s) from the drop-down list.

change the sampling rate

select the rate from the Sampling Rate drop-down list.

add an inactive period

click Add Inactive Period. Then, using the drop-down lists, specify when and how often you want the traffic profile to refrain from collecting data.

delete an inactive period

click Delete next to the inactive period you want to delete.

Saving a Traffic Profile Requires: DC + RNA

Version 4.7

Use the following procedure to save a traffic profile.


329


Chapter 10

To save a traffic profile: Access: Rules or Admin

h

You have two options.

•

To save the profile without activating it, click Save.

•

To save the profile and start collecting data immediately, click Save & Activate.

Activating and Deactivating Traffic Profiles Requires: DC + RNA

When you want it to begin profiling the traffic on a monitored network segment, you must activate a traffic profile. Deactivate a profile when you want it to stop collecting and evaluating flow data. Rules written against deactivated traffic profiles do not trigger. In addition, deactivating a traffic profile deletes all data collected and aggregated by the profile. If you later reactivate a deactivated traffic profile, you must wait the length of its PTW before rules written against it will trigger. To activate or deactivate a traffic profile:


1.



To activate an inactive traffic profile, click Activate next to the profile.

•

To deactivate an active traffic profile, click Deactivate next to the profile. Confirm that you want to deactivate the profile by clicking OK.

Editing a Traffic Profile Requires: DC + RNA

You cannot substantially edit an active traffic profile; if the traffic profile is active you can only change its name and description. To edit a traffic profile’s conditions options, you must first deactivate it. Note that deactivating a traffic profile deletes all the data it has collected. For more information on activating and deactivating traffic profiles, see Activating and Deactivating Traffic Profiles on page 330. To edit a traffic profile:


Version 4.7

1.



330


Chapter 10

2. Next to the traffic profile you want to edit, click Edit. The Create Profile page appears. 3. Make changes to the profile and click Save. Your profile is updated.

Understanding Condition-Building Mechanics Requires: DC + RNA

You build traffic profiles by specifying the conditions they use to collect data. You can create either simple conditions or more elaborate constructs with nested conditions. For example, if you want to create a traffic profile that collects data for your entire monitored network segment, you can create a very simple profile with no conditions, as shown in the following graphic.

If you wanted to constrain the profile and collect data only for the 10.4.x.x network, you can add a single condition, as shown in the following graphic.

But the following traffic profile, which collects HTTP activity on the 10.4.x.x network and the 192.168.x.x network, has three conditions, with the last constituting a complex condition.

Version 4.7


331


Chapter 10

The syntax you can use within conditions varies depending on the element you are creating, but the mechanics are the same. For more information, see: •

Building A Single Condition on page 332

•

Adding and Linking Conditions on page 334

•

Using Multiple Values in a Condition on page 336

Building A Single Condition Requires: DC + RNA

Most conditions have three parts: a category, an operator, and a value. Some conditions are more complex and contain several categories, each of which may have their own operators and values. For example, the following traffic profile collects information on the 10.4.x.x network. The category of the condition is Initiator/Responder IP, the operator is is in, and the value is 10.4.0.0/16.

The following steps explain how to build this traffic profile condition. Access: Rules or Admin

1.


2. Click New Profile. The Create Profile page appears. 3. Under Profile Conditions, begin building the profile’s single condition by selecting Initiator/Responder IP from the first (category) drop-down list. 4. Select is in from the second (operator) drop-down list. TIP! When the category represents an IP address, choosing is in or is not in as the operator allows you to specify whether the IP address is in or is not in a specific CIDR block. See Specifying Subnets with CIDR Notation on page 1131 for more information. 5. Type 10.4.0.0/16 in the text field.

Version 4.7


332


Chapter 10

In contrast, the following host profile qualification is more complex; it constrains a traffic profile such that it collects flow data only if the responding host in the detected flow is running a version of Microsoft Windows.

The following steps explain how to build this host profile qualification. Access: Rules or Admin

1.


2. Click New Profile. The Create Profile page appears. 3. Click Add Host Profile Qualification. 4. Under Host Profile Qualification, in the first condition, specify the host whose information you want to collect. In this example, select Responder Host because we only want information on responding hosts in a flow. 5. Begin specifying the details of the operating system of the host by choosing the Operating System category. Three subcategories appear: OS Vendor, OS Name, and OS Version. 6. To specify that the host can be running any version of Microsoft Windows, use the same operator for all three subcategories: is. 7.

Finally, specify the values for the subcategories. Select Microsoft as the value for OS Vendor, Windows as the value for OS Name, and leave any as the value for OS Version.

Note that the categories you can choose from depend on whether you are building traffic profile conditions or a host profile qualification. In addition, a condition’s available operators depend on the category you choose. Finally, the syntax you can use to specify a condition’s value depends on the category and operator. Sometimes you must type the value in a text field. Other times, you can pick a value from a drop-down list. IMPORTANT! Where the condition syntax allows you to pick a value from a dropdown list, you can often use multiple values from the list. For more information, see Using Multiple Values in a Condition on page 336.

Version 4.7


333


Chapter 10

For information on the syntax for building traffic profile conditions and host profile qualifications, see: •

Syntax for Traffic Profile Conditions on page 324

•

Syntax for Host Profile Qualifications on page 326

Adding and Linking Conditions Requires: DC + RNA

You can create simple traffic profile conditions and host profile qualifications, or you can create more elaborate constructs by combining and nesting conditions. When your construct includes more than one condition, you must link them with an AND or an OR operator. Conditions on the same level are evaluated together. •

The AND operator requires that all conditions on the level it controls must be met.

•

The OR operator requires that at least one of the conditions on the level it controls must be met.

For example, the following traffic profile contains two conditions linked by AND. This means that the traffic profile collects flow data only if both conditions are true. In this example, it collects HTTP flows for all hosts with an IP addresses in the 10.4.x.x subnet.

In contrast, the following traffic profile, which collects flow data for HTTP activity in either the 10.4.x.x network or the 192.168.x.x network, has three conditions, with the last constituting a complex condition.

Version 4.7


334


Chapter 10

Logically, the above traffic profile is evaluated as follows: (A and (B or C))

Where...

Is the condition that states...

A

Service Name is http

B

IP Address is in 10.4.0.0/16

C


To add a single condition: Access: Rules or Admin

h

To add a single condition, click Add condition above the current condition. A new condition is added to the same logical level as the current set of conditions. By default, it is linked to the conditions on its level with the OR operator, though you can change the operator to AND. For example, if you add a simple condition to the following host profile qualification:

The result is:

Version 4.7


335


Chapter 10

To add a complex condition: Access: Rules or Admin

h

Click Add complex condition above the current condition. A complex condition is added below the current set of conditions. The complex condition comprises two subconditions, which are linked to each other with the opposite operator from the one used to link the conditions on the level above it. For example, if you add a complex condition to the following host profile qualification:

The result is:

To link conditions: Access: Rules or Admin

h

Use the drop-down list to the left of a set of conditions.

•

To require that all conditions on the level that the operator controls are met, select AND.

•

To require that only one of the conditions on the level that the operator controls is met, select OR.

Using Multiple Values in a Condition Requires: DC + RNA

Version 4.7

When you are building a condition, and the condition syntax allows you to pick a value from a drop-down list, you can often use multiple values from the list. For example, if you want to add a host profile qualification to a traffic profile that requires that a host be running some flavor of UNIX, instead of constructing multiple conditions linked with the OR operator, use the following procedure.


336

Working with Flow Data and Traffic Profiles Viewing Traffic Profiles

Chapter 10

To include multiple values in one condition: Access: Rules or Admin

1.

Build a condition, choosing is in or is not in as the operator. The drop-down list changes to a text field.

2. Click anywhere in the text field or on the Edit link. A pop-up window appears.

3. Under Available, use Ctrl or Shift while clicking to select multiple values. You can also click and drag to select multiple adjacent values. 4. Click the right arrow (>) to move the selected entries to Selected. 5. Click OK. Your selections appear in the value field of your condition on the Create Profile page.

Viewing Traffic Profiles Requires: DC + RNA

Version 4.7

Because traffic profiles are based on flow data, you can view graphs of traffic profiles. The following graphic shows a traffic profile with a PTW of one week, a


337


Chapter 10

sampling rate of five minutes, and a daily half-hour inactive period from midnight to 12:30AM.

You can perform almost all the same actions on traffic profile graphs that you can perform on flow data graphs. However, because traffic profiles are based on aggregated data (flow summaries), you cannot examine the individual flow events on which the graphs are based. In other words, you cannot drill down to a flow data table view from a traffic profile graph. See Viewing Flow Data on page 299 for more information. In addition, traffic profiles appear as detached graphs. For more information, see Detaching Flow Data Graphs on page 318. In addition, traffic profile graphs plotted over time show the mean (average) y-axis value as a bold horizontal line. Graphs over time also plot the values of the first four standard deviations above and below the mean, assuming that network traffic is distributed normally. By default, these statistics are calculated over the PTW, but if you alter the time settings for a graph, the Defense Center recalculates the statistics. Rules written against traffic profile statistics, however, are always evaluated against the statistics for the PTW. To view a traffic profile graph for a traffic profile: Access: Rules or Admin

Version 4.7

1.



338


Chapter 10

2. Next to the traffic profile for which you want to view the graph, click Graph. The graph for the traffic profile appears in a separate browser window.

Version 4.7


339

Chapter 10

Using RNA as a Compliance Tool

A compliance white list (or white list) is a set of criteria that allows you to specify the operating systems, client applications, services, and protocols that are allowed to run on a specific subnet, and automatically generate an event if a host on the subnet violates the white list. For example, your security policy might state that while your web servers are allowed to run the HTTP service, none of the other hosts on your network are. You could create a white list that evaluates your entire network, excluding your web farm, to determine which hosts are running the HTTP service. Note that you could create a compliance rule that performs this function by configuring the rule so that it triggers when: •

RNA discovers new information about a service

•

the service name is http

•

the IP address of the host involved in the RNA event is not in your web farm

However, compliance rules, which provide you with a more flexible way of alerting you and responding to policy violations on your network, are more complex to configure and maintain than white lists. Compliance rules are also wider in scope, allowing you to generate a compliance event when any specific flow, intrusion, RNA, RUA, or host input event occurs and the event meets any criteria that you

Version 4.7


340

Using RNA as a Compliance Tool

Chapter 11

specify. On the other hand, white lists are specifically meant to help you evaluate the operating systems, client applications, services, and protocols that are running on your network and whether that violates your organization’s policies. You can create custom white lists that meet your specific needs, or you can use the default white list created by the Vulnerability Research Team (VRT) that contains recommended settings for allowed operating systems, client applications, services, and protocols. You may also want to customize the default white list for your network environment. If you add a white list to an active compliance policy, when RNA detects that a host is violating the white list, the Defense Center logs a white list event—which is a special kind of compliance event— to the database. Further, you can configure the Defense Center to trigger responses (remediations and alerts) automatically when it detects a white list violation. IMPORTANT! Although you can configure the RNA detection policy to add hosts and services to the network map based on data exported by NetFlow devices, the available information about these hosts and services is limited. For example, there is no operating system data available for these hosts, unless you provide it using the host input feature. This may affect the way you build compliance white lists. For more information, see What Information Does RNA Provide? on page 127. Because the Defense Center creates a host attribute for each host that indicates whether it is in compliance with any white lists you create, you can obtain an at-a-glance summary of the compliance of your network. In just a few seconds, you can determine exactly which hosts in your organization are running the HTTP service in violation of your policy, and take appropriate action. Then, using the policy and response feature, you can configure the Defense Center to alert you whenever a host that is not in your web farm starts running the HTTP service. In addition, the Sourcefire 3D System allows you to use host profiles to determine whether an individual host is violating any of the white lists you have configured, and in which way it is violating the white list. The Sourcefire 3D System also includes workflows that allow you to view each of the individual white list violations, as well as the number of violations per host. Finally, you can use the Status Dashboard to monitor recent system-wide compliance activity, including white list events and summary views of the overall white list compliance of your network. IMPORTANT! You must use a Defense Center to create compliance white lists and to view white list events. You cannot create white lists on a Master Defense Center, but you can view white list events forwarded from managed Defense Centers.

Version 4.7


341

Using RNA as a Compliance Tool Understanding Compliance White Lists

Chapter 11

For more information on creating and managing compliance white lists and on interpreting white list events and violations, see the following sections: •

Understanding Compliance White Lists on page 342

•

Creating Compliance White Lists on page 350

•

Managing Compliance White Lists on page 370

•

Working with Shared Host Profiles on page 371

•

Working with White List Events on page 378

•

Working with White List Violations on page 385

In addition, see the following chapters and sections for more information: •

Creating Compliance Policies on page 439 explains how to create and configure compliance policies that include compliance white lists, and explains how to assign responses and priorities to the white lists.

•

Using Host Profiles on page 172 explains how to use a host’s profile to determine whether it is violating any white lists.

•

Using the Status Dashboard on page 1413 explains how to obtain an at-a-glance view of your current system status, including white list compliance activity.

Understanding Compliance White Lists Requires: DC + RNA

A compliance white list is a set of criteria that specify the operating systems, client applications, services, and protocols that are allowed to run on your network. You can create custom white lists that meet your specific needs, or you can use the default white list created by the VRT that contains recommended settings. Custom white list criteria can be simple; you can specify that only hosts running a certain operating system are allowed. Your criteria can also be complex; you can specify that while all operating systems are allowed, only hosts running a certain operating system are allowed to run a certain service on a specific port. White lists comprise two main parts: targets and host profiles. The targets are the specific hosts that are evaluated by the white list, while the host profiles specify the operating systems, client applications, services, and protocols are allowed to run on the targets. After you create a white list and add it to an active compliance policy, the Defense Center evaluates the white list’s targets against its host profiles to determine whether the targets are in compliance with the white list. After this initial evaluation, the Defense Center generates a white list event when it detects that a valid target is violating the white list.

Version 4.7


342


Chapter 11


Understanding White List Targets on page 343 explains how white lists only target the hosts that you specify.

•

Understanding White List Host Profiles on page 344 explains the different kinds of profiles that describe which client applications, services, and protocols are allowed to run on your network.

•

Understanding White List Evaluations on page 348 explains how RNA evaluates the hosts on your network against white lists, and how you can tell which hosts are in compliance and which are not.

•

Understanding White List Violations on page 349 explains how RNA detects and the Defense Center notifies you of white list violations.

Understanding White List Targets Requires: DC + RNA

When you create a white list, you first specify the portions of your network it applies to. You can use a white list to evaluate all the hosts on your monitored network, or you can restrict the white list to evaluate only certain network segments or even individual IP addresses. You can further restrict the white list so that it evaluates only hosts that have a certain host attribute or that belong to a certain VLAN. A host that is eligible to be evaluated by a white list is called a valid target (or target). A valid target: •

must be in one of the IP address ranges you specify. You can also exclude ranges of IP addresses.

•

must have at least one of the host attributes you specify. For example, you could configure a white list to evaluate only hosts that have a high host criticality. For information on host attributes, including host criticality, see Working with User-Defined Host Attributes on page 202 and Assigning a Host Criticality Value to a Host on page 201.

•

must belong to one of the VLANs you specify.

If a host does not meet all of these criteria, it is not evaluated against the white list, regardless of whether its host profile is in violation of the white list. If your white list contains more than one target, a host must meet the criteria specified in only one of them to be considered valid. For example, if you create a target that includes the 10.5.x.x network and one that excludes the 10.5.x.x network, a host in that network is considered a valid target. Note that if your white list does not contain any targets, none of the hosts on your network will be evaluated against the white list. The targets for your white list are listed on left of the Create White List page. \

Version 4.7


343


Chapter 11

Note that the default white list uses a target of 0.0.0.0/0, which represents the entire monitored network. If you choose to use this white list, you can leave the target as-is or modify it to reflect your network environment. For information on creating white list targets, see Configuring Compliance White List Targets on page 355.

Understanding White List Host Profiles Requires: DC + RNA

Once you specify which targets the white list evaluates, the next step is to configure host profiles. Host profiles in a white list specify which operating systems, client applications, services, and protocols are allowed to run on the target hosts. There are three kinds of host profiles you can configure in a white list: global host profiles, host profiles for specific operating systems, and shared host profiles. Each type of host profile appears differently when you are creating a white list.

The Accessing Compliance White List Host Profiles table explains how to identify and access the different kinds of host profiles. Accessing Compliance White List Host Profiles To view...

Under Allowed Host Profiles, click...

the global host profile for the white list

Any Operating System

a host profile for a specific operating system

a host profile name that is listed in plain text rather than italics

a shared host profile used by the white list

a host profile name that is listed in italics

For more information, see the following sections:

Version 4.7

•

Understanding the Global Host Profile on page 345

•

Understanding Host Profiles for Specific Operating Systems on page 345

•

Understanding Shared Host Profiles on page 346


344


Chapter 11

Understanding the Global Host Profile Requires: DC + RNA

Every white list contains a global host profile, which specifies the services, client applications, and protocols that are allowed to run on target hosts, regardless of the host’s operating system.

For example, instead of editing multiple Microsoft Windows and Linux host profiles to allow NetBIOS services, you can configure the global host profile to allow the services regardless of the operating system on which they were detected. Note that the ARP, IP, TCP, and UDP protocols are always allowed to run on every host; you cannot disallow them. For more information, see Configuring the Global Host Profile on page 359.

Understanding Host Profiles for Specific Operating Systems Requires: DC + RNA

Version 4.7

You must create one host profile for each operating system you want to allow on your network. To disallow an operating system on your network, do not create a host profile for that operating system. For example, to make sure that all the


345


Chapter 11

hosts on your network are running Microsoft Windows, configure the white list to only contain host profiles for that operating system.

When you create a host profile for an operating system, you can also require that it have a particular version. For example, you could require that compliant hosts run Windows XP. After you create a host profile for a particular operating system, you can specify the services, client applications, and protocols that are allowed to run on target hosts running that operating system. For example, you could allow the SSH service to run on Linux hosts on port 22. You could also restrict the particular vendor and version of the service to OpenSSH 4.2. Note that unidentified hosts remain in compliance with all white lists until they are identified. You can, however, create a white list host profile for unknown hosts. IMPORTANT! Unidentified hosts are not the same as unknown hosts. Unidentified hosts are hosts about which RNA has not yet gathered enough information to identify their operating systems. Unknown hosts are hosts whose traffic has been analyzed by RNA, but whose operating systems do not match any of RNA’s known fingerprints. For more information, see Creating Host Profiles for Specific Operating Systems on page 359.

Understanding Shared Host Profiles Requires: DC + RNA

Version 4.7

Shared host profiles are tied to specific operating systems, but you can use each shared host profile in more than one white list. That is, if you create multiple


346


Chapter 11

white lists but want to use the same host profile to evaluate hosts running a particular operating system across the white lists, use a shared host profile.

For example, if you have offices worldwide and you want to create a separate white list for each location, but always want to use the same profile for all hosts running Apple Mac OS X, you can create a shared profile for that operating system and use it in all your white lists. The default white list represents recommended “best practices” settings for allowed operating systems, client applications, services, and protocols. This white list uses a special category of shared host profiles, called built-in host profiles.

Note that built-in host profiles are marked with the built-in host profile icon (

).

Built-in host profiles use built-in services, protocols, and client applications. You can use these elements as-is in both the default white list and in any custom white list that you create or you can modify them to suit your needs. They are displayed in italics within the built-in host profile and in any other host profile that uses them.

Version 4.7


347


Chapter 11

Keep in mind that like all shared host profiles, if you modify a built-in host profile, it affects every white list that uses it. Likewise, if you modify a built-in service, protocol, or client application, it affects every white list that uses it. For more information on shared host profiles, Working with Shared Host Profiles on page 371.

Understanding White List Evaluations Requires: DC + RNA

After you create white list host profiles and save the white list, you can add the white list to a compliance policy, just as you would a compliance rule. For more information, see Configuring Compliance Policies and Rules on page 392. Once you activate the compliance policy, the Defense Center evaluates the targets of the white list against the white list criteria.You can then use the host attributes network map to gain an overall view of the white list compliance of the hosts on your network.

Every host on the network is assigned a host attribute that has the same name as the white list. This host attribute has one of the following values: •

Compliant, for valid targets that are compliant with the white list

•

Non-Compliant, for valid targets that violate the white list

•

Not Evaluated, for invalid targets and hosts that have not yet been evaluated for any reason

Note that if your network is large and the Defense Center is in the process of evaluating all the valid targets in the network map against the white list, targets that have not yet been evaluated are marked as Not Evaluated. As the Defense Center completes its processing, more hosts move from Not Evaluated to either Compliant or Non-Compliant. The Defense Center can evaluate approximately 100 hosts per second. Additionally, a host may be marked as Not Evaluated if the Defense Center has insufficient information to determine whether the host is in compliance. For example, this may occur if RNA has detected a new host but has not yet gathered relevant information on the operating system, client applications, services, or protocols running on the host. IMPORTANT! If you change or delete a host attribute from a host and that change or deletion means that the host is no longer a valid target, the host changes from either Compliant or Non-Compliant to Not Evaluated.

Version 4.7


348


Chapter 11

For more information on host attributes, see Working with the Host Attributes Network Map on page 161.

Understanding White List Violations Requires: DC + RNA

After the initial white list evaluation, the Defense Center generates a white list event when it detects that a valid target is violating the white list. White list events are a special kind of compliance event, and are logged to the Defense Center compliance event database. You can view white list events in a workflow, or search for specific white list events. For more information, see Working with White List Events on page 378. White list violations occur when RNA generates an event that indicates that a host is out of compliance. Similarly, RNA events can indicate that a previously non-compliant host is now compliant, although the Defense Center does not generate a white list event when this occurs. The following RNA events can change the compliance of a host: •

RNA detects a change in a host’s operating system

•

RNA detects a new TCP service port (for example, a port used by SMTP or web services) active on a host, or a new UDP service running on a host

•

RNA detects a change in a discovered TCP or UDP service running on a host, for example, a version change due to an upgrade

•

RNA detects a new client application running on a host

•

RNA drops a client application from its database due to inactivity

•

RNA detects that a host is communicating with a new network protocol, such as Novell Netware or IPv6, or a new transport protocol, such as ICMP or EGP

•

RNA detects that a TCP or UDP port has closed or timed out on a host

In addition, you can trigger a compliance change for a host by using the host input feature or the host profile to: •

add a client application, protocol, or service to a host

•

delete a client application, protocol, or service from a host

•

set the operating system definition for a host

•

change a host attribute for a host so that the host is no longer a valid target

For example, if your white list specifies that only Microsoft Windows hosts are allowed on your network, and RNA detects that the host is now running Mac OS X, the Defense Center generates a white list event. In addition, the host attribute associated with the white list changes its value from Compliant to NonCompliant for that host.

Version 4.7


349

Using RNA as a Compliance Tool Creating Compliance White Lists

Chapter 11

For the host in this example to come back into compliance, one of the following must occur: •

you edit the white list so that the Mac OS X operating system is allowed

•

you manually change the operating system definition of the host to Microsoft Windows

•

RNA detects that the operating system has changed back to Microsoft Windows

In any case, the host attribute associated with the white list changes its value from Non-Compliant to Compliant for that host. As another example, if your compliance white list disallows the use of the AIM service, and you then delete the AIM service from the services network map or from a services event view, hosts running the AIM service become compliant. However, if RNA detects the service again, the Defense Center generates a white list event and the hosts become non-compliant. Note that if RNA generates an event that contains insufficient information for the white list, the white list does not trigger. For example, consider a scenario where your white list specifies that you allow only TCP FTP traffic on port 21. Then, RNA detects that port 21, using the TCP protocol, has become active on one of the white list targets, but RNA is unable to determine whether the traffic is FTP. In this scenario, the white list does not trigger until either RNA identifies the traffic as something other than FTP traffic or you use the host input feature to designate the traffic as non-FTP traffic. IMPORTANT! During the initial evaluation of a white list, the Defense Center does not generate white list events for non-compliant hosts. If you want to generate white list events for all non-compliant targets, you must purge the Defense Center database. This causes the hosts on your network and their associated client applications, services, and protocols to be rediscovered, which can trigger white list events. For more information, see Purging the RNA and RUA Databases on page 1232. Finally, you can configure the Defense Center to trigger responses automatically when it detects a white list violation. Responses include remediations (such as blocking a host at the firewall or router), alerts (email, SNMP, and syslog alerts), or combination of alerts and remediations. For more information, see Configuring Responses for Compliance Policies on page 456.

Creating Compliance White Lists Requires: DC + RNA

Version 4.7

When you create a white list, you can survey either your entire network or a specific network segment. Surveying the network populates the white list with one host profile for each operating system that RNA has detected on the network segment. By default, these host profiles allow all of the client applications,


350


Chapter 11

services and protocols that RNA has detected on the applicable operating systems. Then, you must specify the targets of the white list. You can configure a white list to evaluate all the hosts on your monitored network, or you can restrict the white list to evaluate only certain network segments or even individual IP addresses. You can further restrict the white list so that it evaluates only hosts that have a certain host attribute or that belong to a certain VLAN. If you surveyed your network, by default the network segment that you surveyed represents the white list targets. You can edit or delete the surveyed network, or you can add new targets. Next, create host profiles that represent compliant hosts. Host profiles in a white list specify which operating systems, client applications, services, and protocols are allowed to run on the target hosts. You can configure the global host profile, edit the host profiles created by any network survey your performed, as well as add new host profiles, and add and edit shared host profiles. Finally, save the white list and add it to an active compliance policy. The Defense Center begins evaluating the target hosts for compliance, generating white list events when a host violates the white list, and triggering any responses you have configured to white list violations. For a more detailed introduction to compliance white lists, see Understanding Compliance White Lists on page 342. TIP! You can also create a white list from a table view of hosts. For more information, see Creating a Compliance White List Based on Selected Hosts on page 238. To create a compliance white list: Access: Rules or Admin

1.

Select Policy & Response > Compliance > White List. The White List page appears.

2. Click New White List. The Survey Network page appears.

3. Optionally, survey your network.

Version 4.7

•

To survey your network, see Surveying Your Network on page 352.

•

To create a white list without surveying your network, continue with the next step.


351


Chapter 11

4. Specify the targets for the white list. You can edit or delete the targets created by a network survey as well as add new targets. Optionally, further restrict targets based on host attributes or VLAN ID. For more information, see Configuring Compliance White List Targets on page 355. 5. Create host profiles that represent compliant hosts. You can configure the global host profile, edit the host profiles created by a network survey, as well as add new host profiles and add and edit shared host profiles. For more information, see Configuring Compliance White List Host Profiles on page 358. 6. Click Save White List to save your white list. The white list is saved. You can now add it to an active compliance policy to begin evaluating the target hosts for compliance, generating white list events when a host violated the white list, and, optionally triggering responses to white list violations. For more information, see Creating Compliance Policies on page 439.

Surveying Your Network Requires: DC + RNA

When you begin creating a compliance white list, you can survey either your entire network or a specific network segment. Surveying your network gathers data from the RNA database about the services, client applications, and protocols running on the different detected operating systems. Then, the Defense Center creates one host profile within the white list for each detected operating system. By default, these host profiles allow all of the detected client applications, services and protocols that RNA has detected on each applicable operating systems. This creates a baseline white list so that you do not have to manually create and configure multiple host profiles. After you survey your network, you can then edit or delete the host profiles that the survey created to suit your needs, and also you can add any other host profiles you might need. Note that you can survey your network at any time during the white list creation process. This can add additional allowed client applications, services, and protocols to the host profiles that already exist, and can create additional host profiles if the survey detects hosts running operating systems that were not detected during the initial survey. If you resurvey your network within a white list that is used within an active compliance policy, and the survey changes either your targets or host profiles, when you save the white list the target hosts are re-evaluated. Although this re-evaluation may bring some hosts into compliance, it does not generate any white list events. To begin creating a compliance white list by surveying your network:


Version 4.7

1.



352


Chapter 11

2. Click New White List. The Survey Network page appears.

3. Do you want to survey your network? •

If yes, continue with the next step.

•

If no, click Skip. The Create White List page appears and displays a blank white list. Continue with the procedure in the next section, Providing Basic White List Information.

4. In the IP Address and Netmask fields, enter the IP address and network mask (in CIDR notation) that represents the IP addresses you want to survey. Make sure that you specify a network that you configured RNA to monitor in Configuring RNA Detection Policies on page 134. For more information about using netmasks, see Specifying IP Addresses in Searches on page 1130. TIP! To survey the entire monitored network use the default value of 0.0.0.0/0.

Version 4.7


353


Chapter 11

5. Click OK. The Create White List page appears.

The white list is pre-populated; its targets are the hosts in the network you surveyed and its allowed host profiles are those of the targets. 6. To survey additional networks, click Survey Network and repeat steps 4 and 5 for each additional network you want to survey. Surveying an additional network can add additional allowed client applications, services, and protocols to the host profiles that already exist, and can create additional host profiles if the survey detects hosts running operating systems that were not detected during the initial survey. Surveying an additional network also adds a target to the white list that represents the hosts in the network segment that you surveyed. You can then edit or delete this target. 7.

Continue with Providing Basic White List Information.

Providing Basic White List Information Requires: DC + RNA

You must give each white list a name, and, optionally, short description.

To provide basic white list information: Access: Rules or Admin

Version 4.7

1.

In the Name field, type a name for the new white list.

2. In the Description field, type a short description of the white list.


354


Chapter 11

3. Continue with Configuring Compliance White List Targets.

Configuring Compliance White List Targets Requires: DC + RNA

When you create a compliance white list, you must specify the portions of your network it applies to. You can use a white list to evaluate all the hosts on your monitored network, or you can restrict the white list to evaluate only certain network segments or even individual IP addresses. You can further restrict the white list so that it evaluates only hosts that have a certain host attribute or that belong to a certain VLAN. A host that is eligible to be evaluated by a white list is called a target. For a more detailed introduction to white list targets, see Understanding White List Targets on page 343. When you are finished creating compliance white list targets, continue with Configuring Compliance White List Host Profiles on page 358. IMPORTANT! If you change or delete a host attribute from a host and that modification means that the host is no longer a valid target, the host is no longer evaluated by the white list and is considered neither compliant nor non-compliant. For information on how to create, modify, and delete targets, see: •

Creating a Target on page 355

•

Modifying Existing Targets on page 357

•

Deleting Existing Targets on page 358

Creating a Target Requires: DC + RNA

When you create a target for a compliance white list, you specify the criteria a host must meet to be evaluated against the white list. A valid target: •

must be in one of the IP address ranges you specify. You can also exclude ranges of IP addresses.

•

must have at least one of the host attributes you specify.

•

must belong to one of the VLANs you specify.

Note that if you add a target to a white list that is used by an active compliance policy, once you save the white list, the new target hosts are evaluated for compliance. However, this evaluation does not generate white list events.

Version 4.7


355


Chapter 11

To create a compliance white list target: Access: Rules or Admin

1.

On the Create White List Page, next to Targets, click the Add icon (

).

The settings for the new target appear.

TIP! You can also create a new target by surveying a network segment. On the Create White List page, click Survey Network, then follow steps 4 and 5 in Surveying Your Network on page 352. The new target is created and is named according to the IP addresses you specified. Click the target you just created and continue with the rest of this procedure to rename the target, add or exclude additional networks, and add host attribute or VLAN restrictions. 2. In the Name field, type a name for the new target. 3. Target a specific set of IP addresses by clicking Add next to Targeted Networks.

4. In the IP Address and Netmask fields, enter the IP address and network mask (as in CIDR notation) that represents the IP addresses you want to target or exclude from targeting. Make sure that you specify a network that you configured RNA to monitor in Configuring RNA Detection Policies on page 134. For more information about using netmasks, see Specifying IP Addresses in Searches on page 1130. TIP! To target the entire monitored network, use 0.0.0.0/0. 5. If you want to exclude the network from monitoring, select Exclude. 6. To add additional networks, repeat steps 4 and 5.

Version 4.7


356


7.

Chapter 11

Target hosts that have a specific host attribute by clicking Add next to Targeted Host Attributes.

8. From the Attribute and Value drop-down lists, specify the host attribute. 9. To add additional host attributes, repeat steps 7 and 8. A host must have at least one of the host attributes you specify to be evaluated against the white list. 10. Target hosts that belong to a specific VLAN by clicking Add next to Targeted VLANs.

11. In the VLAN ID field, specify the VLAN IDs of the hosts you want to evaluate against the white list. This can be any integer between 0-4095 for 802.1q VLANs. 12. To add additional VLAN IDs, repeat steps 10 and 11. The host must be a member of one of the VLANs you specify to be evaluated against the white list. TIP! To remove a network, host attribute restriction, or VLAN restriction, click the Delete icon ( ) next to the element you want to delete.

Modifying Existing Targets Requires: DC + RNA

After you modify a target, you must save the white list for your changes to take effect. Note that if you modify a target in a white list that is used by an active compliance policy, after you save the white list, any new target hosts are evaluated for compliance. However, this evaluation does not generate white list events. In addition, the Defense Center changes the white list host attribute of previously valid targets to Not Evaluated. To modify an existing target:


1.

On the Create White List page, under Targets, click the target you want to modify. The settings for the target appear.

2. Make changes as needed. You can rename the target, add or exclude additional networks, and add host attribute or VLAN restrictions. For more information, see Creating a Target on page 355.

Version 4.7


357


Chapter 11

Deleting Existing Targets Requires: DC + RNA

After you delete a target, you must save the white list for your changes to take effect. Note that if you delete a target from a white list that is used by an active compliance policy, the Defense Center changes the white list host attribute of previously valid targets to Not Evaluated. To delete a white list target:


1.

Next to the target you want to delete, click the Delete icon (

).

2. At the prompt, confirm that you want to delete the target. The target is deleted.

Configuring Compliance White List Host Profiles Requires: DC + RNA

Host profiles in a compliance white list specify which operating systems, client applications, services, and protocols are allowed to run on the target hosts. There are three kinds of host profiles you can configure in a white list: •

global host profiles, which specify the services, client applications, and protocols that are allowed to run on target hosts, regardless of the host’s operating system

•

host profiles for specific operating systems, which specify not only which operating systems are allowed to run on your network, but also the services, client applications, and protocols that are allowed to run on those operating systems

•

shared host profiles, which function exactly like the host profiles for specific operating systems, except they are not tied to a single white list; you can use them across multiple white lists

For a more detailed introduction to compliance white list host profiles, see Understanding White List Host Profiles on page 344. When you are finished creating compliance white list host profiles, you can add the white list to an active compliance policy to begin evaluating the target hosts for compliance, generating white list events when a host violated the white list, and, optionally triggering responses to white list violations. For information on how to create, modify, and delete compliance white list host profiles, see:

Version 4.7

•

Configuring the Global Host Profile on page 359

•

Creating Host Profiles for Specific Operating Systems on page 359

•

Adding a Shared Host Profile to a Compliance White List on page 366

•

Modifying Existing Host Profiles on page 367

•

Deleting Existing Host Profiles on page 369


358


Chapter 11

Configuring the Global Host Profile Requires: DC + RNA

Every white list contains a global host profile, which specifies the services, client applications, and protocols that are allowed to run on target hosts, regardless of the host’s operating system. For a more detailed introduction to the global host profile, see Understanding the Global Host Profile on page 345. To configure the global host profile:


1.

On the Create White List page, under Allowed Host Profiles, click Any Operating System. The settings for the global host profile appear.

2. To specify the services you want to allow, follow the directions in Adding a Service to a Host Profile on page 361. 3. To specify the client applications you want to allow, follow the directions in Adding a Client Application to a Host Profile on page 362. 4. To specify the protocols you want to allow, follow the directions in Adding a Protocol to a Host Profile on page 364. Note that ARP, IP, TCP, and UDP are always allowed.

Creating Host Profiles for Specific Operating Systems Requires: DC + RNA

Version 4.7

Host profiles for specific operating systems indicate not only which operating systems are allowed to run on your network, but also the services, client applications, and protocols that are allowed to run on those operating systems. For a more detailed introduction, see Understanding Host Profiles for Specific Operating Systems on page 345.


359


Chapter 11

To create a new compliance white list host profile for a specific OS: Access: Rules or Admin

1.

Next to Allowed Host Profiles, click the Add icon (

).

The settings for the new host profile appear.

2. In the Name field, type a descriptive name for the host profile. 3. From the OS Vendor, OS Name, and Version drop-down lists, pick the operating system and version for which you want to create a host profile. 4. Specify the services you want to allow. You have three options: •

To allow all services, leave the Allow all Services check box selected.

•

To allow no services, clear the Allow all Services check box.

•

To allow specific services, follow the directions in Adding a Service to a Host Profile on page 361.

5. Specify the client applications you want to allow. You have three options: •

To allow all applications, leave the Allow all Client Applications check box selected.

•

To allow no applications, clear the Allow all Client Applications check box.

•

To allow specific applications, follow the directions in Adding a Client Application to a Host Profile on page 362.

6. Specify the protocols you want to allow. To add a protocol, next to Allowed Protocols, follow the directions in Adding a Protocol to a Host Profile on page 364. Note that ARP, IP, TCP, and UDP are always allowed.

Version 4.7


360


Chapter 11

Adding a Service to a Host Profile Requires: DC + RNA

You can configure a compliance white list, using either a shared host profile or a host profile that belongs to a single white list, to allow certain services to run on specific operating systems. You can also configure a white list to allow certain services to run on any valid target; these are called globally allowed services. For any allowed service, you can either specify the type of service that you want to allow—aim, ftp, and ssh are examples of service types—or you can allow a custom service by specifying a service type of any. You must also specify the protocol the allowed service uses (TCP or UDP). You can allow the service on any port, or restrict it to a port that you specify. Optionally, you can require that the service have a specific vendor or version. For example, you could allow the SSH service to run on Linux hosts on port 22. You could also restrict the particular vendor and version of the service to OpenSSH 4.2. To add a service to a compliance white list host profile:


1.

While you are creating or modifying a white list host profile, click Add next to Allowed Services (or next to Globally Allowed Services if you are modifying the Any Operating System host profile). A pop-up window appears. The services listed are:

Version 4.7

•

services that you created within the white list

•

services that existed in the network map when you surveyed your networks as described in Surveying Your Network on page 352

•

services that are used by other host profiles in the white list, which may include built-in services created by the VRT for use in the default white list


361


Chapter 11


To add a service already in the list, select it and click OK. Use Ctrl or Shift while clicking to select multiple services. You can also click and drag to select multiple adjacent services. The service is added. Note that if you added a built-in service, its name appears in italics. You can skip the rest of the procedure, or optionally, to change any of the service’s values (such as the port or protocol), click the service you just added to display the service editor.

•

To add a new service, select and click OK. The service editor appears.

3. From the Type drop-down list, select the service type. For custom services, select any. 4. Specify the service port. You have two options: •

To allow the service to run on any port, check the Any port check box.

•

To allow the service to run only on a specific port, type the port number in the port field.

5. From the Protocol drop-down list, select the service protocol: TCP or UDP. 6. Optionally, in the Vendor and Version fields, specify a vendor and version for the service. If you do not specify a vendor or version, the white list allows all vendors and versions as long as the type and protocol match. Note that if you restrict the vendor and version, you must make sure to specify them exactly as they would appear in a table view of services or in the services network map. 7.

Click OK. The service is added. Note that you must save the white list for your changes to take effect. If you added a service to a white list that is used by an active compliance policy, after you save the white list, the target hosts are re-evaluated. Although this re-evaluation may bring some hosts into compliance, it does not generate any white list events.

Adding a Client Application to a Host Profile Requires: DC + RNA

Version 4.7

You can configure a compliance white list, using either a shared host profile or a host profile that belongs to a single white list, to allow certain client applications


362


Chapter 11

to run on specific operating systems. You can also configure a white list to allow certain applications to run on any valid target; these are called globally allowed client applications. For any allowed client application, you must specify the name of the application as well as its type; HTTP Browser and AIM client are examples of application types. Optionally, you can require that the application be a specific version. For example, you could allow only Microsoft Internet Explorer 6.0 to run on Microsoft Windows hosts. To add a client application to a compliance white list host profile: Access: Rules or Admin

1.

While you are creating or modifying a white list host profile, click Add next to Allowed Client Applications (or next to Globally Allowed Client Applications if you are modifying the Any Operating System host profile). A pop-up window appears. The client applications listed are: •

client applications that you created within the white list

•

client applications that were running on hosts in the network map when you surveyed your networks as described in Surveying Your Network on page 352

•

client applications that are used by other host profiles in the white list, which may include built-in client applications created by the VRT for use in the default white list


To add a client application already in the list, select it and click OK. Use Ctrl or Shift while clicking to select multiple applications. You can also click and drag to select multiple adjacent applications. The client application is added. Note that if you added a built-in client application, its name appears in italics. You can skip the rest of the procedure, or optionally, to change any of the application’s values (such as its version), click the application you just added to display the application editor.

Version 4.7


363


•

Chapter 11

To add a new client application, select and click OK. The client application editor appears.

3. From the Application Type and Application drop-down lists, select the client application type and name. 4. Optionally, in the Version fields, specify a version for the client application. If you do not specify a version, the white list allows all versions as long as the type and name match. Note that if you restrict the version, you must specify it exactly as it would appear in a table view of client applications. 5. Click OK. The client application is added. Note that you must save the white list for your changes to take effect. If you added an application to a white list that is used by an active compliance policy, after you save the white list, the target hosts are re-evaluated. Although this re-evaluation may bring some hosts into compliance, it does not generate any white list events.

Adding a Protocol to a Host Profile Requires: DC + RNA

You can configure a compliance white list, using either a shared host profile or a host profile that belongs to a single white list, to allow certain protocols to run on specific operating systems. You can also configure a white list to allow certain protocols to run on any valid target; these are called globally allowed protocols. Note that ARP, IP, TCP, and UDP are always allowed to run on any host; you cannot disallow them. For any allowed protocol, you must specify its type (Network or Transport) and number.

Version 4.7


364


Chapter 11

To add a protocol to a compliance white list host profile: Access: Rules or Admin

1.

While you are creating or modifying a white list host profile, click Add next to Allowed Protocols (or next to Globally Allowed Protocols if you are modifying the Any Operating System host profile). A pop-up window appears. The protocols listed are: •

protocols that you created within the white list

•

protocols that were running on hosts in the network map when you surveyed your networks as described in Surveying Your Network on page 352

•

protocols that are used by other host profiles in the white list, which may include built-in protocols created by the VRT for use in the default white list


To add a protocol already in the list, select it and click OK. Use Ctrl or Shift while clicking to select multiple protocols. You can also click and drag to select multiple adjacent protocols. The protocol is added. Note that if you added a built-in protocol, its name appears in italics. You can skip the rest of the procedure, or optionally, to change any of the protocol’s values (such as the type or number) click the protocol you just added to display the protocol editor.

•

To add a new protocol, select and click OK. The protocol editor appears.

3. From the Type drop-down list, select the protocol type: Network or Transport.

Version 4.7


365


Chapter 11

4. Specify the protocol. You have two options: •

Select a protocol from the drop-down list.

•

Select Other (manual entry) to specify a protocol that is not in the list. For network protocols, type the appropriate number as listed in http://www.iana.org/assignments/ethernet-numbers/. For transport protocols, type the appropriate number as listed in http://www.iana.org/assignments/protocol-numbers/.

5. Click OK. The protocol is added. Note that you must save the white list for your changes to take effect. If you added a protocol to a white list that is used by an active compliance policy, after you save the white list, the target hosts are re-evaluated. Although this re-evaluation may bring some hosts into compliance, it does not generate any white list events.

Adding a Shared Host Profile to a Compliance White List Requires: DC + RNA

Shared host profiles are also tied to specific operating systems, but you can use them across white lists. That is, if you create multiple white lists but want to use the same host profile to evaluate hosts running a particular operating system across the white lists, use a shared host profile. You can add any of the built-in shared host profiles to your compliance white lists, or you can add shared host profiles that you created. For more information, see Understanding Shared Host Profiles on page 346 and Creating Shared Host Profiles on page 371. To add a shared host profile to a compliance white list:


1.

On the Create White List page, click Add Shared Host Profile. The Add Shared Host Profile page appears.

2. From the Name drop-down list, select the shared host profile you want to add to your white list, and click OK. The shared host profile is added to your white list and the Create White List page appears again. The shared host profile’s name appears in italics under Allowed Host Profiles. TIP! You can edit a shared host profile from within a white list that uses it by clicking on the profile name under Allowed Host Profiles. For more information, see Modifying Existing Host Profiles on page 367.

Version 4.7


366


Chapter 11

Modifying Existing Host Profiles Requires: DC + RNA

After you modify a host profile within a compliance white list, you must save the white list for your changes to take effect. If a host profile you modify belongs to a white list used in an active compliance policy, modifying the profile may bring hosts into or out of compliance but does not generate white list events. Further, modifying a shared host profile affects every white list that uses it. This may bring hosts into or out of compliance not only in the white list you are working with, but in other white lists as well. TIP! As with other shared host profiles, you can edit the built-in host profiles used by the default white list. You can also reset them to their factory defaults. For more information, see Resetting Built-In Host Profiles to Their Factory Defaults on page 377. To modify an existing host profile:


1.

On the Create White List page, click the name of the host profile you want to modify. The settings for the host profile appear. Note that if you are editing a shared host profile, an Edit link appears next to the name of the host profile. If you are editing a built-in host profile, the built-in host profile icon ( ) also appears.

Version 4.7


367


Chapter 11

2. You have two options: If you are modifying a shared host profile, click Edit.

•

A pop-up window appears. Make changes as needed as described in the table below. Click Save All Profiles to save the profile, then click Done to close the pop-up window. For more information editing shared host profiles, see Modifying a Shared Host Profile on page 373. If you are modifying either the white list’s global host profile or a host profile for a specific operating system, perform one of the actions described in the table below.

•

Version 4.7

To...

You can...

rename the host profile

type a new name in the Name field.

change the operating system for the host profile

select the new operating system and version from the OS Vendor, OS Name, and Version drop-down lists. If you change these values, you may also want to rename the host profile. Note that a white list’s global host profile has no operating system associated with it, so you cannot change it.

add a service

follow the directions in Adding a Service to a Host Profile on page 361.

add a client application

follow the directions in Adding a Client Application to a Host Profile on page 362.

add a protocol

follow the directions in Adding a Protocol to a Host Profile on page 364.

allow all services

under Allowed Services, select the Allow all Services check box. Note that the check box does not appear until you delete any services you have previously allowed.

allow all client applications

under Allowed Client Applications, select the Allow all Client Applications check box. Note that the check box does not appear until you delete any services you have previously allowed.


368


Chapter 11

To...

You can...

modify a service, client application, or protocol

click the element you want to modify. For more information on the properties you can change, see: • Adding a Service to a Host Profile on page 361 • Adding a Client Application to a Host Profile on page 362 • Adding a Protocol to a Host Profile on page 364 IMPORTANT! The changes you make to a service, client application, or protocol are reflected in every host profile that uses that element.

delete a service, client application, or protocol

next to the element you want to delete, click Delete.

survey your network

click Survey Network. Surveying your network can add additional allowed client applications, services, and protocols to the host profiles that already exist, and can create additional host profiles if the survey detects hosts running operating systems that were not detected during any initial survey. For more information, see Surveying Your Network on page 352.

Deleting Existing Host Profiles Requires: DC + RNA

After you delete a host profile from a compliance white list, you must save the white list for your changes to take effect. Note that deleting a shared host profile removes it from the white list, but does not delete the profile or remove it from any other white lists that use it. You cannot delete a white list’s global host profile. If the host profile you delete belongs to one or more white lists used in an active compliance policy, deleting the profile may force hosts out of compliance, but does not generate white list events. To delete a compliance white list host profile:


1.

On the Create White List page, next to the host profile you want to delete, click the Delete icon ( ).

2. At the prompt, confirm that you want to delete the host profile. The host profile is deleted.

Version 4.7


369

Using RNA as a Compliance Tool Managing Compliance White Lists

Chapter 11

Managing Compliance White Lists Requires: DC + RNA

Use the White List page to manage compliance white lists. You can create, modify, and delete white lists, including the default white list. You can also edit any shared host profiles you have created, as well as the built-in shared host profiles, and add new shared host profiles.



•

Modifying a Compliance White List on page 370

•

Deleting a Compliance White List on page 370

•

Working with Shared Host Profiles on page 371

Modifying a Compliance White List Requires: DC + RNA

When you modify a compliance white list that is included in an active compliance policy, the Defense Center re-evaluates the target hosts. Note that the Defense Center does not generate white list events—and therefore does not trigger any responses you associated with the white list—during this re-evaluation, even if the white list is included in an active compliance policy and a previously compliant host becomes non-compliant with the updated white list. To modify an existing compliance white list:


1.


2. Next to the white list you want to modify, click Edit. The Create White List page appears. 3. Make modifications as necessary and click Save White List. The white list is updated.

Deleting a Compliance White List Requires: DC + RNA

You cannot delete a compliance white list that you are using in one or more compliance policies; you must first delete the white list from all policies where it is used. For information on deleting a white list from a policy, see Modifying a Compliance Policy on page 446. Deleting a white list also removes the host attribute associated with the white list from all hosts on your network.

Version 4.7


370

Using RNA as a Compliance Tool Working with Shared Host Profiles

Chapter 11

To delete an existing compliance white list: Access: Rules or Admin

1.


2. Next to the white list you want to delete, click Delete. The white list is deleted.

Working with Shared Host Profiles Requires: DC + RNA

Shared host profiles specify which operating systems, client applications, services, and protocols are allowed to run on target hosts across multiple white lists. That is, if you create multiple white lists but want to use the same host profile to evaluate hosts running a particular operating system across the white lists, use a shared host profile. Note that the default white list uses a special category of shared host profiles, called built-in host profiles. For a more detailed introduction to shared host profiles, see Understanding Shared Host Profiles on page 346. You can create, modify, and delete shared host profiles. In addition, if you modify or delete any of the built-in shared host profiles, or modify or delete any of the built-in services, protocols, or client applications, you can reset them to their factory defaults. For more information, see: •

Creating Shared Host Profiles on page 371

•

Modifying a Shared Host Profile on page 373

•

Deleting a Shared Host Profile on page 377

•

Resetting Built-In Host Profiles to Their Factory Defaults on page 377

After you create a shared host profile, you can add it to multiple white lists. For more information, see Adding a Shared Host Profile to a Compliance White List on page 366.

Creating Shared Host Profiles Requires: DC + RNA

Create a shared host profile if you want to use the same host profile to evaluate hosts running a particular operating system across multiple white lists. TIP! You can also create a shared host profile for your compliance white lists using the host profile of a specific host. For more information, see Creating a White List Host Profile from a Host Profile on page 185. To create a shared host profile:


Version 4.7

1.



371


Chapter 11

2. Click Edit Shared Profiles. The Edit Shared Profiles page appears.

3. Optionally, survey your network. Surveying your network creates several baseline shared white lists based on the data RNA has accumulated about your network. This saves you from manually creating and configuring multiple shared host profiles. •

To survey your network, click Survey Network. For more information, see Surveying Your Network on page 352. RNA creates one or more baseline shared host profiles. You can edit or delete these shared host profiles as described in Modifying a Shared Host Profile on page 373 and Deleting a Shared Host Profile on page 377. To add any other shared host profiles you might need, continue with the next step.

•

To skip surveying you network, continue with the next step.

4. Next to Shared Host Profiles, click the Add icon (

).

The settings for the new shared host profile appear.

5. In the Name field, type a descriptive name for the shared host profile. 6. From the OS Vendor, OS Name, and Version drop-down lists, pick the operating system and version for which you want to create a shared host profile.

Version 4.7


372


7.

Chapter 11

Specify the services you want to allow. You have three options: •

To allow all services, select the Allow all Services check box.

•

To allow no services, leave the Allow all Services check box cleared.

•

To allow specific services, next to Allowed Services, follow the directions in Adding a Service to a Host Profile on page 361.

8. Specify the client applications you want to allow. You have three options: •

To allow all applications, select the Allow all Client Applications check box.

•

To allow no applications, leave the Allow all Client Applications check box cleared.

•

To allow specific applications, follow the directions in Adding a Client Application to a Host Profile on page 362.

9. Specify the protocols you want to allow. To add a protocol, next to Allowed Protocols, follow the directions in Adding a Protocol to a Host Profile on page 364. Note that ARP, IP, TCP, and UDP are always allowed. 10. Click Save all Profiles to save your changes. The shared host profile is created. You can now add the shared host profile to any compliance white list.

Modifying a Shared Host Profile Requires: DC + RNA

Modifying a shared host profile changes the profile for all the white lists it belongs to. For the white lists that use the shared host profile and are also used in an active compliance policy, modifying a shared host profile may bring hosts into or out of compliance, but does not generate white list events. To modify a shared host profile:


Version 4.7

1.



373


Chapter 11

2. Click Edit Shared Profiles. The Edit Shared Profiles page appears.

3. Do you want to edit one of the built-in shared host profiles? •

If yes, expand Built-in Host Profiles to display those host profiles.

•

If no, continue with the next step.

.

Version 4.7


374


Chapter 11

4. Click the name of the shared host profile you want to modify. The host profile appears.

5. Perform any of the actions described in the table below.

Version 4.7

To...

You can...

rename the host profile

type a new name in the Name field.

change the operating system

select the new operating system and version from the OS Vendor, OS Name, and Version drop-down lists. If you change these values, you may also want to rename the host profile.

add a service

follow the directions in Adding a Service to a Host Profile on page 361.

add a client application

follow the directions in Adding a Client Application to a Host Profile on page 362.

add a protocol

follow the directions in Adding a Protocol to a Host Profile on page 364.

allow all services

under Allowed Services, select the Allow all Services check box. Note that the check box does not appear until you delete any services you have previously allowed.


375


Chapter 11

To...

You can...

allow all client applications

under Allowed Client Applications, select the Allow all Client Applications check box. Note that the check box does not appear until you delete any services you have previously allowed.

modify a service, client application, or protocol

click the element you want to modify. For more information on the properties you can change, see: • Adding a Service to a Host Profile on page 361 • Adding a Client Application to a Host Profile on page 362 • Adding a Protocol to a Host Profile on page 364 IMPORTANT! The changes you make to a service, client application, or protocol are reflected in every host profile that uses that element.

delete a service, client application, or protocol

next to the element you want to delete, click Delete.

survey your network

click Survey Network. Surveying your network can add additional allowed client applications, services, and protocols to the host profiles that already exist, and can create additional host profiles if the survey detects hosts running operating systems that were not detected during any initial survey. For more information, see Surveying Your Network on page 352.

6. Click Save all Profiles to save your changes. The shared host profile is deleted and removed from all compliance white lists that use it.

Version 4.7


376


Chapter 11

Deleting a Shared Host Profile Requires: DC + RNA

If the shared host profile you delete belongs to one or more white lists used in an active compliance policy, deleting the profile may force hosts out of compliance, but does not generate white list events. TIP! If you delete a built-in shared host profile that is used by the default white list, you can restore it by resetting the built-in profiles to their factory defaults. For more information, see Resetting Built-In Host Profiles to Their Factory Defaults on page 377. To delete a shared host profile:


1.


2. Click Edit Shared Profiles. The Edit Shared Profiles page appears. 3. Do you want to delete one of the built-in shared host profiles? •

If yes, expand Built-in Host Profiles to display those host profiles.

•

If no, continue with the next step.

4. Next to the shared host profile you want to delete, click the Delete icon (

).

Confirm that you want to delete the shared host profile. 5. Click Save all Profiles to save your changes. The shared host profile is deleted and removed from all compliance white lists that use it.

Resetting Built-In Host Profiles to Their Factory Defaults Requires: DC + RNA

Version 4.7

The default white list uses a special category of shared host profiles, called builtin host profiles. Built-in host profiles use built-in services, protocols, and client applications. You can use any these elements as-is in both the default white list and in any custom white list that you create, or you can modify them to suit your needs. For more information, see Understanding Shared Host Profiles,.


377

Using RNA as a Compliance Tool Working with White List Events

Chapter 11

If you make changes to the built-in profiles, services, protocols, or client applications that you need to undo, you can reset to factory defaults. When you reset to factory defaults, the following things occur: •

All built-in host profiles, services, protocols, and client applications that you modified are reset to their factory defaults.

•

All built-in host profiles, services, protocols, and client applications that you deleted are restored.

•

All white lists (including the default white list) that are used by active compliance policies and that used any of the reset built-in host profiles, services, protocols, or client applications are re-evaluated. Although this re-evaluation may change the compliance of some hosts into compliance, it does not generate any white list events.

To reset built-in host profiles, services, protocols, and client applications: Access: Rules or Admin

1.


2. Click Edit Shared Profiles. The Edit Shared Profiles page appears. 3. Click Built-in Host Profiles. The Built-in Host Profiles page appears.

4. Click Reset to Factory Defaults. 5. Confirm that you want to reset to factory defaults by clicking OK. All built-in host profiles, services, protocols, and client applications are reset to factory defaults. Any white list that is used by an active compliance policy and that used any of the reset built-in host profiles, services, protocols, or client applications is re-evaluated.

Working with White List Events Requires: DC/MDC + RNA

Version 4.7

When RNA generates an RNA event that indicates that a host is out of compliance with a white list that is included in an activated compliance policy, a white list event is generated. White list events are a special kind of compliance event, and are logged to the compliance event database. You can search, view, and delete white list events. If you are using the Event Streamer to stream


378


Chapter 11

compliance events (which include white list events) to RNA Visualizer, RNA Visualizer can report compliance policy violations. TIP! For information on configuring the number of events saved in the database, see Configuring Database Event Limits on page 1197. Note that white list events are stored in the compliance event database. For more information, see the following sections: •

Viewing White List Events on page 379

•

Understanding the White List Events Table on page 381

•

Searching for Compliance White List Events on page 382

Viewing White List Events Requires: DC/MDC + RNA

You can use the Defense Center to view a table of compliance white list events. Then, you can manipulate the event view depending on the information you are looking for. The page you see when you access white list events differs depending on the workflow you use. You can use the predefined workflow, which includes the table view of white list events. You can also create a custom workflow that displays only the information that matches your specific needs. For information on creating a custom workflow, see Creating Custom Workflows on page 1179. The Compliance White List Event Actions table below describes some of the specific actions you can perform on an white list events workflow page.

Compliance White List Event Actions To...

You can...





) that appears next to the IP address.

)that appears next to the user identity. For more

information, see Understanding User Details and Host History on page 1091. sort and constrain events on the current workflow page




Version 4.7


379


Chapter 11

Compliance White List Event Actions (Continued) To...

You can...



learn more about the columns that appear

find more information in Understanding the White List Events Table on page 381.


find more information in see Setting Event Time Constraints on page 1169.



delete white list events from the system

use one of the following methods: • To delete some events, select the check boxes next to the events you want to delete, then click Delete. • To delete all events in the current constrained view, click Delete All, then confirm you want to delete all the events. See Purging the RNA and RUA Databases on page 1232 for information on deleting all RNA events from the database.











search for white list events

click Search. For more information, see Searching for Compliance White List Events on page 382.

Version 4.7


380


Chapter 11

To view compliance white list events: Access: Data or Admin

h

Select Analysis & Reporting > Compliance > White List Events. The first page of your preferred white list events workflow appears. If you created a custom white list events workflow and did not specify a default, you must first select one. For information on specifying a default workflow, see Setting Event Preferences on page 35. If no events appear, you may need to adjust the time range. See Setting Event Time Constraints on page 1169 for more information.

Understanding the White List Events Table Requires: DC/MDC + RNA

You can use the compliance policy feature to build compliance policies that let your Defense Center respond in real time to threats on your network. Compliance policies describe the type of activity that constitutes a policy violation, which include compliance white list violations. For more information on compliance policies, see Configuring Compliance Policies and Rules on page 392. When a compliance white list is violated, the Defense Center generates a white list event. The fields in the white list events table are described in the Compliance White List Event Fields table. Compliance White List Event Fields

Version 4.7

Field

Description

Time

The date and time that the white list event was generated.

IP Address

The IP address of the non-compliant host.

User

The identity of any known user logged in to the non-compliant host.

Port

The port, if any, associated with the event that triggered the white list violation.


381


Chapter 11

Compliance White List Event Fields (Continued) Field

Description

Description

A description of how the white list was violated. For example: Client Application “AOL Instant Messenger” is not allowed.

Violations that involve a service indicate the service name and version, as well as the port and protocol (TCP or UDP) it is using. If you restrict prohibitions to a particular operating system, the description includes the operating system name. For example: Service "ssh / 22 TCP ( OpenSSH 3.6.1p2 )" is not allowed on Operating System “Linux Linux 2.4 or 2.6”.

Policy

The name of the compliance policy that was violated, that is, the compliance policy that includes the white list.

White List

The name of the white list.

Priority

The priority specified by the policy or white list that triggered the policy violation. For information on setting compliance rule and policy priorities, see Providing Basic Policy Information on page 441 and Setting Rule and White List Priorities on page 442.

Host Criticality

The user-assigned host criticality of the host that is out of compliance with the white list: None, Low, Medium, or High. For more information on host criticality, see Assigning a Host Criticality Value to a Host on page 201.

Detection Engine

The name of the detection engine that generated the event that triggered the white list violation.

Count

The number of events that match the constraints described in the row. The Count field appears only after you apply a constraint to the data.

Searching for Compliance White List Events Requires: DC/MDC + RNA

Version 4.7

You can search for specific compliance white list events. You may want to create searches customized for your network environment, then save them to re-use


382


Chapter 11

later. The search criteria you can use are described in the Compliance White List Event Search Criteria table. Compliance White List Event Search Criteria Field


Policy

Enter all or part of the name of a compliance policy to return all events caused by violations of white lists included in that policy.

White List

Enter all or part of the name of a white list to return all events caused by violations of that white list.

Description

Enter all or part of the white list event description. You can use an asterisk (*) as a wildcard character in this field. For example, enter *ssh* to return all white list events that involve the SSH service. For more information, see Using Wildcards and Symbols in Searches on page 1129.

Priority

Specify the priority of the white list event, which is determined either by the priority of the white list in a compliance policy or by the priority of the compliance policy itself. Note that the white list priority overrides the priority of its policy. Enter none for no priority. For information on setting compliance rule and policy priorities, see Providing Basic Policy Information on page 441 and Setting Rule and White List Priorities on page 442.

Version 4.7

IP Address

Specify the IP address of a host that has become non-compliant with a white list. See Specifying IP Addresses in Searches on page 1130 for detailed information about how to enter IP addresses.

User

Specify the identity of the user logged in to a host that has become non-compliant with a white list.

Port

Specify the port, if any, associated with the RNA event that indicates a host’s noncompliance with a white list. See Specifying Ports in Searches on page 1132 for information about the syntax for specifying ports.


383


Chapter 11

Compliance White List Event Search Criteria (Continued) Field


Host Criticality

Specify the host criticality of the source host involved in the white list event: None, Low, Medium, or High. For more information on host criticality, see Assigning a Host Criticality Value to a Host on page 201.

Detection Engine

Specify the name of the detection engine, detection engine group, sensor, or sensor group that generated the RNA event that indicated a host’s noncompliance with a white list. For more information, see Specifying Detection Engine/Appliance Names on page 1133.

For more information on searching, including how to load and delete saved searches, see Searching for Events on page 1124. To search for compliance white list events: Access: Data or Admin

1.

Select Analysis & Reporting > Searches > White List Events. The White List search page appears.

TIP! To search the database for a different kind of event, select it from the Table list. 2. Optionally, if you want to save the search, enter a name for the search in the Name field. If you do not enter a name, the Defense Center automatically creates one when you save the search.

Version 4.7


384

Using RNA as a Compliance Tool Working with White List Violations

Chapter 11

3. Enter your search criteria in the appropriate fields. Search criteria are described in the the Compliance White List Event Search Criteria table on page 383. If you enter multiple criteria, the Defense Center returns only the records that match all the criteria. 4. If you want to save the search so that other users can access it, clear the Save As Private check box. Otherwise, leave the check box selected to save the search as private. TIP! If you want to save a search as a restriction for restricted data users, you must save it as a private search. 5. You have the following options: •

Click Search to start the search. Your search results appear in the default white list events workflow, constrained by the current time range on the Defense Center. If you created a custom white list events workflow and did not specify a preferred workflow, you must select one. For information on specifying a preferred workflow, see Setting Event Preferences on page 35.

•


•


Working with White List Violations Requires: DC + RNA

The Defense Center keeps track of the ways in which hosts on your network violate the compliance white lists in active compliance policies. You can search and view these records. For more information, see the following sections: •

Viewing White List Violations on page 385

•

Understanding the White List Violations Table on page 388

•

Searching for White List Violations on page 389

Viewing White List Violations Requires: DC + RNA

Version 4.7

You can use the Defense Center to view a table of white list violations. Then, you can manipulate the event view depending on the information you are looking for.


385


Chapter 11

The page you see when you access white list violations differs depending on the workflow you use. There are two predefined workflows: •

The Host Violation Count workflow provides a series of pages that list all the hosts that violate at least one white list. The first page sorts the hosts based on the number of violations per host, with the hosts with the greatest number of violations at the top of the list. If a host violates more than one white list, there is a separate row for each violated white list. The workflow also contains a table view of white list violations that lists all violations with the most recently detected violation at the top of the list. Each row in the table contains a single detected violation.

•

The White List Violations workflow includes a table view of white list violations that lists all violations with the most recently detected violation at the top of the list. Each row in the table contains a single detected violation

Both predefined workflows terminate in a host view, which contains a host profile for every host that meets your constraints. You can also create a custom workflow that displays only the information that matches your specific needs. For more information, see Creating Custom Workflows on page 1179. The Compliance White List Violations Actions table below describes some of the specific actions you can perform on a white list violations workflow page. Compliance White List Violations Actions To...

You can...










find more information in Understanding the White List Violations Table on page 388.

Version 4.7

) that appears next to the IP address.


386


Chapter 11

Compliance White List Violations Actions (Continued) To...

You can...


use one of the following methods: • To drill down to the next workflow page constraining on a specific value, click a value within a row. Note that this only works on drilldown pages. Clicking a value within a row in a table view constrains the table view and does not drill down to the next page. • To drill down to the next workflow page constraining on some events, select the checkboxes next to the events you want to view on the next workflow page, then click View. • To drill down to the next workflow page keeping the current constraints, click View All. TIP! Table views always include “Table View” in the page name. For more information, see Constraining Events on page 1170.











search for white list violations

click Search. For more information, see Searching for White List Violations on page 389. To view compliance white list violations:


Version 4.7

h

Select Analysis & Reporting > Compliance > White List Violations. If you specified a preferred white list violations workflow, the first page of the workflow appears. Otherwise, you must select a workflow. For information on specifying a preferred workflow, see Setting Event Preferences on page 35.


387


Chapter 11

Understanding the White List Violations Table Requires: DC + RNA

You can use the compliance policy feature to build compliance policies that let your Defense Center respond in real time to threats on your network. Compliance policies describe the type of activity that constitutes a policy violation, which include compliance white list violations. For more information on compliance policies, see Configuring Compliance Policies and Rules on page 392. When a compliance white list is violated, the Defense Center records the violation. The fields in the white list violations table are described in the Compliance White List Violation Fields table. Compliance White List Violation Fields Field

Description

Time

The date and time that the white list violation was detected.

IP Address

The IP address of the non-compliant host.

Type

The type of white list violation, that is, whether the violation occurred as a result of a non-compliant: • operating system (os) • service (service) • client application (client app) • protocol (protocol)

Information

Any available vendor, product, or version information associated with the white list violation. For example, if you have a white list that allows only Microsoft Windows hosts, the Information field describes the operating systems of the hosts that are not running Microsoft Windows. For protocols that violate a white list, the Information field also indicates whether the violation is due to a network or transport protocol.

Version 4.7

Port

The port, if any, associated with the event that triggered the white list violation.

Protocol

The protocol, if any, associated with the event that triggered the white list violation.


388


Chapter 11

Compliance White List Violation Fields (Continued) Field

Description

White List

The name of the white list that was violated.

Count

The number of white list violations that match the constraints described in the row. The Count field appears only after you apply a constraint to the data.

Searching for White List Violations Requires: DC + RNA

You can search for specific compliance white list violations. You may want to create searches customized for your network environment, then save them to re-use later. The search criteria you can use are described in the Compliance White List Violations Search Criteria table. Compliance White List Violations Search Criteria Field


Time

Specify the date and time that the white list was violated. See Specifying Time Constraints in Searches on page 1130 for the syntax for entering time.

IP Address

Specify the IP address of a host that has become non-compliant with a white list. See Specifying IP Addresses in Searches on page 1130 for detailed information about how to enter IP addresses.

White List

Enter all or part of the name of a white list to return all violations of that white list.

Type

Enter the type of white list violation: • enter os (or operating system) to search for violations based on operating systems • enter service to search for violations based on services • enter clientapp (or client app) to search for violations based on client applications • enter protocol to search for violations based on protocols

Version 4.7


389


Chapter 11

Compliance White List Violations Search Criteria (Continued) Field


Information

Enter all or part of the white list violation information. You can use an asterisk (*) as a wildcard character in this field. For example, enter *Apple* to return all violations that occurred because you set up a white list that disallows Apple, Inc. operating systems. For more information, see Using Wildcards and Symbols in Searches on page 1129.

Port

Specify the port, if any, associated with the RNA event that indicates a host’s noncompliance with a white list. See Specifying Ports in Searches on page 1132 for information about the syntax for specifying ports.

Protocol

Specify the protocol for which you want to view white list violations.

For more information on searching, including how to load and delete saved searches, see Searching for Events on page 1124. To search for compliance white list events: Access: Data or Admin

1.

Select Analysis & Reporting > Searches > White List Violations. The White List Violations search page appears.

TIP! To search the database for a different kind of event, select it from the Table list.

Version 4.7


390


Chapter 11

2. Optionally, if you want to save the search, enter a name for the search in the Name field. If you do not enter a name, the Defense Center automatically creates one when you save the search. 3. Enter your search criteria in the appropriate fields. Search criteria are described in the the Compliance White List Violations Search Criteria table on page 389. If you enter multiple criteria, the Defense Center returns only the records that match all the criteria. 4. If you want to save the search so that other users can access it, clear the Save As Private check box. Otherwise, leave the check box selected to save the search as private. TIP! If you want to save a search as a restriction for restricted data users, you must save it as a private search. 5. You have the following options: •

Click Search to start the search. If you specified a preferred white list violations workflow, your search results appear. Otherwise, you must select a workflow. For information on specifying a preferred workflow, see Setting Event Preferences on page 35.

Version 4.7

•


•



391

Chapter 11

Configuring Compliance Policies and Rules

You can use the powerful policy and response feature to build compliance policies that let the Defense Center respond in real time to threats to your network. Compliance policies are populated by compliance rules and compliance white lists. A compliance rule triggers when a specific flow, intrusion, RNA, RUA, or host input event occurs and the event meets criteria that you specify. You can also configure a compliance rule to trigger when your network traffic deviates from your normal network traffic pattern as characterized in an existing traffic profile. Compliance white lists, on the other hand, comprise criteria that specify which operating systems, client applications, services, and protocols are allowed to run on your network; when a host violates those criteria, the white list triggers. A policy violation occurs when the activity on your network triggers either a compliance rule or white list. When this occurs, the Defense Center logs either a compliance event or a white list event to the database, depending on the type of policy violation. You can search, view, and delete compliance events and compliance white list events. Within compliance policies, you can configure the Defense Center to trigger responses automatically when it detects a policy violation. Responses include remediations (such as blocking a host at the firewall or router when it violates a policy), alerts (email, SNMP, and syslog alerts), or combination of alerts and

Version 4.7


392

Configuring Compliance Policies and Rules

Chapter 12

remediations. For more information on responses, see Configuring Responses for Compliance Policies on page 456. IMPORTANT! This chapter focuses on compliance policies, compliance rules, and compliance events. For more information on compliance white lists, see Using RNA as a Compliance Tool on page 340. The following graphic illustrates the event notification and the policy and response process:

IMPORTANT! You must use a Defense Center to create compliance policies and to view compliance events. On the Master Defense Center, you cannot create compliance policies, but you can view compliance events that were forwarded from managed Defense Centers.

Version 4.7


393

Configuring Compliance Policies and Rules Creating Rules for Compliance Policies

Chapter 12

For more information on creating compliance rules and compliance policies, see the following sections. •

Creating Rules for Compliance Policies on page 394

•

Managing Rules for Compliance Policies on page 437

•

Creating Compliance Policies on page 439

•

Managing Compliance Policies on page 445

•

Working with Compliance Events on page 447

Creating Rules for Compliance Policies Requires: DC

Before you create a compliance policy, you should create compliance rules or compliance white lists (or both) to populate it. IMPORTANT! This section describes how to create compliance rules. For information on creating compliance white lists, see Creating Compliance White Lists on page 350. A compliance rule triggers (and generates a compliance event) when your network traffic meets criteria that you specify. You can build compliance rules to trigger when specific flow, intrusion, RNA, RUA, or host input events occur and the event meets those criteria. You can also build compliance rules to trigger when your network traffic deviates from your normal network traffic pattern as characterized in an existing traffic profile. You can build complex rules with multiple conditions; you can even configure a compliance rule to trigger another rule, provided that both rules use the same type of network discovery event as their basis. In addition, you can constrain some compliance rules with information from the host profile of a host involved in the event. This constraint is called a host profile qualification. You can further constrain a compliance rule so that once its initial criteria are met, RNA begins tracking certain flows. Then, a compliance event is generated only if the tracked flows meet additional criteria. This configuration is called a flow tracker. IMPORTANT! You cannot add a host profile qualification or a flow tracker to a rule that triggers on a traffic profile change. In addition, you cannot add a host profile qualification to a rule that triggers on the detection of a new IP host. If you employ the Real Time User Awareness (RUA) feature, a user qualification can be added to the compliance rule to track certain users or groups of users. For example, you could constrain a compliance rule so that it triggers only when the identity of the source or destination user is a certain user or, for example, one from the marketing department.

Version 4.7


394


Chapter 12

Finally, you configure compliance rules to have snooze periods and inactive periods. When a compliance rule triggers, a snooze period instructs the Defense Center to stop firing that rule for a specified interval, even if the rule is violated again during the interval. When the snooze period has elapsed, the rule can trigger again (and start a new snooze period). During inactive periods, the compliance rule does not trigger. When you create compliance rule trigger criteria, host profile qualifications, user qualifications, and flow trackers, you can use simple conditions or you can create more elaborate constructs by combining and nesting conditions. The syntax you can use within conditions varies depending on the element you are creating, but the mechanics remains consistent. For more information, See Understanding Rule-Building Mechanics on page 429. To create a compliance rule: Access: Rules or Admin

1.

Select Policy & Response > Compliance > Rule Management. The Rule Management page appears.

2. Click Create Rule. The Create Rule page appears.

3. Provide basic rule information, such as the rule name, description, and group. See Providing Basic Rule Information on page 396. 4. Specify the basic criteria on which you want the rule to trigger. See Specifying Compliance Rule Trigger Criteria on page 396.

Version 4.7


395


Chapter 12

5. Optionally, add a host profile qualification to the rule. See Adding a Host Profile Qualification on page 411. 6. Optionally, add a flow tracker to the rule. See Adding a Flow Tracker on page 415. 7.

Optionally, add a user qualification to the rule. See Adding a User Qualification on page 426.

8. Optionally, add an inactive period or snooze period (or both) to the rule. See Adding Snooze and Inactive Periods on page 428. 9. Click Save Rule. The rule is saved. You can now use the rule within compliance policies or within other compliance rules that trigger on the same event type.

Providing Basic Rule Information Requires: DC

You must give each compliance rule a name, and, optionally, a short description. You can also place the rule in a rule group.

To provide basic rule information: Access: Rules or Admin

1.

On the Create Rule page, in the Rule Name field, type a name for the rule.

2. In the Rule Description field, type a description for the rule. 3. Optionally, select a group for the rule from the Rule Group drop-down list. For more information on rule groups, see Managing Rules for Compliance Policies on page 437. 4. Continue with the procedure in the next section, Specifying Compliance Rule Trigger Criteria.

Specifying Compliance Rule Trigger Criteria Requires: DC

Version 4.7

A simple compliance rule requires only that any flow, intrusion, RNA, RUA, or host input event occur; you do not need to provide more specific conditions. Also, compliance rules based on traffic profiles require only one condition. In contrast, compliance rules can be complex, with multiple nested conditions. For example, the rule shown in the following graphic comprises criteria that direct the rule to


396


Chapter 12

trigger if an IP address that is not in the 10.x.x.x subnet transmits an IGMP message.

To specify compliance rule trigger criteria: Access: Rules or Admin

Version 4.7

1.

Select the type of event on which you want to base your rule. When you build a compliance rule, first you must select the type of event on which you want to base your rule. You have a few options under Select the type of event for this rule: •

Requires: DC + RNA Select a flow event occurs to trigger the rule when flow data meets specific criteria.

•

Requires: DC + IPS Select an intrusion event occurs to trigger your rule when a specific intrusion event occurs.

•

Requires: DC + RNA Select an RNA event occurs to trigger the rule when a specific RNA event occurs. When triggering a compliance rule on an RNA event, you must also choose the type of event you want to use. You can choose from a subset of the RNA events described in Understanding RNA Network Discovery Event Types on page 219; you cannot, for example, trigger a compliance rule on a confidence change. You can, however, choose there is any type of event to trigger the rule when any kind of RNA event occurs.

•

Requires: DC + RUA Select an RUA event occurs to trigger the rule when a new user identity is detected or a user logs in to a host.

•

Requires: DC + RNA Select a host input event occurs to trigger the rule when a specific host input event occurs. When triggering a compliance rule on a host input event, you must also choose the type of event you want to use. You can choose from a subset of the events described in Understanding RNA Host Input Event Types on page 223.

•

Requires: DC + RNA Select a traffic profile changes to trigger the compliance rule when network traffic deviates from your normal network traffic pattern as characterized in an existing traffic profile.


397


Chapter 12

2. Specify the rule’s conditions. The syntax you can use within compliance rule trigger criteria conditions varies depending on the base event you chose in step 1, but the mechanics are the same. For more information, see Understanding Rule-Building Mechanics on page 429. The syntax you can use to build conditions is described in the following sections. •

Syntax for Flow Events on page 398

•

Syntax for Intrusion Events on page 401

•

Syntax for RNA Events on page 402

•

Syntax for RUA Events on page 404

•

Syntax for Host Input Events on page 405

•

Syntax for Traffic Profile Changes on page 406

TIP! You can nest rules that share the base event type you specified in step 1. For example, if you create a new rule based on the detection of a new TCP service, the trigger criteria for the new rule could include rule “MyDoom Worm” is true and rule “Bittorrent (TCP) P2P” is true. 3. Optionally, continue with the procedures in the next sections to add a host profile qualification, a flow tracker, and inactive and snooze periods. •

Adding a Host Profile Qualification on page 411

•

Adding a Flow Tracker on page 415

•

Adding Snooze and Inactive Periods on page 428

Syntax for Flow Events Requires: DC + RNA

The Syntax for Flow Events table describes how to build a compliance rule condition when you choose a flow event as the base event. Note that if you configure your 3D Sensors to transmit flow data to the Defense Center as flow summaries only, when you build a compliance rule with a flow event as the base event, you should use data that the flow summaries contain. A trigger criterion based on information that is not included in a flow summary automatically evaluates to true. For example, flow summaries do not include information on the initiator port. Therefore, if you build a compliance rule that requires that the initiator must be using a specific port, the rule will trigger for every flow summary that meets the other criteria in the rule. If that is the only criterion in the rule, the rule will trigger for every flow summary that the Defense Center receives. For more information, see Understanding Flow Summary Data on page 282. In addition, you should keep in mind that flows detected by 3D Sensors with RNA and flows exported by NetFlow devices contain different information. For

Version 4.7


398


Chapter 12

example, flows detected by 3D Sensors with RNA do not contain TCP flag information. Therefore, if you want to specify that a flow event have a certain TCP flag to trigger a compliance rule, none of the flows detected by 3D Sensors with RNA will trigger the rule. As another example, NetFlow records do not contain information about which host in the flow is the initiator and which is the responder. When RNA processes NetFlow records, it uses an algorithm to determine this information based on the ports each host is using, and whether those ports are well-known. For more information, see Understanding Flow Data Tables on page 291. Syntax for Flow Events If you specify...


Flow Duration

Type the duration of the flow event, in seconds.


Either type a single IP address or CIDR notation to specify a range of IP addresses. For example, to restrict the rule to respond to flows originating from a computer with an IP address of 192.168.1.1, select Initiator IP and specify 192.168.1.1. To restrict the rule to detect responses by hosts in the 192.168.1.x range with a subnet mask of 255.255.255.0, select Responder IP and specify 192.168.1.0/24. For more information on CIDR notation, see Specifying Subnets with CIDR Notation on page 1131.



Protocol


Detection Engine

Select the detection engine that detected the flow (for flows detected by 3D Sensors with RNA), or processed the flow (for flow data exported by a NetFlow device).

Flow Type

Select whether you want to trigger the compliance rule based on whether the flow was detected by a 3D Sensor with RNA (RNA) or was exported by a NetFlow device (NetFlow).

NetFlow Device

Select the IP address of the NetFlow device that exported the flow data you want to use to trigger the compliance rule. If you did not add any NetFlow devices to your deployment (using the system settings), the NetFlow Device drop-down list is blank.

TCP Flags

Select a TCP flag that a flow must contain in order to trigger the compliance rule. IMPORTANT! Only flows exported by NetFlow devices contain TCP flag data.

Service Name

Version 4.7

Select one or more service names from the list of available services.


399


Chapter 12

Syntax for Flow Events (Continued) If you specify...


Application

Select one or more applications from the list of available applications.

Application Type

Select one or more application types from the list of available application types. Application types include web browsers, email clients, and various instant-messaging clients.

Application Version

Type the version number of the application.

Initiator Bytes, Responder Bytes, or Total Bytes

Type one of: • the number of bytes transmitted by the hosts on the monitored network segment (Initiator Bytes). • the number of bytes received by the hosts on the monitored network segment (Responder Bytes). • the number of bytes both transmitted and received by the hosts on the monitored network segment (Total Bytes).

Initiator Packets, Responder Packets, or Total Packets

Type one of: • the number of packets transmitted by the hosts on the monitored network segment (Initiator Packets). • the number of packets received by the hosts on the monitored network segment (Responder Packets). • the number of packets both transmitted and received by the hosts on the monitored network segment (Total Packets)

Version 4.7


400


Chapter 12

Syntax for Intrusion Events Requires: DC + IPS

The Syntax for Intrusion Events table describes how to build a compliance rule condition when you choose an intrusion event as the base event.

Syntax for Intrusion Events If you specify...


Source IP, Destination IP, or Source/Destination IP

Either type a single IP address or use CIDR notation to specify a range of IP addresses. For example, to restrict the rule to respond to intrusion events on traffic originating from a computer with an IP address of 192.168.1.1, select Source IP and specify 192.168.1.1. To restrict the rule to respond to intrusion events on traffic going to any computer in the 192.168.1.x range with a subnet mask of 255.255.255.0, select Destination IP and specify 192.168.1.0/24. For more information on CIDR notation, see Specifying Subnets with CIDR Notation on page 1131.

Generator ID

Select one or more preprocessors from the list of available preprocessors. See Tuning Preprocessors on page 846 for more information about available preprocessors.

Classifications

Select one or more classifications from the list of available classifications.

Rule SID

Type a single Snort ID number (SID) or multiple SIDs separated by commas. IMPORTANT! If you choose is in or is not in as the operator, you cannot use the multi-selection pop-up window. You must type a comma-separated list of SIDs.

Rule Message

Type all or part of the rule message.

Rule Type

Specify whether the rule is or is not local. Local rules include custom standard text intrusion rules, standard text rules that you modified, and any new instances of shared object rules created when you saved the rule with modified header information. For more information, see Constructing a Rule on page 1008.

Priority

Select the rule priority from the list of available priorities (low, medium, or high). For rule-based intrusion events, the priority corresponds to either the value of the priority keyword or the value for the classtype keyword. For other intrusion events, the priority is determined by the decoder or preprocessor.

Version 4.7


401


Chapter 12

Syntax for Intrusion Events If you specify...


Impact Flag

Select the impact flag assigned to the intrusion event. You can select from the following (the numeric equivalents for use with greater than or less than operators appear in parentheses): • 1 - red (Vulnerable) • 2 - orange (Potentially Vulnerable) • 3 - yellow (Currently Not Vulnerable) • 4 - blue (Unknown Target) • 5 - gray (Unknown) Note that impact flags (other than gray) are assigned to intrusion events only when you deploy IPS and RNA on the same network segment and manage both with the same Defense Center. IMPORTANT! Because there is no operating system information available for hosts added to the network map based on NetFlow data, the Defense Center cannot assign red (Vulnerable) impact flags for intrusion events involving those hosts, unless you use the host input feature to manually set the host operating system identity. For more information, see Using Impact Flags to Evaluate Events on page 686. TIP! You cannot select the black flag. To add a compliance rule for drop events, use Inline Result.

Source Port or Destination Port


Protocol


Detection Engine

Select one or more detection engines that may have generated the event.

Inline Result

Select whether the packet is or is not dropped as part of an inline intrusion policy. For more information, see Using the Drop Rule State on page 798.

Syntax for RNA Events Requires: DC + RNA

Version 4.7

If you base your compliance rule on an RNA event, you must first choose the type of RNA event you want to use from a drop-down list. You can choose from a subset of the RNA events described in Understanding RNA Network Discovery Event Types on page 219. (You cannot specifically trigger a compliance rule on confidence changes, user-initiated RNA events, and a few other types of RNA events. You can, however, choose there is any type of event to trigger the rule when any type of RNA event occurs.)


402


Chapter 12

After you choose the RNA event type, you can build compliance rule conditions as described in the Syntax for RNA Events table. IMPORTANT! Depending on the type of RNA event you choose, you can build conditions using subsets of the criteria in the following table. For example, if you trigger your compliance rule when a new client application is detected, you can build conditions based on the IP or MAC address of the host, the application name, type, or version, and the detection engine that detected the event. Syntax for RNA Events If you specify...


Application


Application Type


Application Version

Type the version number of the application.

Detection Engine

Select the detection engine that generated the event.

Host Type

Select one or more host types from the list of host types. You can choose Bridge, Host, or Router.

IP Address or New IP Address

Either type a single IP address or use CIDR notation to specify a range of IP addresses. For example, to restrict the rule to RNA events occurring on a computer with an IP address of 192.168.1.1, select IP Address and specify 192.168.1.1. To restrict the rule to RNA events occurring on any host in the 192.168.1.x range with a subnet mask of 255.255.255.0, select IP Address and specify 192.168.1.0/24. For more information on CIDR notation, see Specifying Subnets with CIDR Notation on page 1131.

MAC Address

Type all or part of the MAC address of the host. For example, if you know that a certain hardware manufacturer’s devices’ MAC addresses begins with 0A:12:34, you could choose begins with as the operator, then type 0A:12:34 as the value.

MAC Type

Select whether the MAC address was ARP/DHCP Detected. That is, select whether RNA positively identified the MAC address as belonging to the host (is ARP/DHCP Detected), or whether RNA is seeing many hosts with that MAC address because, for example, there is a router between the sensor and the host (is not ARP/DHCP Detected).

Version 4.7


403


Chapter 12

Syntax for RNA Events (Continued) If you specify...


NETBIOS Name

Type all or part of the NetBIOS name of the host. For example, if you know that all your Windows hosts in your Denver office have NetBIOS names that contain DNV, you could choose contains the string as the operator, then type DNV as the value.

Network Protocol


OS Name

Select one or more operating system names from the list of available names.

OS Vendor

Select one or more operating system vendor names from the list of available vendors.

OS Version

Select one or more operating system versions from the list of available versions.

Service Name

Select one or more services from the list of available services.

Service Port


Transport Protocol


VLAN ID

Type the VLAN ID number.

Syntax for RUA Events Requires: DC + RUA

If you base your compliance rule on an RUA event, choose the type of RUA event you want to use from a drop-down list. After you choose the RUA event type, you can build compliance rule conditions as described in the Syntax for RUA Events table. IMPORTANT! Depending on the type of RUA event you choose, you can build conditions using subsets of the criteria in the following table. For example, if you trigger your compliance rule when a user logs in to a host, you can build conditions based on the IP host.

Version 4.7


404


Chapter 12

Syntax for RUA Events If you specify...


A new User Identity is detected

Type the username.

A user logs in to a host

Type the host IP address or the username.

Syntax for Host Input Events Requires: DC + RNA

Version 4.7

If you base your compliance rule on a host input event, the rule triggers when the event occurs. During rule creation, you can select the type of event that will trigger the rule and set specific criteria for the triggering event. For example, if you wanted an alert if a user other than one of your administrative users changed client application data in your network map, you could set up a rule that notifies you when a client application is deleted from a host. You could specify that the rule triggers if the Source Type is User and the Source is neither admin or admin2, as shown in the following graphic.


405


Chapter 12

The Syntax for Host Input Events table describes how to build a condition in a compliance rule when you choose a host input event as the base event. Syntax for Host Input Events If you specify...


IP Address

Either type a single IP address or use CIDR notation to specify a range of IP addresses. Note that to use a range of IP addresses, you must use the is in or is not in operators. For example, to restrict the rule to host input events occurring on a computer with an IP address of 192.168.1.1, select IP Address is and specify 192.168.1.1. To restrict the rule to host input events occurring on any host in the 192.168.1.x range with a subnet mask of 255.255.255.0, select IP Address is in and specify 192.168.1.0/24. For more information on CIDR notation, see Specifying Subnets with CIDR Notation on page 1131.

Source Type

Select the type of the source for the host input data from the list of available source types.

Source

Select the source for the host input data from the list of available sources.

Syntax for Traffic Profile Changes Requires: DC + RNA

If you base your compliance rule on a traffic profile change, the rule triggers when network traffic deviates from your normal network traffic pattern as characterized in an existing traffic profile. For information on how to build a traffic profile, see Creating Traffic Profiles on page 319. You can trigger the rule based on either raw data or on the statistics calculated from the data. For example, you could write a rule that triggers if the amount of data traversing your network (measured in bytes) suddenly spikes, which could

Version 4.7


406


Chapter 12

indicate an attack or other security policy violation. You could specify that the rule trigger if either: •

the number of bytes traversing your network spikes above a certain number of standard deviations above or below the mean amount of traffic Note that to create a rule that triggers when the number of bytes traversing your network falls outside a certain number of standard deviations (whether above or below), you must specify upper and lower bounds, as shown in the following graphic.

To create a rule that triggers when the number of bytes traversing is greater than a certain number of standard deviations above the mean, use only the first condition shown in the graphic. To create a rule that triggers when the number of bytes traversing is greater than a certain number of standard deviations below the mean, use only the second condition. •

the number of bytes traversing your network spikes above a certain number of bytes

You can also use velocity data, which uses rates of change between data points. If you wanted to use velocity data in the above example, you could specify that the rule triggers if either: •

the change in the number of bytes traversing your network spikes above or below a certain number of standard deviations above the mean rate of change

•

the change in the number of bytes traversing your network spikes above a certain number of bytes

For more information on velocity data, see Changing the Graph Type on page 313. To use velocity data: Access: Rules or Admin

Version 4.7

h

Check use velocity data next to the condition you are building.

The Syntax for Traffic Profile Changes table describes how to build a condition in a compliance rule when you choose a traffic profile change as the base event.


407


Chapter 12

If your traffic profile uses flow data exported by NetFlow devices, there are two important points to keep in mind:

Version 4.7

•

For flows detected by 3D Sensors, RNA generates one bidirectional record, or flow event. On the other hand, NetFlow devices export unidirectional flow data, so RNA generates at least two flow events for each flow detected by NetFlow devices, depending on whether you configured the device to output records at a fixed interval even if a flow is still ongoing.

•

NetFlow records do not contain information about which host in the flow is the initiator and which is the responder. When RNA processes NetFlow records, it uses an algorithm to determine this information based on the ports each host is using, and whether those ports are well-known.


408


Chapter 12

For more information, see Understanding Flow Data Tables on page 291. Syntax for Traffic Profile Changes If you specify...


Number of Flows

Type the total number of flows detected on the monitored network segment.

And then choose one of the following... • flows • standard deviation(s)

or Type the number of standard deviations either above or below the mean that the number of flows detected must be in to trigger the rule. Total Bytes, Initiator Bytes, or Responder Bytes

Type one of: • the total bytes transmitted on the monitored network segment (Total Bytes)

• bytes • standard deviation(s)

• the number of bytes transmitted by the hosts on the monitored network segment (Initiator Bytes) • the number of bytes received by the hosts on the monitored network segment (Responder Bytes) or Type the number of standard deviations either above or below the mean that one of the above criteria must be in to trigger the rule.

Version 4.7


409


Chapter 12

Syntax for Traffic Profile Changes (Continued) If you specify...


Total Packets, Initiator Packets, or Responder Packets

Type one of: • the total packets transmitted on the monitored network segment (Total Packets)

And then choose one of the following... • packets • standard deviation(s)

• the number of packets transmitted by the hosts on the monitored network segment (Initiator Packets) • the number of packets received by the hosts on the monitored network segment (Responder Packets) or Type the number of standard deviations either above or below the mean that one of the above criteria must be in trigger the rule. Unique Initiators

Type the number of unique hosts that initiated sessions that were detected on the monitored network segment.

• initiators • standard deviation(s)

or Type the number of standard deviations either above or below the mean that the number of unique initiators detected must be to trigger the rule. Unique Responders

Type the number of unique hosts that responded to sessions that were detected on the monitored network segment.

• responders • standard deviation(s)

or Type the number of standard deviations either above or below the mean that the number of unique responders detected must be to trigger the rule.

Version 4.7


410


Chapter 12

Adding a Host Profile Qualification Requires: DC

If you are using an flow, intrusion, RNA, RUA, or host input event to trigger your compliance rule, you can constrain the rule based on the host profile of a host involved in the event. This constraint is called a host profile qualification. IMPORTANT! You cannot add a host profile qualification to a compliance rule that triggers on a traffic profile change or on the detection of a new IP host. For example, as shown in the following graphic, you could constrain a compliance rule so that it triggers only when a Microsoft Windows host is the target of the offending traffic, because only Microsoft Windows computers are vulnerable to the vulnerability the rule is written for.

As another example, the host profile qualification shown in the following graphic constrains a compliance rule so that it triggers only when the host is out of compliance with a white list.

Note that to use a host profile qualification, the host must exist in the RNA database and the host profile property you want to use as a qualification must already be included in the host profile. For example, if you configure a compliance rule to trigger when an intrusion event is generated on a host running Windows, the rule only triggers if the host is already identified as Windows when the intrusion event is generated.

Version 4.7


411


Chapter 12

To add a host profile qualification: Access: Rules or Admin

1.

On the Create Rule Page, click Add Host Profile Qualification. The Host Profile Qualification section appears.

TIP! To remove a host profile qualification, click Remove Host Profile Qualification. 2. Build the host profile qualification’s conditions. You can create a single, simple condition, or you can create more elaborate constructs by combining and nesting conditions. See Understanding RuleBuilding Mechanics on page 429 for information on how to use the web interface to build conditions. The syntax you can use to build conditions is described in Syntax for Host Profile Qualifications on page 412. 3. Optionally, continue with the procedures in the following sections to add a flow tracker and inactive and snooze periods. •


•


Syntax for Host Profile Qualifications Requires: DC

When you build a host profile qualification condition, you must first select the host you want to use to constrain your compliance rule. The host you can choose depends on the type of event you are using to trigger the rule, as follows: •

If you are using a flow event, select Responder Host or Initiator Host.

•

If you are using an intrusion event, select Destination Host or Source Host.

•

If you are using an RNA or host input event, select RNA Host.

•

If you are using an RUA event, select RNA Host

After you select the host type, you continue building your host profile qualification condition, as described in the Syntax for Host Profile Qualifications table. Note that although you can configure the RNA detection policy to add hosts to the network map based on data exported by NetFlow devices, the available information about these hosts is limited. For example, there is no operating system data available for these hosts, unless you provide it using the host input feature. In addition, if your traffic profile uses flow data exported by NetFlow devices, keep in mind that NetFlow records do not contain information about which host in the flow is the initiator and which is the responder. When RNA

Version 4.7


412


Chapter 12

processes NetFlow records, it uses an algorithm to determine this information based on the ports each host is using, and whether those ports are well-known. For more information, see What Information Does RNA Provide? on page 127 and Understanding Flow Data Tables on page 291. Syntax for Host Profile Qualifications If you specify...


Host Type

Select one or more host types from the drop-down list. You can select Bridge, Host, or Router.

NETBIOS Name

Type all or part of the NetBIOS name of the host. For example, if you know that all your Windows hosts in your Denver office have NetBIOS names that contain DNV, you could choose contains the string as the operator, then type DNV as the value.

Operating System > OS Name

Select one or more operating system names from the drop-down list.

Operating System > OS Vendor

Select one or more operating system vendor names from the drop-down list.

Operating System > OS Version

Select one or more operating system versions from the drop-down list.

Network Protocol


Transport Protocol


Host Criticality

Select the host criticality from the list that appears. You can select None, Low, Medium, or High. For more information on host criticality, see Assigning a Host Criticality Value to a Host on page 201.

VLAN ID

Type the VLAN ID number of the host.

Service > Service Name

Select one or more services from the drop-down list.

Service > Service Port


Service > Service Protocol

Select one or more protocols from the drop-down list.

Version 4.7


413


Chapter 12

Syntax for Host Profile Qualifications (Continued) If you specify...


Client Application > Application Type

Select one or more application types from the drop-down list. Application types include web browsers, email clients, and various instant-messaging clients.

Client Application > Application

Select one or more applications from the drop-down list.

Client Application > Application Version

Type the application version.

MAC Address > MAC Address

Type all or part of the MAC address of the host.

MAC Address > MAC Type

Select whether the MAC type is ARP/DHCP Detected.

any available host attribute, including the default compliance white list host attribute

For example, if you know that a certain hardware manufacturer’s devices’ MAC addresses begins with 0A:12:34, you could choose begins with as the operator, then type 0A:12:34 as the value.

That is, select whether RNA positively identified the MAC address as belonging to the host (is ARP/DHCP Detected), whether RNA is seeing many hosts with that MAC address because, for example, there is a router between the sensor and the host (is not ARP/DHCP Detected), or whether the MAC type is irrelevant (is any). Specify the appropriate value, which depends on the type of host attribute you select: • If the host attribute type is Integer, enter an integer value in the range defined for the attribute. • If the host attribute type is Text, and enter a text value. • If the host attribute type is List, select a valid list string from the dropdown list. • If the host attribute type is URL, enter a URL value. For more information on host attributes, see Working with User-Defined Host Attributes on page 202. Note that you can often use event data when constructing a host profile qualification. For example, assume your compliance rule triggers when RNA detects the use of Microsoft Internet Explorer on one of your monitored hosts.

Version 4.7


414


Chapter 12

Further assume that when you detect this use, you want to generate an event if the version of the browser is not the latest (for this example, assume the latest version is 6.0). You could add a host profile qualification to this compliance rule so that the rule triggers only if the Application Type is the Event Application Type (that is, HTTP Browser) and the Application is the Event Application (that is, Microsoft Internet Explorer), but the Application Version is not 6.0.

TIP! To specify that the application version be the same as the one detected in the event, click switch to event fields and select Event Application Version. Click switch to manual entry to go back to manually specifying the version.

Adding a Flow Tracker Requires: DC + RNA

If you are using an flow, intrusion, RNA, RUA, or host input event to trigger your compliance rule, you can add a flow tracker to the rule. A flow tracker constrains a compliance rule so that once its initial criteria are met, RNA begins tracking certain flows. The Defense Center generates a compliance event for the rule only if the tracked flows meet additional criteria. You cannot add a flow tracker to a rule that triggers on a traffic profile change. Unlike traffic profiles, which typically monitor a broad range of network traffic and run persistently, flow trackers typically monitor very specific traffic and, when triggered, run only for a finite, specified time. For more information on traffic profiles, see Creating Traffic Profiles on page 319. IMPORTANT! If you configure your 3D Sensors to transmit flow data to the Defense Center as flow summaries only, when you build a flow tracker, you should use data that the flow summaries contain. A flow tracker criterion based on information that is not included in a flow summary automatically evaluates to true. For example, flow summaries do not include information on the initiator port. Therefore, if you build a flow tracker that tracks every flow summary where the initiator is using a specific port, the Defense Center will track every flow summary that meets the other criteria in the flow tracker. If that is the only criterion in the flow tracker, the Defense Center will track every flow summary that it receives. For more information, see Understanding Flow Summary Data on page 282.

Version 4.7


415


Chapter 12

When you configure a flow tracker, you must specify: •

which flows you want to track

•

the conditions that the flows you are tracking must meet for the Defense Center to generate a compliance event

•

the amount of time that can elapse before the flow tracker “expires,” that is, the amount of time after which RNA stops tracking flows if the flow tracker conditions have not yet been met

When you add a flow tracker to a compliance rule, once your network traffic satisfies the basic conditions of the rule as well as of any host profile qualification you added, RNA begins tracking flows according to the criteria you specified. If your network traffic meets the flow tracker’s conditions before the time period you specify expires, the Defense Center generates a compliance event and immediately stops tracking flows for that rule instance. On the other hand, if time expires before your network traffic meets the conditions in the flow tracker, the Defense Center does not generate a compliance event. After time expires, RNA stops tracking flows for that rule instance. TIP! You can add a flow tracker to a simple compliance rule that requires only that any flow, intrusion, RNA, RUA, or host input event occurs. For example, consider a scenario where you archive sensitive files on network 10.1.0.0/16, and where hosts outside this network typically do not initiate connections to hosts inside the network. An occasional connection initiated from outside the network might occur, but you have determined that when four or more connections are initiated within two minutes, there is cause for concern. The rule shown in the following graphic specifies that once a connection occurs from outside the 10.1.0.0/16 network to inside the network, RNA begins tracking flows that meet that criterion. The Defense Center then generates a compliance

Version 4.7


416


Chapter 12

event if RNA detects four flows (including the original flow) within two minutes that match that signature.

The following graphic shows how network traffic can trigger the above compliance rule.

In this example, RNA detected a flow that met the basic conditions of the compliance rule, that is, RNA detected a connection from a host outside the 10.1.0.0/16 network to a host inside the network. This created a flow tracker.

Version 4.7


417


Chapter 12

RNA processes the flow tracker in the following stages: 1.

RNA starts tracking flows when it detects a connection from Host A outside the network to Host 1 inside the network.

2. RNA detects two more flows that match the flow tracker signature: Host B to Host 2 and Host C to Host 1. 3. RNA detects a fourth qualifying flow when Host A connects to Host 3 within the two-minute time limit. The rule conditions are met. 4. the Defense Center generates a compliance event and RNA stops tracking flows. Note that when you add a flow tracker to a compliance rule, depending on the type of event you use to trigger the rule, the flow tracker is populated with default constraints. For example, the following graphic shows a flow tracker added to the Bittorrent (TCP) P2P rule, which normally triggers when a new TCP service is detected on a port between 6881 and 6889, inclusive. The flow tracker constrains the rule so that it does not trigger until more than 5MB of data is transmitted by the host, using the port and protocol in the RNA event that initially violated the compliance rule, in the five minutes following the initial policy violation.

Version 4.7


418


Chapter 12

The following graphic shows how network traffic can trigger the above compliance rule.

In this example, RNA detected two flows that meet the basic conditions of the compliance rule, that is, RNA detected new TCP services on port 6882 for two different hosts: Host 1 and Host 2. This created two flow trackers, Flow Tracker 1 and Flow Tracker 2, each with its own signature. The signatures represent unique combinations of protocol, IP address, and port. That is, RNA created two flow trackers because the IP addresses of Host 1 and Host 2 differ. If RNA had detected a new TCP service on a different qualifying port (for example, 6883) for either Host 1 or Host 3, it would have created a third flow tracker. However, it would not have created an additional flow tracker if it detected a new UDP service on a qualifying port. This is because the basic conditions of the compliance rule require the TCP protocol.

Version 4.7


419


Chapter 12

RNA processes Flow Tracker 1 in the following stages: 1.

RNA starts tracking flows at the 0-second marker when RNA detects a new TCP service on port 6882 of Host 1. Note that Flow Tracker 1 will expire if Host 1 does not transmit 5MB of TCP data over port 6882 in the next 5 minutes (by the 300-second marker).

2. RNA detects that Host 1 transmitted data that matches the signature for Flow Tracker 1: •

1MB to Host A, at the 1-second marker

•

2MB to Host B, at the 5-second marker

•

2MB to Host C, at the 15-second marker

Although Host 1 has now transmitted 5MB of data on port 6882, the rule does not trigger because the total number of bytes transmitted must be more than 5MB (Responder Bytes are greater than 5000000). 3. RNA detects that Host 1 has transmitted 2MB to Host D on port 6882 using the TCP protocol at the 30-second marker, for a total of 7MB transmitted by Host 1. The rule conditions are met. 4. The Defense Center generates a compliance event and RNA stops tracking flows. Note that the Defense Center generates the compliance event after Host 1 transmits the entire 2MB to Host D, because it does not tally flow data until the session terminates. Also, note that the flow tracker terminates after the Defense Center generates the compliance event, even though the 5-minute period has not expired. If RNA detects a new TCP service on port 6882 of Host 1 at any time after the flow tracker terminates, it will create a new flow tracker. RNA processes Flow Tracker 2 in the following stages: 1.

RNA starts tracking flows at the 7-second marker when it detects a new TCP service on port 6882 of Host 2. Note that Flow Tracker 2 will expire if Host 2 does not transmit 5MB of TCP data over port 6882 in the next 5 minutes (by the 307-second marker).

2. RNA detects that Host 2 transmitted data, totaling 2MB, that matches the signature for Flow Tracker 2: •

1MB to Host A, at the 10-second marker

•

1MB to Host B, at the 20-second marker

3. Flow Tracker 2 expires after the 5 minutes, at the 307-second marker. RNA has not detected any more data transmissions that match the appropriate signature. 4. RNA stops tracking flows and does not generate a compliance event.

Version 4.7


420


Chapter 12

To add a flow tracker: Access: Rules or Admin

1.

On the Create Rule Page, click Add Flow Tracker. The Flow Tracker section appears.

TIP! To remove a flow tracker click Remove Flow Tracker. 2. Specify which flows you want to track by setting flow tracker criteria. You can set flow tracker criteria by creating a single, simple condition, or you can create more elaborate constructs by combining and nesting conditions. 3. For example, the following graphic shows three conditions that specify that RNA track flows that occur on the port involved in the policy violation and that involve the host that triggered the policy violation.

See Understanding Rule-Building Mechanics on page 429 for information on how to use the web interface to build conditions. The syntax you can use to build flow tracker conditions is described in Syntax for Flow Trackers on page 422.

Version 4.7


421


Chapter 12

4. Based on the flows you decided to track in step 2, describe when you want to generate a compliance event. You can create a single, simple condition that describes when you want to generate an event, or you can create more elaborate constructs by combining and nesting conditions. You must also specify the interval (in seconds, minutes, or hours) during which the conditions you specify must be met to generate a compliance event. For example, the following graphic shows a flow tracker that generates an event if more than about 5MB of data are transmitted by the host in the five minutes following the policy violation.

See Understanding Rule-Building Mechanics on page 429 for information on how to use the web interface to build conditions. The syntax you can use to build flow tracker conditions is described in Syntax for Flow Tracker Events on page 425. 5. Optionally, continue with the procedure in the next section, Adding Snooze and Inactive Periods, to add inactive and snooze periods.

Syntax for Flow Trackers Requires: DC + RNA

The Syntax for Flow Trackers table describes how to build a flow tracker condition that specifies the kind of flows you want to track. You should keep in mind that flows detected by 3D Sensors with RNA and flows exported by NetFlow devices contain different information. For example, flows detected by 3D Sensors with RNA do not contain TCP flag information. Therefore, if you want to specify that a flow event have a certain TCP flag to trigger a compliance rule, none of the flows detected by 3D Sensors with RNA will trigger the rule. As another example, NetFlow records do not contain information about which host in the flow is the initiator and which is the responder. When RNA processes NetFlow records, it uses an algorithm to determine this information based on the ports each host is using, and whether

Version 4.7


422


Chapter 12

those ports are well-known. For more information, see Understanding Flow Data Tables on page 291. Syntax for Flow Trackers If you specify...


Flow Duration

Type the flow duration, in seconds.


Either type a single IP address or CIDR notation to specify a range of IP addresses. For example, to restrict the flow tracker to track flows originating from a computer with an IP address of 192.168.1.1, select Initiator IP and specify 192.168.1.1. To restrict the tracker to track responses by hosts in the 192.168.1.x range with a subnet mask of 255.255.255.0, select Responder IP and specify 192.168.1.0/24. For more information on CIDR notation, see Specifying Subnets with CIDR Notation on page 1131.



Protocol

Type the name or number of the transport protocol as listed in http://www.iana.org/assignments/protocolnumbers.

Detection Engine

Select the detection engine that detected the flow (for flows detected by 3D Sensors with RNA), or processed the flow (for flow data exported by a NetFlow device).

Flow Type

Select whether you want to track flows based on how they were detected: by a 3D Sensor with RNA (RNA) or exported by a NetFlow device (NetFlow).

NetFlow Device

Select the IP address of the NetFlow device that exported the flows you want to track. If you did not add any NetFlow devices to your deployment (using the system settings), the NetFlow Device dropdown list is blank.

TCP Flags

Select the TCP flag that flows must contain in order to track them. IMPORTANT! Only flows exported by NetFlow devices contain TCP flag data.

Service Name

Version 4.7

Select one or more services from the list of available services.


423


Chapter 12

Syntax for Flow Trackers (Continued) If you specify...


Application


Application Type


Application Version

Type the version of the application.

Initiator Bytes, Responder Bytes, or Total Bytes

Type one of: • the number of bytes transmitted by the hosts on the monitored network segment (Initiator Bytes) • the number of bytes received by the hosts on the monitored network segment (Responder Bytes) • the number of bytes both transmitted and received by the hosts on the monitored network segment (Total Bytes)

Initiator Packets, Responder Packets, or Total Packets

Type one of: • the number of packets transmitted by the hosts on the monitored network segment (Initiator Packets) • the number of packets received by the hosts on the monitored network segment (Responder Packets) • the number of packets both transmitted and received by the hosts on the monitored network segment (Total Packets)

Note that you can often use event data when constructing a flow tracker. For example, assume your compliance rule triggers when RNA detects a new client application on one of your monitored hosts; that is, the rule triggers when an RNA event whose base event type is a new client application is detected is generated.

Further assume that when you detect this new application, you want to track flows involving the new application on the host where it was detected. Because RNA “knows” the IP address of the host and the client application name, you can build a simple flow tracker that tracks those flows.

Version 4.7


424


Chapter 12

In fact, when you add a flow tracker to this type of compliance rule, the flow tracker is populated with those default constraints; that is, the Initiator/Responder IP is set to the Event IP Address and the Application is set to the Event Application.

TIP! To specify that the flow tracker track flows for a specific IP address or range of IP addresses, click switch to manual entry to manually specify the IP. Click switch to event fields to go back to using the IP address in the event.

Syntax for Flow Tracker Events Requires: DC + RNA

The Syntax for Flow Tracker Events table describes how to how to build a flow tracker condition that specifies when you want to generate a compliance event based on the flows you are tracking. Syntax for Flow Tracker Events If you specify...


Number of Flows

Type the total number of flows detected on the monitored network segment.

Total Bytes, Initiator Bytes, or Responder Bytes

Type one of: • the total bytes transmitted on the monitored network segment (Total Bytes) • the number of bytes transmitted by the hosts on the monitored network segment (Initiator Bytes) • the number of bytes received by the hosts on the monitored network segment (Responder Bytes)

Version 4.7


425


Chapter 12

Syntax for Flow Tracker Events (Continued) If you specify...


Total Packets, Initiator Packets, or Responder Packets

Type one of: • the total packets transmitted on the monitored network segment (Total Packets) • the number of packets transmitted by the hosts on the monitored network segment (Initiator Packets) • the number of packets received by the hosts on the monitored network segment (Responder Packets)

Unique Initiators or Unique Responders

Type one of: • the number of unique hosts that initiated sessions that were detected on the monitored network segment (Unique Initiators) • the number of unique hosts that responded to flow transactions that were detected on the monitored network segment (Unique Responders)

Adding a User Qualification Requires: DC

If you are using an flow, intrusion, RNA, or host input event to trigger your compliance rule, you can constrain the rule based on the identity of a user involved in the event. This constraint is called a user identity qualification. IMPORTANT! You cannot add a user identity qualification to a compliance rule that triggers on a traffic profile change or on the detection of a RUA event. For example, as shown in the following graphic, you could constrain a compliance rule so that it triggers only when the identity of the source or destination user is one from the sales department.

Version 4.7


426


Chapter 12

To add a user identity qualification: Access: Rules or Admin

1.

On the Create Rule Page, click Add User Qualification. The User Identity Qualification section appears.

TIP! To remove a User Identity profile qualification, click Remove User Qualification. 2. Build the user profile qualification’s conditions. You can create a single, simple condition, or you can create more elaborate constructs by combining and nesting conditions. See Understanding RuleBuilding Mechanics on page 429 for information on how to use the web interface to build conditions. The syntax you can use to build conditions is described in Syntax for User Identity Qualifications on page 427. 3. Optionally, continue with the procedures in the following sections to add a flow tracker and inactive and snooze periods. •


•


Syntax for User Identity Qualifications Requires: DC

Version 4.7

When you build a user qualification condition, you must first select the identity you want to use to constrain your compliance rule. The identity you can choose depends on the type of event you are using to trigger the rule, as follows: •

If you are using a flow event, select Identity on Initiator or Identity on Responder.

•

If you are using an intrusion event, select Identity on Destination or Identity on Source.

•

If you are using an RNA event, select Identity on Host.

•

If you are using a host input event, select Identity on Host.


427


Chapter 12

After you select the host type, you continue building your host profile qualification condition, as described in the Syntax for User Qualifications table. Syntax for User Qualifications If you specify...


Username

Select username retrieved from LDAP server from drop-down list.

First Name

Select first name as retrieved from LDAP server from drop-down list.

Last Name

Select last name as retrieved from LDAP server from drop-down list.

Department

Select department name as retrieved from LDAP server from drop-down list.

Phone

Select telephone number as retrieved from LDAP server from drop-down list.

Email

Select email name as retrieved from LDAP server from drop-down list.

Adding Snooze and Inactive Periods Requires: DC

You can configure snooze periods in compliance rules. When a compliance rule triggers, a snooze period instructs the Defense Center to stop firing that rule for a specified interval, even if the rule is violated again during the interval. When the snooze period has elapsed, the rule can trigger again (and start a new snooze period). For example, you may have a host on your network that should never generate traffic. A simple compliance rule that triggers whenever RNA detects a flow involving that host can create multiple compliance events in a short period of time, depending on the network traffic to and from the host. To limit the number of compliance events exposing your policy violation, you can add a snooze period so that the Defense Center generates a compliance event only for the first flow (within a time period that you specify) that RNA detects involving that host. You can also set up inactive periods in compliance rules. During inactive periods, the compliance rule will not trigger. You can set up inactive periods to recur daily, weekly, or monthly. For example, you might perform a nightly Nessus scan on your internal network to look for vulnerabilities. In that case, you could set a daily inactive period on the affected compliance rules for the time and duration of your scan so that those rules do not trigger erroneously. The following graphic shows a portion of a compliance rule that is configured with a snooze period and an inactive period.

Version 4.7


428


Chapter 12

To add a snooze period: Access: Rules or Admin

h

On the Create Profile page, under Rule Options, specify the interval that the Defense Center should wait to trigger a rule again, after the rule triggers. TIP! To remove a snooze period, specify an interval of 0 (seconds, minutes, or hours).

To add an inactive period: Access: Rules or Admin

1.

On the Create Profile page, under Rule Options, click Add Inactive Period.

2. Using the drop-down lists and text field, specify when and how often you want the Defense Center to refrain from evaluating network traffic against the compliance rule. TIP! To delete an inactive period, click Delete next to the inactive period you want to delete. When you are finished adding snooze and inactive periods, continue with step 9 of the procedure in Creating Rules for Compliance Policies on page 394 to save the rule.

Understanding Rule-Building Mechanics Requires: DC

You build compliance rules, flow trackers, user qualifications, and host profile qualifications by specifying the conditions under which they trigger. You can create simple conditions, or you can create more elaborate constructs by combining and nesting conditions. For example, if you want to generate a compliance event every time a new host is detected, you can create a very simple rule with no conditions, as shown in the following graphic.

Version 4.7


429


Chapter 12

If you wanted to further constrain the rule and generate an event only if that new host was detected on the 10.4.x.x network, you can add a single condition, as shown in the following graphic.

But the following rule, which detects TCP Bittorent peer-to-peer activity on the 10.4.x.x network and the 192.168.x.x network, has four conditions, with the last constituting a complex condition.

The syntax you can use within conditions varies depending on the element you are creating, but the mechanics are the same. For more information, see: •

Building a Single Condition on page 430

•

Adding and Linking Conditions on page 433

•

Using Multiple Values in a Condition on page 435

Building a Single Condition Requires: DC

Most conditions have three parts: a category, an operator, and a value; some conditions are more complex and contain several categories, each of which may have their own operators and values. For example, the following compliance rule triggers if a new host is detected on the 10.4.x.x network. The category of the condition is IP Address, the operator is is in, and the value is 10.4.0.0/16.

Version 4.7


430


Chapter 12

To build the compliance rule trigger criteria in the example above: Access: Rules or Admin

1.

Begin building a compliance rule. For more information, see Creating Rules for Compliance Policies on page 394.

2. On the Create Rule page, under Select the type of event for this rule, select an RNA event occurs, then select a new IP host is detected from the drop-down list. 3. Start building the rule’s single condition by selecting IP Address from the first (or category) drop-down list. 4. Select is in from the operator drop-down list that appears. TIP! When the category represents an IP address, choosing is in or is not in as the operator allows you to specify whether the IP address is in or is not in a specific CIDR block. See Specifying Subnets with CIDR Notation on page 1131 for more information. 5. Type 10.4.0.0/16 in the text field. In contrast, the following host profile qualification is more complex; it constrains a compliance rule such that the rule triggers only if the host involved in the RNA event on which the rule is based is running a version of Microsoft Windows.

To build the host profile qualification in the example above: Access: Rules or Admin

1.

Build a compliance rule that triggers on an RNA event. For more information, see Creating Rules for Compliance Policies on page 394.

2. On the Create Rule page, click Add Host Profile Qualification. The Host Profile Qualification section appears.

Version 4.7


431


Chapter 12

3. Under Host Profile Qualification, in the first condition, specify the host whose host profile you want to use to constrain your compliance rule. Because this host profile qualification is part of a compliance rule based on an RNA event, the only available category is RNA Host. 4. Begin specifying the details of the operating system of the host by choosing the Operating System category. Three subcategories appear: OS Vendor, OS Name, and OS Version. 5. To specify that the host can be running any version of Microsoft Windows, use the same operator for all three subcategories: is. 6. Finally, specify the values for the subcategories. Select Microsoft as the value for OS Vendor, Windows as the value for OS Name, and leave any as the value for OS Version. Note that the categories you can choose from depend on whether you are building compliance rule triggers, a host profile qualification, or a flow tracker. Within compliance rule triggers, the categories further depend on what kind of event is the basis for your compliance rule. In addition, a condition’s available operators depend on the category you choose. Finally, the syntax you can use to specify a condition’s value depends on the category and operator. Sometimes you must type the value in a text field. Other times, you can pick a value from a drop-down list. IMPORTANT! Where the condition syntax allows you to pick a value from a dropdown list, you can often use multiple values from the list. For more information, see Using Multiple Values in a Condition on page 435. For more information on the syntax for building compliance rule trigger criteria, see: •

Syntax for Flow Events on page 398

•

Syntax for Intrusion Events on page 401

•

Syntax for RNA Events on page 402

•

Syntax for RUA Events on page 404

•

Syntax for Host Input Events on page 405

•

Syntax for Traffic Profile Changes on page 406

For more information on the syntax for building host profile qualifications, user qualifications, and flow trackers, see:

Version 4.7

•

Syntax for Host Profile Qualifications on page 412

•

Syntax for User Identity Qualifications on page 427

•

Syntax for Flow Trackers on page 422

•

Syntax for Flow Tracker Events on page 425


432


Chapter 12

Adding and Linking Conditions Requires: DC

You can create simple compliance rule triggers, flow trackers, and host profile qualifications, user qualifications, or you can create more elaborate constructs by combining and nesting conditions. When your construct includes more than one condition, you must link them with an AND or an OR operator. Conditions on the same level are evaluated together. •

The AND operator requires that all conditions on the level it controls must be met.

•

The OR operator requires that at least one of the conditions on the level it controls must be met.

For example, the following compliance rule trigger criteria contains two conditions, linked by AND. This means that the rule triggers if both conditions are true, that is, if a host with an IP address that is not in the 10.x.x.x subnet transmits an IGMP message.

In contrast, the following rule, which detects TCP Bittorent peer-to-peer activity, has four conditions, the bottom two of which constitute a complex condition.

This rule triggers if a new TCP service is detected on a specific port range; the first two conditions demand that the port is between 6881 and 6889, inclusive. The rule further requires that the IP address of the host involved in the event is in either the 10.4.x.x network or the 192.168.x.x network.

Version 4.7


433


Chapter 12

Logically, the rule is evaluated as follows: (A and B and (C or D))

Where...

Is the condition that states...

A

Service port is greater than or equal to 6881

B

Service port is less than or equal to 6889

C


D


To add a single condition: Access: Rules or Admin

h

To add a single condition, click Add condition above the current condition. A new condition is added below the current set of conditions, on the same level as the current set of conditions. By default, it is linked to the conditions on the same level with the OR operator, though you can change the operator to AND. For example, if you add a simple condition to the following rule:

The result is:

Version 4.7


434


Chapter 12

To add a complex condition: Access: Rules or Admin

h

Click Add complex condition above the current condition. A complex condition is added below the current set of conditions. The complex condition comprises two subconditions, which are linked to each other with the opposite operator from the one used to link the conditions on the level above it. For example, if you add a complex condition to the following rule:

The result is:

To link conditions: Access: Rules or Admin

h

Use the drop-down list to the left of a set of conditions. Choose:

•

the AND operator to require that all conditions on the level it controls be met

•

the OR operator to require that only one of the conditions on the level it controls be met

Using Multiple Values in a Condition Requires: DC

Version 4.7

When you are building a condition, and the condition syntax allows you to pick a value from a drop-down list, you can often use multiple values from the list. For example, if you want to add a host profile qualification to a rule that requires that a host be running some flavor of UNIX, instead of constructing multiple conditions linked with the OR operator, use the following procedure.


435


Chapter 12

To include multiple values in one condition: Access: Rules or Admin

1.

Build a condition, choosing is in or is not in as the operator. The drop-down list changes to a text field.

2. Click anywhere in the text field or on the Edit link. A pop-up window appears.

3. Under Available, use Ctrl or Shift while clicking to select multiple values. You can also click and drag to select multiple adjacent values. 4. Click the right arrow (>) to move the selected entries to Selected. 5. Click OK. The Create Rule page appears again. Your selections appear in the value field of your condition.

Version 4.7


436

Configuring Compliance Policies and Rules Managing Rules for Compliance Policies

Chapter 12

Managing Rules for Compliance Policies Requires: DC

Use the Rule Management page to manage compliance rules used within compliance policies.

You can create, modify, and delete rules. You can also create rule groups to help you organize compliance rules. For more information on modifying rules, deleting rules, and creating rule groups, see: •

Modifying a Rule on page 437

•

Deleting a Rule on page 438

•

Creating a Rule Group on page 438

•

Deleting a Rule Group on page 439

For more information on creating rules, see Creating Rules for Compliance Policies on page 394.

Modifying a Rule Requires: DC

Use the following procedure to modify an existing compliance rule. To modify an existing rule:


1.


2. If the rule is in a rule group, click the group name to expand the group. 3. Next to the rule you want to modify, click Edit. The Create Rule page appears. 4. Make modifications as necessary and click Update Rule. The rule is updated.

Version 4.7


437

Configuring Compliance Policies and Rules Managing Rules for Compliance Policies

Chapter 12

Deleting a Rule Requires: DC

You cannot delete compliance rules that you are using in one or more policies; you must first delete the rule from all policies in which it is included. For information on deleting a rule from a policy, see Modifying a Compliance Policy on page 446. To delete an existing rule:


1.


2. If the rule is in a rule group, click the group name to expand the group. 3. Next to the rule you want to delete, click Delete. The rule is deleted.

Creating a Rule Group Requires: DC

Create rule groups to help you organize compliance rules. The Sourcefire 3D System ships with many default rules, which are grouped according to function. For example, the Worms rule group comprises rules that detect activity by common worms. Note that rule groups exist only to help you organize compliance rules; you cannot assign a group of rules to a compliance policy. Instead, add each rule individually. You can add a rule to an existing group when you create the rule. You can also modify an existing rule to add it to a group. For more information, see the following sections: •


•

Modifying a Rule on page 437.

For information on deleting a rule group, see Deleting a Rule Group on page 439. To create a rule group: Access: Rules or Admin

1.


2. Click Create Group. The Groups page appears.

3. In the Group Name field, type a name for the group. 4. Click Add Group. The group is added.

Version 4.7


438

Configuring Compliance Policies and Rules Creating Compliance Policies

Chapter 12

Deleting a Rule Group Requires: DC

When you delete a rule group, rules that were in the group are not deleted. Rather, they merely become ungrouped. To delete a rule group:


1.


2. Next to the rule group you want to delete, click Delete. 3. Confirm that you want to delete the rule group. The group is deleted and rules that were in that group become ungrouped.

Creating Compliance Policies Requires: DC

After you create compliance rules or compliance white lists (or both), and, optionally, alert responses and remediations, you can use them to build compliance policies. When your network traffic meets the criteria specified in a compliance rule or white list in an active policy, the Defense Center generates either a compliance event or white list event. It also launches any responses you assigned to the rule or white list. You can map each rule or white list to a single response or to a group of responses. If the network traffic triggers multiple rules or white lists, the Defense Center launches all the responses associated with each rule and white list. For more information on creating the compliance rules, compliance white lists, and responses you can use to build a compliance policy, see the following sections: •


•


•

Configuring Responses for Compliance Policies on page 456.

TIP! Optionally, you can create a skeleton policy and modify it later to add rules and responses.

Version 4.7


439


Chapter 12

To create a compliance policy: Access: Rules or Admin

1.

Select Policy & Response > Compliance > Policy Management. The Policy Management page appears.


3. Provide basic policy information, such as the name and description. See Providing Basic Policy Information on page 441. 4. Add one or more rules or white lists to the compliance policy. See Adding Rules and White Lists to a Compliance Policy on page 441. 5. Optionally, set rule and white list priorities. See Setting Rule and White List Priorities on page 442. 6. Optionally, add responses to the rules or white lists you added. Adding Responses to Rules and White Lists on page 443. 7.

Click Save. The policy is saved. IMPORTANT! You must activate the policy before it can generate compliance and white list events and launch responses to policy violations. For more information, see Managing Compliance Policies on page 445.

Version 4.7


440


Chapter 12

Providing Basic Policy Information Requires: DC

You must give each policy an identifying name. Optionally, you can add a short description to the policy.

You can also assign a user-defined priority to your policy. If your compliance policy is violated, the resultant compliance events display the priority value you assign to the policy (unless the rule that was triggered has its own priority). The policy priority is also used to determine how RNA Visualizer displays an affected host when it is run in real-time mode. IMPORTANT! Rule and white list priorities override policy priorities. For more information, see Adding Rules and White Lists to a Compliance Policy on page 441. To provide basic policy information: Access: Rules or Admin

1.

On the Create Policy page, in the Policy Name field, type a name for the policy.

2. In the Policy Description field, type a description for the policy. 3. From the Default Priority list, select a priority for the policy. You can select a priority value from 1 to 5, where 1 is highest and 5 is lowest. Or, you can select None to only use the priorities assigned to specific rules. 4. Continue with the procedure in the next section, Adding Rules and White Lists to a Compliance Policy on page 441.

Adding Rules and White Lists to a Compliance Policy Requires: DC

Version 4.7

A compliance policy contains one or more compliance rules or white lists. When any rule or white list in a policy is violated, RNA logs an event to the database. If you assigned one or more responses to the rule or white list, those responses are launched.


441


Chapter 12

The following graphic shows a compliance policy composed of a compliance white list and a set of compliance rules, configured with a variety of responses. z

To add rules or white lists to a compliance policy: Access: Rules or Admin

1.

On the Create Policy page, click Add Rules. The Available Rules pop-up appears.

2. Click the appropriate folder name to expand it. 3. Select the rules and white lists that you want to use in the policy and click Add. The Create Policy page appears again. The rules and white lists you selected populate the policy. 4. Continue with the procedure in the next section, Setting Rule and White List Priorities on page 442

Setting Rule and White List Priorities Requires: DC

Version 4.7

You can assign a user-defined priority to each compliance rule or compliance white list in your compliance policy. If a rule or white list triggers, the resulting event displays the priority you assign to the rule or white list. On the other hand, if


442


Chapter 12

you do not assign a priority value and the rule or white list triggers, the resulting event displays the priority value of the policy. For example, consider a policy where the policy itself has a priority of 1 and its rules or white lists are set with the default priority, with the exception of one rule given a priority of 3. If the priority 3 rule triggers, the resulting compliance event shows 3 as its priority value. If other rules or white lists in the policy trigger, the resulting events show 1 as their priority values, retained from the policy’s priority. To set rule or white list priorities: Access: Rules or Admin

1.

On the Create Policy page, from the Priority list for each rule or white list, select a default priority.

You can select: •

a priority value from 1 to 5, where 1 is highest and 5 is lowest

•

None

•

Default to use the policy’s default priority

2. Continue with the procedure in the next section, Adding Responses to Rules and White Lists on page 443.

Adding Responses to Rules and White Lists Requires: DC

Within a compliance policy, you can map each rule or white list to a single response or to a group of responses. When any one of the rules or white lists in a policy is violated, RNA logs an associated event to the database and launches the responses assigned to that rule or white list. If multiple rules or white lists within a policy trigger, the Defense Center launches the responses associated with each rule or white list. For more information on creating responses and response groups, see Configuring Responses for Compliance Policies on page 456. IMPORTANT! Do not assign a Nessus or Nmap remediation as a response to a compliance rule that triggers on a traffic profile change. The remediation will not launch.

Version 4.7


443


Chapter 12

The following graphic shows a compliance policy composed of a compliance white list and a set of compliance rules, configured with a variety of responses. z

To add responses to rules and white lists: Access: Rules or Admin

1.

On the Create Policy page, next to a rule or white list where you want to add responses, click Responses. A pop-up window appears.

2. Under Unassigned Responses, select the response, multiple responses, or response group you want to launch when the rule or white list triggers, and click the up arrow. TIP! Hold down the Ctrl key while clicking to select multiple responses. 3. Click Update. The Create Policy page appears again. The responses you specified are added to the rule or white list.

Version 4.7


444

Configuring Compliance Policies and Rules Managing Compliance Policies

Chapter 12

Managing Compliance Policies Requires: DC

You manage compliance policies on the Policy Management page. You can create, modify, sort, activate, deactivate, and delete policies.

A policy’s status appears with its name. If the light bulb icon next to the policy name is lit, the policy is active. If it is dark, the policy is inactive. If you want the policy to generate compliance events and white list events, you must activate it. You can sort policies by state (active versus inactive) or alphabetically by name using the Sort by drop-down list. If an active compliance policy contains a compliance white list, the following actions do not delete the host attribute associated with the white list, nor do they change that host attribute’s values: •

deactivating the policy

•

modifying the policy to remove the white list

•

deleting the policy

That is, hosts that were compliant when you performed the action still appear as compliant on the host attributes network map, and so on. To delete the host attribute, you must delete its corresponding white list. To update the white list compliance of the hosts on your network, you must either reactivate the compliance policy (if you deactivated it) or add the white list to another active compliance policy (if you deleted the white list from a compliance policy or deleted the policy itself). Note that the re-evaluation of the white list that occurs when you do this does not generate white list events and therefore does not trigger any responses you associated with the white list. For more information on compliance white lists, see Using RNA as a Compliance Tool on page 340. For more information on managing compliance policies, see: •

Activating and Deactivating Compliance Policies on page 446

•

Modifying a Compliance Policy on page 446

•

Deleting a Compliance Policy on page 446

For information on creating new policies, see Creating Compliance Policies on page 439.

Version 4.7


445

Configuring Compliance Policies and Rules Managing Compliance Policies

Chapter 12

Activating and Deactivating Compliance Policies Requires: DC

Use the following procedure to either activate or deactivate a compliance policy. To activate or deactivate a policy:


1.



To activate a policy so that it will generate events and launch associated responses when triggered, click Activate next to the policy.

•

To deactivate a policy so that it will not generate events or launch associated responses when triggered, click Deactivate next to the policy.

Modifying a Compliance Policy Requires: DC

Use the following procedure to modify a compliance policy. To modify a policy:


1.


2. Click Edit next to the policy. The Create Policy page appears. See Creating Compliance Policies on page 439 for information on the various configurations you can change. To remove a rule or white list from a compliance policy, on the Create Policy page, click Delete next to the rule or white list you want to remove. 3. Make changes as needed and click Save. The policy is changed. If the policy is active, the changes you made take effect immediately.

Deleting a Compliance Policy Requires: DC

Use the following procedure to delete a compliance policy. To delete a policy:


1.


2. Click Delete next to the policy you want to delete. The policy is deleted.

Version 4.7


446

Configuring Compliance Policies and Rules Working with Compliance Events

Chapter 12

Working with Compliance Events Requires: DC/MDC

When a compliance rule within an active compliance policy triggers, the Defense Center generates a compliance event and logs it to the database. You can search, view, and delete compliance events. If you are using the Event Streamer to stream compliance events to RNA Visualizer, RNA Visualizer can report compliance policy violations. IMPORTANT! When a compliance white list within an active policy triggers, the Defense Center generates a white list event. For more information, see Working with White List Events on page 378.

TIP! For information on configuring the number of compliance and white list events saved in the database, see Configuring Database Event Limits on page 1197. For more information, see the following sections: •

Viewing Compliance Events on page 447

•

Understanding the Compliance Events Table on page 450

•

Searching for Compliance Events on page 452

Viewing Compliance Events Requires: DC/MDC

You can view a table of compliance events, and then manipulate the event view depending on the information you are looking for. The page you see when you access compliance events differs depending on the workflow you use. You can use the predefined workflow, which includes the table view of compliance events. You can also create a custom workflow that displays only the information that matches your specific needs. For information on creating a custom workflow, see Creating Custom Workflows on page 1179.

Version 4.7


447


Chapter 12

The Compliance Event Actions table below describes some of the specific actions you can perform on an compliance events workflow page. Compliance Event Actions To...

You can...


click the host profile icon that appears next to the IP address.



)that appears next to the user identity. For more

information, see Understanding User Details and Host History on page 1091. sort and constrain events on the current workflow page







find more information in Understanding the Compliance Events Table on page 450.





delete compliance events from the system

use one of the following methods: • To delete some events, select the checkboxes next to the events you want to delete, then click Delete. • To delete all events in the current constrained view, click Delete All, then confirm you want to delete all the events. See Purging the RNA and RUA Databases on page 1232 for information on deleting all RNA events from the database.

Version 4.7


448


Chapter 12

Compliance Event Actions (Continued) To...

You can...











search for compliance events

click Search. For more information, see Searching for Compliance Events on page 452.

To view compliance events: Access: Data or Admin

h

Select Analysis & Reporting > Compliance > Compliance Events. The first page of the default compliance events workflow appears. If you created a custom compliance events workflow and did not specify a default, you must first select one. For information on specifying a default workflow, see Setting Event Preferences on page 35. If no events appear, you may need to adjust the time range. See Setting Event Time Constraints on page 1169 for more information.

Version 4.7


449


Chapter 12

Understanding the Compliance Events Table Requires: DC/MDC

When a compliance rule triggers, the Defense Center generates a compliance event. The fields in the compliance events table are described in the Compliance Event Fields table. Compliance Event Fields

Version 4.7

Field

Description

Time

The date and time that the compliance event was generated.

Impact Flag

The impact flag assigned to the compliance event based on the correlation between IPS data, RNA data, and vulnerability information. For more information, see Using Impact Flags to Evaluate Events on page 686.

Inline Result

A black flag indicates the packet that triggered the event was dropped. If the field is blank, the packet was not dropped. For more information, see Using the Drop Rule State on page 798.

Source IP

The IP address of the source host in the event that triggered the policy violation.

Destination IP

The IP address of the destination host in the event that triggered the compliance rule.

Source User

The name of the user logged in to the source host in the event that triggered the policy violation

Destination User

The name of the user logged in to the destination host in the event that triggered the policy violation

Source Port

The source port associated with the event that triggered the compliance rule.

Destination Port

The destination port associated with the event that triggered the compliance rule.


450


Chapter 12

Compliance Event Fields (Continued) Field

Description

Description

The description of the compliance event. The information in the description depends on how the rule was triggered. For example, if the rule was triggered by an operating system information update event, the new operating system name and confidence level appears. If a new TCP service information event triggered the rule, the port, service name, confidence level, and any service subtypes appear. If the rule was triggered by a new TCP service event, the service port appears.

Policy

The name of the policy that was violated.

Rule

The name of the rule that triggered the policy violation.

Priority

The priority specified by the policy or rule that triggered the policy violation.

Src Host Criticality

The user-assigned host criticality of the source host involved in the compliance event: None, Low, Medium, or High. Note that only compliance events generated by rules based on RNA events, host input events, or flow events contain a source host criticality. For more information on host criticality, see Assigning a Host Criticality Value to a Host on page 201.

Dst Host Criticality

The user-assigned host criticality of the destination host involved in the compliance event: None, Low, Medium, or High. Note that only compliance events generated by rules based on RNA events or flow events contain a destination host criticality. For more information on host criticality, see Assigning a Host Criticality Value to a Host on page 201.

Version 4.7

Detection Engine

The name of the detection engine that generated the event that triggered the compliance rule.

Count

The number of events that match the constraints described in the row. The count field appears on the table view of compliance events only after you apply a constraint to the data.


451


Chapter 12

For more information on displaying the compliance events table, see the following: •

Viewing Compliance Events on page 447.

•


Searching for Compliance Events Requires: DC/MDC

You can search for specific compliance events. You may want to create searches customized for your network environment, then save them to re-use later. The search criteria you can use are described in the Compliance Event Search Criteria table.

Compliance Event Search Criteria Field


Policy

Enter all or part of the name of the policy you want to search for.

Rule

Enter all or parts of the name of the rule you want to search for.

Description

Enter all or part of the compliance event description. The information in the description depends on how the rule was triggered. For example, if the rule was triggered by an operating system information update event, the new operating system name and confidence level appears. If a new TCP service information event triggered the rule, the port, service name, confidence level, and any service subtypes appear. If the rule was triggered by a new TCP service event, the service port appears.

Priority

Specify the priority of the compliance event, which is determined by the priority of the compliance rule whose triggering generated the event, or of the compliance policy that was violated. Enter none for no priority. For information on setting compliance rule and policy priorities, see Providing Basic Policy Information on page 441 and Setting Rule and White List Priorities on page 442.

Source IP

Specify the IP address of the source host in the event that triggered the compliance rule that generated the compliance event. See Specifying IP Addresses in Searches on page 1130 for detailed information about how to enter IP addresses.

Destination IP

Specify the destination IP address of the host or hosts whose compliance events you want to view. Note that only compliance events generated by rules based on intrusion events and flow events contain a destination IP.See Specifying IP Addresses in Searches on page 1130 for detailed information about how to enter IP addresses.

Source User

Specify the name of the user logged in to the source host in the event that triggered the policy violation

Version 4.7


452


Chapter 12

Compliance Event Search Criteria (Continued) Field


Destination User

Specify the name of the user logged in to the destination host in the event that triggered the policy violation

Source Port

Specify the source port associated with the event that triggered the compliance rule. See Specifying Ports in Searches on page 1132 for information about the syntax for specifying ports.

Destination Port

Specify the destination port associated with the event that triggered the compliance rule. See Specifying Ports in Searches on page 1132 for information about the syntax for specifying ports.

Source/Destination IP

Specify the source or destination IP address of the host or hosts whose compliance events you want to view.

Impact Flag

For Defense Centers, specify the impact flag assigned to the compliance event based on the correlation between IPS and RNA data. Valid values are red, orange, yellow, blue, and gray. TIP! You cannot specify a black flag. To specify events generated by drop rules, use Inline Result. For more information, see Using Impact Flags to Evaluate Events on page 686.

Inline Result

If your detection engine uses an inline interface set, specify dropped to view events where the packet was dropped as part of the event. For more information, see Using the Drop Rule State on page 798.

Src Host Criticality

Specify the host criticality of the source host involved in the compliance event: None, Low, Medium, or High. Note that only compliance events generated by rules based on RNA events contain a source host criticality. For more information on host criticality, see Assigning a Host Criticality Value to a Host on page 201.

Dst Host Criticality

Specify the host criticality of the destination host involved in the compliance event: None, Low, Medium, or High. Note that only compliance events generated by rules based on RNA events contain a destination host criticality. For more information on host criticality, see Assigning a Host Criticality Value to a Host on page 201.

Detection Engine

Specify the name of the detection engine, detection engine group, sensor, or sensor group that generated the event that caused the Defense Center to generate the compliance events you want to view. For more information, see Specifying Detection Engine/Appliance Names on page 1133. For more information on searching, including how to load and delete saved searches, see Searching for Events on page 1124.

Version 4.7


453


Chapter 12

To search for compliance events: Access: Data or Admin

1.

Select Analysis & Reporting > Searches > Compliance Events. The Compliance Events search page appears.

TIP! To search the database for a different kind of event, select it from the Table list. 2. Optionally, if you want to save the search, enter a name for the search in the Name field. If you do not enter a name, one is created automatically when you save the search. 3. Enter your search criteria in the appropriate fields, as described in the Compliance Event Search Criteria table. If you enter multiple criteria, the search returns only the records that match all the criteria. 4. If you want to save the search so that other users can access it, clear the Save As Private check box. Otherwise, leave the check box selected to save the search as private. TIP! If you want to save a search as a restriction for restricted data users, you must save it as a private search.

Version 4.7


454


Chapter 12

5. You have the following options: •

Click Search to start the search. Your search results appear in the default compliance events workflow, constrained by the current time range. If you created a custom compliance events workflow and did not specify a preferred workflow, you must select one. For information on specifying a preferred workflow, see Setting Event Preferences on page 35.

Version 4.7

•


•



455

Chapter 12

Configuring Responses for Compliance Policies

You can configure the Defense Center to launch responses to network discovery events (also called RNA events), to intrusion events that have specific impact flag values, and to compliance policy violations. The most basic kind of response you can launch is an alert. Alerts notify you, in one of three ways, of an RNA event, impact flag, or compliance policy violation. You can receive alerts via email, an simple network management protocol (SNMP) trap server, or a syslog server. Another kind of response you can launch is a remediation. A remediation is a program that the Defense Center runs when your network traffic violates a compliance policy. The Sourcefire 3D System ships with predefined remediations, which perform actions such as blocking a host at the firewall or router when it violates a policy or scanning the host. When the Defense Center launches a remediation, it also generates a remediation status event. You can search, view, and delete remediation status events, as you would any other event. The Sourcefire 3D System also provides a flexible API that allows you to create custom remediation modules to respond to compliance policy violations. For example, if you are running a Linux-based firewall, you could write and upload a remediation module that dynamically updates the iptables file on the Linux server so that traffic violating a compliance policy is blocked. For more information about writing your own remediation modules, refer to the Sourcefire Remediation API Guide.

Version 4.7


456

Configuring Responses for Compliance Policies Configuring Alerts

Chapter 13

You can group alerts and remediations so that a compliance policy violation triggers all of the responses within the group. IMPORTANT! You must use a Defense Center to create alerts and assign them to RNA events or impact flags or to configure and use remediations with RNA events. You can also use a Master Defense Center to create alerts and assign them to intrusion events with specific impact flags. For more information, see •

Configuring Alerts on page 457

•

Assigning Notification Alerts to RNA Events on page 468

•

Configuring External Alerting on Impact Flags on page 470

•

Configuring Remediations on page 471

•

Working with Remediation Status Events on page 524

•

Configuring Response Groups on page 530

Configuring Alerts Requires: DC/MDC

Version 4.7

You can create three types of alerts: syslog, email, and SNMP. RNA events, intrusion events that have specific impact flag values, and compliance rules can use these alerts. The information you receive in an alert depends on the type of event that triggered the alert (or, in the case of alerts launched from within compliance policies, the type of event that triggered the compliance policy


457


Chapter 13

violation). The Alert Information table describes the information you receive in alerts. IMPORTANT! If you configure an alert as a response to a compliance rule that contains a flow tracker, the alert information you receive is the same as that for alerts on traffic profile changes, even if the compliance rule is based on a different kind of event. Alert Information Event Type RNA or host input event

Alert Information • the event type • the name of the detection engine that generated the event • the date and time the alert was generated • the IP address of the host involved in the event • a description of the event (for example, if you want to be alerted when RNA detects a new network protocol, the alert includes the name of the protocol) For more information on RNA and host input event types, see Understanding RNA Network Discovery Event Types on page 219 and Understanding RNA Host Input Event Types on page 223.

RUA event

• the date and time the alert was generated • the event type • the user associated with the event • the IP address of the host involved in the event • a description of the event • the name of the detection engine that generated the event For more information on RUA events, see Working with RUA Events on page 1095.

flow event

Version 4.7

none


458


Chapter 13

Alert Information (Continued) Event Type traffic profile change

Alert Information • the date and time the alert was generated • the number of connections open when the compliance rule triggered • the top 5 initiators and the number of connections open for each initiator when the compliance rule triggered • the top 5 responders and the number of connections open for each responder when the compliance rule triggered

white list event

• the date and time the alert was generated • the IP address of the host involved in the event • the port involved in the event, if any • a description of the event

intrusion event

• the rule name • the impact flag value of the event • the name of the detection engine that generated the event • the date and time the alert was generated • a description of the event

Before you can assign alerts to RNA events or compliance policies, you must create them on the Alerts page.

When you create an alert, its type and status appear with its name. The light bulb icon next to the alert indicates whether the alert is active. If you want to launch an alert in response to an event or to a compliance rule, you must activate it first. If the light bulb icon is lit, the alert is active. If it is dark, the alert is inactive. For more information, see Activating and Deactivating Alerts on page 468. The term In Use indicates an alert that is used in a compliance policy or assigned to an RNA event or impact flag, while Not Used indicates an alert that is not in use. Also, you can sort alerts by state (active versus inactive) or alphabetically by name using the Sort by drop-down list.

Version 4.7


459


Chapter 13


Creating Alerts on page 460

•

Modifying Alerts on page 467

•

Deleting Alerts on page 467

•

Activating and Deactivating Alerts on page 468

After you create an alert, launch it in response to an RNA event, an impact flag, or a rule within a compliance policy. For more information, see: •

Assigning Notification Alerts to RNA Events on page 468

•

Configuring External Alerting on Impact Flags on page 470

•

Adding Responses to Rules and White Lists on page 443

Creating Alerts Requires: DC/MDC

You can create three types of alerts to assign to events, impact flags, and rules within compliance policies. For more information, see: •

Creating Syslog Alerts on page 460

•

Creating Email Alerts on page 464

•

Creating SNMP Alerts on page 465

Creating Syslog Alerts Requires: DC/MDC

You can configure the Defense Center to send messages to an external syslog server. As part of the alert you can specify the severity and facility associated with the syslog messages to ensure that they are processed properly by the remote syslog server. The facility indicates the subsystem that creates the message and the severity defines the severity of the message. Facilities and severities are not displayed in the actual message that appears in syslog, but are instead used to tell the system that receives the syslog message how to categorize it. TIP! For more detailed information about how syslog works and how to configure it, refer to the documentation that accompanies your system. If you are logging to a UNIX- or Linux-based system’s syslog, the syslog.conf man file (type man syslog.conf at the command line) and syslog man file (type man syslog at the command line) provide information about how syslog works and how to configure it. You can select any type of facility when creating a syslog alert, but you should be sure to configure a facility that makes sense based on the configuration of the remote syslog server you use. The syslog.conf file located on the remote system (if you are logging syslog messages to a UNIX- or Linux-based system) should indicate which facilities are saved to which log files on the server.

Version 4.7


460


Chapter 13

The Available Syslog Facilities table lists the facilities you can select. Available Syslog Facilities Facility

Description

KERN

A message generated by the kernel. On many systems, these messages are printed to the console when they appear.

USER

A message generated by a user-level process.

MAIL

A message generated by a mail system.

DAEMON

A message generated by a system daemon.

AUTH

A message associated with security and authorization.

SYSLOG

A message generated by the syslog daemon.

LPR

A message generated by the printing subsystem.

NEWS

A message generated by the network news subsystem.

UUCP

A message generated by the UUCP subsystem.

CRON

A message generated by the clock daemon.

AUTHPRIV

A restricted access message associated with security and authorization. On many systems, these messages are forwarded to a secure file.

FTP

A message generated by the FTP daemon.

NTP

A message generated by the NTP daemon.

AUDIT

A message generated by the audit subsystem.

ALERT

An alert message.

CLOCK

A message generated by the clock daemon. IMPORTANT! Some systems use the CLOCK facility and others use CRON. You should be familiar with the configuration of the system where you want to send syslog messages.

LOCAL0LOCAL7

Version 4.7

A message generated by an internal process.


461


Chapter 13

You can select from the following standard syslog severity levels: Syslog Severity Levels Level

Description

EMERG

A panic condition broadcast to all users.

ALERT

A condition that should be corrected immediately.

CRIT

A critical condition.

ERROR

An error condition.

WARN

Warning messages.

NOTICE

Conditions that are not error conditions, but require attention.

INFO

Informational messages.

DEBUG

Messages that contain debugging information.

WARNING! The computer you configure to receive the syslog messages must be set up to accept remote messages. Otherwise, the Defense Center may send syslog messages to the host, but they will not be accepted. To create a syslog alert: Access: Rules or Admin

1.

Select Policy & Response > Responses > Alerts. The Alerts page appears.

2. Click Create Alert. The Create Alert page appears.

Version 4.7


462


Chapter 13

3. From the Choose Type list in the Configure Alerts section, select Syslog. The Create Alert page expands.

4. In the Name field, type the name you want to use to identify the saved response. 5. In the Host field, type the IP address or host name of the server that will receive the syslog alerts. TIP! If you want to specify multiple syslog servers, separate each IP address with a comma. 6. In the Port field, type the port the server uses for syslog messages. By default, this value is 514. 7.

From the Facility list, select the facility you would like to use for syslog alerts. See the Available Syslog Facilities table on page 461 for a list of all available facilities.

8. From the Severity list, select a severity. See the Syslog Severity Levels table on page 462 for a list and description of all available severities. 9. In the Tag field, type the tag name (using alphanumeric characters only) that you want to appear with the syslog message. For example, if you wanted all messages sent to syslog to be preceded with FromDC, type FromDC in the field. IMPORTANT! You can use only alphanumeric characters in tag names. You cannot use spaces and underscores. 10. Select Active to activate the alert so you can use it within a compliance policy or as a response to an RNA event or an impact flag.

Version 4.7


463


Chapter 13

11. Click Save. The syslog alert is saved.

Creating Email Alerts Requires: DC/MDC

You can configure the Defense Center to send an alert via email in response to an RNA event, impact flag, or a compliance policy violation. WARNING! Before you can send email alerts, you must enable DNS and the Defense Center must be able to reverse resolve its own IP address. To create an email alert:


1.



3. From the Choose Type list in the Configure Alerts section, select Email. The Create Alert page expands.

4. In the Name field, type the name you want to use to identify the email alert. 5. In the To field, type the email address (or multiple addresses separated by commas) that you want to receive notifications. 6. In the From field, type the name that will appear as the sender of the notification email.

Version 4.7


464


7.

Chapter 13

In the Relay Host field, verify that the name or IP address of the mail server is the one that you want to use to transmit the alert. The relay host is configured as part of the system policy. If you need to change the mail server, or if you have not yet configured a relay host, click Edit Relay Host. The System Policy page appears in a pop-up window. For detailed information about editing the system policy to configure a relay host, see Configuring a Mail Relay Host and Notification Address on page 1201. Note that you must apply the system policy after you edit it for your changes to take effect.

8. Select Active to activate the alert so that you can use it within a compliance policy or as a response to an RNA event or an impact flag. 9. Click Save. The email alert is saved.

Creating SNMP Alerts Requires: DC/MDC

You can configure the Defense Center to send an alert to an SNMP trap server in response to an RNA event, impact flag, or compliance policy violation. You can configure SNMP alerts using SNMPv1, SNMPv2, or SNMPv3. When you use SNMPv3, RNA uses an Engine ID value to encode the message. Your SNMP server requires this value to decode the message. Currently, this Engine ID value is the hexadecimal version of the Defense Center’s IP address with 01 at the end of the string. For example, if the Defense Center sending the SNMP alert has an IP address of 172.168.1.50, the Engine ID is 0xAC10013201 or if the Defense Center had an IP address of 10.1.1.77, 0x0a01014D01 is used as the Engine ID. TIP! If your network management system requires the Defense Center’s management information base (MIB) file, you can obtain it at /etc/sf/DCEALERT.MIB. To create an SNMP alert:


1.



Version 4.7


465


Chapter 13

3. From the Choose Type list in the Configure Alerts section, select SNMP. The Create Alert page expands.

4. From the Choose Version section, select the SNMP version you want to use. If you selected SNMP v1 or SNMP v2, their options appear.

If you selected SNMP v3, the SNMP v3 options appear.

5. In the Name field, type the name that you want to use to identify the SNMP response. 6. In the Trap Server field, type the name or IP address of the SNMP trap server. 7.

If you selected SNMP v1 or SNMP v2, type the SNMP community name in the Community String field and skip to step 14.

8. If you selected SNMP v3, in the Authentication Password field, type the password required for authentication with the SNMP server. 9. From the Authentication Protocol drop-down list, select the protocol you want to use for authentication. 10. In the Privacy Password field, type the SNMP privacy key required by the SNMP server.

Version 4.7


466


Chapter 13

11. From the Privacy Protocol list, select None to use no privacy protocol or DES to use Data Encryption Standard as the privacy protocol. 12. In the User Name field, type the name of the user that you want to authenticate with the SNMP server. 13. In the Engine ID field, type the identifier for the SNMP engine. 14. Select Active to activate the alert so that you can use it within a compliance policy or as a response to an RNA event or an impact flag. 15. Click Save. The SNMP alert is saved.

Modifying Alerts Requires: DC/MDC

Use the following procedure to modify an alert. To modify an alert:


1.


2. Click Edit next to the alert you want to modify. The Create Alert page appears. 3. Make changes as needed. 4. You have two options. •

Click Save to modify the existing alert. If the alert is active and in use, the changes you made take effect immediately.

•

Click Save as New to create a new alert with the information you specified. Note that to create a new alert, you must change the name.

Deleting Alerts Requires: DC/MDC

You can delete any alert as long as it is not in use, either within a compliance policy or in response to an RNA event or impact flag. To delete an alert:


1.


2. On the Alerts page, click Delete next to the alert you want to delete. The alert is deleted.

Version 4.7


467

Configuring Responses for Compliance Policies Assigning Notification Alerts to RNA Events

Chapter 13

Activating and Deactivating Alerts Requires: DC/MDC

If you want to temporarily disable an alert without deleting it, you can deactivate it. This leaves the alert on the system, but it will not be launched in response to an RNA event, an impact flag, or a compliance policy violation. To enable the alert again, you must activate it. IMPORTANT! Even you deactivate an alert, it is still considered in use and therefore cannot be deleted unless you remove it in all of the places it is used. To deactivate an alert:


1.


2. Click Deactivate next to the alert you want to deactivate. To activate an alert: Access: Rules or Admin

1.


2. Click Activate next to the alert you want to activate.

Assigning Notification Alerts to RNA Events Requires: DC + RNA

After you create alerts as described in Configuring Alerts on page 457, you can configure the Defense Center to send the alerts when it generates specific RNA events. IMPORTANT! You cannot assign response groups to RNA events. You can use response groups only within compliance policies.

Version 4.7


468

Configuring Responses for Compliance Policies Assigning Notification Alerts to RNA Events

Chapter 13

To assign alerts to events: Access: Rules or Admin

1.

Select Policy & Response > Responses > RNA Event Alerts. The RNA Event Alerts page appears.

2. In the Alerts section, select the alert you want to use for each alert type. TIP! You can create alerts by clicking Create next to the type of alert you want to create. For more information, see Creating Alerts on page 460. 3. Next to each event type, select the check boxes that best match the response you want to occur when the event is generated. You can select one or more of the following: •

Syslog Notification to launch the syslog alert you chose.

•

Email Notification to launch the email alert you chose.

•

SNMP Notification to launch the SNMP alert you chose.

To select all events in a column, select the check box that appears in the column header. TIP! For more information about each event type, see Understanding RNA Network Discovery Event Types on page 219 and Understanding RNA Host Input Event Types on page 223. 4. Click Save.

Version 4.7


469

Configuring Responses for Compliance Policies Configuring External Alerting on Impact Flags

Chapter 13

Configuring External Alerting on Impact Flags Requires: DC/MDC + RNA + IPS

If you are managing sensors that are licensed for IPS and RNA, you can configure the system to notify you of events that have specific impact flag values. This allows you to receive notification of events based on how directly they impact your network. You can also send this information to RNA Visualizer. To configure external alerting for events based on impact:


1.

Select Policy & Response > Responses > Impact Flag Alerts. The Impact Flag Alerts page appears.

2. In the Alerts section, select the alert configuration you want to use for each alert type. TIP! You can create alerts by clicking Create next to the type of alert you want to create. For more information, see Creating Alerts on page 460. 3. In the Impact Configuration section, select the check box for each type of notification you want to receive for each impact flag. You can select the following impact flags: •

Unknown (impact flag 0 - gray)

•

Unknown Target (impact flag 4 - blue)

•

Currently Not Vulnerable (impact flag 3 - yellow)

•

Potentially Vulnerable (impact flag 2 - orange)

•

Vulnerable (impact flag 1 - red)

4. Click Save.

Version 4.7


470

Configuring Responses for Compliance Policies Configuring Remediations

Chapter 13

Configuring Remediations Requires: DC + RNA

In addition to alerts, which are simple notifications of an event or a compliance policy violation, you can also configure responses called remediations. Remediations are programs that the Defense Center runs when a compliance policy is violated. These programs use information provided in the event that triggered the violation to perform a specific action. The Sourcefire 3D System ships with four predefined remediation modules: •

The Check Point OPSEC SAM module, which, if you are running Check Point Firewall-1® NG FP3 or higher, allows you to dynamically block traffic sent to or sent from an IP address or network that violates a compliance policy. See Configuring Remediations for Check Point Firewalls on page 473 for more information.

•

The Cisco IOS Null Route module, which, if you are running Cisco routers that use Cisco IOS® Version 12.0 or higher, allows you to dynamically block traffic sent to an IP address or network that violates a compliance policy. See Configuring Remediations for Cisco IOS Routers on page 493 for more information.

•

The Cisco PIX Shun module, which, if you are running Cisco PIX® Firewall Version 6.0 or higher, allows you to dynamically block traffic sent from an IP address that violates a compliance policy. See Configuring Remediations for Cisco PIX Firewalls on page 501 for more information.

•

The Nessus Scanning module, which, if you are running Nessus 2.2.2a on an external Nessus server or if you use the Nessus server on your Defense Center, allows you to actively scan specific targets to determine vulnerabilities on those hosts. See Configuring Nessus Scan Remediations on page 506 for more information.

•

The Nmap Scanning module, which allows you to actively scan specific targets to determine operating systems and services running on those hosts. See Configuring Nmap Remediations on page 514 for more information.

•

The Set Attribute Value module, which allows you to set a host attribute on a host where a compliance event occurs. See Configuring Set Attribute Remediations on page 520.

You can create multiple instances for each remediation module, where each instance represents a connection to a specific appliance. For example, if you have four Cisco IOS routers where you want to send remediations, you should configure four instances of the Cisco IOS remediation module. When you create an instance, you specify the configuration information necessary for the Defense Center to establish a connection with the appliance.

Version 4.7


471


Chapter 13

Then, for each configured instance, you add remediations that describe the actions you want the appliance to perform when a policy is violated. After they are configured, you can add remediations to what are called response groups, or you can assign the remediations specifically to rules within compliance policies. When the system executes these remediations, it generates a remediation status event, which includes details such as the remediation name, the policy and rule that triggered it, and the exit status message. For more information on these events, see Working with Remediation Status Events on page 524. In addition to the default modules that Sourcefire provides, you can write custom remediation modules that perform other specific tasks when policy violations trigger. Refer to the Sourcefire Remediation API Guide for more information about writing your own remediation modules and installing them on the Defense Center. If you are installing a custom module, you can use the Modules page to install, view, and delete new modules. To install a new module on the Defense Center: Access: Rules or Admin

1.

Select Policy & Response > Responses > Remediations > Modules. The Modules page appears.

2. Click Browse to navigate to the location where you saved the file that contains the custom remediation module (refer to the Sourcefire Remediation API Guide for more information). 3. Click Install. The custom remediation module installs. To view or delete a module from the Defense Center: Access: Rules or Admin

Version 4.7

1.

Select Policy & Response > Responses > Remediations > Modules. The Modules page appears.


472


Chapter 13

2. Perform one of the following actions: •

Click View to view the module. The Module Detail page appears.

•

Click Delete next to the module you want to delete. You cannot delete default modules provided by Sourcefire. The remediation module is deleted.

Configuring Remediations for Check Point Firewalls Requires: DC + RNA

Sourcefire provides a Check Point OPSEC SAM remediation module that allows you to install filters on Check Point firewalls when a compliance policy is violated. The Check Point OPSEC SAM remediation module supports Check Point Firewall-1 NG FP3 and higher. IMPORTANT! A destination-based remediation will only work if you configure it to launch when a compliance rule that is based on a flow data event or intrusion event triggers. RNA network discovery events only transmit source hosts. To create remediations for Check Point, use the following steps:


1.

Create an OPSEC application on each Check Point firewall you want to connect to the Defense Center. See Creating the OPSEC Application on page 474 for the procedures.

2. On the Defense Center, add an OPSEC instance for each Check Point firewall. See Adding an OPSEC Instance on page 477 for the procedures. 3. Create specific remediations for each instance, based on the type of response you want to elicit on the firewall when compliance policies are violated. Each available remediation type is described in the following sections:

Version 4.7

•

OPSEC Block To/From Destination IP/Network Remediations on page 481 explains how to block all traffic sent to or received from the destination host or network in a compliance event.

•

OPSEC Block To Destination Service Remediations on page 484 explains how to block service traffic to the destination host in a compliance event. The blocked service is determined by the protocol and port in the event.

•

OPSEC Block To/From Source IP/Network on page 487 explains how to block all traffic sent to or received from the source host or network in a compliance event.

•

OPSEC Block To Source Service on page 490 explains how to block service traffic to the source host in a compliance event. The blocked service is determined by the protocol and port in the event.


473


Chapter 13

4. Begin assigning OPSEC remediations to specific compliance policy rules. TIP! You can clear configured responses from all configured Check Point firewalls at any time. To do this, select Policy & Response > Remediations > Modules. Click the View link that corresponds to the Check Point OPSEC SAM module. On the module details page that appears, click Clear SAM Responses to clear all responses. Note that this clears all responses for all configured Check Point firewall instances.

Creating the OPSEC Application Requires: DC + RNA

Before adding instances to the Check Point OPSEC SAM module and creating remediations, you should create an application for each Defense Center that will send remediations to the Check Point firewall. IMPORTANT! The default port number for an OPSEC SAM server is 18183. For more information on modifying the default port for an OPSEC SAM server, see the Check Point documentation. To create and configure an OPSEC SAM application connection to the Defense Center:


1.

Open the Check Point SmartDashboard™ and, from the Manage menu, select OPSEC Applications. The OPSEC Applications dialog box appears.

Version 4.7


474


Chapter 13

2. Click New and, from the list that appears, select OPSEC Application. The OPSEC Application Properties page appears.

3. Fill in the fields as follows: •

In the Name field, enter the name for the new OPSEC application that you will use to connect to the Defense Center. Spaces and special characters are not allowed in the application name. For example, you could use pr_sam as the application name. Note the name that you specify. You will need to enter it later when adding a remediation instance on the Defense Center.

•

Optionally, enter a comment in the Comment text box and select a color from the Color list. The Comment and Color features are only used by Check Point management software and have no effect on the connection with the Defense Center.

•

In the Host list, select the Defense Center that the firewall will communicate with. If the Defense Center does not appear in the list, click New, enter the Defense Center’s full server name and domain (for example, DCenter.example.com) and IP address and click OK.

Version 4.7

•

Use the default value, User Defined, for Vendor.

•

Make sure all check boxes are disabled under Server Entities.


475


•

Chapter 13

In the Client Entities box, select the SAM check box to indicate that this application will implement Suspicious Activity Monitoring.

4. Click Communication. The Communication dialog box appears.

The Communication dialog box allows you to specify an activation key to be used to ensure a secure transfer of authentication certificates between the Defense Center and the firewall. 5. In the Activation Key and Confirm Activation Key text boxes, enter a password. Note the activation key that you specify. You will need to enter it later when adding a remediation instance on the Defense Center. 6. Click Initialize to create authentication certificates for the application and then click Close. The Communication dialog box closes and the OPSEC Application Properties page appears again. 7.

Click OK to close the OPSEC Application Properties page and then click Close to close the OPSEC Applications dialog box.

8. From the Policy menu on the Check Point SmartDashboard, select Install. The Install Policy dialog box appears.

Version 4.7


476


Chapter 13

9. Select the module, enable Install on each selected Module independently, and click OK. The new policy is installed on the firewall. 10. Click Close to close the Installation Process dialog box. Your firewall is configured for OPSEC SAM communication with the Defense Center. If you have additional Check Point firewalls where you want the Defense Center to send remediations, repeat this procedure for each firewall. Otherwise, continue with Adding an OPSEC Instance to add an instance to the Defense Center.

Adding an OPSEC Instance Requires: DC + RNA

After you have configured an OPSEC application on the Check Point firewall, you can add an instance to the Defense Center. If you have multiple Check Point firewalls you want to send remediations to, you must create separate applications on the firewall (as described in Creating the OPSEC Application on page 474) and add separate instances for each firewall to the Defense Center. To add a Check Point FW-1 instance:


Version 4.7

1.

Select Policy & Response > Responses > Remediations > Instances. The Instances page appears.


477


Chapter 13

2. From the Add a New Instance list, select Check Point OPSEC SAM and click Add. The Instance Detail page appears.

3. In the Instance Name field, enter a name for the instance. The name you choose cannot contain spaces or special characters and should be descriptive. For example, if you intend to connect to more than one Check Point firewall, you will have multiple instances, so you may want to choose a name such as CPFW_01 and CPFW_02. 4. In the Server field, enter the server name (if DNS is enabled) or the IP address of the firewall. 5. Locate your Check Point module distinguished name. •

If you do not know the Check Point module name, continue with step 6 for instructions on locating it.

•

If you already know the Check Point module name, skip to step 10 to enter it.

WARNING! The Check Point module distinguished name is not the same as the Check Point application distinguished name that was created in Creating the OPSEC Application on page 474. The following steps provide detailed information about accessing the module distinguished name. 6. Open the Check Point SmartDashboard.

Version 4.7


478


7.

Chapter 13

From the Manage menu, select Network Objects. The Network Objects dialog box appears.

8. Select the Check Point module (typically cpmodule), and click Edit. The General Properties page for the module appears.

9. Under Secure Internal Communication, select and copy the module’s distinguished name. In this example, the Check Point module DN name is cn=cp_mgmt,o=cpmodule..v6xzhr. This will be different for your Check Point server, but the format should be similar.

Version 4.7


479


Chapter 13

10. In the Check Point Module DN field, enter the Check Point firewall server module distinguished name (also known as the Secure Internal Communication, or SIC, name). WARNING! The Check Point module DN name is not the same as the distinguished name for the application. If you are unsure of the module name, follow steps 6-9 of this procedure to locate it. 11. In the OPSEC Application Name field, enter the name of the application you created in Creating the OPSEC Application on page 474. 12. In the Activation Key fields, enter the activation key you used when creating authentication credentials in Creating the OPSEC Application on page 474. 13. Optionally, in the Firewall Hosts field, enter any specific firewall object defined on the firewall server that you want to use as a target for the remediation. All, Localhost, and Gateways are provided by default for all Check Point firewall remediations. You should only populate this field if there are additional firewall objects you need to use as a remediation target. IMPORTANT! If you use the All option to set up OPSEC SAM responses to use more than one firewall host, and one of the firewall hosts fails, the failure message you receive does not indicate which host failed. As a workaround, you can review the firewall logs of the management firewall server to determine which specific responses failed and which succeeded. 14. Click Create. The instance is created and remediations appear in the Configured Remediations section of the page. You must add specific remediations for them to be used by a compliance policy. See the following sections for more information:

Version 4.7

•

OPSEC Block To/From Destination IP/Network Remediations on page 481

•

OPSEC Block To Destination Service Remediations on page 484

•

OPSEC Block To/From Source IP/Network on page 487

•

OPSEC Block To Source Service on page 490


480


Chapter 13

OPSEC Block To/From Destination IP/Network Remediations Requires: DC + RNA

The Block To/From Destination IP/Network remediation configures your Check Point firewall to filter the destination IP or network that triggered a compliance rule. IMPORTANT! Do not use this remediation as a response to a compliance rule that is based on an RNA event; RNA events only transmit a source host and not a destination host. You can use this remediation in response to compliance rules that are based on flow data events or intrusion events. To add the remediation:


Version 4.7

1.



481


Chapter 13

2. Next to the instance where you want to add the remediation, click View. If you have not yet added an instance, see Adding an OPSEC Instance on page 477. The Instance Detail page appears.

3. In the Configured Remediations section, select Block To/From Destination IP/Network and click Add. The Remediation Edit page appears.

4. In the Remediation Name field, enter a name for the remediation, using no spaces or special characters. 5. Optionally, in the Description field, enter a description for the remediation.

Version 4.7


482


Chapter 13

6. From the Action list, select the action you would like the firewall rule to perform. You can select from the following options:

7.

Action

Description

Notify

All connection attempts are logged as specified in the Logging Level list. Traffic is not impeded.

Inhibit

All connection attempts are rejected. Existing connections will continue to function.

Inhibit and Close

All connection attempts are rejected. Existing connections are closed.

Drop

All connection attempts are dropped. Existing connections will continue to function.

Drop and Close

All connection attempts are dropped. Existing connections are closed.

From the Logging Level list, select one of the following log types: Log Type

Description

None

Does not log SAM responses to this rule.

Log

Performs detailed logging, but does not store the event that caused the SAM response.

Alert

Keeps more detailed logs along with the event that caused the SAM response.

8. From the Firewall Object list, select the firewall object that should receive the remediation. You can select from the predefined values of All, Gateways, or Localhost. You can also select from additional firewall objects that you added using the Firewall Hosts field when creating the instance. See Adding an OPSEC Instance on page 477 for details about adding firewall objects to instances. IMPORTANT! If you use the All option to set up OPSEC SAM responses to use more than one firewall host, and one of the firewall hosts fails, the failure message you receive does not indicate which host failed. As a workaround, you can review the firewall logs of the management firewall server to determine which specific responses failed and which succeeded.

Version 4.7


483


Chapter 13

9. From the Direction list, select the traffic direction you want to filter from the firewall: •

Select To to filter traffic sent to the host or network.

•

Select From to filter traffic sent from the host or network.

•

Select Both to filter traffic in both directions.

10. Optionally, in the Timeout field, enter the number of seconds that the specified action continues after it is initiated by the firewall. The maximum value is 2,147,483 seconds. Specifying a value of 0 (the default) causes the action to continue until it is manually disabled by a firewall administrator. 11. Optionally, in the Netmask field, enter a subnet mask or use CIDR notation to describe the network you want to block. The default is 255.255.255.255 (matches a single IP address). For example, to block an entire Class C network when a single host triggered a rule (this is not recommended), use 255.255.255.0 or 24 as the netmask. As another example, to block 30 addresses that include the triggering IP address, 255.255.255.224 or 27 as the netmask. In this case, if the IP address 10.1.1.15 triggered the remediation, all IP addresses between 10.1.1.1 and 10.1.1.30 are blocked. To block only the triggering IP address, leave the field blank, enter 255.255.255.255, or enter 32. 12. Specify whether the Match Protocol should be enabled or disabled: •

Select On to include the protocol in the firewall configuration. For example, if a UDP packet triggers the remediation, only UDP traffic from the triggering host is filtered.

•

Select Off (the default) to filter all traffic from the triggering host, regardless of protocol.

13. Click Create, then click Done. The remediation is added.

OPSEC Block To Destination Service Remediations Requires: DC + RNA

The Block To Destination Service remediation configures your Check Point firewall to filter traffic sent to a service (protocol and port) running on the destination host. This is the destination host described in the compliance event. IMPORTANT! Do not use this remediation as a response to a compliance rule that is based on an RNA event; RNA events only transmit a source host and not a destination host. You can use this remediation in response to compliance rules that are based on flow data events or intrusion events.

Version 4.7


484


Chapter 13

To add the remediation: Access: Rules or Admin

1.


2. Next to the instance you want to view, click View. If you have not yet added an instance, see Adding an OPSEC Instance on page 477. The Instance Detail page appears. 3. In the Configured Remediations section, select Block To Destination Service and click Add. The Remediation Edit page appears.

4. In the Remediation Name field, enter a name for the remediation, using no spaces or special characters. 5. Optionally, in the Description field, enter a description for the remediation. 6. From the Action list, select the action you would like the firewall rule to perform. You can select from the following options:

Version 4.7

Action

Description

Notify


Inhibit



485


7.

Chapter 13

Action

Description

Inhibit and Close


Drop


Drop and Close



Description

None


Log


Alert


8. From the Firewall Object list, select the firewall object that should receive the remediation. You can select from the predefined values All, Gateways, or Localhost. You can also select from additional firewall objects that you added using the Firewall Hosts field when creating the instance. See Adding an OPSEC Instance on page 477 for details about adding firewall objects to instances. IMPORTANT! If you use the All option to set up OPSEC SAM responses to use more than one firewall host, and one of the firewall hosts fails, the failure message you receive does not indicate which host failed. As a workaround, you can review the firewall logs of the management firewall server to determine which specific responses failed and which succeeded. 9. Optionally, in the Timeout field, enter the number of seconds that the specified action continues after it is initiated by the firewall. The maximum value is 2,147,483 seconds. Specifying a value of 0 (the default) causes the action to continue until it is manually disabled by a firewall administrator.

Version 4.7


486


Chapter 13

10. Optionally, in the Service Netmask field, enter a subnet mask or use CIDR notation to describe the network where you want to filter service access. The default is 255.255.255.255 (filters connections to the service on the IP address that triggered the compliance policy violation). For example, to filter access to the service on any host in the Class C network of the IP address that triggered the rule, use 255.255.255.0 or 24 as the netmask. To filter access to the service on a block of 30 addresses around the IP address that triggered the policy violation, use 255.255.255.224 or 27. 11. Specify whether the Block from IP/Network option is enabled or disabled: •

Select On to filter from the source IP address or network in the event to the service running on the destination IP address.

•

Select Off (the default) to indicate that traffic from the source IP address or network to the destination IP address or network is not filtered.

WARNING! If you want to use this remediation in response to a rule based on an RNA event (which do not have source IP addresses), disable Block from IP/Network. 12. Optionally, in the From Netmask field, enter a subnet mask or use CIDR notation to describe the source network that you want to filter access for. The default is 255.255.255.255 (matches a single IP address). For example, to disallow the entire Class C network that the source IP address belongs to from contacting a service on the destination host, use 255.255.255.0 or 24 as the netmask. As another example, to block 30 addresses that include the source IP address from accessing the destination host’s service, specify 255.255.255.224 or 27 as the netmask. In this case, if the IP address 10.1.1.15 was the source IP address in the event that triggered the remediation, all IP addresses between 10.1.1.1 and 10.1.1.30 are unable to access the service on the destination host. To block only the source IP address, leave the field blank, enter 255.255.255.255, or enter 32. 13. Click Create, then click Done. The remediation is added.

OPSEC Block To/From Source IP/Network Requires: DC + RNA

Version 4.7

The Block To/From Source IP/Network remediation configures your Check Point firewall to filter the source IP or network that triggered the event. If the compliance policy violation was caused by a flow data event or an intrusion event, this is the source IP address in the event. For RNA events, this remediation triggers on the IP address associated with the event.


487


Chapter 13

To add the remediation: Access: Rules or Admin

1.


2. Next to the instance where you want to add the remediation, click View. If you have not yet added an instance, see Adding an OPSEC Instance on page 477. The Instance Detail page appears. 3. In the Configured Remediations section, select Block To/From Source IP/Network and click Add. The Remediation Edit page appears.


Version 4.7

Action

Description

Notify


Inhibit



488


7.

Chapter 13

Action

Description

Inhibit and Close


Drop


Drop and Close



Description

None


Log


Alert


8. From the Firewall Object list, select the firewall object that should receive the remediation. You can select from the predefined values of All, Gateways, or Localhost. You can also select from additional firewall objects that you added using the Firewall Hosts field when creating the instance. See Adding an OPSEC Instance on page 477 for details about adding firewall objects to instances. IMPORTANT! If you use the All option to set up OPSEC SAM responses to use more than one firewall host, and one of the firewall hosts fails, the failure message you receive does not indicate which host failed. As a workaround, you can review the firewall logs of the management firewall server to determine which specific responses failed and which succeeded. 9. Optionally, in the Timeout field, enter the number of seconds that the specified action continues after it is initiated by the firewall. The maximum value is 2,147,483 seconds. Specifying a value of 0 (the default) causes the action to continue until it is manually disabled by a firewall administrator.

Version 4.7


489


Chapter 13

10. From the Direction list, select the traffic direction you want to filter from the firewall: •

Select To to filter traffic sent to the source host or network.

•

Select From to filter traffic sent from the source host or network.

•

Select Both to filter traffic in both directions.

11. Optionally, in the Netmask field, enter a subnet mask or use CIDR notation to describe the network you want to block. The default is 255.255.255.255 (matches a single IP address). For example, to block an entire Class C network when a single host triggers a rule (this is not recommended), use 255.255.255.0 or 24 as the netmask. As another example, to block 30 addresses that include the triggering source IP address, specify 27 or 255.255.255.224 as the netmask. In this case, if the IP address 10.1.1.15 triggers the remediation, all IP addresses between 10.1.1.1 and 10.1.1.30 are blocked. To block only the triggering IP address, leave the field blank, enter 255.255.255.255, or enter 32. 12. Specify whether the Match Protocol should be enabled or disabled: •

Select On to include the protocol specified in the triggering event in the firewall configuration. For example, if a UDP packet triggers the remediation, only UDP traffic from the triggering host is filtered.

•

Select Off (the default) to filter all traffic from the triggering host, regardless of protocol.


OPSEC Block To Source Service Requires: DC + RNA

The Block To Source Service remediation configures your Check Point firewall to filter traffic sent to a service (protocol and port) running on the source host described in the event that triggered the compliance policy violation. If the compliance policy violation was caused by a flow data event or an intrusion event, this is the source IP address in the event. For RNA events, this remediation triggers on the IP address associated with the event. To add the remediation:


1.


2. Next to the instance where you want to add the remediation, click View. If you have not yet added an instance, see Adding an OPSEC Instance on page 477. The Instance Detail page appears.

Version 4.7


490


Chapter 13

3. In the Configured Remediations section, select Block To Source Service and click Add. The Remediation Edit page appears.


Version 4.7

Action

Description

Notify


Inhibit


Inhibit and Close


Drop


Drop and Close



491


7.

Chapter 13


Description

None


Log


Alert


8. From the Firewall Object list, select the firewall object that should receive the remediation. You can select from the predefined values of All, Gateways, or Localhost. You can also select from additional firewall objects that you added using the Firewall Hosts field when creating the instance. See Adding an OPSEC Instance on page 477 for details about adding firewall objects to instances. IMPORTANT! If you use the All option to set up OPSEC SAM responses to use more than one firewall host, and one of the firewall hosts fails, the failure message you receive does not indicate which host failed. As a workaround, you can review the firewall logs of the management firewall server to determine which specific responses failed and which succeeded. 9. Optionally, in the Timeout field, enter the number of seconds that the specified action continues after it is initiated by the firewall. The maximum value is 2,147,483 seconds. Specifying a value of 0 (the default) causes the action to continue until it is manually disabled by a firewall administrator. 10. Optionally, in the Service Netmask field, enter a subnet mask or use CIDR notation to describe the network where you want to filter service access. The default is 255.255.255.255 (filters connections to the service on the IP address that triggered the compliance policy violation). For example, to filter access to the service on any host in the Class C network of the IP address that triggered the rule, use 255.255.255.0 or 24 as the netmask. To filter access to the service on a block of 30 addresses around the IP address that triggered the policy violation, use 255.255.255.224 or 27.

Version 4.7


492


Chapter 13

11. Specify whether the Block from IP/Network option is enabled or disabled: •

Select On to filter from the destination IP address or network in the event to the service running on the source IP address.

•

Select Off (the default) to indicate that traffic from the destination IP address or network to the source IP address or network is not filtered.

WARNING! If you want to use this remediation in response to a rule based on an RNA event (which does not have destination IP addresses), disable Block from IP/Network. 12. Optionally, in the From Netmask field, enter a subnet mask or use CIDR notation to describe the destination network that you want to filter access for. The default is 255.255.255.255 (matches a single IP address). For example, to disallow the entire Class C network that the destination IP address belongs to from contacting a service on the source host, use 255.255.255.0 or 24 as the netmask. As another example, to block 30 addresses that include the destination IP address from accessing the source host’s service, specify 255.255.255.224 or 27 as the netmask. In this case, if the IP address 10.1.1.15 was the destination IP address in the event that triggered the remediation, all IP addresses between 10.1.1.1 and 10.1.1.30 are unable to access the service on the source host. To block only the destination IP address, leave the field blank, enter 255.255.255.255, or enter 32. 13. Click Create, then click Done. The remediation is added.

Configuring Remediations for Cisco IOS Routers Requires: DC + RNA

Version 4.7

Sourcefire provides a Cisco IOS Null Route remediation module that allows you to block a single IP address or an entire block of addresses using Cisco’s “null route” command when a compliance policy is violated. This forwards all traffic sent to the host or network listed as the source or destination host in the event that violated the compliance policy to the router’s NULL interface, causing it to be dropped (note that this will not block traffic sent from the violating host or network).


493


Chapter 13

The Cisco IOS Null Route remediation module supports Cisco routers running Cisco IOS 12.0 and higher. You must have level 15 administrative access to the router to execute Cisco IOS remediations. IMPORTANT! A destination-based remediation only works if you configure it to launch when a compliance rule that is based on a flow data event or intrusion event triggers. RNA network discovery events only transmit source hosts.

WARNING! When a Cisco IOS remediation is activated, there is no timeout period. To remove the blocked IP address or network from the router, you must manually clear the routing change from the router itself. To create remediations for routers running Cisco IOS: Access: Rules or Admin

1.

Enable Telnet on the Cisco router. Refer to the documentation provided with your Cisco router or IOS software for more information about enabling Telnet.

2. On the Defense Center, add a Cisco IOS Null Route instance for each Cisco IOS router you plan to use with the Defense Center. See Adding a Cisco IOS Instance on page 494 for the procedures. 3. Create specific remediations for each instance, based on the type of response you want to elicit on the router when compliance policies are violated. Each available remediation type is described in the following sections: •

Cisco IOS Block Destination Remediations on page 496

•

Cisco IOS Block Destination Network Remediations on page 498

•

Cisco IOS Block Source Remediations on page 499

•

Cisco IOS Block Source Network Remediations on page 500

4. Begin assigning Cisco IOS remediations to specific compliance policy rules.

Adding a Cisco IOS Instance Requires: DC + RNA

Version 4.7

After you configure Telnet access on the Cisco IOS router (refer to the documentation provided with your Cisco router or IOS software for more information about enabling Telnet access), you can add an instance to the Defense Center. If you have multiple routers where you want to send remediations, you must create a separate instance for each router.


494


Chapter 13

To add a Cisco IOS instance: Access: Rules or Admin

1.


2. From the Add a New Instance list, select Cisco IOS Null Route (v1.0) and click Add. The Instance Detail page appears.

3. In the Instance Name field, enter a name for the instance. The name you choose should contain no spaces or special characters and should be descriptive. For example, if you intend to connect more than one Cisco IOS router, you will have multiple instances, so you may want to choose a name such as IOS_01 and IOS_02. 4. In the Router IP field, enter the IP address of the Cisco IOS router you want to use for the remediation. 5. In the Username field, enter the Telnet user name for the router. This user must have level 15 administrative access on the router. 6. In the Connection Password fields, enter the Telnet user’s user password. The password entered in both fields must match. 7.

Version 4.7

In the Enable Password fields, enter the Telnet user’s enable password. This is the password used to enter privileged mode on the router. The password entered in both fields must match.


495


Chapter 13

8. In the White List field, enter IP addresses that you want to exempt from the remediation, one per line. You can also use CIDR notation or a specific IP address. For example, the following white list would be accepted by the system: 10.1.1.152 172.16.1.0/24

Note that this white list is not associated with any compliance white lists you have created. 9. Click Create. The instance is created and remediations appear in the Configured Remediations section of the page. You must add specific remediations for them to be used by compliance policies. See the following sections for more information: •

Cisco IOS Block Destination Remediations on page 496

•

Cisco IOS Block Destination Network Remediations on page 498

•

Cisco IOS Block Source Remediations on page 499

•

Cisco IOS Block Source Network Remediations on page 500

Cisco IOS Block Destination Remediations Requires: DC + RNA

The Cisco IOS Block Destination remediation allows you to block traffic sent from the router to the destination host in a compliance event. IMPORTANT! Do not use this remediation as a response to a compliance rule that is based on an RNA event; RNA events only transmit a source host and not a destination host. You can use this remediation in response to compliance rules that are based on flow data events or intrusion events. To add the remediation:


Version 4.7

1.



496


Chapter 13

2. Next to the instance where you want to add the remediation, click View. If you have not yet added an instance, see Adding a Cisco IOS Instance on page 494. The Instance Detail page appears.

3. In the Configured Remediations section, select Block Destination and click Add. The Remediation Edit page appears.

4. In the Remediation Name field, enter a name for the remediation. The name you choose cannot contain spaces or special characters and should be descriptive. For example, if you have multiple Cisco IOS router instances and multiple remediations for each instance, you may want to specify a name such as IOS_01_BlockDest. 5. Optionally, in the Description field, enter a description of the remediation. 6. Click Create, then click Done. The remediation is added.

Version 4.7


497


Chapter 13

Cisco IOS Block Destination Network Remediations Requires: DC + RNA

The Cisco IOS Block Destination Network remediation allows you to block any traffic sent from the router to the network of the destination host in a compliance event. IMPORTANT! Do not use this remediation as a response to a compliance rule that is based on an RNA event; RNA events only transmit a source host and not a destination host. You can use this remediation in response to compliance rules that are based on flow data events or intrusion events. To add the remediation:


1.


2. Next to the instance where you want to add the remediation, click View. If you have not yet added an instance, see Adding a Cisco IOS Instance on page 494. The Instance Detail page appears. 3. In the Configured Remediations section, select Block Destination Network and click Add. The Remediation Edit page appears.

4. In the Remediation Name field, enter a name for the remediation. The name you choose cannot contain spaces or special characters and should be descriptive. For example, if you have multiple Cisco IOS router instances and multiple remediations for each instance, you may want to specify a name such as IOS_01_BlockDestNet. 5. Optionally, in the Description field, enter a description of the remediation.

Version 4.7


498


Chapter 13

6. In the Netmask field, enter the subnet mask or use CIDR notation to describe the network that you want to block traffic to. For example, to block traffic to an entire Class C network when a single host triggered a rule (this is not recommended), use 255.255.255.0 or 24 as the netmask. As another example, to block traffic to 30 addresses that include the triggering IP address, specify 255.255.255.224 or 27 as the netmask. In this case, if the IP address 10.1.1.15 triggers the remediation, all IP addresses between 10.1.1.1 and 10.1.1.30 are blocked. To block only the triggering IP address, leave the field blank, enter 32, or enter 255.255.255.255. 7.

Click Create, then click Done. The remediation is added.

Cisco IOS Block Source Remediations Requires: DC + RNA

The Cisco IOS Block Source remediation allows you to block any traffic sent from the router to the source host included in a compliance event that violates a compliance policy. The source host is the source IP address in the flow data event or intrusion event upon which the compliance rule is based, or the host IP address in an RNA event. To add the remediation:


1.


2. Next to the instance where you want to add the remediation, click View. If you have not yet added an instance, see Adding a Cisco IOS Instance on page 494. The Instance Detail page appears. 3. In the Configured Remediations section, select Block Source and click Add. The Remediation Edit page appears.

4. In the Remediation Name field, enter a name for the remediation. The name you choose cannot contain spaces or special characters and should be descriptive. For example, if you have multiple Cisco IOS router instances and multiple remediations for each instance, you may want to specify a name such as IOS_01_BlockSrc. 5. Optionally, in the Description field, enter a description of the remediation.

Version 4.7


499


Chapter 13


Cisco IOS Block Source Network Remediations Requires: DC + RNA

The Cisco IOS Block Source Network remediation allows you to block any traffic sent from the router to the network of the source host in a compliance event. The source host is the source IP address in the flow data event or intrusion event upon which the compliance rule is based, or the host IP address in an RNA event. To add the remediation:


1.


2. Next to the instance where you want to add the remediation, click View. If you have not yet added an instance, see Adding a Cisco IOS Instance on page 494. The Instance Detail page appears. 3. In the Configured Remediations section, select Block Source Network and click Add. The Remediation Edit page appears.

4. In the Remediation Name field, enter a name for the remediation. The name you choose should contain no spaces or special characters and should be descriptive. For example, if you have multiple Cisco IOS router instances and multiple remediations for each instance, you may want to specify a name such as IOS_01_BlockSourceNet/ 5. Optionally, in the Description field, enter a description of the remediation.

Version 4.7


500


Chapter 13

6. In the Netmask field, enter the subnet mask or CIDR notation that describes the network that you want to block traffic to. For example, to block traffic to an entire Class C network when a single host triggered a rule (this is not recommended), use 255.255.255.0 or 24 as the netmask. As another example, to block traffic to 30 addresses that include the triggering IP address, specify 255.255.255.224 or 27 as the netmask. In this case, if the IP address 10.1.1.15 triggers the remediation, all IP addresses between 10.1.1.1 and 10.1.1.30 are blocked. To block only the triggering IP address, leave the field blank, enter 32, or enter 255.255.255.255. 7.

Click Create, then click Done. The remediation is added.

Configuring Remediations for Cisco PIX Firewalls Requires: DC + RNA

Sourcefire provides a Cisco PIX Shun remediation module that allows you to block an IP address or network using Cisco’s “shun” command. This blocks all traffic sent from either the source or destination host that violated the compliance policy and closes all current connections (note that this will not block traffic sent through the firewall to the host). The Cisco PIX Shun remediation module supports Cisco PIX Firewall 6.0 and higher. You must have level 15 administrative access or higher to launch Cisco PIX remediations. IMPORTANT! A destination-based remediation only works if you configure it to launch when a compliance rule that is based on a flow data event or intrusion event triggers. RNA network discovery events only transmit source hosts.

WARNING! When a Cisco PIX remediation is activated, no timeout period is used. To unblock the IP address or network, you must manually remove the rule from the firewall. To create remediations for Cisco PIX firewalls: Access: Rules or Admin

1.

Enable Telnet or SSH (Sourcefire recommends SSH) on the firewall. Refer to the documentation provided with your Cisco PIX firewall for more information about enabling SSH or Telnet.

2. On the Defense Center, add a Cisco PIX Shun instance for each Cisco PIX firewall you plan to use with the Defense Center. See Adding a Cisco PIX Instance on page 502 for the procedures.

Version 4.7


501


Chapter 13

3. Create specific remediations for each instance, based on the type of response you want to elicit on the firewall when compliance policies are violated. The available remediation types are described in the following sections: •

Cisco PIX Block Destination Remediations on page 504

•

Cisco PIX Block Source Remediations on page 506

4. Begin assigning Cisco PIX remediations to specific compliance policy rules.

Adding a Cisco PIX Instance Requires: DC + RNA

After you configure SSH or Telnet on the Cisco PIX firewall you can add an instance to the Defense Center. If you have multiple firewalls you want to send remediations to, you must create a separate instance for each firewall. IMPORTANT! Sourcefire recommends that you use an SSH connection instead of a Telnet connection. Data transmitted using SSH is encrypted, making it much more secure than Telnet. To add a Cisco PIX instance:


Version 4.7

1.



502


Chapter 13

2. From the Add a New Instance list, select Cisco PIX Shun and click Add. The Instance Detail page appears.

3. In the Instance Name field, enter a name for the instance. The name you choose cannot contain spaces or special characters and should be descriptive. For example, if you intend to connect more than one Cisco firewall, you will have multiple instances, so you may want to choose a name such as PIX_01, PIX_02, and so on. 4. In the PIX IP field, enter the IP address of the Cisco PIX firewall you want to use for the remediation. 5. In the Connection Password fields, enter the password required to connect to the firewall using SSH or Telnet. The password entered in both fields must match. 6. In the Enable Password fields, enter the SSH or Telnet enable password. This is the password used to enter privileged mode on the firewall. The password entered in both fields must match. 7.

In the White List field, enter IP addresses that you want to exempt from the remediation, one on each line. You can also use CIDR notation or a specific IP address. For example, the following white list is accepted by the system: 10.1.1.152 172.16.1.0/24

Note that this white list is not associated with any compliance white lists you have created. 8. From the Protocol list, select the method you want to use to connect to the firewall.

Version 4.7


503


Chapter 13

9. Click Create. The instance is created and remediations appear in the Configured Remediations section of the page. You must add specific remediations for them to be used in compliance policies. See the following sections for more information: •

Cisco PIX Block Destination Remediations on page 504

•

Cisco PIX Block Source Remediations on page 506

Cisco PIX Block Destination Remediations Requires: DC + RNA

The Cisco PIX Block Destination remediation allows you to block traffic sent from the destination host in a compliance event. IMPORTANT! Do not use this remediation as a response to a compliance rule that is based on an RNA event; RNA events only transmit a source host and not a destination host. You can use this remediation in response to compliance rules that are based on flow data events or intrusion events. To add the remediation:


Version 4.7

1.



504


Chapter 13

2. Next to the instance where you want to add the remediation, click View. If you have not yet added an instance, see Adding a Cisco PIX Instance on page 502. The Instance Detail page appears.

3. In the Configured Remediations section, select Block Destination and click Add. The Remediation Edit page appears.

4. In the Remediation Name field, enter a name for the remediation. The name you choose cannot contain spaces or special characters and should be descriptive. For example, if you have multiple Cisco PIX firewall instances and multiple remediations for each instance, you may want to specify a name such as PIX_01_BlockDest. 5. Optionally, in the Description field, enter a description of the remediation. 6. Click Create, then click Done. The remediation is added.

Version 4.7


505


Chapter 13

Cisco PIX Block Source Remediations Requires: DC + RNA

The Cisco PIX Block Source remediation allows you to block any traffic sent from the source host included in the event that violates a compliance policy. The source host is the source IP address in the flow data event or intrusion event upon which the compliance rule is based, or the host IP address in an RNA event. To add the remediation:


1.


2. Next to the instance where you want to add the remediation, click View. If you have not yet added an instance, see Adding a Cisco PIX Instance on page 502. The Instance Detail page appears. 3. In the Configured Remediations section, select Block Source and click Add. The Remediation Edit page appears.

4. In the Remediation Name field, enter a name for the remediation. The name you choose cannot contain spaces or special characters and should be descriptive. For example, if you have multiple Cisco PIX firewall instances and multiple remediations for each instance, you may want to specify a name such as PIX_01_BlockSrc. 5. Optionally, in the Description field, enter a description of the remediation. The remediation is added.

Configuring Nessus Scan Remediations Requires: DC + RNA

Sourcefire provides a Nessus Scan remediation module that allows you to scan hosts in response to a compliance policy violation. Nessus, an open source vulnerability scanner developed through the Nessus Project (http://www.nessus.org/), uses plugins to test for vulnerabilities on the hosts that it scans. The Sourcefire 3D System integration with Nessus allows you to select the plugins used to scan by enabling or disabling plugin families, which are groups of plugins organized by type. You must configure at least one scan instance that profiles the Nessus server you want to use. You must also define a remediation that sets the parameters used by

Version 4.7


506


Chapter 13

the Nessus server when scanning. When configuring a remediation, you must decide: •

whether to scan the source IP address, the destination IP address, or both IP addresses contained in the event that triggered the compliance policy violation

•

whether to scan all ports on the host or just scan the port from the triggering event

•

which plugin families to use

•

whether to use dangerous plugins in the scan

•

whether to use safe scanning methods (safe checks) on plugins that provide non-intrusive testing methods.

For more information on Nessus plugins and associated settings, see Understanding Nessus Plugins on page 592. When you create a Nessus remediation, the Defense Center automatically creates a scan target for it. This scan target is dynamic; that is, when a remediation launches due to a compliance policy violation, the Defense Center updates it, depending on what kind of event triggered the policy violation and on the settings you configure when you created the remediation: •

If an IDS event or a flow data event triggered the compliance violation, you can configure the Defense Center to add the source IP address, the destination IP address, or both to the dynamic scan target.

•

If an RNA event triggered the violation, the Defense Center adds the IP address of the host involved in the event to the scan target.

This is useful because you can schedule follow-up scans for the list of IP addresses in the scan target to make sure you periodically rescan targets that have been attacked in the past. The dynamic scan target has the same name as its associated remediation, preceded by a double underscore (__). For more information on scan targets, see Selecting Appropriate Scan Targets on page 573 and Managing Scan Targets on page 623. For an example of how a Nessus remediation may be used on your system, see Example: Responding to the Introduction of a New Service on page 606. To create Nessus scan remediations: Access: Rules or Admin

1.

If you do not have an existing external Nessus server, set up the Nessus server on your Defense Center. For more information on starting the server and configuring and activating a Nessus user, see Configuring a Local Nessus Server on page 610.

2. Create a scan instance to define the Nessus server to be used by your scan. For more information on setting up a Nessus server connection profile, see Adding a Nessus Scan Instance on page 508.

Version 4.7


507


Chapter 13

3. Create specific Nessus scan remediations. For more information, see Nessus Scan Remediations on page 510. 4. Begin assigning Nessus scan remediations to specific compliance policy rules.

Adding a Nessus Scan Instance Requires: DC + RNA

You must set up a separate profile (scan instance) for each Nessus server that you want to use to scan your network for vulnerabilities. When you create a scan instance, the Defense Center creates two predefined remediations for it: one remediation that performs a full scan of its scan target and one that performs a portscan. Both remediations enable safe checks and disable dangerous plugins. However, the full scan remediation has all plugin families enabled, while the portscan remediation has all plugin families disabled. The Defense Center automatically creates a scan target for the remediations in the scan instance. This scan target is dynamic; that is, when a remediation launches due to a compliance policy violation, the Defense Center updates it, depending on what kind of event triggered the policy violation and on the settings you configure when you created the remediation. For more information, see Selecting Appropriate Scan Targets on page 573. To use a Nessus server to scan for vulnerabilities, you need to set up a scan instance to define your Nessus server configuration profile. To create a scan instance:


Version 4.7

1.



508


Chapter 13

2. Select Nessus Scans (v1.0) from the Add a module type drop-down list and click Add. The Instance Detail page appears.

3. In the Instance Name field, enter a name of up to 63 characters for the instance. 4. In the Description field, specify a description for the instance of up to 255 characters. 5. In the Host Name field, specify the host name of the Nessus server where you want to configure a connection. •

If you are creating an instance for the Nessus server on the Defense Center, type localhost.

•

If you are creating an instance for a remote Nessus server, type the fully qualified host name or the IP address of the Nessus server.

6. In the Server Port field, specify the port on the Nessus server that should be used for Nessus scans.

7.

•

If you are creating an instance for the Nessus server on the Defense Center, type 1241.

•

If creating an instance for a remote Nessus server, type the port used when starting the session for the Nessus server. The default port for Nessus sessions is 1241.

In the Username and Password fields, specify the user name and password you want to use to connect to the Nessus server. •

If you are creating an instance for the Nessus server on the Defense Center, type the user name and password you configured earlier. For more information on configuring the Nessus user for the local server, see Configuring a Nessus User on page 611.

•

If you are creating an instance for a remote Nessus server, type the user name and password for a user on that server that has rights to scan the target servers and ports you want to scan.

8. Confirm the password.

Version 4.7


509


Chapter 13

9. Click Create. The scan instance is created. The Defense Center also automatically creates two default remediations for the scan instance, one for a full scan with dangerous plugins disabled and the other for a portscan only, and a scan target that corresponds to each remediation. When a remediation initiates a Nessus scan, the IP address list for the scan target for that remediation updates to include the IP address where the compliance event occurred. If you configure the remediation to use ports from events, the target port is also added to the port list for the scan target.

Nessus Scan Remediations Requires: DC + RNA

You can create a Nessus scan remediation to define the settings that the Nessus server uses when a compliance event triggers the remediation and starts a Nessus scan. WARNING! To prevent resource overload, avoid using Nessus scans as a response to events that occur frequently. To create a Nessus scan remediation:


Version 4.7

1.



510


Chapter 13

2. Next to the instance where you want to add the remediation, click View. If you have not yet added an instance, see Adding a Nessus Scan Instance on page 508. The Instance Detail page appears.

Version 4.7


511


Chapter 13

3. Select Perform Scan from the Add a new remediation of type drop-down list and click Add. The Remediation Edit page appears.

4. Type a name for the remediation in the Remediation Name field. 5. Type a description for the remediation in the Description field.

Version 4.7


512


Chapter 13

6. If you plan to use this remediation in response to a compliance rule that triggers on an intrusion event or a flow data event, configure the Scan Which Address(es) From Event option. •

Select Scan Source and Destination Addresses to scan the hosts represented by the source IP address and the destination IP address in the event.

•

Select Scan Source Address Only to scan the host represented by the event’s source IP address.

•

Select Scan Destination Address Only to scan the host represented by the event’s destination IP address.

If you plan to use this remediation in response to a policy violation that triggers on an RNA event, the remediation by default scans the IP address of the host involved in the event; you do not need to configure this option. For more information on compliance rule triggers, see Specifying Compliance Rule Trigger Criteria on page 396. IMPORTANT! Do not assign a Nessus remediation as a response to a compliance rule that triggers on a traffic profile change. The remediation will not launch. 7.

If you plan to use this remediation in response to compliance rules, configure the Use Port From Event option: •

Select On to cause the remediation scan to scan the port affected by the event rather than the port range specified in the remediation definition.

•

Select Off to cause the remediation scan to scan the port range specified in the remediation definition rather than the port affected by the event.

8. Type the ports to be scanned by default when scanning with this remediation in the Port Range field. You can enter a port number, a negation of a port number, a list of ports separated by commas, or a range of port numbers separated by a dash. The following are examples of acceptable syntax: •

80 scans port 80

•

!23 scans all ports except port 23

•

123-443 scans ports 123 through 443

IMPORTANT!

Do not use spaces when specifying port numbers.

9. Type the number of plugin scripts you want to process simultaneously in the Number of checks to perform at the same time field. 10. In the Path to CGIs field, type the path to the location of CGI script files that may be in use on a web server being scanned.

Version 4.7


513


Chapter 13

11. Configure the Safe Checks option: •

To disable parts of safe-check compatible plugins and cause those plugins to use passive testing methods instead of invasive methods, select On.

•

To enable safe-check compatible plugins to use normal testing methods, which may include invasive or dangerous methods, select Off.

For more information on safe checks, see Understanding Safe Checks on page 596. 12. Configure the Enable Dangerous Plugins option: •

To allow scanning using plugins that may crash a scanned host or service, cause data corruption on the target system or service, cause a denial of service condition on the target host or service, or generate a large volume of traffic on the network, select On.

•

To disable use of plugins that may crash a scanned host or service, cause data corruption on the target system or service, cause a denial of service condition on the target host or service, or generate a large volume of traffic on the network, select Off.

For more information on dangerous plugins, see Understanding Dangerous Plugins on page 596. WARNING! Do not enable dangerous plugins for scans targeted at systems critical to your business infrastructure, unless you are testing at a time when it is permissible for those systems to be offline. Never scan using this option without backing up all data on targeted systems prior to running the scan. Sourcefire recommends that you only enable this option in a remediation at the time you plan to run the scan, then immediately disable it when the scan is complete to prevent accidental scans using dangerous plugins. 13. Configure plugin family options, enabling those that you want to use to scan your systems. For more information on the purpose of each individual plugin family, see Understanding Nessus Plugin Families on page 592. 14. Click Save, then click Done.

Configuring Nmap Remediations Requires: DC + RNA

You can respond to a compliance event by scanning the host where the triggering event occurred. You can choose to scan only the port from the event that triggered the compliance event. To set up Nmap scanning in response to a compliance event, you must first create an Nmap scan instance, then add an Nmap scan remediation. You can then configure Nmap scanning as responses to violations of rules within the policy.

Version 4.7


514


Chapter 13

See the following sections: •

Adding an Nmap Scan Instance on page 515

•

Nmap Scan Remediations on page 516

Adding an Nmap Scan Instance Requires: DC + RNA

You can set up a separate scan instance for each Nmap module that you want to use to scan hosts on your network for operating system and service information. You can set up scan instances for the local Nmap module on your Defense Center and for any sensors you want to use to run scans remotely. The results of each scan are always stored on the Defense Center where you configure the scan, even if you run the scan from a remote sensor. To prevent accidental or malicious scanning of mission-critical hosts, you can create a blacklist for the instance to indicate the hosts that should never be scanned with the instance. Note that you cannot add a scan instance with the same name as any existing scan instance, including Nessus scan instances. To create a scan instance:


1.


2. Select Nmap Remediation (v1.0) from the Add a module type drop-down list and click Add. The Instance Detail page appears.

3. In the Instance Name field, enter a name that includes 1 to 63 alphanumeric characters, with no spaces and no special characters other than underscore (_) and dash (-). 4. In the Description field, specify a description that includes 0 to 255 alphanumeric characters, including spaces and special characters.

Version 4.7


515


Chapter 13

5. Optionally, in the Black Listed Scan hosts field, specify any hosts or networks that should never be scanned with this scan instance, using the following syntax: •

an exact IP address (for example, 192.168.1.101)

•

an IP address range using CIDR notation (for example, 192.168.1.1/24 scans the 256 hosts between 192.168.10.0 and 192.168.10.255, inclusive)

If you specifically target a scan to a host that is in a blacklisted network, that scan will not run. 6. Optionally, to run the scan from a remote sensor instead of the Defense Center, specify the name or IP address of the sensor in the Remote Sensor Name field. Click Create.

7.

The scan instance is created.

Nmap Scan Remediations Requires: DC + RNA

When you use an Nmap scan as a response to a compliance rule, you can configure which address in the event is scanned using the Scan Which Address(es) From Event option. In addition, you can choose from two scan types for your Nmap scans: •

the TCP Syn Scan connects quickly to thousand of ports without using a complete TCP handshake. This options allows you to scan quickly in stealth mode on hosts where the root account has raw packet access or where IPv6 is not running, by initiating TCP connections but not completing them. If a host acknowledges the Syn packet sent in a TCP Syn scan, Nmap resets the connection.

•

the TCP Connect Scan uses the connect() system call to open connections through the operating system on the host. You can use the TCP Connect scan if the root user on your Defense Center or remote 3D Sensor does not have raw packet privileges on a host or you are scanning IPv6 networks. In other words, use this option in situations where the TCP Syn scan cannot be used.

By default, Nmap scans more than 1660 TCP ports. To modify the ports scanned by the remediation, you can use the following options:

Version 4.7

•

If you plan to use the remediation as a response in a compliance policy, select Use Port From Event to cause the remediation to scan only the port specified in the event that triggers the compliance response.

•

Select Fast Port Scan to scan only the TCP ports listed in the nmap-services file located in the /usr/local/sf/nmap/share/nmap/nmap-services directory on the sensor that does the scanning, ignoring other port settings.


516


Chapter 13

•

Select Scan for UDP ports to scan UDP ports in addition to TCP ports. Note that scanning UDP ports may be time-consuming, so avoid using that option if you want to scan quickly.

•

Type specific ports in the Port Ranges and Scan Order option, using Nmap port specification syntax, to identify specific ports.

You can also control whether or not Nmap collects information about operating system and service information: •

Enable the Use Port From Event option to scan the port associated with the new service.

•

Enable Detect Operating System to detect operating system information for the host.

•

Enable Probe open ports for vendor and version information to detect service vendor and version information.

Once Nmap replaces a host’s operating system or services detected by RNA with the results from an Nmap scan, RNA no longer updates the information replaced by Nmap for the host. Nmap-supplied service and operating system data remains static until you run another Nmap scan. If you plan to scan a host using Nmap, you may want to set up regularly scheduled scans to keep any Nmap-supplied operating system and service data up to date. For more information, see Automating Nmap Scans on page 1325. If the host is deleted from the network map and re-detected by RNA, any Nmap scan results are discarded and RNA resumes monitoring of all operating system and service data for the host. WARNING! To prevent resource overload, avoid using Nmap scans as a response to events that occur frequently. To create a Nmap remediation: Access: Rules or Admin

Version 4.7

1.



517


Chapter 13

2. Click View next to the scan instance where you want to add a remediation. The Edit Instance page appears.

3. Select Nmap Scan from the Add a new remediation of type drop-down list and click Add. The Edit Remediation page appears.

4. In the Remediation Name field, type a name for the remediation that includes 1 to 63 alphanumeric characters, with no spaces and no special characters other than underscore (_) and dash (-). 5. In the Description field, type a description for the remediation that includes 0 to 255 alphanumeric characters, including spaces and special characters.

Version 4.7


518


Chapter 13

6. If you plan to use this remediation in response to a compliance rule that triggers on an intrusion event or a flow data event, configure the Scan Which Address(es) From Event option. •


•


•


If you plan to use this remediation in response to a compliance rule that triggers on an RNA event, by default the remediation scans the IP address of the host involved in the event; you do not need to configure this option. IMPORTANT! Do not assign a Nmap remediation as a response to a compliance rule that triggers on a traffic profile change. 7.

Configure the Scan Type option: •

To scan quickly in stealth mode on hosts where the root account has raw packet access or where IPv6 is not running, by initiating TCP connections but not completing them, select TCP Syn Scan.

•

To scan by using a system connect() call, which can be used on hosts where the root account on your Defense Center does not have raw packet access or where IPv6 is running, select TCP Connect Scan.

8. Optionally, to scan UDP ports in addition to TCP ports, select On for the Scan for UDP ports option. TIP! A UDP port scan takes more time than a TCP port scan. To speed up your scans, leave this option disabled. 9. If you plan to use this remediation in response to compliance policy violations, configure the Use Port From Event option: •

Select On to scan the port in the compliance event, rather than the ports you specify in step 12. If you scan the port in the compliance event, note that the remediation scans the port on the IP addresses that you specified in step 6. These ports are also added to the remediation’s dynamic scan target.

•

Version 4.7

Select Off to scan only the ports you will specify in step 12.


519


Chapter 13

10. If you plan to use this remediation in response to compliance policy violations, configure the Scan from reporting detection engine option: •

To scan from the appliance running the reporting detection engine, select On.

•

To scan from the appliance configured in the remediation, select Off.

11. Configure the Fast Port Scan option: •

To only scan ports listed in the nmap-services file located in the /usr/local/sf/nmap/share/nmap/nmap-services directory on the sensor that does the scanning, ignoring other port settings, select On.

•

To scan all TCP ports, select Off.

12. In the Port Ranges and Scan Order field, type the ports you want to scan by default, using Nmap syntax, in the order you want to scan those ports. Separate ports using commas or use a hyphen to indicate a port range. When scanning for both TCP and UDP ports, preface the list of TCP ports you want to scan with a T and the list of UDP ports with a U. For example, to scan ports 53 and 111 for UDP traffic, then scan ports 21-25 for TCP traffic, enter U:53,111,T:21-25. Note that the Use Port From Event option overrides this setting when the remediation is launched in response to a compliance policy violation, as described in step 9. 13. Set Probe open ports for vendor and version information to On to detect service vendor and version information. 14. To set the intensity of the service scan, select a number from the Service Version Intensity drop-down list. 15. To configure scanning for operating system information, configure Detect Operating System settings: •

Select On to scan the host for information to identify the operating system.

•

Select Off to continue using RNA operating system information for the host.

16. Click Save, then click Done. The remediation is created.

Configuring Set Attribute Remediations Requires: DC + RNA

Version 4.7

You can respond to a compliance event by setting a host attribute value on the host where the triggering event occurred. For text host attributes, you can choose to use the description from the event as the attribute value. For more information on host attributes, see Working with the Predefined Host Attributes on page 201 and Working with User-Defined Host Attributes on page 202.


520


Chapter 13

To configure setting an attribute value in response to a compliance event, you must first create a set attribute instance, then add a set attribute remediation. You can then configure attribute value updates as responses to violations of rules within the policy. For more information, see the following sections: •

Adding a Set Attribute Value Instance on page 521

•

Set Attribute Value Remediations on page 522

Adding a Set Attribute Value Instance Requires: DC + RNA

You can set up an instance to set attribute values in response to compliance rule violations. To create a set attribute instance:


1.


2. Select Set Attribute Value (v1.0) from the Add a module type drop-down list and click Add. The Instance Detail page appears.

3. In the Instance Name field, enter a name that includes 1 to 63 alphanumeric characters, with no spaces and no special characters other than underscore (_) and dash (-). 4. In the Description field, specify a description that includes 0 to 255 alphanumeric characters, including spaces and special characters. 5. Click Create. The instance is created.

Version 4.7


521


Chapter 13

Set Attribute Value Remediations Requires: DC + RNA

You can create a set attribute value remediation for each attribute value you want to be able to set in response to a compliance rule violation. If the attribute you want to set is a text attribute, you can set the remediation to use the description from the event as the attribute value. To create a set attribute value remediation:


1.


2. Click View next to the scan instance where you want to add a remediation. The Edit Instance page appears.

Version 4.7


522


Chapter 13

3. Select Set Attribute Value from the Add a new remediation of type drop-down list. The Remediation Edit page appears.

4. In the Remediation Name field, type a name for the remediation that includes 1 to 63 alphanumeric characters, with no spaces and no special characters other than underscore (_) and dash (-). 5. In the Description field, type a description for the remediation that includes 0 to 255 alphanumeric characters, including spaces and special characters. 6. If you plan to use this remediation in response to a compliance rule that triggers on an intrusion event, RUA event, or a flow data event, configure the Update Which Host(s) From Event option. •

Select Update Source and Destination Hosts to update the attribute value on the hosts represented by the source IP address and the destination IP address in the event.

•

Select Update Source Host Only to update the attribute value on the host represented by the event’s source IP address.

•

Select Update Destination Host Only to update the attribute value on the host represented by the event’s destination IP address.

If you plan to use this remediation in response to a compliance rule that triggers on an RNA event or host input event, by default the remediation scans the IP address of the host involved in the event; you do not need to configure this option. 7.

Configure the Use Description From Event For Attribute Value (text attributes only) option: •

To use the description from the event as the attribute value, select On.

•

To use the Attribute Value setting for the remediation as the attribute value, select Off.

8. If you are not planning to use the event description, type the attribute value you want to set in the Attribute Value field.

Version 4.7


523

Configuring Responses for Compliance Policies Working with Remediation Status Events

Chapter 13


Working with Remediation Status Events Requires: DC + RNA

When a remediation triggers, a remediation status event is generated. These events are logged to the database and can be viewed on the Remediation Status page. You can search, view, and delete remediation status events. For more information, see: •

Viewing Remediation Status Events on page 524

•

Searching for Remediation Status Events on page 527

Viewing Remediation Status Events Requires: DC + RNA

The page you see when you access remediation status events differs depending on the workflow you use. You can use the predefined workflow, which includes a table view of remediations. The table view contains a row for each remediation status event. You can also create a custom workflow that displays only the information that matches your specific needs. For information on creating a custom workflow, see Creating Custom Workflows on page 1179. The Remediation Status Actions table below describes some of the specific actions you can perform on a remediation status events workflow page. Remediation Status Actions

Version 4.7

To...

You can...


find more information in Understanding the Remediation Status Table on page 525.


see Setting Event Time Constraints on page 1169.

sort and constrain the events

see Constraining Events on page 1170 and Sorting Workflow Pages and Changing Their Layout on page 1174.

temporarily use different workflow


navigate to the compliance events view to see associated events

click Compliance Events. For more information, see Navigating between Workflows on page 1175.


524


Chapter 13

Remediation Status Actions (Continued) To...

You can...





generate a report based on the data in the table view


delete remediation status events from the system

use one of the following methods: • To delete some events, select the checkboxes next to events you want to delete, then click Delete. • To delete all events in the current constrained view, click Delete All, then confirm you want to delete all the events.

search for remediation status events

click Search. For more information, see Searching for Remediation Status Events on page 527.

To view remediation status events: Access: Data or Admin

h

Select Policy & Response > Responses > Remediations > Status. The first page of your default workflow appears. If you created a custom Remediations workflow and did not specify a default on the Event View Settings page, you must first select one, as described in Selecting Workflows on page 1162. See Setting Event Preferences on page 35 for more information on how to specify a default workflow. If no events appear, you may need to adjust the time range. See Setting Event Time Constraints on page 1169 for more information.

Understanding the Remediation Status Table Requires: DC + RNA

Version 4.7

You can configure the Defense Center to launch a variety of responses to policy violations and to RNA network discovery events. These responses include remediations, such as blocking a host at the firewall or router when it violates a policy. When a remediation triggers, a remediation status event is generated and logged to the database. For more information on remediations, see Configuring Responses for Compliance Policies on page 456.


525


Chapter 13

The fields in the remediation status table are described in the Remediation Status Fields table. Remediation Status Fields Field

Description

Policy

The name of the compliance policy that was violated and triggered the remediation.

Remediation Name

The name of the remediation that was launched.

Result Message

A message that describes what happened when the remediation was launched. Status messages include: • Successful completion of remediation • Error in the input provided to the remediation module • Error in the remediation module configuration • Error logging into the remote device or service • Unable to gain required privileges on remote device or service • Timeout logging into remote device or service • Timeout executing remote commands or services • The remote device or service was unreachable • The remediation was attempted but failed • Failed to execute remediation program • Unknown/unexpected error IMPORTANT! If custom remediation modules are installed, you may see additional status messages that are implemented by the custom module.

Version 4.7

Rule

The name of the rule that triggered the remediation.

Time

The date and time that the Defense Center launched the remediation


526


Chapter 13

To display the table view of remediation status events: Access: Data or Admin

h

Select Policy & Response > Responses > Remediations > Status. The table view appears. For information on working with remediation status events, see Working with Remediation Status Events on page 524. TIP! If you are using a custom workflow that does not include the table view of remediation status events, click Workflows. On the Select Workflow page, click Remediation Status.

Searching for Remediation Status Events Requires: DC + RNA

Version 4.7

You can search for remediation status events to determine when and if a particular remediation was launched. You may want to create searches customized for your network environment, then save them to re-use later. The search criteria you can use are described in the Remediation Status Search Criteria table.


527


Chapter 13

Remediation Status Search Criteria Search Field

Description

Result Message

Enter the exact name of the result message (a message that describes what happened when the remediation was launched) you want to match. Valid status messages are: • Successful completion of remediation • Error in the input provided to the remediation module • Error in the remediation module configuration • Error logging into the remote device or service • Unable to gain required privileges on remote device or service • Timeout logging into remote device or service • Timeout executing remote commands or services • The remote device or service was unreachable • The remediation was attempted but failed • Failed to execute remediation program • Unknown/unexpected error IMPORTANT! If you installed custom remediation modules, you may be able to enter additional status messages implemented by the custom module.

Time

Specify the date and time the Defense Center launched the remediation. See Specifying Time Constraints in Searches on page 1130 for the syntax for entering time.

Remediation Name

Enter the exact name of the remediation that was launched. This is the name you specified when you created the remediation.

Policy

Enter the name of the compliance policy that triggered the remediation.

Rule

Enter the name of the compliance rule that triggered the remediation. For more information on searching, including how to load and delete saved searches, see Searching for Events on page 1124.

Version 4.7


528


Chapter 13

To search for remediation status events: Access: Data or Admin

1.

Select Analysis & Reporting > Searches > Remediation Status. The Remediation Status search page appears.

TIP! To search the database for a different kind of event, select it from the Table list. 2. Optionally, if you want to save the search, enter a name for the search in the Name field. If you do not enter a name, one is automatically created when you save the search. 3. Enter your search criteria in the appropriate fields, as described in the Remediation Status Search Criteria table. If you enter multiple criteria, the search returns only the records that match all the criteria. 4. If you want to save the search so that other users can access it, clear the Save As Private check box. Otherwise, leave the check box selected to save the search as private. TIP! If you want to save a search as a restriction for restricted data users, you must save it as a private search. 5. You have the following options: •

Click Search to start the search. Your search results appear in the default remediation status workflow, constrained by the current time range. If you created a custom remediation status workflow and did not specify a preferred workflow, you must select one. For information on specifying a preferred workflow, see Setting Event Preferences on page 35.

Version 4.7


529

Configuring Responses for Compliance Policies Configuring Response Groups

Chapter 13

•


•


Configuring Response Groups Requires: DC + RNA

You can group alerts and remediations so that a policy violation triggers all of the responses within the group. IMPORTANT! Response groups can only be used within compliance policies. You cannot assign them to launch in response to RNA events on the RNA Event Alerts page or impact flags on the Impact Flag Alerts page. Before you can assign response groups to compliance policies, you must create the groups on the Groups page.

The light bulb icon next to the group indicates whether the group is active. If you want to assign a response group to a rule within a compliance policy, you must activate it. If the light bulb icon is lit, the group is active. If it is dark, the group is inactive. For more information, see Activating and Deactivating Response Groups on page 532. You can sort response groups by state (active versus inactive) or alphabetically by name using the Sort by drop-down list. See the following sections for more information: •

Creating a Response Group on page 530

•

Modifying a Response Group on page 531

•

Deleting a Response Group on page 532

•

Activating and Deactivating Response Groups on page 532

Creating a Response Group Requires: DC + RNA

Version 4.7

You can place individual alerts and remediations in response groups, which can then be assigned to rules within compliance policies so that a group of alerts and remediations can be launched when a policy is violated. After a group has been assigned to rules in active policies, changes to the group and to alerts or remediations within the group are automatically applied to active policies.


530


Chapter 13

To create a response group: Access: Rules or Admin

1.

Select Policy & Response > Responses > Groups. The Groups page appears.

2. Click Create Group. The Groups page expands.

3. Under Response Group Information, in the Name field, enter a name for the new group. 4. Select Active to activate the group so that you can use it in response to a compliance policy violation. 5. Under Select Responses for Group, from the Available Responses list, select the alerts and remediations you want to include in the group. TIP! Hold down the Ctrl key while clicking to select multiple responses. 6. Click > to move alerts and remediations into the group. Conversely, you can select alerts and remediations from the Responses in Group list and click < to move the alerts out of the response group. 7.

Click Save. The group is created.

Modifying a Response Group Requires: DC + RNA

Use the following procedure to modify a response group. To modify a response group:


1.


2. Click Edit next to the group you want to modify. The Groups page reloads with the information for the group you chose.

Version 4.7


531


Chapter 13

3. Make changes as needed and click Save. If the group is active and in use, the changes you made take effect immediately.

Deleting a Response Group Requires: DC + RNA

You can delete a response group as long as it is not in use within a compliance policy. Deleting a response group does not delete the responses in the group, just their association with each other. To delete a response group:


1.


2. Click Delete next to the group you want to delete. The response group is deleted.

Activating and Deactivating Response Groups Requires: DC + RNA

If you want to temporarily disable a response group without deleting it, you can deactivate it. This leaves the group on the system but does not launch it when a policy to which the group is assigned is violated. To enable the group again, you must activate it. IMPORTANT! Even if you deactivate a group, it is still considered in use and cannot be deleted unless you remove it from the compliance policies where it is applied. To deactivate an alert:


h

On the Groups page, click Deactivate next to the group you want to deactivate.

To activate an alert: Access: Rules or Admin

Version 4.7

h

On the Groups page, click Activate next to the group you want to activate.


532

Chapter 13

Enhancing RNA Detection

The Sourcefire 3D System collects data from your network in a variety of ways, including IPS, RNA, scanners such as Nmap and Nessus, and user input through the host input feature, which uses an import file or an API interface to import data from a third-party application or allows users to set specific data for a host using the web interface. The collected information is most valuable to you when the Sourcefire 3D System can correlate the results of all possible sources of information to identify the hosts on your network that are most vulnerable and most important. As an example, if you have several devices on your network running a customized version of SuSE Linux, RNA cannot identify that operating system and so cannot map vulnerabilities to the hosts. However, knowing that RNA has a list of vulnerabilities for SuSE Linux, you may want to create a custom fingerprint for one of the hosts that can then be used to identify the other hosts running the same operating system. You can include a mapping of the vulnerability list for SuSE Linux in the fingerprint to associate that list with each host that matches the fingerprint. The Sourcefire 3D System also allows you to input host data from third-party systems directly into the network map, using the host input feature. However, third-party operating system or service data does not automatically map to RNA vulnerability information. If you want to see vulnerabilities and perform impact correlation for hosts using third-party operating system and service data, you must map the vendor and version information from the third-party system to the vendor and version listed in the RNA vulnerability database (VDB). You also must maintain the host input data on an ongoing basis (or until you delete the affected host from the network map and RNA re-detects it).

Version 4.7


533

Enhancing RNA Detection Assessing Your Detection Strategy

Chapter 14

If RNA cannot identify services running on hosts on your network, you can create custom service detectors for the services that allow RNA to identify them based on a port or a pattern. You can also replace RNA detection of operating system and service data using scan results from the Nmap active scanner or augment the RNA vulnerability lists with Nessus vulnerabilities or third-party vulnerabilities. Note, however, that Nmap data, like host input data, overrides RNA monitoring for the item, so Nmap data must be actively maintained using regularly scheduled scans. For more information on active scanning, see Configuring Active Scanning on page 571.

Assessing Your Detection Strategy Requires: DC + RNA

Before you make any changes to RNA’s default detection capabilities, you should analyze what hosts are not being identified correctly and why, so you can decide what solution to implement. Use the following as a guide for your decision: •

Are Your Sensors Correctly Placed? on page 534

•

Do Unidentified Operating Systems Have a Unique TCP Stack? on page 534

•

Can RNA Identify All Services? on page 535

•

Have You Applied Patches that Fix Vulnerabilities? on page 535

•

Do You Want to Track Third-Party Vulnerabilities? on page 536

Are Your Sensors Correctly Placed? Requires: DC + RNA

If network devices such as load balancers, proxy servers, or NAT devices reside between the 3D Sensor with RNA and the unidentified or misidentified host, place a sensor closer to the misidentified host rather than using custom fingerprinting. Sourcefire does not recommend using custom fingerprinting in this scenario.

Do Unidentified Operating Systems Have a Unique TCP Stack? Requires: DC + RNA

If RNA misidentifies a host, you should investigate why the host is misidentified to help you decide between creating and activating a custom fingerprint or substituting Nmap or host input data for RNA data. WARNING! If you encounter misidentified hosts, contact your support representative before creating custom fingerprints. If a host is running an operating system that is not detected by RNA by default (see Detected Operating Systems on page 1433 for a list of detected operating systems and kernels) and does not share identifying TCP stack characteristics with existing detected operating systems, you should create a custom fingerprint.

Version 4.7


534

Enhancing RNA Detection Assessing Your Detection Strategy

Chapter 14

For example, if you have a customized version of Linux with a unique TCP stack that RNA cannot identify, you would benefit from creating a custom fingerprint, which allows RNA to identify the host and continuing monitoring it, rather than using scan results or third-party data, which require you to actively update the data yourself on an ongoing basis. Note that many open source Linux distributions use the same kernel, and as such, RNA identifies them using the Linux kernel name. If you create a custom fingerprint for a Red Hat Linux system, you may see other operating systems (such as Debian Linux, Mandrake Linux, Knoppix, etc.) identified as Red Hat Linux, because the same fingerprint matches multiple Linux distributions. You should not use a fingerprint in every situation. For example, a modification may have been made to a host’s TCP stack so that it resembles or is identical to another operating system. For example, an Apple Mac OS X host is altered, making its fingerprint identical to a Linux 2.4 host, causing RNA to identify it as Linux 2.4 instead of Mac OS X. If you create a custom fingerprint for the Mac OS X host, it may cause all legitimate Linux 2.4 hosts to be erroneously identified as Mac OS X hosts. In this case, if Nmap correctly identifies the host, you could schedule regular Nmap scans for that host. If you import data from a third-party system using host input, you must map the vendor, product, and version strings that the third-party application uses to describe products to the RNA definitions for those products. For more information, see Managing Third-Party Product Mappings on page 561. Remember that once you override RNA detection capabilities for an operating system or service, whether through an Nmap scan or the host input feature, you have to maintain that data yourself. For Nmap data, you can schedule regular Nmap scans. For host input data, you can regularly run the Perl script for the import or the command line utility. However, note that active scan data and host input data may not be updated with the frequency of RNA data.

Can RNA Identify All Services? Requires: DC + RNA

If a host is correctly identified by RNA but has unidentified services, you can use a custom service detector to provide RNA with port and pattern matching information to help identify the service. For more information, see Detecting Custom Services on page 552.

Have You Applied Patches that Fix Vulnerabilities? Requires: DC + RNA

Version 4.7

If RNA correctly identifies a host but does not reflect applied fixes, you can use the host input feature to import patch information. When you import patch information, you must map the fix name to a fix in the RNA database. For more information, see Mapping Third-Party Product Fixes on page 564.


535

Enhancing RNA Detection Using Custom Fingerprinting

Chapter 14

Do You Want to Track Third-Party Vulnerabilities? Requires: DC + RNA

If you have vulnerability information from a third-party system that you want to use for impact correlation, you can map the third-party vulnerability identifiers to vulnerability identifiers in the RNA database and then import the vulnerabilities using the host input feature. For more information on using the host input feature, see the Sourcefire 3D System Host Input API Guide. For more information on mapping third-party vulnerabilities, see Mapping Third-Party Vulnerabilities on page 566.

Using Custom Fingerprinting Requires: DC + RNA

The Sourcefire 3D System includes operating system fingerprints that RNA uses to identify the operating system on each host it detects. However, sometimes RNA cannot identify a host operating system or misidentifies it because no fingerprints exist that match the operating system. To correct this problem, you can create a custom fingerprint, which provides a pattern of operating system characteristics unique to the unknown or misidentified operating system, to supply the name of the operating system for identification purposes. If RNA cannot match a host’s operating system, it cannot identify the vulnerabilities for the host, because RNA derives the list of vulnerabilities for each host from its operating system fingerprint. For example, if RNA detects a host running Microsoft Windows, RNA has a stored Microsoft Windows vulnerability list that it adds to the host profile for that host based on the detected Windows operating system. As an example, if you have several devices on your network running a new beta version of Microsoft Windows, RNA cannot identify that operating system and so cannot map vulnerabilities to the hosts. However, knowing that RNA has a list of vulnerabilities for Microsoft Windows, you may want to create a custom fingerprint for one of the hosts that can then be used to identify the other hosts running the same operating system. You can include a mapping of the vulnerability list for Microsoft Windows in the fingerprint to associate that list with each host that matches the fingerprint. When you create a custom fingerprint, you can add a customized display of operating system information, and you can select the operating system vendor, product name, and product version for the operating system which RNA should use as a model for the vulnerability list for the fingerprint. The Defense Center lists the set of vulnerabilities associated with that fingerprint for any hosts running the same operating system. If the custom fingerprint you create does not have any vulnerabilities mappings in it, RNA uses the fingerprint to assign the custom operating system information you provide in the fingerprint. When RNA sees new traffic from a host that has already been detected and currently resides in the network map, RNA updates the host with the new fingerprint information. RNA

Version 4.7


536


Chapter 14

also uses the new fingerprint to identify any new hosts with that operating system the first time they are detected. IMPORTANT! When using the Sourcefire Sensor on Nokia, you cannot use the sensor to generate a custom fingerprint. Use the Defense Center to generate the fingerprint instead. Before attempting to fingerprint a host, you should determine why the host is not being identified correctly to decide whether custom fingerprinting is a viable solution. For more information, see Assessing Your Detection Strategy on page 534. You can create two types of fingerprints with RNA: •

Client fingerprints, which identify operating systems based on the SYN packet that the host sends when it connects to a TCP service running on another host on the network. See Fingerprinting Clients on page 537 for information about how to obtain a client fingerprint for a host.

•

Server fingerprints, which identify operating systems based on the SYNACK packet that the host uses to respond to an incoming connection to a running TCP service. See Fingerprinting Servers on page 543 for information about how to obtain a server fingerprint for a host.

After creating fingerprints, you must activate them before RNA can associate them with hosts. See Managing Fingerprints on page 549 for more information. IMPORTANT! If both a client and server fingerprint match the same host, the client fingerprint is used.

Fingerprinting Clients Requires: DC + RNA

Client fingerprints identify operating systems based on the SYN packet a host sends when it connects to a TCP service running on another host on the network. IMPORTANT! You must use the Defense Center to obtain fingerprints. The Sourcefire Sensor on Nokia is not able to gather fingerprint data.

Version 4.7


537


Chapter 14

Before you begin the fingerprinting process, obtain the following information about the host you want to fingerprint: •

The number of network hops between the host and the Defense Center you use to obtain the fingerprint. (Sourcefire highly recommends that you directly connect the Defense Center to the same subnet that the host is connected to.)

•

The network interface (on the Defense Center) that is connected to the network where the host resides.

•

The actual operating system vendor, product, and version of the host.

•

Access to the host in order to generate client traffic. WARNING! Sourcefire recommends that you do not use a sensing interface on the 3D Sensor for fingerprinting for several reasons. First, fingerprinting will not work if the sensing interface is on a span port. Also, if you use the sensing interface on the sensor, the sensor stops monitoring the network for the amount of time it takes to collect the fingerprint. You can, however, use the management interface or any other available network interfaces to collect fingerprints, so long as the interface you choose can access the host you want to fingerprint. See the Installation Guide for the specific model you are using for information about its network interfaces.

To obtain a client fingerprint for a host: Access: Rules or Admin

1.

Select Operations > Tools > Custom Fingerprinting. The Custom Fingerprinting page appears.

2. Click Create Custom Fingerprint. The Create Custom Fingerprint page appears.

3. From the Select A Sensor list, select the Defense Center.

Version 4.7


538


Chapter 14

4. In the Fingerprint Name field, type an identifying name for the fingerprint.

5. In the Fingerprint Description field, type a description for the fingerprint. 6. From the Fingerprint Type list, select Client. 7.

In the Target IP Address field, type the IP address of the host you want to fingerprint.

8. In the Target Distance field, enter the number of network hops between the host and the device that you selected in step 3 to collect the fingerprint. WARNING! This must be the actual number of physical network hops to the host, which may or may not be the same as the number of hops detected by RNA. 9. From the Interface list, select the network interface that is connected to the network segment where the host resides.

Version 4.7


539


Chapter 14

10. If you want to display custom information in the host profile for fingerprinted hosts (or if the host you want to fingerprint does not reside in the OS Vulnerability Mappings section), select Use Custom OS Display in the Custom OS Display section and provide the values you want to display in host profiles for the following: •

In the Vendor String field, type the operating system’s vendor name. For example, the vendor for Microsoft Windows would be Microsoft.

•

In the Product String field, type the operating system’s product name. For example, the product name for Microsoft Windows 2000 would be Windows.

•

In the Version String field, type the operating system’s version number. For example, the version number for Microsoft Windows 2000 would be 2000.

11. In the OS Vulnerability Mappings section, select the operating system, product, and versions you want to use for vulnerability mapping from the following lists (if applicable):

Version 4.7

•

Vendor (required if you want to map vulnerabilities for the host or if you do not specify a custom operating system display)

•

Product (required if you select a vendor)

•

Major Version

•

Minor Version

•

Revision Version

•

Build


540


Chapter 14

•

Patch

•

Extension

For example, if you want your custom fingerprint to assign the list of vulnerabilities from Redhat Linux 9 to matching hosts, select Redhat, Inc. as the vendor, Redhat Linux as the product, and 9 as the major version.

TIP! When creating a fingerprint, you assign a single vulnerability mapping for the fingerprint. After the fingerprint is created and activated, you can add additional vulnerability mappings for other versions of the operating system. See Editing an Active Fingerprint on page 552 for more information. You must specify a Vendor and Product name in this section if you want to use the fingerprint to identify vulnerabilities for matching hosts or if you do not assign custom operating system display information. To map vulnerabilities for all versions of an operating system, specify only the vendor and product name. For example, to add all versions of the Palm OS, you would select PalmSource, Inc. from the Vendor list, Palm OS from the Product list, and leave all other lists at their default settings. IMPORTANT! Not all options in the Major Version, Minor Version, Revision Version, Build, Patch, and Extension drop-down lists may apply to the operating system you choose. In addition, if no definition appears in a list that matches the operating system you want to fingerprint, you can leave these values empty. Be aware that if you do not create any OS vulnerability mappings in a fingerprint, RNA cannot use the fingerprint to assign a vulnerabilities list with hosts identified by the fingerprint. The following graphic shows an example of a completed client fingerprint:

Version 4.7


541


Chapter 14

12. Click Submit. The Custom Fingerprinting status page re-appears. The status page refreshes every ten seconds until it receives data from the host in question. TIP! When you click Submit, the status briefly shows New, then switches to Pending, where it remains until traffic is seen for the fingerprint, then the status switches to Ready.

Version 4.7


542


Chapter 14

13. Access the host you are trying to fingerprint and initiate a TCP connection to the Defense Center. For example, access the web interface of the Defense Center from the host you want to fingerprint or SSH into the Defense Center from the host. The Custom Fingerprinting page should then reload with a “Ready” status. IMPORTANT! To create an accurate fingerprint, traffic must be seen by the Defense Center collecting the fingerprint. If you are connected through a switch, traffic to a system other than the Defense Center may not be seen by RNA. 14. After the fingerprint is created, you must activate it before the Defense Center can use it to identify hosts. See Managing Fingerprints on page 549 for more information.

Fingerprinting Servers Requires: DC + RNA

Server fingerprints identify operating systems based on the SYN-ACK packet that the host uses to respond to an incoming connection to a running TCP service. Before you begin, you should obtain the following information about the host you want to fingerprint: •

The number of network hops between the host and the Defense Center you use to obtain the fingerprint. Sourcefire highly recommends that you directly connect an unused interface on the Defense Center to the same subnet that the host is connected to.

•

The network interface (on the Defense Center) that is connected to the network where the host resides.

•

The actual operating system vendor, product, and version of the host.

•

An IP address that is not currently in use and is authorized on the network where the host is located.

IMPORTANT! You must use the Defense Center to obtain fingerprints. The Sourcefire Sensor on Nokia is not able to gather fingerprint data. To obtain a server fingerprint for a host: Access: Rules or Admin

Version 4.7

1.



543


Chapter 14

2. Click Create Custom Fingerprint. The Create Custom Fingerprint page appears.

3. From the Select A Sensor list, select the Defense Center.

4. In the Fingerprint Name field, type an identifying name for the fingerprint.

5. In the Fingerprint Description field, type a description for the fingerprint. 6. From the Fingerprint Type list, select Server. Server fingerprinting options appear.

7.

Version 4.7

In the Target IP Address field, type the IP address of the host you want to fingerprint.


544


Chapter 14

8. In the Target Distance field, enter the number of network hops between the host and the device that you selected in step 3 to collect the fingerprint. WARNING! This must be the actual number of physical network hops to the host, which may or may not be the same as the number of hops detected by RNA. 9. From the Interface list, select the network interface that is connected to the network segment where the host resides. 10. Click Get Active Ports. If RNA has detected any open ports on the host, they appear in the dropdown list. 11. In the Server Port field, type the port that you want the device selected to collect the fingerprint to initiate contact with, or select a port from the Get Active Ports drop-down list. You can use any server port that you know is open on the host (for instance, 80 if the host is running a web server). 12. In the Source IP Address field, type an IP address that should be used to attempt to communicate with the host.

You should use a source IP address that is authorized for use on the network but is not currently being used, for example, a DHCP pool address that is currently not in use. This prevents you from temporarily knocking another host offline while you create the fingerprint. In addition, you should exclude that IP address from monitoring in your RNA detection policy while you create the fingerprint. Otherwise, the network map and RNA event views will be cluttered with inaccurate information about the host represented by that IP address. For more information, see Configuring RNA Detection Policies on page 134. 13. In the Source Subnet Mask field, type the subnet mask for the IP address you are using. 14. If the Source Gateway field appears, enter the default gateway IP address that should be used to establish a route to the host. The Source Gateway field appears if the target distance (number of hops) is 1 or higher and you are using an interface other than the management interface to connect to the network where the host resides.

Version 4.7


545


Chapter 14

15. If you want to display custom information in the host profile for fingerprinted hosts or if the fingerprint name you want to use does not exist in the OS Definition section, select Use Custom OS Display in the Custom OS Display section.

Provide the values you want to appear in host profiles for the following: •

In the Vendor String field, type the operating system’s vendor name. For example, the vendor for Microsoft Windows would be Microsoft.

•

In the Product String field, type the operating system’s product name. For example, the product name for Microsoft Windows 2000 would be Windows.

•

In the Version String field, type the operating system’s version number. For example, the version number for Microsoft Windows 2000 would be 2000.

16. In the OS Vulnerability Mappings section, select the operating system, product, and versions you want to use for vulnerability mapping from the following lists (if applicable):

Version 4.7

•

Vendor

•

Product

•

Major Version

•

Minor Version

•

Revision Version

•

Build


546


Chapter 14

•

Patch

•

Extension

For example, if you want your custom fingerprint to assign the list of vulnerabilities from Redhat Linux 9 to matching hosts, select Redhat, Inc. as the vendor, Redhat Linux as the product, and 9 as the version.

TIP! When creating a fingerprint, you assign a single vulnerability mapping for the fingerprint. After the fingerprint is created and activated, you can add additional vulnerability mappings for other versions of the operating system. See Editing an Active Fingerprint on page 552 for more information. You must specify a Vendor and Product name in this section if you want to use the fingerprint to identify vulnerabilities for matching hosts or if you do not assign custom operating system display information. To map vulnerabilities for all versions of an operating system, specify only the vendor and product name. For example, to add all versions of the Palm OS, you would select PalmSource, Inc. from the Vendor list, Palm OS from the Product list, and leave all other lists at their default settings. IMPORTANT! Not all options in the Major Version, Minor Version, Revision Version, Build, Patch, and Extension drop-down lists may apply to the operating system you choose. In addition, if no definition appears in a list that matches the operating system you want to fingerprint, you can leave these values empty. Be aware that if you do not create any OS vulnerability mappings in a fingerprint, RNA cannot use the fingerprint to assign a vulnerabilities list with hosts identified by the fingerprint. The following graphic shows an example of a completed server fingerprint:

Version 4.7


547


Chapter 14

17. Click Submit. The Custom Fingerprinting status page appears. It reloads every ten seconds and should reload with a “Ready” status. IMPORTANT! If the target system stops responding during the fingerprinting process, the status shows an ERROR: No Response message. If you see this message, submit the fingerprint again. Wait three to five minutes (the time period may vary depending on the target system), click Edit to access the Custom Fingerprinting page, and then click Submit.

Version 4.7


548


Chapter 14

18. After the fingerprint is created, activate it and, optionally, add vulnerability mappings. See Managing Fingerprints on page 549 for more information.

Managing Fingerprints Requires: DC + RNA

You can activate, deactivate, delete, view, and edit custom fingerprints. When creating a fingerprint, you assign a single vulnerability mapping for the fingerprint. For more information on creating a fingerprint, see Fingerprinting Clients on page 537 and Fingerprinting Servers on page 543. After the fingerprint is created and activated, you can edit the fingerprint to make changes or add vulnerability mappings. To access the Custom Fingerprints page:


h


You can refresh the page at any time by clicking Refresh Status. In addition, if the system is awaiting data to create a fingerprint, it automatically refreshes the page every 10 seconds until the fingerprint is created. See the following sections for more information: •

Activating Fingerprints on page 549

•

Deactivating Fingerprints on page 550

•

Deleting Fingerprints on page 550

•

Editing Fingerprints on page 551

Activating Fingerprints Requires: DC + RNA

After creating a custom fingerprint, you must activate it before RNA can use it to identify hosts. After the new fingerprint is activated, RNA uses it to re-identify previously discovered hosts and discover new hosts. To activate a fingerprint:


Version 4.7

1.



549


Chapter 14

2. Click Activate next to the fingerprint you want to activate. The Defense Center activates the fingerprint. The lightbulb icon next to the fingerprint name changes to a lit lightbulb icon.

Deactivating Fingerprints Requires: DC + RNA

If you want to stop using a fingerprint, you can deactivate it. Deactivating a fingerprint allows a fingerprint to no longer be used, but allows it to remain on the system. When you deactivate a fingerprint, the operating system is marked as unknown for hosts that use the fingerprint. If the hosts are detected again and match a different active fingerprint, they are then identified by that active fingerprint. Deleting a fingerprint removes it from the system completely. After deactivating a fingerprint, you can delete it. To deactivate an active fingerprint:


1.


2. Click Deactivate next to the active fingerprint you want to deactivate. The Defense Center deactivates the fingerprint.

Deleting Fingerprints Requires: DC + RNA

If you no longer have use for a fingerprint, you can delete it from the system. Note that you must deactivate fingerprints before you can delete them. To delete a fingerprint:


1.


2. If the fingerprints you want to delete are active, click Deactivate next to each one to deactivate it. 3. Click Delete next to the fingerprint.

Version 4.7


550


Chapter 14

4. Click OK to confirm that you want to delete the fingerprint. The fingerprint is deleted.

Editing Fingerprints Requires: DC + RNA

After you create a fingerprint, you can view or edit it. This allows you to make changes and resubmit the fingerprint or add additional vulnerability mappings to it. You can modify fingerprints whether they are active or inactive, but depending on a fingerprint’s state, the things that can be modified differ. If a fingerprint is inactive, you can modify all elements of the fingerprint and resubmit it to the Defense Center. This includes all properties you specified when creating the fingerprint, such as fingerprint type, target IP addresses and ports, vulnerability mappings, and so on. When you edit an inactive fingerprint and submit it, it is resubmitted to the system and, if it is a client fingerprint, you must re-send traffic to the Defense Center before activating it. Note that you can select only a single vulnerability mapping for an inactive fingerprint. After you activate the fingerprint, you can map additional operating systems and versions to its vulnerabilities list. If a fingerprint is active, you can modify the fingerprint name, description, custom operating system display, and map additional vulnerabilities to it. For more information, see the following sections: •

Editing an Inactive Fingerprint on page 551

•

Editing an Active Fingerprint on page 552

Editing an Inactive Fingerprint Requires: DC + RNA

If a fingerprint is inactive, you can modify its properties and resubmit it to the system. This includes making changes such as the type of fingerprint to use, the target system to fingerprint, and so on. To edit inactive fingerprints:


1.


2. Click Edit next to the fingerprint you want to edit. The Edit Custom Fingerprint page appears. 3. Make changes to the fingerprint as necessary:

Version 4.7

•

If you are modifying a client fingerprint, see Fingerprinting Clients on page 537 for more information about the options you can configure.

•

If you are modifying a server fingerprint, see Fingerprinting Servers on page 543 for more information about the options you can configure.


551

Enhancing RNA Detection Detecting Custom Services

Chapter 14

4. Click Submit to re-submit the fingerprint. IMPORTANT! If you modified a client fingerprint, remember to send traffic from the host to the Defense Center gathering the fingerprint.

Editing an Active Fingerprint Requires: DC + RNA

When a fingerprint is active, you can change its name, description, and display label. In addition, you can manage vulnerability mappings, including adding and deleting vulnerability mappings. To edit active fingerprints:


1.


2. Click Edit next to the fingerprint you want to edit. The Edit Custom Fingerprint Product Mappings page appears. 3. Modify the fingerprint name, description, and custom OS display, if necessary. 4. If you want to delete a vulnerability mapping, click Delete next to the mapping in the Pre-Defined OS Product Maps section of the page. 5. If you want to add additional operating systems for vulnerability mapping, select the Product and, if applicable, the Major Version, Minor Version, Revision Version, Build, Patch, and Extension and then click Add OS Definition. The vulnerability mapping is added to the Pre-Defined OS Product Maps list. 6. Click Save to save your changes.

Detecting Custom Services Requires: DC + RNA

When RNA analyzes IP traffic, it collects information about the services used by hosts on your network. RNA uses built-in service detectors to identify service traffic for commonly used services. If you use custom services on your network, or if you use non-standard ports for services on your network, you can augment RNA’s service detection capabilities by creating custom service detectors that provide RNA with the information it needs to identify non-standard services. You can base custom service detection on the port used by service traffic, or a pattern within the traffic, or on both the port and the pattern. For example, if you expect traffic for a custom service to use port 1180, you can create a service detector that detects traffic on that port. As another example, if you know that the header for any packet containing service traffic has a string of “ServiceName” in it, you can create a service detector that registers the ASCII string of “ServiceName” as a pattern to match. If you know both the port and a pattern for

Version 4.7


552


Chapter 14

the service traffic, you can create a service detector that uses both criteria; this increases the likelihood of correctly identifying traffic for that service. If you provide a pattern to match in a custom service detector or if you provide both a port and a pattern, RNA uses that service detector to process traffic in the same way that it uses built-in service detectors. If you specify only a port or ports for the custom service detector, that port is added to a list of custom service ports. When service traffic does not match any of the built-in service detectors or custom service detectors that contain patterns, RNA checks the custom service port list. If the port for the traffic matches an entry on the list, RNA assigns that service identification to service traffic using that port. Note that while custom service detectors collect service information and add it to host profiles, that service information is not used to correlate host data with intrusion events. You cannot specify a version or vendor for a custom service, so vulnerability information cannot be assigned to a host based on a custom service. For more information on host profiles, see Using Host Profiles on page 172. IMPORTANT! You can configure custom service detectors on a Defense Center that does not have an RNA host license installed, but you must add the license before RNA can use the detectors. For more information, see the following sections: •

Creating a Service Detector on page 553

•

Managing Service Detectors on page 556

Creating a Service Detector Requires: DC + RNA

RNA provides several predefined custom service detectors. You can also create new service detectors for any additional services you want to identify on your network. TIP! You can export a service detector group, then import it on another appliance using the Import/Export tool. For more information, see Creating Service Detector Groups on page 558 and Importing and Exporting Objects on page 1248. To create a custom service detector:


Version 4.7

1.

Select Policy & Response > RNA > Custom Service Detectors. The Custom Service Detectors page appears.


553


Chapter 14

2. Click Add Detector. The Edit Service Detector page appears.

3. In the Name field, type the name of the new service detector. 4. In the Description field, type a description for the new service detector. 5. From the Group drop-down list, select the group for the service detector. TIP! To copy settings from another service detector, click Copy Settings, select the source service detector from the Copy Settings From drop-down list in the pop-up window that appears, then click Copy. Note that you cannot create two service detectors that inspect traffic on the same port; after you copy the settings you must change the port that the service detector inspects before you save it. 6. From the Protocol drop-down list, select the protocol for traffic the service detector should check. 7.

Version 4.7

Optionally, to identify service traffic based on the port it uses, type the port in the Ports field. To use multiple ports, separate them by commas or spaces


554


Chapter 14

8. Do you want to inspect traffic for matches to a particular pattern that occurs in traffic for that service? •

If no, skip to step 13.

•

If yes, click Add Pattern.

9. Select ASCII to match against an ASCII format text string or HEX to match against a binary string in hexadecimal format. 10. Enter a string of the type you specified in the Pattern String field. 11. To specify where RNA should begin searching for the pattern match in a packet, select the Use Offset check box, then use the Offset field to specify the offset (in bytes) from the beginning of the packet payload. Note that because packet payloads start at byte 0, calculate the offset by subtracting 1 from the number of bytes you want to move forward from the beginning of the packet payload. For example, to look for the pattern in the fifth bit of the packet, type 4 in the Offset field. 12. Optionally, repeat steps 8 to 11 to add additional patterns. If you add multiple patterns, the service traffic must match all of the patterns for RNA to identify the custom service. 13. Do you want to test the service detector against the contents of a PCAP file? •


•

If yes, click Add PCAP to upload a PCAP file that contains packets with traffic from the service you want to match against. A pop-up window appears.

14. Browse to the PCAP file and click Upload. The PCAP file appears in the PCAP file list.

15. To test your service detector against the contents of the PCAP file, click Evaluate next to the PCAP file. A message appears, indicating whether the test succeeded. 16. Optionally, repeat steps 13 to 15 to test the service detector against additional PCAP files.

Version 4.7


555


Chapter 14

17. Click Save to save the service detector. The service detector is saved. IMPORTANT! You must activate the service detector before RNA can use it to analyze service traffic. For more information, see Activating and Deactivating Service Detectors on page 556.

Managing Service Detectors Requires: DC + RNA

You manage custom service detectors on the Custom Service Detectors page. You can modify, delete, activate, and deactivate service detectors. You can also create groups to help you organize service detectors. A custom service detector’s status appears with its name. If the light bulb icon next to the service detector name is lit, the service detector is active. If it is dark, the service detector is inactive. If you want RNA to use the detector to analyze service traffic, you must activate it.


Activating and Deactivating Service Detectors on page 556

•

Modifying Service Detectors on page 557

•

Deleting Service Detectors on page 557

•

Creating Service Detector Groups on page 558

•

Modifying Service Detector Groups on page 558

•

Deleting Service Detector Groups on page 559

Activating and Deactivating Service Detectors Requires: DC + RNA

You must activate a custom service detector before RNA can use it to analyze service traffic. To activate or deactivate a service detector:


1.


2. If the service detector you want to activate or deactivate is in a group, click the folder icon next to the group name to expand the group.

Version 4.7


556


Chapter 14


To activate a service detector, so that RNA will use it when analyzing service traffic, click Activate next to the service detector.

•

To deactivate a service detector so that RNA will not use it when analyzing service traffic, click Deactivate next to the service detector.

Modifying Service Detectors Requires: DC + RNA

You cannot edit an active custom service detector; you must first deactivate it. For more information, see Activating and Deactivating Service Detectors on page 556. To modify a custom service detector:


1.


2. If the service detector you want to modify is in a group, click the folder icon next to the group name to expand the group. 3. Next to the service detector you want to modify, click Edit. The Edit Service Detector page appears. See Creating a Service Detector on page 553 for information on the various configurations you can change. 4. Make changes to the service detector and click Save. TIP! If you are editing a predefined service decoder, you can click Restore Original Settings to reset it to factory defaults. Note that this also reactivates the service decoder. Your service detector is updated. IMPORTANT! If you want RNA to use the modified custom service detector to analyze service traffic, you must activate it. For more information, see Activating and Deactivating Service Detectors on page 556.

Deleting Service Detectors Requires: DC + RNA

Use the following procedure to delete a custom service detector. To delete a custom service detector:


1.


2. If the service detector you want to delete is in a group, click the folder icon next to the group name to expand the group.

Version 4.7


557


Chapter 14

3. Next to the service detector you want to delete, click Delete. 4. Click OK to confirm that you want to delete the service detector. The service detector is deleted.

Creating Service Detector Groups Requires: DC + RNA

Create custom service detector groups to help you organize service detectors. The Sourcefire 3D System ships with many default service detectors, which are grouped according to the protocol they use (either TCP or UDP). You can add a service detector to an existing group when you create the service detector, modify an existing service detector to add it to a different group, or specify which service detectors belong to a group by modifying the group. To create a custom service detector group:


1.


2. Click Add Group. The Create Custom Service Detector Group page appears.

3. In the Group Name field, type a name for the group. 4. Click Create. The group is created.

Modifying Service Detector Groups Requires: DC + RNA

Modify a custom service detector group to specify which service detectors belong to it. Note that a service detector can only belong to one group at a time. If you want to move a grouped service detector to another group, you must either: •

edit the service detector as described in Modifying Service Detectors on page 557

•

use the following procedure to remove the service detector from the original group, then again to add it to the new group

To modify a custom service detector group: Access: Rules or Admin

Version 4.7

1.



558

Enhancing RNA Detection Importing Host Input Data

Chapter 14

2. Next to the group you want to modify, click Edit. The Edit Custom Service Detector Group page appears. The list on the left contains the service detectors currently in the group. The Available Custom Service Detectors list contains any ungrouped service detectors.


To move a service detector out of the group, select it from the list on the left, then click the right arrow (>) button.

•

To move a service detector into the group, select it from the Available Custom Service Detectors list, then click the left arrow ( RNA > Custom Service Detectors. The Custom Service Detectors page appears.

2. Next to the group you want to delete, click Delete. 3. Click OK to confirm that you want to delete the group. The group is deleted and service detectors that were in that group become ungrouped.

Importing Host Input Data Requires: DC + RNA

Version 4.7

If your organization has the capability to write scripts or create command line import files to import host data from third-party applications, you can import data to augment the information in the RNA network map. You can also use the host


559


Chapter 14

input feature by modifying operating system or service identities or deleting services, protocols, host attributes, or client applications using the web interface. Note, however, that when you overwrite RNA data with host input data, RNA no longer monitors that data. If you update data for a host using the host input feature, you must periodically re-input data to maintain that data yourself. To reset RNA management of data, delete the host where the data resides from the network map and allow RNA to re-detect it. All data except third-party vulnerabilities is discarded when the affected host is removed from the network map. For more information on setting up scripts or import files, see the Sourcefire 3D System Host Input API Guide. To include imported data in impact correlations, you must map the data to the operating system and service definitions in the RNA database. For more information, see the following sections: •

Managing Third-Party Product Mappings on page 561

•

Mapping Third-Party Vulnerabilities on page 566

•

Managing Custom Product Mappings on page 567

Enabling Use of Third-Party Data Requires: DC + RNA

You can import network map data from third-party systems on your network. However, to enable features where IPS and RNA data are used together, such as RNA recommended rules or impact assessment, you should map as many elements of it as possible to corresponding definitions. Consider the following requirements for using third-party data: •

Version 4.7

If you have a third-party application that has more specific data on the operating systems or services running on hosts on your network, you can import that data using the host input feature. However, because third-party applications may name the products differently, you must map the thirdparty application vendor, product, and versions to the corresponding RNA product definition. After you map the products, you must enable RNA


560


Chapter 14

vulnerability mappings for impact assessment in the RNA settings in the system policy to allow impact correlation. For more information, see Mapping Third-Party Products on page 561 and Configuring RNA Settings on page 1204. •

If you import patch information from a third-party application and you want to mark all vulnerabilities fixed by that patch as invalid, you must map the third-party fix name to a fix definition in the RNA database. All vulnerabilities addressed by the fix will then be removed from hosts where you add that fix. For more information, see Mapping Third-Party Product Fixes on page 564.

•

If you import vulnerabilities from a third-party application and you want to use them for impact correlation, you must map the third-party vulnerability identification string to vulnerabilities in the RNA database. After the vulnerabilities are mapped, you must enable third-party vulnerability mappings for impact assessment in the RNA settings in the system policy. For more information, see Mapping Third-Party Vulnerabilities on page 566 and Configuring RNA Settings on page 1204.

•

If you import service data and you want to use that data for impact correlation, you must map the vendor string for each service to the corresponding RNA service definition. For more information, see Managing Custom Product Mappings on page 567.

Managing Third-Party Product Mappings Requires: DC + RNA

When you add data from third-party applications to the network map through the user input feature, you must map the vendor, product, and version names used by the third-party application to the RNA product definitions. Mapping the products to RNA definitions assigns vulnerabilities based on those definitions. Similarly, if you are importing patch information from a third-party application, such as a patch management product, you must map the name for the fix to the appropriate vendor and product and the corresponding fix in the RNA database. For more information, see the following sections: •

Mapping Third-Party Products on page 561

•

Mapping Third-Party Product Fixes on page 564

Mapping Third-Party Products Requires: DC + RNA

If you import data from a third-party application, you must map the RNA product to the third-party name to assign vulnerabilities and perform impact correlation using that data. Mapping the product associates RNA vulnerability information with the third-party product name, which allows the Sourcefire 3D System to perform impact correlation using that data. As an example, if you import data from a third-party application that lists Apache Tomcat as a service and you know it is version 6 of that product, you could add a

Version 4.7


561


Chapter 14

third-party map where Vendor Name is set to Apache, Product Name is set to Tomcat, Apache is selected from the Vendor drop-down list, Tomcat is selected from the Product drop-down list, and 6 is selected from the Version drop-down list. That mapping would cause any vulnerabilities for Apache Tomcat 6 to be assigned to hosts with a service listing for Apache Tomcat. To map a third-party product to an RNA product definition: Access: Admin

1.

Select Policy & Response > RNA > Network Map > User 3rd Party Mappings. The User 3rd Party Mappings page appears.

2. You have two choices: •

To edit an existing map set, click Edit next to the map set.

•

To create a new map set, click Create Product Map Set.

The Edit 3rd Party Product Mappings page appears.

3. Type a name for the mapping set in the Mapping Set Name field. 4. Type a description in the Description field.

Version 4.7


562


Chapter 14


To map a third-party product, click Add Product Map.

•

To edit an existing third-party product map, click Edit next to the map set.

The Add Product Map pop-up window appears.

6. Type the vendor string used by the third-party product in the Vendor String field. 7.

Type the product string used by the third-party product in the Product String field.

8. Type the version string used by the third-party product in the Version String field. 9. In the Product Mappings section, select the operating system, product, and versions you want to use for RNA vulnerability mapping from the following lists (if applicable):

Version 4.7

•

Vendor

•

Product

•

Major Version

•

Minor Version

•

Revision Version

•

Build


563


Chapter 14

•

Patch

•

Extension

For example, if you want a host running a product whose name consists of third party strings to use the vulnerabilities from Red Hat Linux 9, select Redhat, Inc. as the vendor, Redhat Linux as the product, and 9 as the version. 10. Click Add.

Mapping Third-Party Product Fixes Requires: DC + RNA

If you map a fix name to a particular set of fixes in the RNA database, you can then import data from a third-party patch management application and apply the fix to a set of hosts. When the fix name is imported to a host, RNA marks all vulnerabilities addressed by the fix as invalid for that host. To map third-party fixes to RNA fix definitions:

Access: Admin

1.



To edit an existing map set, click Edit next to the map set.

•

To create a new map set, click Create Product Map Set.

The Edit 3rd Party Product Mappings page appears.

3. Type a name for the mapping set in the Mapping Set Name field. 4. Type a description in the Description field.

Version 4.7


564


Chapter 14


To map a third-party product, click Add Fix Map.

•

To edit an existing third-party product map, click Edit next to it.

The Add Fix Map pop-up window appears.

6. Type the name of the fix you want to map in the Fix Name field. 7.

In the Product Mappings section, select the operating system, product, and versions you want to use for RNA fix mapping from the following lists (if applicable): •

Vendor

•

Product

•

Major Version

•

Minor Version

•

Revision Version

•

Build

•

Patch

•

Extension

For example, if you want your mapping to assign the selected fixes from Red Hat Linux 9 to hosts where the patch is applied, select Redhat, Inc. as the vendor, Redhat Linux as the product, and 9 as the version.

Version 4.7


565


Chapter 14

8. Click Select Fixes. The Available Package Fixes for Select Product page appears.

9. Optionally, enter a regular expression in the Filter field to filter the list of fixes you can select from. To clear a filter, click Clear. 10. Select the fixes you want to automatically apply to the configured product and click Add. TIP! Use Ctrl or Shift while clicking to select multiple fixes. You can click and drag to select multiple adjacent fixes. The fixes are added to the Applied Package Fixes list. 11. Click Finish to save the fix map.

Mapping Third-Party Vulnerabilities Requires: DC + RNA

To add vulnerability information from a third-party application to the RNA vulnerability database, you must map the third-party identification string for each imported vulnerability to any existing RNA, Bugtraq, or Snort ID. After you create a mapping for the vulnerability, the mapping works for all vulnerabilities imported to hosts in your network map and allows impact correlation for those vulnerabilities. Note that you must also enable impact correlation for third-party vulnerabilities in the RNA Settings in the system policy to allow correlation to occur. For more information, see Configuring RNA Settings on page 1204. To map a third-party vulnerability to an existing vulnerability:

Access: Admin

1.


Version 4.7


566


Chapter 14


To edit an existing vulnerability set, click Edit next to the vulnerability set.

•

To create a new vulnerability set, click Create Vuln Map Set.

The Edit 3rd Party Vulnerability Mappings page appears.

3. Click Add Vuln Map. The Add Vulnerability Map pop-up window appears.

4. Type the third-party application identification for the vulnerability in the Vulnerability ID field. 5. Type a description in the Vulnerability Description field. 6. Optionally, enter a Signature ID in the Snort Vulnerability ID Mappings field. 7.

Optionally, enter an RNA vulnerability ID in the RNA Vulnerability ID Mappings field.

8. Optionally, enter a Bugtraq identification number in the Bugtraq Vulnerability ID Mappings field. 9. Click Add.

Managing Custom Product Mappings Requires: DC + RNA

Version 4.7

You can use product mappings to ensure that services or applications input by a third-party application are associated with the appropriate RNA service definitions. Once you define and activate the product mapping, all services or applications on hosts in your network map that have the mapped vendor strings use the custom product mappings. For this reason, you may want to map vulnerabilities for all services in the network map with a particular vendor string instead of explicitly setting the vendor, product, and version for the service.


567


Chapter 14

As an example, if hosts on your network run services with a custom banner of Custom HTTP Service, you can map the string to For more information, see the following: •

Creating Custom Product Mappings on page 568

•

Editing Custom Product Mapping Lists on page 569

•

Managing Custom Product Mapping Activation State on page 570

Creating Custom Product Mappings Requires: DC + RNA

If RNA cannot map a service in the network map to a vendor and product in the RNA vulnerability database, you can manually create the mapping for RNA to use when identifying services. When you activate a custom product mapping, RNA maps vulnerabilities for the selected vendor and product to all services in the network map where that vendor string occurs. IMPORTANT! Custom product mappings apply to all occurrences of a service, regardless of the source of the service data (such as RNA, Nmap, or the host input feature). However, if third-party vulnerability mappings for data imported using the host input feature conflicts with the mappings you set through a custom product mapping, the third-party vulnerability mapping overrides the custom product mapping and uses the third-party vulnerability mapping settings when the input occurs. For more information, see Mapping Third-Party Vulnerabilities on page 566. You create lists of product mappings and then enable or disable use of several mappings at once by activating or deactivating each list. When you select an RNA vendor to map to, RNA updates the list of products to include only those made by that vendor. After you create a custom product mapping, you must activate the custom product mapping list. After you activate a list of custom product mappings, RNA updates all services with occurrences of the specified vendor strings. For data imported through the host input feature, vulnerabilities update unless you have already explicitly set the product mappings for this service. If, for example, your company modifies the banner for your Apache Tomcat web services to read Internal Web Server, you can map the vendor string Internal Web Server to the vendor Apache and the product Tomcat, then activate the list containing that mapping, all hosts where a service labelled Internal Web Server occurs have the vulnerabilities for Apache Tomcat in the RNA database. TIP! You can use this feature to map vulnerabilities to local intrusion rules by mapping the SID for the rule to another vulnerability.

Version 4.7


568


Chapter 14

To create a custom product mapping: Access: Admin

1.

Select Policy & Response > RNA > Network Map > Custom Product Mappings. The Custom Product Mappings page appears.

2. Click Create Custom Product Mapping List. The Edit Custom Product Mappings List page appears.

3. Type a name in the Custom Product Mapping List Name field. 4. Click Add Vendor String. The Add Vendor String pop-up window appears.

5. In the Vendor String field, type the vendor string that identifies the services that should map to the selected RNA vendor and product values. 6. Select the RNA vendor you want to map to from the Vendor drop-down list. 7.

Select the RNA product you want to map to from the Product drop-down list.

8. Click Add to add the mapped vendor string to the list. 9. Optionally, repeat steps 4 to 8 as needed to add additional vendor string mappings to the list. 10. When you finish, click Save. The Custom Product Mappings page appears again, with the list you added.

Editing Custom Product Mapping Lists Requires: DC + RNA

You can modify existing custom product mapping lists by adding or removing vendor strings or changing the list name. To create a custom product mapping:

Access: Admin

1.


Version 4.7


569


Chapter 14

2. Click Edit next to the product mapping list to edit. The Edit Custom Product Mappings List page appears.

3. Make changes to the list as needed. For more information, see Creating Custom Product Mappings on page 568. 4. When you finish, click Save. The Custom Product Mappings page appears, with the list you updated.

Managing Custom Product Mapping Activation State Requires: DC + RNA

You can enable or disable use of an entire list of custom product mappings at once. After you activate a custom product mapping list, each mapping on that list applies to all services on hosts in the network map with the specified vendor string, whether detected by RNA or imported through the host input feature. To activate or deactivate a custom product mapping list:

Access: Admin

1.


2. Modify the state of custom product mapping lists:

Version 4.7

•

To enable use of a custom product mapping list, click Activate.

•

To disable use of a custom product mapping list, click Deactivate.


570

Chapter 14

Configuring Active Scanning

RNA builds a network map through passive analysis of traffic on your network. However, you may sometimes need to actively scan a host to determine information about that host. For example, if a host has a service running on an open port but the service has not received or sent traffic during the time that RNA has been active, RNA does not add information about that service to the network map. If you directly scan that host using an active scanner, however, you can detect the presence of the service. When you actively scan a host, you send packets in an attempt to obtain information about the host. The Sourcefire 3D System integrates with two active scanning modules. Nessus™ 2.2.3, an open source vulnerability scanner developed by the Nessus Project, can be used to simulate attacks and test hosts for vulnerabilities. Nmap™ 4.20, an open source active scanner for network exploration or security auditing, can be used to detect operating systems and services running on a host. With an Nmap scan, you can check for detailed information about the operating system and services running on the host and refine RNA’s vulnerability reporting based on those results. IMPORTANT! Some scanning options (such as portscans) can place a significant load on networks with low bandwidths. You should always schedule scans like these to run during periods of low network use. For more information, see the following sections:

Version 4.7

•

Selecting an Active Scanner on page 572

•

Understanding Nmap Scans on page 572

•

Managing Nmap Scanning on page 587


571

Configuring Active Scanning Selecting an Active Scanner

Chapter 15

•

Understanding Nessus Scans on page 591

•

Setting up Nessus Scans on page 609

•

Managing Nessus Scanning on page 618

•

Managing Scan Targets on page 623

•

Working with Active Scan Results on page 625

Selecting an Active Scanner Requires: DC + RNA

The active scanner you select depends on your purpose in running the scan. Both Nmap and Nessus scans can act as remediations in response to compliance policy violations. You can also launch each type of scan on demand or by scheduling a scan task. Use the information in the following table to determine which scanner offers the features you need for your task. Nmap versus. Nessus Feature Support Feature

Nessus

Nmap

Port scanning

Yes

Yes

Operating system detection and mapping

No

Yes

Service detection and mapping

No

Yes

Vulnerability lookup

Yes

No

Update host profile

Yes (vulnerabilities)

Yes (operating system and services)

Update vulnerability map

Yes

No (though RNA may update due to operating system or service updates)

Understanding Nmap Scans Requires: DC + RNA

Version 4.7

Nmap allows you to actively scan ports on hosts on your network to determine operating system and service data for the hosts. Although you can scan hosts using Nmap and view the scan results in a results file with a Defense Center and a 3D Sensor in your Sourcefire 3D System, to access the full functionality of the Sourcefire 3D System Nmap integration, your Defense Center should have an RNA host license installed. With an RNA license, the results of an Nmap scan


572

Configuring Active Scanning Understanding Nmap Scans

Chapter 15

enhance your RNA network map and let you fine-tune the accuracy of the vulnerabilities mapped to scanned hosts. When you scan a host using Nmap, services on previously undetected open ports are added to the Services list in the host profile for that host. The host profile lists any services detected on filtered or closed TCP ports or on UDP ports in the Scan Results section. Nmap compares the results of the scan to over 1500 known operating system fingerprints to determine the operating system and assigns scores to each. The operating system assigned to the host is the operating system fingerprint with the highest score. The Nmap host, bridge, and router device types map to the RNA device types. In addition, Nmap uses 34 other well-defined device types that may be reflected in the scan results. If RNA recognizes a service identified in an Nmap scan and has a corresponding service definition, RNA maps vulnerabilities for that service to the host. RNA maps the names Nmap uses for services to the corresponding RNA service definitions, and then uses the vulnerabilities mapped to each service in RNA. Similarly, RNA maps Nmap operating system names to RNA operating system definitions. When Nmap detects an operating system for a host, RNA assigns vulnerabilities from the corresponding RNA operating system definition to the host. Note that the host must exist in the network map before Nmap can append the results to the host profile.

Creating an Nmap Scanning Strategy Requires: DC + RNA

While active scanning can obtain valuable information, overuse of a tool such as Nmap can overload your network resources or even crash important hosts. When using any active scanner, you should create a scanning strategy to make sure that you are scanning only the hosts and ports that you need to scan. For more information, see the following sections: •

Selecting Appropriate Scan Targets on page 573

•

Selecting Appropriate Ports to Scan on page 574

Selecting Appropriate Scan Targets Requires: DC + RNA

Version 4.7

When you configure Nmap, you can create scan targets that identify which hosts you want to scan. A scan target includes a single IP address, a list of IP addresses, or a CIDR block or octet range of IP addresses to scan, as well as the ports on the host or hosts.


573


Chapter 15

You can specify targets in the following ways: •

an exact IP address (for example, 192.168.1.101) or a list of IP addresses separated by commas or spaces

•


•

an IP address range using octet range addressing (for example, 192.168.0-255.1-254 scans all addresses in the 192.168.x.x range, except those that end in .0 and or .255)

Ideal scan targets for Nmap scans include hosts with operating systems RNA is unable to identify, hosts with unidentified services, or hosts recently detected on your network. Remember that Nmap results cannot be added to the network map for hosts that do not exist in the network map. WARNING! Once Nmap replaces a host’s operating system or services detected by RNA with the results from an Nmap scan, RNA no longer updates the information replaced by Nmap for the host. Nmap-supplied service and operating system data remains static until you run another Nmap scan. If you plan to scan a host using Nmap, you may want to set up regularly scheduled scans to keep any Nmap-supplied operating system and service data up to date. For more information, see Automating Nmap Scans on page 1325. If the host is deleted from the network map and re-detected by RNA, any Nmap scan results are discarded and RNA resumes monitoring of all operating system and service data for the host. In addition, make sure you have permission to scan your targets. Using Nmap to scan hosts that do not belong to you or your company may be illegal.

Selecting Appropriate Ports to Scan Requires: DC + RNA

For each scan target you configure, you can select the ports you want to scan. You can designate individual port numbers, port ranges, or a series of port numbers and port ranges to identify the exact set of ports that should be scanned on each target. By default, Nmap scans more than 1660 TCP ports. If you plan to use the remediation as a response in a compliance policy, you can cause the remediation to scan only the port specified in the event that triggers the compliance response. If you run the remediation on demand or as a scheduled task, or if you do not use the port from the event, you can use other port options to determine which ports are scanned. You can choose to scan only the TCP ports listed in the nmapservices file, ignoring other port settings. You can also scan UDP ports in addition to TCP ports. Note that scanning for UDP ports may be time-consuming, so avoid using that option if you want to scan quickly. To select the specific ports or range of ports to scan, use Nmap port specification syntax to identify specific ports.

Version 4.7


574


Chapter 15

Sample Nmap Scanning Profiles Requires: DC + RNA

The following scenarios provide examples of how Nmap might be used on your network: •

Example: Resolving Unknown Operating Systems on page 575

•

Example: Responding to New Hosts on page 576

Example: Resolving Unknown Operating Systems Requires: DC + RNA

If RNA cannot determine the operating system on a host on your network, you can can use Nmap to actively scan the host. Nmap uses the information it obtains from the scan to rate the possible operating systems. It then uses the operating system that has the highest rating as the host operating system identification. Using Nmap to challenge new hosts for operating system and service information deactivates RNA monitoring of that data for scanned hosts. If you use Nmap to discover host and service operating system for hosts RNA marks as having unknown operating systems, you may be able to identify groups of hosts that are similar. You can then create a custom fingerprint based on one of them to cause RNA to associate the fingerprint with the operating system you know is running on the host based on the Nmap scan. Whenever possible, create a custom fingerprint rather than inputting static data through a third-party source like Nmap because the custom fingerprint allows RNA to continue to monitor the host operating system and update it as needed. To discover operating systems with Nmap:


1.

Configure a scan instance for an Nmap module. For more information, see Creating an Nmap Scan Instance on page 578.

2. Create an Nmap remediation using the following settings: •


•


•


For information on creating Nmap remediations, see Creating an Nmap Remediation on page 581. 3. Create a compliance rule that triggers when RNA detects a host with an unknown operating system. The rule should trigger when an RNA event occurs and the OS information for a host has changed and it meets the following conditions: OS Name is unknown. For information on creating compliance rules, see Creating Rules for Compliance Policies on page 394.

Version 4.7


575


Chapter 15

4. Create a compliance policy that contains the compliance rule. For more information on creating compliance policies, see Creating Compliance Policies on page 439. 5. In the compliance policy, add the Nmap remediation you created in step 2 as a response to the rule you created in step 3. 6. Activate the compliance policy. 7.

Purge the hosts on your network map to force RNA to restart and rebuild the network map.

8. After a day or two, search for events generated by the compliance policy. Analyze the Nmap results for the operating systems detected on the hosts to see if there is a particular host configuration on your network that RNA does not recognize. For more information on analyzing Nmap results, see Analyzing Nmap Results on page 629. 9. If you find hosts with unknown operating systems whose Nmap results are identical, create a custom fingerprint for one of those hosts and use it to identify similar hosts in the future. For more information, see Fingerprinting Clients on page 537.

Example: Responding to New Hosts Requires: DC + RNA

When RNA detects a new host in a subnet where intrusions may be likely, you may want to scan that host to make sure you have accurate vulnerability information for it. You can accomplish this by creating and activating a compliance policy that detects when a new host appears in this subnet, and that launches a remediation that performs an Nmap scan on the host. After you activate the policy, you can periodically check the remediation status view (Policy & Response > Responses > Remediations > Status) to see when the remediation launched. The remediation’s dynamic scan target should include the IP addresses of the hosts it scanned as a result of the service detection. Check the host profile for those hosts to see if there are vulnerabilities that need to be addressed for the host, based on the operating system and services detected by Nmap. WARNING! If you have a large or dynamic network, detection of a new host may be too frequent an occurrence to respond to using a scan. To prevent resource overload, avoid using Nmap scans as a response to events that occur frequently. In addition, note that using Nmap to challenge new hosts for operating system and service information deactivates RNA monitoring of that data for scanned hosts.

Version 4.7


576


Chapter 15

To scan in response to the appearance of a new host: Access: Rules or Admin

1.

Configure a scan instance for an Nmap module. For more information, see Creating an Nmap Scan Instance on page 578.

2. Create an Nmap remediation using the following settings: •


•


•


For information on creating Nmap remediations, see Creating an Nmap Remediation on page 581. 3. Create a compliance rule that triggers when RNA detects a new host on a specific subnet. The rule should trigger when an RNA event occurs and a new host is detected. For information on creating compliance rules, see Creating Rules for Compliance Policies on page 394. 4. Create a compliance policy that contains the compliance rule. For more information on creating compliance policies, see Creating Compliance Policies on page 439. 5. In the compliance policy, add the Nmap remediation you created in step as a response to the rule you created in step 3. 6. Activate the compliance policy. 7.

Version 4.7

When you are notified of a new host, check the host profile to see the results of the Nmap scan and address any vulnerabilities that apply to the host.


577

Configuring Active Scanning Setting up Nmap Scans

Chapter 15

Setting up Nmap Scans Requires: DC + RNA

To scan using Nmap, you must first configure a scan instance and a scan remediation. If you plan to schedule Nmap scans, you must also define a scan target.


Creating an Nmap Scan Instance on page 578

•

Creating an Nmap Scan Target on page 580

•

Creating an Nmap Remediation on page 581

Creating an Nmap Scan Instance Requires: DC + RNA

You can set up a separate scan instance for each Nmap module that you want to use to scan your network for vulnerabilities. You can set up scan instances for the local Nmap module on your Defense Center and for any sensors you want to use to run scans remotely. The results of each scan are always stored on the Defense Center where you configure the scan, even if you run the scan from a remote sensor. To prevent accidental or malicious scanning of mission-critical hosts, you can create a blacklist for the instance to indicate the hosts that should never be scanned with the instance. Note that you cannot add a scan instance with the same name as any existing scan instance, including Nessus scan instances.

Version 4.7


578


Chapter 15

To create a scan instance: Access: Rules or Admin

1.

Select Operations > Tools > Scanners. The Scanners page appears.

2. Click Add Nmap Instance. The Instance Detail page appears.

3. In the Instance Name field, enter a name that includes 1 to 63 alphanumeric characters, with no spaces and no special characters other than underscore (_) and dash (-). 4. In the Description field, specify a description with 0 to 255 alphanumeric characters, which can include spaces and special characters. 5. Optionally, in the Black Listed Scan hosts field, specify any hosts or networks that should never be scanned with this scan instance, using the following syntax: •


•


If you specifically target a scan to a host that is in a blacklisted network, that scan will not run.

Version 4.7


579


Chapter 15

6. Optionally, to run the scan from a remote sensor instead of the Defense Center, specify the IP address or name of the sensor as it appears in the Information page for the sensor in the Defense Center web interface, in the Remote Sensor Name field. 7.

Click Create. The scan instance is created.

Creating an Nmap Scan Target Requires: DC + RNA

You can create and save scan targets that identify specific hosts and ports. Then, when you perform an on-demand scan or schedule a scan, you can use one of the saved scan targets. You can use an IP address, a list of IP addresses, CIDR notation, or Nmap scan octets to select the hosts to scan. Once Nmap replaces a host’s operating system or services detected by RNA with the results from an Nmap scan, RNA no longer updates the information replaced by Nmap for the host. Nmap-supplied service and operating system data remains static until you run another Nmap scan. If you plan to scan a host using Nmap, you may want to set up regularly scheduled scans to keep any Nmap-supplied operating system and service data up to date. For more information, see Automating Nmap Scans on page 1325. If the host is deleted from the network map and re-detected by RNA, any Nmap scan results are discarded and RNA resumes monitoring of all operating system and service data for the host. To create a scan target:


1.


2. On the toolbar, click Targets. The Scan Target List page appears.

3. Click Create Scan Target. The Scan Target page appears.

4. In the Name field, type the name you want to use for this scan target.

Version 4.7


580


Chapter 15

5. In the IP Range text box, specify the host or hosts you want to scan, using the following syntax: •

an exact IP address (for example, 192.168.1.101) or comma-separated list of IP addresses

•


•

an IP address range using octet range addressing (for example, 192.168.0-255.1-254 scans all addresses in the 192.168.x.x range, except those that end in .0 and or .255)

6. In the Ports field, specify the ports you want to scan. You can enter any of the following:

7.

•

a port number

•

a negation of a port number

•

a list of ports separated by commas

•

a range of port numbers separated by a dash

•

ranges of port numbers separated by dashes, separated by commas

•

a negation of a port range

Click Save. The scan target is created.

Creating an Nmap Remediation Requires: DC + RNA

You can define the settings for an Nmap scan by creating an Nmap remediation. An Nmap remediation can be used as a response in a compliance policy, run on demand, or scheduled to run at a specific time. In order for the results of an Nmap scan to appear in the network map, the scanned host must already exist in the network map. Note that both RNA and NetFlow can add hosts to the network map. When you use an Nmap scan as a response to a compliance rule, you can configure which address in the event is scanned using the Scan Which Address(es)

Version 4.7


581


Chapter 15

From Event? option. In addition, you can choose between two scan types for your Nmap scans: •

the TCP Syn scan connects quickly to thousand of ports without using a complete TCP handshake. This options allows you to scan quickly in stealth mode on hosts where the root account has raw packet access or where IPv6 is not running, by initiating TCP connections but not completing them. If a host acknowledges the Syn packet sent in a TCP Syn scan, Nmap resets the connection.

•

the TCP Connect scan uses the connect() system call to open connections through the operating system on the host. You can use the TCP Connect scan if the root user on your Defense Center or remote 3D Sensor does not have raw packet privileges on a host or you are scanning IPv6 networks. In other words, use this option in situations where the TCP Syn scan cannot be used.

By default, Nmap scans more than 1660 TCP ports. To modify the ports scanned by the remediation, you can use the following options: •

If you plan to use the remediation as a response in a compliance policy, select Use Port From Event to cause the remediation to scan only the port specified in the event that triggers the compliance response.

•

Select Fast Port Scan to scan only the TCP ports listed in the nmap-services file located in the /usr/local/sf/nmap/share/nmap/nmap-services directory on the sensor that does the scanning, ignoring other port settings.

•

Select Scan for UDP ports to scan UDP ports in addition to TCP ports. Note that scanning UDP ports may be time-consuming, so avoid using that option if you want to scan quickly.

•

Type specific ports in the Port Ranges and Scan Order option, using Nmap port specification syntax, to identify specific ports.

You can also control whether Nmap collects information about operating system and service information:

Version 4.7

•


•

Enable Probe open ports for vendor and version information to detect service vendor and version information. If you probe open ports for service vendor and version information, Nmap obtains service data that it uses to identify services. It then replaces the RNA service data for that service.

•

Set the Service Version Intensity. Higher service intensity numbers cause more probes to be used and result in higher accuracy, while lower intensity probes are faster but obtain less information.


582


•

Chapter 15

Enable Detect Operating System to detect operating system information for the host. If you configure detection of the operating system for a host, Nmap scans the host and uses the results to create a rating for each operating system that reflects the likelihood that that operating system is running on the host. Nmap replaces the operating system data detected by RNA with the operating system with the highest rating.

Once Nmap replaces a host’s operating system or services detected by RNA with the results from an Nmap scan, RNA no longer updates that information for the host. Nmap-supplied service and operating system data remains static until you run another Nmap scan. If you plan to scan a host for operating system and service data using Nmap, you may want to set up regularly scheduled scans to keep any Nmap-supplied operating system and service data up to date. For more information, see Automating Nmap Scans on page 1325. If the host is deleted from the network map and re-detected by RNA, any Nmap scan results are discarded and RNA resumes monitoring of all operating system and service data for the host. To create a Nmap remediation: Access: Rules or Admin

Version 4.7

1.



583


Chapter 15

2. Click Add Remediation next to the scan instance where you want to add a remediation. The Edit Remediation page appears.

3. In the Remediation Name field, type a name for the remediation that includes 1 to 63 alphanumeric characters, with no spaces and no special characters other than underscore (_) and dash (-). 4. In the Description field, type a description for the remediation that includes 0 to 255 alphanumeric characters, including spaces and special characters. 5. If you plan to use this remediation in response to a compliance rule that triggers on an intrusion event, a flow event, or a RUA event, configure the Scan Which Address(es) From Event? option. •


•


•


If you plan to use this remediation in response to a compliance rule that triggers on an RNA event or a host input event, by default the remediation scans the IP address of the host involved in the event; you do not need to configure this option. IMPORTANT! Do not assign a Nmap remediation as a response to a compliance rule that triggers on a traffic profile change.

Version 4.7


584


Chapter 15

6. Configure the Scan Type option:

7.

•

To scan quickly in stealth mode on hosts where the root account has raw packet access or where IPv6 is not running, by initiating TCP connections but not completing them, select TCP Syn Scan.

•

To scan by using a system connect() call, which can be used on hosts where the root account on your Defense Center does not have raw packet access or where IPv6 is running, select TCP Connect Scan.

Optionally, to scan UDP ports in addition to TCP ports, select On for the Scan for UDP ports option. TIP! A UDP portscan takes more time than a TCP portscan. To speed up your scans, leave this option disabled.

8. If you plan to use this remediation in response to compliance policy violations, configure the Use Port From Event option: •

Select On to scan the port in the compliance event, rather than the ports you specify in step 11. If you scan the port in the compliance event, note that the remediation scans the port on the IP addresses that you specified in step 5. These ports are also added to the remediation’s dynamic scan target.

•

Select Off to scan only the ports you will specify in step 11.

9. If you plan to use this remediation in response to compliance policy violations and want to run the scan using the appliance running the detection engine that detected the event, configure the Scan from reporting detection engine option: •

To scan from the appliance running the reporting detection engine, select On.

•

To scan from the appliance configured in the remediation, select Off.

10. Configure the Fast Port Scan option:

Version 4.7

•

To only scan ports listed in the nmap-services file located in the /usr/local/sf/nmap/share/nmap/nmap-services directory on the sensor that does the scanning, ignoring other port settings, select On.

•

To scan all TCP ports, select Off.


585


Chapter 15

11. In the Port Ranges and Scan Order field, type the ports you want to scan by default, using Nmap syntax, in the order you want to scan those ports. Separate ports using commas or use a hyphen to indicate a port range. When scanning for both TCP and UDP ports, preface the list of TCP ports you want to scan with a T and the list of UDP ports with a U. For example, to scan ports 53 and 111 for UDP traffic, then scan ports 21-25 for TCP traffic, enter U:53,111,T:21-25. Note that the Use Port From Event option overrides this setting when the remediation is launched in response to a compliance policy violation, as described in step 6. 12. To probe open ports for service vendor and version information, configure Probe open ports for vendor and version information: •

Select On to scan open ports on the host for service information to identify service vendors and versions.

•

Select Off to continue using RNA service information for the host.

WARNING! Once you scan a host with this setting enabled, RNA no longer monitors service data for any services detected by Nmap. You may want to schedule Nmap scans to periodically refresh the service information. If you delete the host from the network map, RNA re-detects the host and then resumes monitoring all service data for the host. 13. If you choose to probe open ports, set the number of probes used by selecting a number from the Service Version Intensity drop-down list: •

To use more probes for higher accuracy with a longer scan, select a higher number.

•

To use fewer probes for less accuracy with a faster scan, select a lower number.

14. To scan for operating system information, configure Detect Operating System settings: •

Select On to scan the host for information to identify the operating system.

•

Select Off to continue using RNA operating system information for the host.

WARNING! Once you scan a host with this setting enabled, RNA no longer monitors the operating system for the host. You may want to schedule Nmap scans to periodically refresh the host operating system information. If you delete the host from the network map, RNA re-detects the host and then resumes monitoring the operating system data for the host.

Version 4.7


586

Configuring Active Scanning Managing Nmap Scanning

Chapter 15


Managing Nmap Scanning Requires: DC + RNA

You can modify or delete Nmap scan instances and remediations as needed. You can also run an on-demand Nmap scan. You can also view or download Nmap results for previous scans. For more information, see the following sections: •

Managing Nmap Scan Instances on page 587

•

Managing Nmap Remediations on page 589

•

Running an On-Demand Nmap Scan on page 589

Managing Nmap Scan Instances Requires: DC + RNA

You can edit or delete Nmap scan instances. For more information, see the following sections: •

Editing an Nmap Scan Instance on page 587

•

Deleting an Nmap Scan Instance on page 588

Editing an Nmap Scan Instance Requires: DC + RNA

Use the following procedure to modify scan instances. Note that you can view, add, and delete remediations associated with the instance when you modify it. To edit a scan instance:


Version 4.7

1.



587


Chapter 15

2. Click View next to the instance you want to edit. The Instance Detail page appears.

3. Optionally, click View next to the remediation you want to view or edit. For more information on editing remediations, see Editing an Nmap Remediation on page 589. 4. Optionally, click Delete next to the remediation you want to delete. For more information on deleting remediations, see Deleting an Nmap Remediation on page 589. 5. Optionally, click Add to add a new remediation to this scan instance. For more information on creating new remediations, see Creating an Nmap Remediation on page 581. 6. Optionally, make changes to the scan instance settings, then click Save. 7.

Click Done. The scan instance is modified.

Deleting an Nmap Scan Instance Requires: DC + RNA

Delete an Nmap scan instance when you no longer want to use the Nmap module profiled in the instance. Note that when you delete the scan instance, you also delete any remediations that use that instance. To delete a scan instance:


1.

Click Operations > Tools > Scanners. The Scanners page appears.

2. Click Delete next to the scan instance you want to delete. The instance is deleted.

Version 4.7


588


Chapter 15

Managing Nmap Remediations Requires: DC + RNA

You can edit or delete Nmap remediations. For more information, see the following sections: •

Editing an Nmap Remediation on page 589

•

Deleting an Nmap Remediation on page 589

Editing an Nmap Remediation Requires: DC + RNA

Modifications you make to Nmap remediations do not affect scans in progress. The new settings take effect when the next scan starts. To edit an Nmap remediation:


1.


2. Next to the remediation you want to edit, click View. The Remediation Edit page appears. 3. Make modifications as necessary. For information on the settings you can change, see Creating a Nessus Remediation on page 615. 4. Click Save, then click Done. The remediation is modified.

Deleting an Nmap Remediation Requires: DC + RNA

Delete an Nmap remediation if you no longer need it. To delete a Nmap remediation:


1.


2. Next to the remediation you want to delete, click Delete. 3. Confirm that you want to delete the remediation. The remediation is deleted.

Running an On-Demand Nmap Scan Requires: DC + RNA

You can launch on-demand Nmap scans whenever needed. You can specify the target for an on-demand scan by entering the IP addresses and ports you want to scan or by selecting an existing scan target. Once Nmap replaces a host’s operating system or services detected by RNA with the results from an Nmap scan, RNA no longer updates the information replaced by Nmap for the host. Nmap-supplied service and operating system data remains

Version 4.7


589


Chapter 15

static until you run another Nmap scan. If you plan to scan a host using Nmap, you may want to set up regularly scheduled scans to keep any Nmap-supplied operating system and service data up to date. For more information, see Automating Nmap Scans on page 1325. If the host is deleted from the network map and re-detected by RNA, any Nmap scan results are discarded and RNA resumes monitoring of all operating system and service data for the host. To run an on-demand Nmap scan: Access: Rules or Admin

1.


2. Next to the Nmap remediation you want to use to perform the scan, click Scan. The Nmap Scan Target dialog box appears.

3. Optionally, to scan using a saved scan target, select a target from the Saved Targets drop-down list and click Load. The IP addresses and ports associated with the scan target populate the IP Range(s) and Ports fields. TIP! To create a scan target, click Edit/Add Targets. For more information, see Creating an Nmap Scan Target on page 580.

Version 4.7


590

Configuring Active Scanning Understanding Nessus Scans

Chapter 15

4. In the IP Range(s) field, specify the IP address for hosts you want to scan or modify the loaded list. You can specify multiple IP addresses separated by commas or use CIDR notation. You can also negate IP addresses by preceding them with an exclamation point (!). For details on entering IP addresses, see Specifying IP Addresses in Searches on page 1130. 5. In the Ports field, specify the ports you want to scan or modify the loaded list. You can enter a port number, a negation of a port number, a list of ports separated by commas, or a range of port numbers separated by a dash. For details on entering ports, see Specifying Ports in Searches on page 1132. 6. Click Scan Now. The Nmap server performs the scan.

Understanding Nessus Scans Requires: DC + RNA

You can use Nessus 2.2.3, an open source vulnerability scanner developed by the Nessus Project (http://www.nessus.org/) that emulates the actions of an attacker, to identify vulnerabilities on your network. In this way, you can identify security weaknesses so that you can fix them before an actual attack occurs. IMPORTANT! System.

You cannot use Nessus 3.0 servers with the Sourcefire 3D

Nessus scans are configured as remediations, which are programs that you can configure the Defense Center to run in response to a compliance policy violation. Unlike remediations other than Nmap, however, you can also perform on-demand Nessus scans on your network or on specific hosts to collect data on current vulnerabilities, and you can schedule periodic scans to regularly assess the security on your network. (For more information on remediations, see Configuring Remediations on page 471.) You can add Nessus scan results to the RNA network map to augment the vulnerability information that the Defense Center provides. You can also choose to perform impact flag correlation with both Nessus results and RNA data, or you can use Nessus results in place of RNA data. The Defense Center includes an installation of the Nessus 2.2.3 Server, and you can perform scans using either the local Nessus server or an existing external Nessus server, although Sourcefire recommends using a external Nessus server (that is, not on your Defense Center). The Defense Center also includes an installation of the Nessus 2.2.3 Client. Note that you may not install or use a different Nessus client on the Defense Center. You must use the web interface to manage Nessus scans initiated through the Sourcefire 3D System.

Version 4.7


591


Chapter 15

A Nessus scan emulates the actions of an attacker. You can enable the use of families of plugins to cause Nessus to test for specific types of vulnerabilities on your network. You can manually run Nessus scans, or you can schedule periodic scans. You can also configure a Nessus scan remediation as a response to a compliance policy violation. For more information, see the following topics: •

Understanding Nessus Plugins on page 592

•

Understanding Other Sourcefire Nessus Integration Settings on page 597

•

Creating a Nessus Scanning Strategy on page 601

•

Sample Scanning Profiles on page 605

•

Setting up Nessus Scans on page 609

Understanding Nessus Plugins Requires: DC + RNA

Nessus uses plugins, which are scripts written in the Nessus Attack Scripting Language (NASL), to test for vulnerabilities. Over 9000 Nessus plugins exist. Each plugin detects a specific vulnerability on your system. IMPORTANT! As Nessus developers identify new vulnerabilities, they create new Nessus plugins to find those vulnerabilities. If you are using an external Nessus server, you can register for a plugin feed to obtain updated plugins on an ongoing basis. For more information on obtaining a license for the Nessus plugin feed, see http://www.nessus.org/. However, you cannot configure the Nessus server on the Defense Center to work with a plugin feed.

Understanding Nessus Plugin Families Requires: DC + RNA

To help you decide which plugins to use, Nessus groups the plugins into families. Each family contains plugins related to a particular category of threats. When you configure a Nessus remediation, you can enable or disable families of plugins. You can use RNA to identify the operating systems and services running on hosts on your network. This allows you to more easily identify which plugin families you should use to perform Nessus scans against those hosts. TIP! If you are using an external Nessus server with a plugin feed and you want to use new plugins, edit the scan instance for your Nessus server. This forces the Defense Center to add appropriate configuration options for any new plugin families to the web interface. For more information, see Editing a Nessus Scan Instance on page 619.You can also schedule a task to synchronize Nessus plugins. For more information, see Synchronizing Nessus Plugins on page 1324.

Version 4.7


592


Chapter 15

The Nessus Plugin Families table table describes the Nessus plugin families available on the release date of this document. For more information on currently available Nessus plugin families, including risk factors associated with each plugin, see http://www.nessus.org/. Nessus Plugin Families Plugin Family

Description

Recommended For

Debian Local Security Checks

Determines whether available updates have been installed to address known security issues relating to Debian GNU/Linux components and programs that run on Debian.

Computers running Debian GNU/Linux.

Windows

Determines whether available updates have been installed to address known security issues relating to Microsoft Windows components and programs that run on Windows.

Computers running Microsoft Windows.

Denial of Service

Detects vulnerabilities that would allow an attacker to carry out a denial of service (DoS) attack against the vulnerable servers.

Web servers, FTP servers, mail servers, and other outward-facing servers that provide service to external clients.

Gentoo Local Security Checks

Determines whether available updates have been installed to address known security issues relating to Gentoo Linux components and programs that run on Gentoo.

Computers running Gentoo Linux.

SMTP problems

Detects vulnerabilities, on a variety of mail servers running SMTP services, that would allow an attacker to gain root access to a server, to carry out a denial of service attack against the server, or to use the server to execute arbitrary code or as a spam relay server.

Mail servers running SMTP services.

FTP

Detects vulnerabilities, on a variety of FTP servers, that would allow an attacker unauthorized access to files, let the attacker carry out a denial of service attack, or allow the attacker to use the server to post unauthorized content.

FTP servers.

General

Detects generic vulnerabilities.

Any computer.

Service detection

Detects services running on scanned targets. Can be used to identify unnecessary services that could provide opportunities for an attacker to compromise the machine.

Any server.

Version 4.7


593


Chapter 15

Nessus Plugin Families (Continued) Plugin Family

Description

Recommended For

Backdoors

Detects services running on non-standard ports and other conditions which may create opportunities for an attacker to bypass authentication and take control of the vulnerable server.

Any computer.

Gain root remotely

Detects vulnerabilities that an attacker could exploit to gain administrative access to a server.

Any computer.

CGI abuses

Detects script-based vulnerabilities that could be used by an attacker to launch injection attacks or cross-site scripting attacks.

Web servers.

Remote file access

Detects vulnerabilities that would provide unauthorized access to files by a remote attacker.

Any computer, but particularly file servers and FTP servers.

CGI abuses: XSS

Detects script-based vulnerabilities that could be used by an attacker to launch cross-site scripting attacks.

Web servers.

Useless services

Detects services that might be unnecessary services so they can be disabled if they are not needed.

Any computer.

Windows: Microsoft Bulletins

Detects Microsoft Windows vulnerabilities that have been identified in Microsoft support bulletins.

Computers running Microsoft Windows.

Netware

Determines whether available updates have been installed to address known security issues relating to Novell NetWare components and programs that run on NetWare.

Computers running Novell NetWare.

Misc.

Detects miscellaneous vulnerabilities.

Any computer.

Settings

Configures settings used by other plugin families.

Any computer.

Peer-To-Peer File Sharing

Detects the presence of peer-to-peer clients, which may indicate file sharing that is illegal or inappropriate to a business environment, or may expose vulnerabilities that can be exploited by attackers.

Any computer.

Gain a shell remotely

Detects vulnerabilities that an attacker could exploit to gain shell access to a server.

Any computer.

Default Unix Accounts

Detects instances of unchanged default passwords that could be exploited by attackers.

Any UNIX or Linux computer.

Version 4.7


594


Chapter 15


Description

Recommended For

Firewalls

Detects firewall vulnerabilities that would allow an attacker to breach the firewall and access resources on the internal network.

Firewalls.

SNMP

Detects vulnerabilities where system information can be obtained through SNMP requests and then used by an attacker.

Any computer.

CISCO

Detects vulnerabilities in Cisco servers and appliance services that may allow various attacks, including denial of service, arbitrary code execution, and authentication bypasses.

Cisco hardware.

RPC

Detects vulnerabilities in RPC services that may allow attackers to gain root access or retrieve sensitive information.

Any computer.

MacOS X Local Security Checks

Determines whether available updates have been installed to address known security issues relating to Mac OS X components and programs that run on Mac OS X.

Computers running the Mac OS X operating system.

Finger abuses

Detects finger services that need to be upgraded or disabled to prevent exploitation of the finger daemon.

Any computer.

AIX Local Security Checks

Determines whether available AIX Critical Security Patches have been installed on AIX servers and whether the servers are running the latest AIX maintenance package.

Computers running the AIX operating system.

Red Hat Local Security Checks

Determines whether available updates have been installed to address known security issues relating to Red Hat Linux components and programs that run on Red Hat Linux.

Computers running the Red Hat Linux operating system.

Brute Force Attacks

Detects vulnerabilities that could be exploited through a brute force attack.

Any computer.

FreeBSD Local Security Checks

Determines whether available updates have been installed to address known security issues relating to FreeBSD components and programs that run on FreeBSD.

Computers running the FreeBSD operating system.

Mandrake Local Security Checks

Determines whether available updates have been installed to address known security issues relating to Mandriva (formerly known as Mandrake) components and programs that run on Mandriva/Mandrake.

Computers running the Mandriva/Mandrake operating system.

Version 4.7


595


Chapter 15


Description

Recommended For

HP-UX Local Security Checks

Determines whether available updates have been installed to address known security issues relating to HP-UX components and programs that run on HP-UX.

Computers running the HP-UX operating system.

NIS

Determines whether Network Information Servers (NIS) have vulnerabilities that might allow an attacker to obtain password or domain information.

UNIX computers running an NIS server.

Slackware Local Security Checks

Determines whether available updates have been installed to address known security issues relating to Slackware Linux components and programs that run on Slackware Linux.

Computers running the Slackware Linux operating system.

Solaris Local Security Checks

Determines whether available updates have been installed to address known security issues relating to Solaris components and programs that run on Solaris.

Computers running the Solaris operating system.

SuSE Local Security Checks

Determines whether available updates have been installed to address known security issues relating to SuSE Linux components and programs that run on SuSE Linux.

Computers running the SuSE Linux operating system.

Web Servers

Detects web server vulnerabilities.

Web servers.

Windows: user management

Detects vulnerabilities in Microsoft Windows user management functionality, such as poor password management practices.

Windows servers.

Understanding Safe Checks Requires: DC + RNA

Safe checks allow you to eliminate the possibility of causing harm when scanning. If you need to run a stealth scan or if you scan production systems that must not crash as a result of the scan, you should enable safe checks when you configure scans. Note that safe checks protects your system by using passive methods of identification of vulnerabilities, such as checking headers. As a result, scans performed with safe checks may identify fewer vulnerabilities than the same scan without safe checks. if you run scans with safe checks, you may want to periodically schedule maintenance windows to run scans without it.

Understanding Dangerous Plugins Requires: DC + RNA

Version 4.7

Dangerous plugins are plugins that can: •

crash a scanned host or service

•

cause data corruption on the target system or service


596


Chapter 15

•

cause a denial of service condition on the target host or service

•

generate a large volume of traffic on the network

You can configure the Defense Center so that dangerous plugins do not run during a scan, even if you enable their plugin families. WARNING! Do not enable dangerous plugins for scans targeted at systems that are critical to your business infrastructure, unless you can scan them when those systems can be offline. Before you scan with dangerous plugins, make sure you back up all data on targeted systems. Sourcefire recommends that you only enable dangerous plugins when you plan to run the scan, then immediately disable it when the scan is complete.

Understanding Other Sourcefire Nessus Integration Settings Requires: DC + RNA

You can use the Sourcefire 3D System Nessus client to change several Nessus client configuration settings. However, you cannot change the majority of the client configuration settings. The Nessus Settings table describes the settings you can change as well as the default settings that you cannot change. IMPORTANT! If you need to run a Nessus scan using options not supported by the Sourcefire 3D System Nessus client, use an external Nessus client to run the scan, then import the scan results to the Sourcefire 3D System. For more information, see Importing Results on page 626.

Nessus Settings Setting

Value

Description

Modifiable?

Maximum number of checks run against a host simultaneously

10

A maximum of 10 plugins can be run simultaneously against a host.

Yes, by adjusting the Number of checks to perform at the same time setting.

CGI file location

/cgi-bin:/scripts

The Nessus server checks the specified path on the target when running plugins that check for CGI vulnerabilities.

Yes, by modifying the Path to CGIs setting.

Port range

default

When the Nessus server scans a target, it scans the specified ports.

Yes, by modifying the Port Range setting or enabling the Use Port from Event setting.

Version 4.7


597


Chapter 15

Nessus Settings (Continued) Setting

Value

Description

Modifiable?

Safe Checks

yes

For safe-checks enabled plugins, the Nessus server relies on reported banners rather than actually carrying out tests that might destabilize the scan target.

Yes, by disabling the Safe Checks option so that the actual tests are performed.

Niceness

no

The Nessus server does not adjust the process priority on child processes of the nessusd process.

No

Dump file

/dev/null

The Nessus server does not create a dump file for log messages from plugins.

No

Log file

/dev/null

The Nessus server does not create a log file.

No

Log whole attack

no

The Nessus server only logs the beginning and end of each scan, not the execution time for each plugin.

No

Log plugin names at load

no

The Nessus server does not log the name of each plugin being loaded at startup or on receipt of the HUP signal.

No

Maximum hosts scanned simultaneously

30

A maximum of 30 hosts can be scanned simultaneously.

No

Plugins folder

/var/sf/nessus/lib/ nessus/plugins

Plugins are stored in the specified location.

No

Rules database

/var/sf/nessus/etc/ nessus/nessusd.rule s

The rules database used by the Nessus server is in the specified location.

No

Version 4.7


598


Chapter 15


Value

Description

Modifiable?

Test optimization

yes

The Nessus server launches some plugins only if certain conditions exist (for example, if a particular service is detected or a specific port is open).

No

Language

English

The Nessus server uses English.

No

Connection timeout

5 seconds

The Nessus server waits five seconds for a reply from target hosts for each connection from each plugin.

No

Non-simultaneous ports

139 and 445

The Nessus server does not simultaneously connect to the specified ports on the same target host.

No

Plugin process timeout

320 seconds

The Nessus server kills any plugin process that does not finished its testing within the timeout period.

No

Automatically enable dependencies

yes

If there are plugins on which other plugins have dependencies, the Nessus server enables those plugins automatically.

No

Use MAC address

no

The Nessus server does not accept a MAC address in place of an IP address for the target host.

No

all knowledge base options

no

The Nessus server does not save collected information (the knowledge base) about scanned hosts.

No

Version 4.7


599


Chapter 15


Value

Description

Modifiable?

Maximum knowledge base age

864000

This option has no effect on Nessus server behavior because the knowledge base is not saved.

No

Manually upload plugins

no

The Nessus server does not accept plugins manually uploaded by users.

No

Allowed upload plugin suffixes

.nasl and .inc

This option has no effect on Nessus server behavior because users cannot upload plugins.

No

Administrative user

root

The Nessus server treats the root user on the appliance as the administrative user for Nessus.

No

Slice network addresses

no

If you specify a range of target IP addresses, the Nessus server scans them from the beginning of the range to the end.

No

Do not check for NASL signature

no

The Nessus server checks for scripts signed by the Nessus development team and rejects scripts that have changed or that have a signature that has changed without being re-signed by the Nessus team.

No

Version 4.7


600


Chapter 15


Value

Description

Modifiable?

Server certificate file location

/var/sf/nessus/com/ nessus/CA/servercer t.pem

The Nessus server looks for the server certificate in the specified location.

No

Key file location

/var/sf/nessus/var/ nessus/CA/serverkey .pem

The Nessus server looks for a private key file for the SSL certificate to be used to connect to services on the target in the specified location.

No

Certificate authority file location

/var/sf/nessus/com/ nessus/CA/cacert.pe m

The Nessus server looks for the file that contains the certificate authority for the SSL certificate used to connect to services on the client in the specified location.

No

Creating a Nessus Scanning Strategy Requires: DC + RNA

Nessus scanning is a useful tool for identifying vulnerabilities on your network. However, scanning can cause system crashes, particularly if you scan using dangerous plugins or disable safe checks. Before you begin scanning, you should first create a strategy that details the tests that you want to perform on specific ports and hosts. For more information, see the following sections: •

Selecting Appropriate Scan Targets on page 601

•

Selecting Appropriate Ports to Scan on page 602

•

Identifying Appropriate Plugin Families for Your Network on page 602

•

DC + RNA on page 605

•

Sample Scanning Profiles on page 605

Selecting Appropriate Scan Targets Requires: DC + RNA

Version 4.7

When you configure your Nessus server, you can create scan targets that identify which hosts you want to scan. A scan target includes a single IP address, a list of IP addresses, or a block of IP address to scan, as well as the ports on the host or hosts.


601


Chapter 15

Ideal scan targets include web servers, mail servers, file servers, FTP servers, and servers on your network perimeter. You can also periodically scan groups of servers running a particular operating system to make sure that the operating systems on those servers have all the latest security updates installed. The Defense Center also automatically creates a scan target for the remediations in the scan instance. This scan target is dynamic; that is, when a remediation launches due to a compliance policy violation, the Defense Center updates it, depending on what kind of event triggered the policy violation and on the settings you configure when you created the remediation: •

If an intrusion event or a flow data event triggered the compliance violation, you can configure the Defense Center to add the source IP address, the destination IP address, or both to the dynamic scan target.

•

If an RNA event triggered the violation, the Defense Center adds the IP address of the host involved in the event to the scan target.

This is useful because you can schedule follow-up scans for the list of IP addresses in the scan target to make sure you periodically rescan targets that have been attacked in the past. The dynamic scan target has the same name as its associated remediation, preceded by a double underscore (__). WARNING! Nessus scans may crash scanned systems, even if you do not use dangerous plugins. If you need to test for vulnerabilities on hosts critical to your infrastructure, you may want to schedule the scanning for a specific time or transfer processing responsibilities for the duration of the scan. In addition, make sure you have permission to scan your targets. Using Nessus to scan hosts that do not belong to you or your company may be illegal.

Selecting Appropriate Ports to Scan Requires: DC + RNA

For each scan target you configure, you can select the ports you want to scan. You can designate individual port numbers, port ranges, or a series of port numbers and port ranges to identify the exact set of ports that should be scanned on each target. You can also configure dynamic port targeting for a Nessus remediation so that when the remediation launches due to a compliance policy violation, it scans the ports in the compliance event, rather than the ports you specified when you created the remediation.

Identifying Appropriate Plugin Families for Your Network Requires: DC + RNA

You can reduce the time and resources dedicated to Nessus scanning by creating remediations that use only the plugin families specific to the needs of your network. Several of the plugin families are grouped by the affected operating system. If you plan to scan hosts running the operating system in question, enable the plugin

Version 4.7


602


Chapter 15

family. For example, if you only need to scan Windows servers, you can disable plugin families that identify vulnerabilities on other operating systems. The Operating System-Related Plugin Families table lists the plugin families that you should enable depending on the operating systems running on hosts on your network. Operating System-Related Plugin Families If you have machines running...

Enable at least...

Debian GNU/Linux

Debian Local Security Checks and Default Unix Accounts

MacOS X

MacOS X Local Security Checks

Novell NetWare

Netware

Gentoo Linux

Gentoo Local Security Checks and Default Unix Accounts

Microsoft Windows

Microsoft Windows and Windows: Microsoft Bulletins

AIX

AIX Local Security Checks and Default Unix Accounts

Red Hat Linux

Red Hat Local Security Checks and Default Unix Accounts

UNIX (various vendors)

Default Unix Accounts

Other plugin families are grouped by the affected client application. If you plan to scan hosts running the applications in question, enable the plugin family. The Client Application-Related Plugin Families table lists the minimum plugin families

Version 4.7


603


Chapter 15

that you should enable depending on the client applications running on hosts on your network. Client Application-Related Plugin Families If you have hosts used as... Web servers

Enable at least... • Backdoors • CGI abuses • CGI abuses: XSS • Denial of Service • Web Servers

Email servers

• Backdoors • Denial of Service • SMTP problems

FTP servers

• Backdoors • Denial of Service • FTP

Version 4.7


604


Chapter 15

Selecting a Scanning Approach Requires: DC + RNA

You can perform a Nessus scan in one of three ways: •

in response to a compliance policy violation

•

as a scheduled scan

•

as an on-demand scan

The Factors to Consider for Nessus Scans table describes considerations you should keep in mind when planning Nessus scans. Factors to Consider for Nessus Scans If...

Consider this approach... • Back up data on the hosts before you scan.

you are scanning hosts that need to be highly available

• Run a manual scan the first time you scan the hosts, at a low usage time for the hosts. • Schedule scans at times when the hosts typically have low usage levels. • Scan with safe checks if the hosts are active. • Disable dangerous plugins if the hosts are active, or schedule a maintenance window when the hosts can be unavailable if you need to enable dangerous plugins. • Disable unnecessary plugins to reduce scan time and risk of host service disruption. • Add the scan to a compliance policy as a response.

you need immediate response to compliance policy violations

• Consider enabling safe checks to avoid crashing the host. • Disable dangerous plugins. • Set up a scanning schedule using the dynamic scan target for the Nessus remediation that launched in response to a compliance policy violation.

you need to check for recurring compliance policy violations

• If you have RNA, Nessus vulnerabilities appear in the network map and the host profile.

Sample Scanning Profiles Requires: DC + RNA

Version 4.7

The following sections describe scenarios in which you might use Nessus scanning. •

Example: Responding to the Introduction of a New Service on page 606

•

Example: Using Scheduled Nessus Scans to Detect Vulnerabilities on page 607

•

Example: Checking a New Network Using an On-Demand Scan on page 608


605


Chapter 15

Example: Responding to the Introduction of a New Service Requires: DC + RNA

When RNA detects a new service on a critical host, you may want to scan that host for vulnerabilities to make sure no unauthorized activity can take place. You can accomplish this by using the Defense Center to identify critical hosts with a user-defined host attribute. Then, create and activate a compliance policy that detects when a new service appears on one of those hosts, and that launches a remediation that performs a Nessus scan on the host. After you activate the policy, you can periodically check the remediation status view (Policy & Response > Responses > Remediations > Status) to see when the remediation launched. The remediation’s dynamic scan target should include the IP addresses of the hosts it scanned as a result of the service detection. Check the host profile for those hosts to see if Nessus detected any vulnerabilities you need to correct to prevent further attack. WARNING! If you have a large or dynamic network, detection of a new service may be too frequent an occurrence to respond to using a scan. To prevent resource overload, avoid using Nessus scans as a response to events that occur frequently. To scan in response to the appearance of a new service:


1.

Set up a Nessus server. If you do not have an existing Nessus server, configure the local Nessus server on the Defense Center. For more information, see Configuring a Local Nessus Server on page 610.

2. Configure a profile (called a scan instance) for the Nessus server. For more information, see Creating a Nessus Scan Instance on page 612. 3. Create a host attribute and use it to identify the hosts you want to monitor. For information on creating host attributes, see Working with User-Defined Host Attributes on page 202. 4. Create a Nessus remediation using the following settings:

Version 4.7

•


•

If there is a possibility that the affected host will be a web server, type the path to the location of CGI script files in the Path to CGIs field.

•

Enable safe checks and disable parts of safe-check compatible plugins to cause those plugins to use passive testing methods instead of invasive methods.


606


Chapter 15

•

Disable dangerous plugins. Also, disable use of plugins that may crash a scanned host or service, cause data corruption on the target system or service, cause a denial of service condition on the target host or service, or generate a large volume of traffic on the network.

•

Enable at least the Service Detection plugin family. Also, enable plugin families appropriate for the operating systems running on hosts on your network. If specific service types concern you, such as SMTP or FTP, enable the plugin families for those service types.

For information on creating Nessus remediations, see Nessus Scan Remediations on page 510. 5. Create two compliance rules that trigger when RNA detects a new service on critical host. The rules should trigger when: •

an RNA event occurs and a new TCP service is detected

•

an RNA event occurs and a new UDP service is detected

You must also create a host profile qualification that constrains each rule so that it only triggers if the service is detected on a host that displays the host attribute you created in step 3. For information on creating compliance rules, see Creating Rules for Compliance Policies on page 394. 6. Create a compliance policy that contains the compliance rules. For more information on creating compliance policies, see Creating Compliance Policies on page 439. 7.

In the compliance policy, add the Nessus remediation you created in step 4 as a response to both of the rules you created in step 5.

8. Activate the compliance policy.

Example: Using Scheduled Nessus Scans to Detect Vulnerabilities Requires: DC + RNA

The occurrence of an attack on a host can indicate that similar attacks will occur in the future. For that reason, you may want to periodically scan hosts where attacks already occurred. For example, you could configure the default worm detection compliance policy delivered with the Sourcefire 3D System so that it responds to worm attacks by launching a Nessus remediation that scans the target host. Each time the scan runs, the Defense Center updates the dynamic scan target in the Nessus remediation to include the IP address of the target host. Then, because you deem previously attacked hosts to be high risk, you could use that dynamic scan target as the scan target for a periodic, scheduled scan that checks for new vulnerabilities on the hosts in the scan target. After each scheduled scan, you can check the Nessus results file to see if Nessus detected any vulnerabilities you need to correct to prevent further attack.

Version 4.7


607


Chapter 15

To respond to worm attacks and then periodically rescan attacked hosts: Access: Rules or Admin

1.


2. Configure a profile (called a scan instance) for the Nessus server. Note that the instance contains two predefined remediations: one that performs a full scan of its scan target and one that performs a portscan. For more information, see Creating a Nessus Scan Instance on page 612. 3. Edit the default worm detection compliance policy so that when it is violated, it launches a Nessus scan. Add the predefined full scan Nessus remediation for the scan instance you created in step 2 as a response to each of the worm detection rules in the policy. For more information, see Creating Compliance Policies on page 439. 4. Activate the compliance policy. 5. Schedule a monthly Nessus scan using the dynamic scan target from the remediation you used as a response in step 3. For more information on scheduling Nessus scans, see Automating Nessus Scans on page 1321.

Example: Checking a New Network Using an On-Demand Scan Requires: DC + RNA

You can use on-demand Nessus scanning to run a scan immediately when you need it. For example, before you bring a new network online, you can scan all hosts on the network to identify their vulnerabilities. After you perform the scan, check the results file or the network map to see if Nessus detected any vulnerabilities you need to correct. For more information, see Analyzing Nessus Results on page 630. WARNING! Do not enable dangerous plugins for scans targeted at systems that are critical to your business infrastructure, unless you can scan them when those systems can be offline. Before you scan with dangerous plugins, make sure you back up all data on targeted systems. Sourcefire recommends that you only enable dangerous plugins when you plan to run the scan, then immediately disable it when the scan is complete. To scan a new network to identify and correct vulnerabilities:


Version 4.7

1.



608

Configuring Active Scanning Setting up Nessus Scans

Chapter 15

2. Configure a profile (called a scan instance) for the Nessus server. Note that the instance contains two predefined remediations: one that performs a full scan of its scan target and one that performs a portscan. For more information, see Creating a Nessus Scan Instance on page 612. 3. Create a scan target for the network you want to scan. For more information, see Creating a Nessus Scan Target on page 614. 4. Run an on-demand Nessus scan using the scan target you created in step 3. For more information, see Running an On-Demand Nessus Scan on page 622.

Setting up Nessus Scans Requires: DC + RNA

Version 4.7

Before you use Nessus to scan your network for vulnerabilities, you must set up your Defense Center to perform Nessus scanning. The following diagram illustrates that process.


609


Chapter 15

To set up your Defense Center to perform Nessus scanning: Access: Rules or Admin

1.


2. Configure a profile (called a Nessus scan instance) for the Nessus server. Note that the instance contains two predefined remediations: one that performs a full scan of its scan target and one that performs a portscan. For more information, see Creating a Nessus Scan Instance on page 612. 3. Create scan targets. Set up scan targets for computers or groups of computers that you want to scan. For more information, see Creating a Nessus Scan Target on page 614. 4. Create a Nessus remediation. For more information, see Creating a Nessus Remediation on page 615.

Configuring a Local Nessus Server Requires: DC + RNA

If you do not have an existing Nessus server that you want to use, configure the local Nessus server on the Defense Center. IMPORTANT! To optimize appliance processing resources, Sourcefire recommends using a external Nessus server (that is, not on your Defense Center). In addition, if you use an external Nessus server, you can register for a plugin feed to obtain updated plugins on an ongoing basis. To perform Nessus scans using an external Nessus server, add a server profile (scan instance) that points to that server. For more information, see Creating a Nessus Scan Instance on page 612. To configure the local server, first you must start it. Then, you must configure a Nessus user. For more information, see the following topics: •

Starting the Local Nessus Server on page 610

•

Configuring a Nessus User on page 611

Starting the Local Nessus Server Requires: DC + RNA

Version 4.7

You must start the local Nessus server before you can use it to perform scans.


610


Chapter 15

To start the local Nessus server: Access: Rules or Admin

1.


2. Click Nessus Server Configuration on the toolbar. The Nessus Server Configuration page appears.

3. Under Nessus Status, click Start Server. The server status indicates that the server started successfully.

Configuring a Nessus User Requires: DC + RNA

The local Nessus server requires a user name and password to authenticate scan requests. To configure a Nessus user for the local Nessus server:


1.


2. Click Nessus Server Configuration on the toolbar. The Nessus Server Configuration page appears.

Version 4.7


611


Chapter 15

3. Under User Setup, click Edit. The Edit User page appears.

4. In the Username field, enter a user name. 5. In the Password fields, enter a password and password confirmation for the Nessus user. IMPORTANT! You will use this user name and password when you create a server profile (scan instance) for the Nessus server. 6. Click Update User to save the user settings. The Nessus user is added.

Creating a Nessus Scan Instance Requires: DC + RNA

You must set up a separate scan instance for each Nessus server that you want to use to scan your network for vulnerabilities. You can set up scan instances that profile external Nessus servers and that profile the local Nessus server on your Defense Center. When you create a scan instance, the Defense Center creates two predefined remediations for it: one remediation that performs a full scan of its scan target and one that performs a portscan. Both remediations enable safe checks and disable dangerous plugins. However, the full scan remediation has all plugin families enabled, while the portscan remediation has all plugin families disabled. The Defense Center also automatically creates a scan target for the remediations in the scan instance. This scan target is dynamic; that is, when a remediation launches due to a compliance policy violation, the Defense Center updates it, depending on what kind of event triggered the policy violation and on the settings you configure when you created the remediation. For more information, see Selecting Appropriate Scan Targets on page 601. To create a scan instance:


Version 4.7

1.



612


Chapter 15

2. Select Operations > Tools > Scanners. The Scanners page appears.

3. Click Add Nessus Instance. The Instance Detail page appears.

4. In the Instance Name field, with no spaces and no special characters other than underscore (_) and dash (-). 5. In the Description field, specify a description for the instance of up to 255 characters, which can include spaces and special characters. 6. In the Host Name field, specify the host name of the Nessus server where you want to configure a connection.

7.

Version 4.7

•

If you are creating an instance for the Nessus server on the Defense Center, type localhost.

•

If you are creating an instance for a remote Nessus server, type the fully qualified host name or the IP address of the Nessus server.

In the Server Port field, specify the port on the Nessus server that should be used for Nessus scans. •

If you are creating an instance for the Nessus server on the Defense Center, type 1241.

•

If creating an instance for a remote Nessus server, type the port used when starting the session for the Nessus server. The default port for Nessus sessions is 1241.


613


Chapter 15

8. In the Username and Password fields, specify the user name and password you want to use to connect to the Nessus server. •

If you are creating an instance for the Nessus server on the Defense Center, type the user name and password you configured earlier. For more information on configuring the Nessus user for the local server, see Configuring a Nessus User on page 611.

•

If you are creating an instance for a remote Nessus server, type the user name and password for a user on that server that has rights to scan the target servers and ports you want to scan.

9. Confirm the password. 10. Click Create. The scan instance is created.

Creating a Nessus Scan Target Requires: DC + RNA

You can create and save scan targets that identify specific hosts and ports. Then, when you perform an on-demand scan or schedule a scan, you can use one of the saved scan targets. To create a scan target:


1.



3. Click Create Scan Target. The Scan Target page appears.

4. In the Name field, type the name you want to use for this scan target.

Version 4.7


614


Chapter 15

5. In the IP Range text box, specify the host or hosts you want to scan. You can specify a single IP address, specify multiple IP addresses separated by commas, or use CIDR notation to specify a block of IP addresses. You can also negate IP addresses by preceding them with an exclamation point (!). For details on entering IP addresses, see Specifying IP Addresses in Searches on page 1130. 6. In the Ports field, specify the ports you want to scan. You can enter a port number, a negation of a port number, a list of ports separated by commas, or a range of port numbers separated by a dash. For details on entering ports, see Specifying Ports in Searches on page 1132. 7.

Click Save. The scan target is created.

Creating a Nessus Remediation Requires: DC + RNA

When you create a Nessus remediation, you must specify the settings and plugin families that the Nessus server uses when it performs a scan. For more information on the settings and plugins, see Understanding Nessus Scans on page 591. To create a Nessus remediation:


Version 4.7

1.



615


Chapter 15

2. Click Add Remediation next to the scan instance where you want to add a remediation. The Remediation Edit page appears.

3. In the Remediation Name field, type a name for the remediation that includes 1 - 63 alphanumeric characters, with no spaces and no special characters other than underscore (_) and dash (-). 4. In the Description field, type a description for the remediation that includes 0255 alphanumeric characters, including spaces and special characters.

Version 4.7


616


Chapter 15

5. If you plan to use this remediation in response to a compliance rule that triggers on an intrusion event or a flow data event, configure the Scan Which Address(es) From Event? option. •


•


•


If you plan to use this remediation in response to a compliance rule that triggers on an RNA event, by default the remediation scans the IP address of the host involved in the event; you do not need to configure this option. Note that these IP addresses are automatically added to the remediation’s dynamic scan target when the remediation is launched due to a compliance policy violation. IMPORTANT! Do not assign a Nessus remediation as a response to a compliance rule that triggers on a traffic profile change. The remediation will not launch. 6. If you plan to use this remediation in response to compliance policy violations, configure the Use Port From Event option: •

Select On to scan the port in the compliance event, rather than the ports you will specify in step 7. If you scan the port in the compliance event, note that the remediation scans the port on the IP addresses that you specified in step 5. These ports are also added to the remediation’s dynamic scan target.

• 7.

Select Off to scan the ports you will specify in step 7.

In the Port Range field, type the ports you want to scan by default. You can enter a port number, a negation of a port number, a list of ports separated by commas, or a range of port numbers separated by a dash. For details on entering ports, see Specifying Ports in Searches on page 1132. Note that you can override this setting when the remediation is launched in response to a compliance policy violation by turning on the Use Port From Event option, as described in step 6.

8. In the Number of checks to perform at the same time field, type the number of plugin scripts you want to process simultaneously. WARNING! To avoid resource overload, do not perform more than 10 checks simultaneously.

Version 4.7


617

Configuring Active Scanning Managing Nessus Scanning

Chapter 15

9. In the Path to CGIs field, type the location of CGI script files that may be in use on a web server being scanned. 10. Configure the Safe Checks option. •

To disable parts of safe-check compatible plugins and cause those plugins to use passive testing methods instead of invasive methods, select On.

•

To force safe-check compatible plugins to use normal testing methods, which may include invasive or dangerous methods, select Off.

11. Configure the Enable Dangerous Plugins option. •

To allow scanning using plugins that may crash a scanned host or service, cause data corruption on the target system or service, cause a denial of service condition on the target host or service, or generate a large volume of traffic on the network, select On.

•

To disable use of dangerous plugins, select Off.

WARNING! Do not enable dangerous plugins for scans targeted at systems that are critical to your business infrastructure, unless you can scan them when those systems can be offline. Before you scan with dangerous plugins, make sure you back up all data on targeted systems. Sourcefire recommends that you only enable dangerous plugins when you plan to run the scan, then immediately disable it when the scan is complete. 12. Configure plugin family options by enabling those that you want to use to scan your systems. For more information, see Understanding Nessus Plugin Families on page 592. 13. Click Save, then click Done. The remediation is created.

Managing Nessus Scanning Requires: DC + RNA

Version 4.7

You can modify or delete Nessus scan instances and remediations and run Nessus scans on demand. For more information, see the following sections: •

Managing Nessus Scan Instances on page 619

•

Managing Nessus Remediations on page 621

•

Running an On-Demand Nessus Scan on page 622


618


Chapter 15

Managing Nessus Scan Instances Requires: DC + RNA

A Nessus scan instance is a profile of the Nessus server you want to use to perform scans. When you create a scan instance, you must: •

specify the host name of the Nessus server that you want to use

•

indicate the port used for the Nessus server session

•

provide Nessus user credentials

You must set up a separate scan instance for each Nessus server you want to use. You can set up scan instances that profile external Nessus servers and that profiles the local Nessus server on your Defense Center. For more information, see the following topics: •

Creating a Nessus Scan Instance on page 612

•

Editing a Nessus Scan Instance on page 619

•

Deleting a Nessus Scan Instance on page 620

Editing a Nessus Scan Instance Requires: DC + RNA

Use the following procedure to modify scan instances. Note that you can view, add, and delete remediations associated with the instance when you modify it. TIP! If you are using an external Nessus server with a plugin feed and you want to use new plugins, edit the scan instance for your Nessus server. This forces the Defense Center to add appropriate configuration options for any new plugin families to the web interface. You can also schedule a task to synchronize Nessus plugins. For more information, see Synchronizing Nessus Plugins on page 1324. To edit a scan instance:


Version 4.7

1.



619


Chapter 15

2. Click View next to the instance you want to edit. The Instance Detail page appears.

3. Optionally, click View next to the remediation you want to view or edit. For more information on editing remediations, see Editing a Nessus Remediation on page 621. 4. Optionally, click Delete next to the remediation you want to delete. For more information on deleting remediations, see Deleting a Nessus Remediation on page 622. 5. Optionally, click Add to add a new remediation to this scan instance. For more information on creating new remediations, see Creating a Nessus Remediation on page 615. 6. Optionally, make changes to the server profile settings, then click Save. 7.

Click Done. The scan instance is modified.

Deleting a Nessus Scan Instance Requires: DC + RNA

Version 4.7

Delete a Nessus scan instance when you no longer want to use the Nessus server profiled in the instance. Note that when you delete the scan instance, you also delete any remediations that use that instance.


620


Chapter 15

To delete a scan instance: Access: Rules or Admin

1.

Click Operations > Tools > Scanners. The Scanners page appears.

2. Click Delete next to the scan instance you want to delete. The instance is deleted.

Managing Nessus Remediations Requires: DC + RNA

Nessus scans are configured as remediations, which are programs that you can configure the Defense Center to run in response to a compliance policy violation. For information on configuring Nessus scans as responses in compliance policies, see Creating Compliance Policies on page 439. WARNING! To prevent resource overload, do not use a Nessus scan as a response to events that occur frequently. Unlike other remediations, however, you can also use Nessus remediations to perform on-demand Nessus scans on your network or on specific hosts to collect data on current vulnerabilities. In addition, you can schedule periodic Nessus scans to regularly assess the security on your network. For more information, see the following topics: •

Creating a Nessus Remediation on page 615

•

Editing a Nessus Remediation on page 621

•

Deleting a Nessus Remediation on page 622

•

Running an On-Demand Nessus Scan on page 622

•

Automating Nessus Scans on page 1321

Editing a Nessus Remediation Requires: DC + RNA

Modifications you make to Nessus remediations do not affect scans in progress. The new settings take effect when the next scan starts. To edit a Nessus remediation:


1.


2. Next to the remediation you want to edit, click View. The Remediation Edit page appears. 3. Make modifications as necessary. For information on the settings you can change, see Creating a Nessus Remediation on page 615.

Version 4.7


621


Chapter 15

4. Click Save, then click Done. The remediation is modified.

Deleting a Nessus Remediation Requires: DC + RNA

Delete a Nessus remediation if you no longer need it. To delete a Nessus remediation:


1.


2. Next to the remediation you want to delete, click Delete. 3. Confirm that you want to delete the remediation. The remediation is deleted.

Running an On-Demand Nessus Scan Requires: DC + RNA

You can launch on-demand Nessus scans whenever needed. You can specify the target for an on-demand scan by entering the IP addresses and ports you want to scan or by selecting an existing scan target. Existing scan targets include any scan targets you created and saved as well as the dynamic scan targets that the Defense Center automatically creates for Nessus remediations. To run an on-demand Nessus scan:


Version 4.7

1.



622

Configuring Active Scanning Managing Scan Targets

Chapter 15

2. Next to the remediation you want to use to perform the scan, click Scan. The Nessus Scan Target dialog box appears.

3. Optionally, to scan using a saved scan target, select a target from the dropdown list and click Load. The IP addresses and ports associated with the scan target populate the IP Range(s) and Ports fields. TIP! To create a scan target, click Edit/Add Targets. For more information, see Creating a Nessus Scan Target on page 614. 4. In the IP Range(s) field, specify the IP address for hosts you want to scan or modify the loaded list. You can specify multiple IP addresses separated by commas or use CIDR notation. You can also negate IP addresses by preceding them with an exclamation point (!). For details on entering IP addresses, see Specifying IP Addresses in Searches on page 1130. 5. In the Ports field, specify the ports you want to scan or modify the loaded list. You can enter any of the following: •

a port number

•

a negation of a port number

•

a list of ports separated by commas

•

a range of port numbers separated by a dash

•

ranges of port numbers separated by dashes, separated by commas

•

a negation of a port range

Click Scan Now. The Nessus server performs the scan.

Managing Scan Targets Requires: DC + RNA

Version 4.7

When you configure a Nessus server or Nmap module, you can create and save scan targets that identify the hosts and ports you want to target when you


623

Configuring Active Scanning Managing Scan Targets

Chapter 15

perform an on-demand or a scheduled scan, so that you do not have to construct a new scan target every time. A scan target includes a single IP address or a block of IP addresses to scan, as well as the ports on the host or hosts. For Nmap targets, you can also use Nmap octet range addressing. For more information on Nmap octet range addressing, refer to the Nmap documentation at http://insecure.org. Once you create a scan target, you can modify or delete it. You can also modify the dynamic scan targets that the Defense Center automatically creates for Nessus remediations. For more information, see the following sections: •

Creating a Nessus Scan Target on page 614

•

Creating an Nmap Scan Target on page 580

•

Editing a Scan Target on page 624

•

Deleting a Scan Target on page 625

Editing a Scan Target Requires: DC + RNA

You can modify both scan targets you created and the dynamic scan targets that the Defense Center automatically creates for Nessus remediations. TIP! You might want to edit a remediation’s dynamic scan target if you do not want to use the remediation to scan a specific IP address, but the IP address was added to the target because the host was involved in a compliance policy violation that launched the remediation. To edit an existing scan target:


1.



Version 4.7


624

Configuring Active Scanning Working with Active Scan Results

Chapter 15

3. Click Edit next to the scan target you want to edit. The Scan Target page appears.

4. Make modifications as necessary and click Save. The scan target is updated.

Deleting a Scan Target Requires: DC + RNA

Delete a scan target if you no longer want to scan the hosts listed in it. To delete a scan target:


1.



3. Next to the scan target you want to delete, click Delete. The scan target is deleted.

Working with Active Scan Results Requires: DC + RNA

Version 4.7

For information on how to monitor Nessus or Nmap scans in progress, import results from scans previously performed through the Sourcefire 3D System or results preformed outside the Sourcefire 3D System, and view and analyze scan results, see the following sections: •

Monitoring Scans on page 626

•

Importing Results on page 626

•

Searching for Scan Results on page 627

•

Analyzing Nmap Results on page 629

•

Analyzing Nessus Results on page 630


625


Chapter 15

Monitoring Scans Requires: DC + RNA

You can check the progress of a Nessus or Nmap scan and cancel scan jobs currently in progress. Once the scan is completed, you can also view the scan results as a rendered page in a pop-up window. You can download Nessus scan results file so that you can view the raw XML code in any text editor. Nmap results you can download and view using the Nmap Version 1.01 DTD, available at http://insecure.org. You can also clear scan results. To monitor a scan:


1.

Select Operations > Tools > Scan Results. The Scan Results page appears. It contains a row for each completed scan and the start time and end time of the scan. It also provides links to view the scan results or download the results file.

2. You can perform the following actions: •

To view the scan results as a rendered page in a pop-up window, click View next to the scan job.

•

To save a copy of the scan results file so that you can view the raw XML code in any text editor, click Download next to the scan job.

Importing Results Requires: DC + RNA

Version 4.7

You can import XML results files created by a Nessus or Nmap scan performed outside of the Sourcefire 3D System. You can also import XML results files that you previously downloaded from the Sourcefire 3D System. To import Nmap scan results, the results file must be in XML format and adhere to the Nmap Version 1.01 DTD. For more information on creating Nmap results and on the Nmap DTD, refer to the Nmap documentation at http://insecure.org. For information on how to create XML results files for a Nessus scan performed outside of the Sourcefire 3D System, refer to the documentation for your Nessus server. For information on downloading XML results from the Sourcefire 3D System, see Monitoring Scans on page 626.


626


Chapter 15

To import results: Access: Rules or Admin

1.

Select Operations > Tools > Scanners. The Scan Instances page appears.

2. On the toolbar, click Import Results. The Import Results page appears.

3. Select the type of scan results you want to import: Nessus or Nmap. 4. Click Browse to navigate to the results file. 5. After you return to the Import Results page, click Import to import the results. The results file is imported.

Searching for Scan Results Requires: DC + RNA

You can search for Nmap or Nessus scan results for any scans run on an appliance or managed appliance in your Sourcefire 3D System.

Scan Results Search Criteria Field


Start Time

Type the date and time that the scan that produced the results started. See Specifying Time Constraints in Searches on page 1130 for the syntax for entering time.

End Time

Type the date and time that the scan that produced the results ended. See Specifying Time Constraints in Searches on page 1130 for the syntax for entering time.

Version 4.7


627


Chapter 15

Scan Results Search Criteria (Continued) Field


Scan Target

Type the IP address (or host name, if DNS resolution is enabled) of the scan target for the scan that produced the results. Use a specific IP address or CIDR notation to specify a range of IP addresses. See Specifying IP Addresses in Searches on page 1130 for a full description of the syntax allowed for IP addresses.

Scan Type

Type either Nessus or Nmap to indicate the type of the scan that produced the results.

Scan Mode

Type the mode of the scan that produced the results: • Type On Demand to retrieve results from scans run on demand. • Type Imported to retrieve results from scans on a different system and imported onto the Defense Center. • Type Scheduled to retrieve results from scans run as a scheduled task. For more information on searching, including how to load and delete saved searches, see Searching for Events on page 1124. To search for scan results:


1.

Select Analysis & Reporting > Searches > Scan Results. The Scan Results search page appears.


Version 4.7


628


Chapter 15

2. Optionally, if you want to save the search, enter a name for the search in the Name field. If you do not enter a name, the Defense Center automatically creates one when you save the search. 3. Enter your search criteria in the appropriate fields, as described in the Scan Results Search Criteria table. If you enter multiple criteria, the Defense Center returns only the records that match all the criteria. 4. If you want to save the search so that other users can access it, clear the Save As Private check box. Otherwise, leave the check box selected to save the search so that only you can use it. TIP! If you want to save a search as a restriction for restricted data users, you must save it as a private search. 5. You have the following options: •

Click Search to start the search. If you specified a preferred flow data workflow, your search results appear, constrained by the current time range on the Defense Center. Otherwise, you must select a workflow. For information on specifying a preferred workflow, see Setting Event Preferences on page 35.

•



Analyzing Nmap Results Requires: DC + RNA

You can view scan results that you create using the local Nmap module as a rendered page in a pop-up window. You can also download the Nmap results file in raw XML format. You can also view operating system and service information detected by Nmap in host profiles and in the network map. If a scan of a host produces service information for services on filtered or closed ports, or if a scan collects information that cannot be included in the operating system information or the services section, the host profile includes those results in an Nmap Scan Results section. For more information, see Viewing Host Profiles on page 175.

Version 4.7


629


Chapter 15

Analyzing Nessus Results Requires: DC + RNA

Nessus results files include: •

Nessus server settings used in the scan

•

Nessus plugin settings used in the scan

•

vulnerabilities identified in the scan.

You can view scan results that you create using the local Nessus server as a rendered page in a pop-up window. You can also download the Nessus results file and view it in any text editor. You can also view Nessus vulnerabilities in host profiles and in the network map. For more information, see Viewing Host Profiles on page 175 and Working with the Vulnerabilities Network Map on page 158.

Enabling the Nessus Vulnerability Database Requires: DC + RNA

You can use the Nessus vulnerability database to perform impact flag correlation with intrusion events. To enable the Nessus vulnerability database:


1.

Enable Use Nessus Vulnerability Mappings on the RNA Settings page of the system policy. For information on configuring RNA settings, see Configuring RNA Settings on page 1204.

2. Apply the system policy to the Defense Center. For information on applying a system policy, see Applying a System Policy on page 1192. IMPORTANT! Your changes to the policy do not take effect until you reapply the policy to the Defense Center that uses it.

Version 4.7


630

Chapter 15

Preparing the Defense Center for RNA Visualizer

Before installing RNA Visualizer client software on your workstation, you must enable database access on the Defense Center, create at least one user account for RNA Visualizer clients to use when communicating with the Defense Center, and configure the networks that are allowed to access the Defense Center database from the RNA Visualizer client. If you plan to use Estreamer for notifications of new hosts, or Streamviewer to view events, you also need to set up Estreamer client connections. For more information on setting up Estreamer clients, see Managing Event Streamer Clients on page 1256. If you are managing 3D Sensors that use both the IPS and RNA components, you can configure the system to send events with specific impact flag values to RNA Visualizer. For more information on enabling event transmission by impact flags, see Configuring External Alerting on Impact Flags on page 470. IMPORTANT!

RNA Visualizer is not currently supported for Nokia customers.


Version 4.7

•

Enabling Remote Database Access on page 632

•

Creating RNA Visualizer User Accounts on page 632

•

Changing RNA Visualizer User Account Passwords on page 634

•

Modifying RNA Visualizer User Accounts on page 635

•

Deleting RNA Visualizer User Accounts on page 635


631

Preparing the Defense Center for RNA Visualizer Enabling Remote Database Access

Chapter 16

Enabling Remote Database Access Requires: DC + RNA + RNA Visualizer

You must enable remote database access before RNA Visualizer users can access the RNA database. TIP! You can access Estreamer from the Visualizer page. Configuring Estreamer allows the Defense Center to transmit real-time new host events to RNA Visualizer. To access Estreamer Configuration, click Estreamer on the toolbar, or, under Configure Estreamer, click Configure. See Managing Event Streamer Clients on page 1256 for instructions on how to configure Estreamer. To enable remote database access:

Access: Admin

1.

Select Operations > Configuration > Visualizer. The Visualizer page appears.

2. Click Enable. The status changes to Enabled and displays a lit light bulb icon. The database is now accessible for any RNA Visualizer user accounts that you add. TIP! You can disable access for all RNA Visualizer clients connecting to the database on your Defense Center by clicking Disable.

Creating RNA Visualizer User Accounts Requires: DC + RNA + RNA Visualizer

You must create at least one RNA Visualizer user and enable database access so that RNA Visualizer can access the Defense Center. To add an RNA Visualizer user:

Access: Admin

1.

On the Defense Center, select Operations > Configuration > Visualizer. The Visualizer page appears.

Version 4.7


632

Preparing the Defense Center for RNA Visualizer Creating RNA Visualizer User Accounts

Chapter 16

2. Click Create User. The Edit User page appears.

3. In the User Name field, enter a user name. 4. In the Enter Password and Re-Enter Password fields, enter a password for the RNA Visualizer user. TIP! Make a note of the user name and password for use when configuring the RNA Visualizer client software. 5. To add networks from which the user can log into RNA Visualizer, click Add Network. A row appears for the new network. 6. In the IP Address field, enter the IP address that represents the host or network where RNA Visualizer clients originate. 7.

In the Netmask field, enter the netmask (using CIDR notation) that describes the number of IP addresses that you want to allow. For example, to allow access only for the IP address 192.168.1.50, enter

192.168.1.50 in the IP Address field, and 32 in the Netmask field. If you want

all hosts between IP addresses 192.168.1.1 and 192.168.1.255 to access the database using the account, use 192.168.1.0 and 24. TIP! For more information about using CIDR notation to specify IP addresses, see Specifying IP Addresses in Searches on page 1130.

8. Repeat steps 5-7 for each network segment or IP address you want to add to the account. TIP! To delete a network, click Delete next to the network you want to delete.

Version 4.7


633

Preparing the Defense Center for RNA Visualizer Changing RNA Visualizer User Account Passwords

Chapter 16

9. Click Save. The Visualizer page appears, showing the user you just added.

10. Click Activate to activate the account. 11. To add more users, repeat steps 2-10. You are now ready to download, install, and configure the RNA Visualizer software. Refer to the RNA Visualizer User Guide for information about downloading and installing RNA Visualizer. WARNING! You must activate new users and enable remote database access. Otherwise, RNA Visualizer cannot communicate with the Defense Center.

Changing RNA Visualizer User Account Passwords Requires: DC + RNA + RNA Visualizer

You can change the password for an RNA Visualizer user at any time. TIP! Make sure you also update the password in the connection profiles for any RNA Visualizer clients that use that user to connect to the database. To change the password for an RNA Visualizer user account:

Access: Admin

1.


2. Next to the account you want to modify, click Change Password. The Change Password page appears.

3. In the Old Password field, type the current password for the account.

Version 4.7


634

Preparing the Defense Center for RNA Visualizer Modifying RNA Visualizer User Accounts

Chapter 16

4. In the New Password and Re-enter New Password fields, type the new password. 5. Click Change. The password is changed.

Modifying RNA Visualizer User Accounts Requires: DC + RNA + RNA Visualizer

After creating RNA Visualizer user accounts, you can modify the monitored networks. To modify RNA Visualizer user accounts:

Access: Admin

1.


2. Next to the account you want to modify, click Edit. The Edit User page appears.

3. Make changes to the account settings as needed: •

To remove a network, click Delete in the row for that network.

•

To add a network, click Add Network and type values in the IP Address and Netmask fields.

TIP! For more information about entering IP addresses, including examples, see step 7 of Creating RNA Visualizer User Accounts on page 632. 4. When you have finished modifying the account, click Save. The account is modified.

Deleting RNA Visualizer User Accounts Requires: DC + RNA + RNA Visualizer

Version 4.7

Delete an RNA Visualizer user account if it is no longer needed.


635

Preparing the Defense Center for RNA Visualizer Deactivating RNA Visualizer User Accounts

Chapter 16

To delete an RNA Visualizer user account: Access: Admin

1.


2. Click Delete. The account is deleted.

Deactivating RNA Visualizer User Accounts Requires: DC + RNA + RNA Visualizer

You can deactivate RNA Visualizer user accounts if they are not currently needed but might be used in the future. Deactivating an account prevents users from using the account to connect to the database. To deactivate an RNA Visualizer user account:

Access: Admin

1.


2. Click Deactivate. The account is inactive and cannot be used until it is activated.

Activating RNA Visualizer User Accounts Requires: DC + RNA + RNA Visualizer

You must activate inactive RNA Visualizer user accounts before they can be used. By default, an account is inactive after you create it. To activate an RNA Visualizer user account:

Access: Admin

1.


2. Click Activate. The account is activated and can now be used.

Version 4.7


636

Chapter 16

Introduction to Sourcefire IPS

You can deploy your Sourcefire 3D System either inline or passively on your network to help you monitor for network traffic that could threaten the availability, integrity, and confidentiality of hosts and their data. The term intrusion detection generally refers to the process of passively analyzing network traffic for potential intrusions and storing attack data for security analysis. The term intrusion prevention includes the concept of intrusion detection, but adds the ability to block or alter malicious traffic as it travels across your network. The Sourcefire IPS component of the Sourcefire 3D System can perform as both an intrusion detection system and an intrusion prevention system depending on: •

how you attach 3D Sensors with IPS to your network: inline or out of band

•

how you configure the sensors’ interface sets: passive or inline

•

the type of intrusion policy you apply to the sensors’ detection engines: passive or inline

After you deploy your 3D Sensors with IPS and configure them according to your needs, IPS has several mechanisms it uses to look for the broad range of exploits that attackers have developed. You can then use the broad range of tools in the Sourcefire 3D System to analyze and respond to the intrusion events that are generated by IPS. IMPORTANT! All of the intrusion detection and prevention features in the Sourcefire 3D System require that you deploy 3D Sensors with the IPS component. IPS adds a full web interface to the 3D Sensor, but you can gain additional insight into your network and the attacks on it by managing your 3D Sensors with a Defense Center.

Version 4.7


637


Chapter 17

Sensing Intrusions 3D Sensors use detection engines, which are a collection of one or more sensing interfaces on a sensor plus a portion of the sensor’s computing resources, to analyze network traffic for evidence of attacks on network resources. Each detection engine on the 3D Sensor has several methods that it uses to look for a broad range of exploits. First, packet decoders and preprocessors report on anomalous traffic that might signal an intrusion attempt. Next, the detection engine uses intrusion rules to examine the decoded packets for attacks based on patterns. Used together, intrusion rules and preprocessors provide broader and deeper packet inspection than a signature-based system and help to identify intrusions more effectively. The Sourcefire Vulnerability Research Team (VRT) regularly sends out updates called Security Enhancement Updates, or SEUs, that can contain new intrusion rules, decoders, and preprocessors, so you can be sure that you are detecting the most recently released attacks.

Responding to Intrusions When a packet travels over a segment monitored by a detection engine, the IPS detection engine captures and analyzes it using a series of decoders and preprocessors and then a rules engine. When a detection engine identifies a possible intrusion, it generates an intrusion event, which is a record indicating the date, time, the type of exploit, and contextual information about the source of the attack and its target. If the IPS detection engine is deployed inline and traffic flows through a pair of interfaces on the sensor, the detection engine can block possible intrusions or replace harmful content in a packet. For packet-based events, a copy of the packet or packets that triggered the event is also recorded. You can also generate alerts in response to events, or launch a remediation using a firewall. In a Sourcefire 3D System deployment that includes 3D Sensors with IPS and a Defense Center, the sensors transmit their events to the Defense Center where

Version 4.7


638


Chapter 17

you can view the aggregated data and gain a greater understanding of the attacks against your network assets.

To learn more about IPS and how a Sourcefire 3D System deployment that includes IPS can help protect your network, see the following sections:

Version 4.7

•

Understanding How Traffic Is Analyzed on page 640

•

Analyzing Intrusion Event Data on page 644

•

Using Intrusion Event Responses on page 645

•

Understanding IPS Deployments on page 646

•

The Benefits of Custom Intrusion Policies on page 649


639

Introduction to Sourcefire IPS Understanding How Traffic Is Analyzed

Chapter 17

Understanding How Traffic Is Analyzed Requires: IPS or DC/MDC + IPS

3D Sensors with IPS use award-winning Snort® technology to analyze network traffic and generate intrusion events, which are records of the traffic that violates the intrusion policy applied to a detection engine on the sensor that is monitoring a specific network segment. Event analysts can review the events and determine whether they are important in the context of your network. Intrusion events can be generated by: •

a link layer decoder such as the Ethernet II decoder

•

a network layer decoder such as the IP decoder

•

a transport layer decoder such as the TCP decoder

•

an application layer decoder or preprocessor such as the HTTP Inspect preprocessor

•

the rules engine

The following diagram illustrates the process:

Events include:

Version 4.7

•

the date and time the event was generated

•

the event priority

•

Requires: DC + IPS + RNA the impact flag associated with the event

•

the name of the detection engine that generated the event

•

the protocol of the packet that caused the event

•

the source IP address and port for the event

•

the destination IP address and port for the event

•

the ICMP type and code (for ICMP traffic)

•

the Sourcefire 3D System component that generated the event (for example, the rule, decoder, or preprocessor)

•

a brief description of the event


640


Chapter 17

For details on the basic information included in an intrusion event, see Understanding the Intrusion Events Table on page 659. IMPORTANT! available.

For events generated by shared object rules, the rule itself is not

The following sections describe more about how IPS acquires and processes information: •

Capturing and Decoding Packets on page 641

•

Processing Packets on page 642

•

Generating Events on page 644

Capturing and Decoding Packets Requires: IPS or DC/MDC + IPS

Before packets can be inspected by the IPS detection engine, the packets must be captured from the network. The following illustration shows how the detection engine sniffs packets, then decodes them prior to any further analysis.

As the detection engine captures packets, it sends them to the packet decoder. The packet decoder converts the packet headers and payloads into a format that can be easily used by the preprocessors and the rules engine. Each layer of the TCP/IP stack is decoded in turn, beginning with the data link layer and continuing

Version 4.7


641


Chapter 17

through the network and transport layers, as described in the Decoded Packets table. Decoded Packets In this TCP/IP layer... Data Link

These packets are decoded... • raw packets • loopback interface • Ethernet • Token Ring • Fiber Distributed Data Interface (FDDI) • Linux SLL (cooked mode) • IEEE 802.11 • Point-to-Point Protocol (PPP) • Point-to-Point Protocol over Ethernet (PPPOE) • Serial Line Internet Protocol (SLIP) • ISDN for Linux (I4L) • Address Resolution Protocol (ARP) • Extensible Authentication Protocol (EAP) • EAP over LAN (EAPOL)

Network

• Internet Protocol (IP) • Internet Control Message Protocol (ICMP)

Transport

• Transmission Control Protocol (TCP) • User Datagram Protocol (UDP)

Processing Packets Requires: IPS or DC/MDC + IPS

Version 4.7

After the packets are decoded through the first three TCP/IP layers, they are sent to preprocessors, which normalize traffic at the application layer and detect protocol anomalies. After the packets have passed through the preprocessors, they are sent to the rules engine. The rules engine inspects the packet headers


642


Chapter 17

and payloads to determine whether they trigger any of the shared object rules or standard text rules.

You can enable and disable preprocessors and preprocessor options to suit your environment. For example, one of the preprocessors normalizes HTTP traffic. If you are confident that your network does not include any web servers using Microsoft Internet Information Services (IIS), you can disable the preprocessor option that looks for IIS-specific traffic and thereby reduce system processing overhead. The rules engine takes three tracks as it inspects packets from the preprocessors: •

the rule optimizer

•

the multi-rule search engine

•

the event selector

For more information on preprocessors, see Tuning Preprocessors on page 846. When you apply an intrusion policy to the detection engines, and before any packets are processed, the rule optimizer reads in all the activated rules and then classifies them in subsets based on criteria such as transport layer, application protocol, direction to or from the protected network, and so on. As packets arrive at the rules engine, it selects the appropriate rule subsets to apply to each packet. After the rule subsets are selected, the multi-rule search engine performs three different types of searches: •

The protocol field search looks for matches in particular fields in an application protocol.

•

The generic content search looks for ASCII or binary byte matches in the packet payload.

•

The packet anomaly search looks for packet headers and payloads that, rather than containing specific content, violate well-established protocols.

After the multi-rule search engine examines the packets, it generates an event for every rule triggered and adds it to an event queue. The event selector prioritizes the events in the queue and logs an event to the event database. These are the intrusion events that appear in the event intrusion statistics and intrusion event reports.

Version 4.7


643

Introduction to Sourcefire IPS Analyzing Intrusion Event Data

Chapter 17

Generating Events Requires: IPS or DC/MDC + IPS

Packets are evaluated by the packet decoder, the preprocessors, and the rules engine. At each step of the process, a packet could cause Sourcefire 3D System to generate an event, which is an indication that the packet or its contents may be a risk to the security of your network, or, in the case of an attack that originates from within your network, to the security of either your network or an external network.

For example, if the packet decoder receives an IP packet that is less than 20 bytes (which is the size of an IP datagram without any options or payload), the decoder interprets this as anomalous traffic and generates an event. Similarly, at the preprocessing step, if the IP defragmentation preprocessor encounters a series of overlapping IP fragments, the preprocessor interprets this as a possible attack and generates an event. The same kind of response occurs within the rules engine, with most rules written so that they also generate events when triggered by packets. Each event in the database includes two types of information about the potential attack. The first is called an event header and contains information about the event name and classification, the source and destination IP addresses and ports, the process that generated the event, and the date and time of the event. The second is the packet log and includes a copy of the decoded packet header and packet payload.

Analyzing Intrusion Event Data Requires: IPS or DC/MDC + IPS

Version 4.7

As IPS accumulates intrusion events, you can begin your analysis of potential attacks. The Sourcefire 3D System provides you with the tools you need to review


644

Introduction to Sourcefire IPS Using Intrusion Event Responses

Chapter 17

the intrusion events and evaluate whether they are important in the context of your network environment and your security policies. These tools include: •

an Intrusion Event Statistics page that gives you an overview of the current activity on your 3D Sensor For more information, see Viewing Intrusion Event Statistics on page 653.

•

text-based and graphical reports that you can generate for any time period you choose; you can also design your own event reports and then configure them to run at scheduled intervals For more information, see Building and Generating Reports on page 1103.

•

an incident-handling tool that you can use to gather event and packet data related to an attack; you can also add notes to help you track your investigation and response For more information, see Handling Incidents on page 707.

•

predefined and custom workflows that you can use to drill down through the intrusion events and to identify the events that you want to investigate further For more information, see Understanding and Using Workflows on page 1147 and Working with Intrusion Events on page 651.

Using Intrusion Event Responses Requires: IPS or DC/MDC + IPS

In addition to generating intrusion events based on attacks, you can use an extensive list of alerting mechanisms to make sure that specific attacks are brought to your attention immediately. Conversely, you can suppress events that are less likely to affect critical systems or set a threshold that the number of events must reach before you are alerted. You can use the following tools to set up automatic responses to intrusion events: •

automated alerting that you can configure for SNMP, email, and syslog For more information, see Configuring Intrusion Event Responses on page 718.

•

automated firewall response that you can configure For more information, see Responding to Events with a Check Point Firewall on page 730.

•

Requires: DC + IPS automated compliance policies that you can use to respond to and remediate specific intrusion events For more information, see Configuring Responses for Compliance Policies on page 456.

Version 4.7


645

Introduction to Sourcefire IPS Understanding IPS Deployments

Chapter 17

Understanding IPS Deployments Requires: IPS or DC/MDC + IPS

You can assign a passive interface set to an IPS detection engine and apply a passive intrusion policy so that the detection engine senses traffic out of band from the packet stream. Similarly, you can assign an inline interface set to an IPS detection engine so that the traffic flows between a pair of sensing interfaces on the sensor. An inline interface set on an IPS detection engine with an inline intrusion policy allows you to drop or replace packets that you know to be harmful. You can tailor intrusion policies for each IPS detection engine so that it generates events only for the attacks that are likely to affect the security of the hosts on specific portions of your network. You can specify which rules do not alert, which rules generate events and, for an inline deployment, which rules generate events and also drop the malicious traffic. For either type of system, you connect sensing interfaces to the appropriate segments on your network and add those interfaces to a interface set. These interfaces are configured in stealth mode so, to other devices on the network, the 3D Sensor itself does not appear to be connected to the network at all. Additionally, the interfaces are configured in promiscuous mode so that they detect all of the traffic on the network segment regardless of where the traffic is going. In this configuration, the detection engine can see all of the traffic on the network segment but is itself invisible. The key deployment difference between an out-of-band deployment and an inline deployment lies in the interface sets used by each system. An out-of-band deployment uses a passive interface set; an inline deploment uses an inline or inline with fail open interface set. The interfaces for a passive interface set passively analyze the traffic on the segments they monitor, while traffic flows between pairs of interfaces in an inline or inline with fail open interface set. The following illustration shows an example of a 3D Sensor with IPS deployed passively and configured with two detection engines using passive interface sets.

Version 4.7


646


Chapter 17

Each IPS detection engine is using a different network interface on the sensor and is monitoring a different network segment.

Configuring an out-of-band IPS detection engine allows you to devote almost all of the detection engine’s bandwidth and computational power to monitoring traffic, reconstructing datagrams and streams, normalizing packets, detecting anomalies, and alerting you to possible intrusions. Moreover, because the detection engine is deployed out of band and operates in stealth mode, attackers are unlikely to know of its existence, which renders it less of a target for attacks. In an inline deployment, by comparison, you configure an IPS detection engine that uses an inline interface set. To do this, you connect the 3D Sensor with IPS to your network so that traffic flows between the network interfaces that are assigned to your detection engine. When the interface set is configured as Inline or Inline with Fail Open, the interfaces are again configured in promiscuous mode so that they detect all of the traffic on the network segment regardless of where the traffic is going. The detection engine can see all of the traffic on the network segment but is itself invisible. However, when the interface set is deployed inline, you can configure intrusion rules to drop suspicious packets or replace malicious portions of a packet payload with more benign content.

Version 4.7


647


Chapter 17

For example, the following illustration shows an IPS. The detection engine uses an interface set containing two of the network interfaces on the back of the sensor and is monitoring a single network segment.

Similar to a detection engine using a passive interface set, the detection engine using an inline interface set can see all of the traffic that passes through the interfaces in its interface set, regardless of the traffic’s destination. However, because the traffic flows between the interfaces, you can modify or block suspicious packets. For example, if the detection engine detects a packet whose payload contains a known exploit that your network may be vulnerable to, you can configure the engine to drop the packet. In this case, the malicious packet never reaches its intended target. When using IPS in an inline deployment, you can also replace a portion of the payload with content of your own choosing. Consider a simple example where the detection engine detects a packet that contains bin/sh, which can often indicate a shellcode attack. You can write a custom intrusion rule that replaces all or part of this string with exactly the same number of characters. For example, replacing bin/sh with foo/sh and then passing the packet on to its destination causes the shellcode attack to fail without tipping off the attacker that the packet was altered. Compare this result with the result when the same traffic is inspected passively. In that scenario, the same rule detects the exploit, but instead of having an option to drop the packet, you can only alert on its presence. As you consider the benefits of deploying an IPS, you should weigh some of the tradeoffs. First, if you deploy an IPS, you must choose a 3D Sensor model that matches or exceeds the traffic bandwidth the network segment. Also, depending on the criticality of the hosts on the network segment, you should consider deploying the sensor with the optional fail-open network card. The fail-open card ensures that traffic continues to pass through the interfaces even if the appliance itself fails or loses power (although you may lose a few packets when you reboot the appliance). For more information on detection engines and interface sets, see

Version 4.7


648

Introduction to Sourcefire IPS The Benefits of Custom Intrusion Policies

Chapter 17

Using Detection Engines and Interface Sets on page 102. You can learn more about deployment options in your sensor’s Installation Guide.

The Benefits of Custom Intrusion Policies Requires: IPS or DC/MDC + IPS

IPS provides default intrusion policies for both passive and inline deployments. However, you may find that the rules and preprocessor options configured in those policies do not address the security needs of your network. You can tune the policy by enabling or disabling preprocessor options and rules. Tuning preprocessor options and rule sets allows you to configure, at a very granular level, how the system processes and inspects the traffic on your network. Intrusion policies provide the following ways to tune preprocessors: •

Deactivate preprocessors that do not apply to the traffic on the subnet you are monitoring.

•

Specify ports, where appropriate, to focus the activity of the preprocessor.

•

Determine whether or not you want the preprocessor to generate an event when it acts on a packet.

•

Configure preprocessors to generate events when they encounter certain features in packets, for example, state problems or certain combinations of TCP flags.

Note that the tuning options available vary by preprocessor. For details on the available preprocessors, their options, and how to tune your preprocessor configuration, see Tuning Preprocessors on page 846. Additionally, within each intrusion policy, you can tune rules in the following ways: •

Improve performance by using fewer rules; disable rules that are not applicable to your environment.

•

Verify that all rules applicable to your environment are enabled.

•

For inline detection engines, specify which rules should direct the detection engine to drop malicious packets from the packet stream. TIP! Requires: DC + IPS + RNA If your Sourcefire 3D System deployment includes IPS and RNA, you can use RNA to identify the operating systems on your network. This allows you to more easily identify which rules are applicable to your environment.

Version 4.7

•

Modify the values of variables used in rules so that the rules are more specific to your network.

•

Modify existing rules, if necessary, to correspond to your network infrastructure.

•

Write new standard text rules as needed using the Snort language and the rule editor to catch new exploits or to enforce your security policies.


649

Introduction to Sourcefire IPS The Benefits of Custom Intrusion Policies

Chapter 17

For details on rule keywords, their arguments and syntax, and how to tune your rule set, see Understanding and Writing Intrusion Rules on page 948. RuleWriting Examples and Tips on page 1018 provides additional tuning examples and suggestions. You can also set suppression levels and thresholds to control how frequently you are notified of intrusion events. You can chose to suppress event notifications and set thresholds for individual rules or entire intrusion policies. For more information, see Setting Threshold Options within the Packet View on page 678, Setting Suppression Options within the Packet View on page 679, and Limiting Intrusion Event Notification Per Policy on page 766. Specifying the protocol analysis, data normalization, and traffic inspection performed by IPS and saving this configuration as a whole allows you to control the kind of information IPS provides you to best meet your enterprise security needs. It also provides a simple mechanism for changing as much or little of your policy as needed to continue to detect new attacks and exploits.

Version 4.7


650

Chapter 17

Working with Intrusion Events

The Sourcefire 3D System can help you monitor your network for traffic that could affect the availability, integrity, and confidentiality of a host and its data. By placing 3D Sensors that are licensed for the IPS component on key network segments, you can examine the packets that traverse your network for malicious activity. IPS has several mechanisms it uses to look for the broad range of exploits that attackers have developed. When IPS identifies a possible intrusion, it generates an intrusion event, which is a record of the date, time, the type of exploit, and contextual information about the source of the attack and its target. For packet-based events, a copy of the packet or packets that triggered the event is also recorded. In a Sourcefire 3D System deployment that includes a Defense Center managing 3D Sensors with IPS, the sensors transmit their events to the Defense Center where you can view the aggregated data and gain a greater understanding of the attacks against your network assets. You can also deploy IPS as an inline intrusion system, which allows you to configure the sensor to drop or replace packets that you know to be harmful. The Sourcefire 3D System also provides you with the tools you need to review the events that IPS generates and evaluate whether they are important in the context of your network environment and your security policies. These tools include:

Version 4.7

•

an Event Summary page that gives you an overview of the current activity on your 3D Sensors with IPS

•

text-based and graphical reports that you can generate for any time period you choose; you can also design your own reports and configure them to run at scheduled intervals


651

Working with Intrusion Events

Chapter 18

•

an incident-handling tool that you can use to gather event data related to an attack; you can also add notes to help you track your investigation and response

•

automated alerting that you can configure for SNMP, email, and syslog

•

on a Defense Center that manages 3D Sensors with IPS and RNA, automated compliance policies that you can use to respond to and remediate specific intrusion events

•

predefined and custom workflows that you can use to drill down through the data to identify the events that you want to investigate further


Version 4.7

•

Viewing Intrusion Event Statistics on page 653 describes the Intrusion Event Statistics page, which provides you with an overview of the health of the appliance and a summary of the top threats to your network.

•

Viewing Intrusion Event Graphs on page 657 explains how to generate charts that show event trends over time.

•

Viewing Intrusion Events on page 658 describes how to use the web interface to view and investigate your intrusion events.

•

Viewing Reviewed Intrusion Events on page 661 explains how to identify intrusion events that were previously marked as reviewed.

•

Understanding Workflow Pages for Intrusion Events on page 662 describes the various pages that are available in intrusion event workflows and explains how you can use them to analyze your intrusion events.

•

Using Drill-Down and Table View Pages on page 667 describes the features of two of the types of pages in an intrusion event workflow.

•

Using the Packet View on page 673 explains how to use the packet view of intrusion events.

•

Using Impact Flags to Evaluate Events on page 686 describes how you can use the impact flag to evaluate intrusion events if your Defense Center manages 3D Sensors with RNA and IPS deployed on the same network segments.

•

Searching for Intrusion Events on page 689 explains how you can use the search feature to constrain a list of intrusion events to specific criteria.

•

Locating Whois Information for a Host on page 695 describes how to look up information for the IP addresses of attackers from within the web interface.

•

Using the Clipboard on page 695 describes how to add intrusion events to a holding area called the clipboard so that you can later add the events to incidents. This section also explains how to generate event reports based on the contents of the clipboard.

•

Sample Event Analysis on page 698 steps through the features you use as you investigate the intrusion events on your system.


652

Working with Intrusion Events Viewing Intrusion Event Statistics

Chapter 18

Also, see: •

Handling Incidents on page 707 for more information about incident handling and how you can use incidents to track the progress of an event analysis.

•

Configuring Intrusion Event Responses on page 718 for more information about automated alerting.

•

Building and Generating Reports on page 1103 for more information about intrusion event reports.

Viewing Intrusion Event Statistics Requires: IPS or DC/MDC + IPS

Version 4.7

The Intrusion Event Statistics page provides you with a quick summary of the current state of your appliance and any intrusion events generated by IPS for your network.


653


Chapter 18

The Intrusion Event Statistics page has three main areas: •

Host Statistics on page 655 describes the Host Statistics section, which provides information about the appliance and, for Defense Centers, their managed 3D Sensors with IPS.

•

Event Overview on page 655 describes the Event Overview, which provides an overview of the information in the event database.

•

Event Statistics on page 656 describes the Event Statistics, which provides more specific details about the information in the event database, such as the top 10 event types.

Each of the IP addresses, ports, protocols, and event messages on the page is a link. Click any link to view the associated event information. For example, if one of the top 10 destination ports is 80 (http)/tcp, clicking that link displays the first page in your preferred workflow and lists the events targeting that port. Note that only the events (and the detection engines that generate events) in the current time range appear. Also, intrusion events that you have marked as reviewed continue to appear in the statistics. For example, if the current time range is the past hour but the first event was generated five hours ago, when you click the First Event link, the resulting event pages will not show the event until you change the time range. To view intrusion event statistics: Access: Data or Admin

1.

Select Analysis & Reporting > Event Summary > Intrusion Event Statistics. The Intrusion Event Statistics page appears.

2. From the list of detection engines, select the detection engine whose statistics you want to view, or select all to view statistics for all the detection engines that are collecting intrusion events. 3. Click Select Detection Engines. The Intrusion Event Statistics page refreshes with data from the detection engines you selected. On the Defense Center, note that if you selected a single detection engine, the Event Overview section for that detection engine is repeated. TIP! Click Refresh to refresh the display with current data. You can also set a refresh interval so that the Event Summary page updates on a regular basis. See Setting Event Preferences on page 35 for more information. To view data from a custom time range, click the link next to Events in Time Range and follow the directions in Setting Event Time Constraints on page 1169.

Version 4.7


654


Chapter 18

4. See the following sections for more information about the statistics that appear on the Intrusion Event Statistics page: •

Host Statistics on page 655

•

Event Overview on page 655

•

Event Statistics on page 656

Host Statistics Requires: IPS or DC/MDC + IPS

The Host Statistics section of the Intrusion Event Statistics page provides information about the appliance itself. On the Defense Center, this section also provides information about any managed 3D Sensors with IPS.

This information includes the following: •

Time shows the current time on the appliance.

•

Uptime shows the number of days, hours, and minutes since the appliance itself was restarted. On the Defense Center, the uptime also shows the last time each managed sensor was rebooted, the number of users logged in, and the load average.

•

Disk Usage shows the percentage of the disk that is being used.

•

Memory Usage shows the percentage of system memory that is being used.

•

Load Average shows the average number of processes in the CPU queue for the past 1 minute, 5 minutes, and 15 minutes.

Event Overview Requires: IPS or DC/MDC + IPS

Version 4.7

The Event Overview section of the Intrusion Event Statistics page provides an overview of the information in the intrusion event database.


655


Chapter 18

These statistics include the following. •

Events shows the number of events in the intrusion event database.

•

Events in Time Range shows the currently selected time range as well as the number and percentage of events from the database that fall within the time range. TIP! You can change the time range by clicking the time range link. For more information, see Setting Event Time Constraints on page 1169.

•

First Event shows the event message for the first event in the event database.

•

Last Event shows the event message for the last event in the event database.

IMPORTANT! On the Defense Center, note that if you selected a single detection engine, the Event Overview section for that detection engine is repeated.

Event Statistics Requires: IPS or DC/MDC + IPS

The Event Statistics section of the Intrusion Event Statistics page provides more specific information about of the information in the intrusion event database.

This information includes details on:

Version 4.7

•

the top 10 event types

•

the top 10 source IP addressees


656

Working with Intrusion Events Viewing Intrusion Event Graphs

Chapter 18

•

the top 10 destination IP addresses

•

the top 10 destination ports

•

the detection engines and protocols with the greatest number of events

Viewing Intrusion Event Graphs Requires: IPS or DC/MDC + IPS

The Sourcefire 3D System provides graphs that show you intrusion event trends over time. You can generate intrusion event graphs over time periods ranging from the last hour to the last month, for the following: •

one or all detection engines

•

top 10 destination ports

•

top 10 source IP addresses

•

top 10 event messages

TIP! You can also view performance statistics such as the number of alerts per second, number of megabits per second, average number of bytes per packet, and the percent of packets dropped for your detection engines. See Viewing IPS Performance Statistics on page 1347 for more information. To generate an event graph: Access: Data or Admin

1.

Select Analysis & Reporting > Event Summary > Event Graphs. The Event Graphs page appears. Three selection boxes at the top of the page control which graph is generated. Note that the following graphic shows the Defense Center version of the page.

2. Under Select Device, select all to include all detection engines or select the specific detection engine you want to include in the graph. 3. Under Select Graph(s), select the type of graph you want to generate. 4. Under Select Time Range, select the time range for the graph.

Version 4.7


657

Working with Intrusion Events Viewing Intrusion Events

Chapter 18

5. Click Graph. The graph is generated.

Viewing Intrusion Events Requires: IPS or DC/MDC + IPS

When a detection engine on your IPS recognizes a packet that is potentially malicious, it generates an intrusion event and adds it to the intrusion event database. Each intrusion event includes the following information: •

the time of the event

•

the event priority

•

the impact flag

•

the name of the detection engine

•

the name of the protocol

•

the source IP address

•

the destination IP address

•

the source port number or, for ICMP traffic, the ICMP type

•

the destination port number or, for ICMP traffic, the ICMP code

•

the generator, which identifies the IPS feature that detected the exploit

•

the event message

The page you see when you access intrusion events differs depending on the workflow you use. You can use one of the predefined workflows, which include one or more drill-down pages, a table view of intrusion events, and a terminating packet view, or you can create your own workflow. For information on creating a custom workflow, see Creating Custom Workflows on page 1179. For information on manipulating and constraining intrusion event views so that you can narrow the focus of your investigation, see Using Drill-Down and Table View Pages on page 667 and Using the Packet View on page 673. You can also learn more by following the steps in Sample Event Analysis on page 698.

Version 4.7


658


Chapter 18

Note that you can also view intrusion events that you have marked as reviewed. Reviewed events are stored in the event database, but no longer appear in the default event pages. For more information, see Viewing Reviewed Intrusion Events on page 661. IMPORTANT!

Reviewed events are included in the event summary statistics.

On the Defense Center, also note that you can view workflows based on custom tables, which may include intrusion events. For more information, see Viewing a Workflow Based on a Custom Table on page 1143. To view intrusion events: Access: Data or Admin

h

Select Analysis & Reporting > IPS > Intrusion Events. •

If the first page of your preferred intrusion events workflow appears, continue with your event analysis. See Setting Event Preferences on page 35 for more information on how to specify a default workflow.

•

If the Select Workflow page appears, click the name of the workflow that you want to use and continue with your event analysis. See Selecting Workflows on page 1162 for more information.

See Understanding the Intrusion Events Table on page 659 to learn more about the events that appear in intrusion event views. See Understanding Workflow Pages for Intrusion Events on page 662 to learn more about how to narrow your view to the intrusion events that are important to your analysis.

Understanding the Intrusion Events Table Requires: IPS or DC/MDC + IPS

IPS examines the packets that traverse your network for malicious activity that could affect the availability, integrity, and confidentiality of a host and its data. When IPS identifies a possible intrusion, it generates an intrusion event, which is a record of the date, time, the type of exploit, and contextual information about the source of the attack and its target. For packet-based events, a copy of the packet or packets that triggered the event is also recorded. The fields in the intrusion events table are described in the Intrusion Event Fields table. Intrusion Event Fields

Version 4.7

Fields

Description

Time

The date and time of the event.

Priority

The event priority.


659


Chapter 18

Intrusion Event Fields (Continued) Fields

Description

Impact Flag

On a Defense Center managing a 3D Sensor with IPS, the impact flag in this field indicates the correlation between IPS data, RNA data, and vulnerability information. For more information, see Using Impact Flags to Evaluate Events on page 686. IMPORTANT! Intrusion events are qualified with impact flags only if you deploy sensors with IPS and RNA on the same network segment, and then view those events on a Defense Center that manages those sensors. IMPORTANT! Because there is no operating system information available for hosts added to the network map based on NetFlow data, the Defense Center cannot assign red (Vulnerable) impact flags for intrusion events involving those hosts, unless you use the host input feature to manually set the host operating system identity.

Version 4.7

Inline Result

On a 3D Sensor with IPS, as well as on a Defense Center managing a sensor with IPS, a black flag indicates the packet that triggered the event was dropped. If this field is blank, the packet was not dropped. For more information, see Using the Drop Rule State on page 798.

Detection Engine

The name of the detection engine that generated the event.

Protocol

The protocol used by the event.

Source IP

The IP address of the sending host.

Destination IP

The IP address of the receiving host.

Source User

The User ID for any known user logged in to the source host.

Destination User

The User ID for any known user logged in to the destination host.

SRC Port/ ICMP Type

The port number on the sending host. For ICMP traffic, the ICMP type appears instead.

DST Port/ ICMP Code

The port number for the host receiving the traffic. For ICMP traffic, the ICMP code appears instead.


660

Working with Intrusion Events Viewing Reviewed Intrusion Events

Chapter 18

Intrusion Event Fields (Continued) Fields

Description

Generator

The component that generated the event. See the Generator IDs table on page 851 for a list of intrusion event generator IDs.

Message

The explanatory text for the event. For rule-based intrusion events, the event message is pulled from the rule. For decoder- and preprocessor-based events, the event message is hardcoded.

Classification

The classification where the rule that generated the event belongs. See the Rule Classifications table on page 693 for list of rule classification names and numbers.

Count

The number of events that match the constraints described in the row. The count field appears on the table view of intrusion events only after you apply a constraint to the table.

Viewing Reviewed Intrusion Events Requires: IPS or DC/MDC + IPS

If you have accounted for an intrusion event and are confident that the event does not represent a threat to your network security (perhaps because you know that none of the host on your network are vulnerable to the detected exploit), you can mark the event as reviewed. Events that you mark as reviewed remain in the event database, but no longer appear in intrusion event views. If you want any of these reviewed events to appear in the event pages again, you can mark them as unreviewed. IMPORTANT! Although they do not appear on intrusion event-related workflow pages, reviewed events are included in the event summary statistics.

TIP! You can remove intrusion events from the database by selecting the events on any page in the workflow and clicking Delete. To view events that you have previously marked as reviewed: Access: Data or Admin

1.

Select Analysis & Reporting > IPS > Reviewed Events. The Select Workflow page appears.

2. Click the name of the workflow that you want to use. The workflow you selected appears. Continue with your event analysis. Note that the constraint indicates that you are viewing reviewed events.

Version 4.7


661

Working with Intrusion Events Understanding Workflow Pages for Intrusion Events

Chapter 18

To mark reviewed events as unreviewed: Access: Data or Admin

h

On an intrusion event page that displays reviewed events, you have two options: •

To remove individual intrusion events from the list of reviewed events, select the check boxes next to the events and click Unreview.

•

To remove all intrusion events from the list of reviewed events, click Unreview All.

A success message appears and the list of reviewed events is updated.

Understanding Workflow Pages for Intrusion Events Requires: IPS or DC/MDC + IPS

The preprocessors, protocol decoders, and intrusion rules that are enabled in the current intrusion policy generate intrusion events whenever the traffic that you monitor violates the policy. The Sourcefire 3D System provides a set of predefined workflows, populated with event data, that you can use to view and analyze intrusion events. Each of these workflows steps you through a series of pages to help you pinpoint the intrusion events that you want to evaluate. The predefined intrusion event workflows contain three different types of pages, or event views: •

one or more drill-down pages

•

the table view of intrusion events

•

a packet view

Drill-down pages generally include two or more columns in a table (and, for some drill-down views, more than one table) that allow you to view one specific type of

Version 4.7


662


Chapter 18

information. For example, the following graphics shows a drill-down page with the number of events generated for each destination port.

When you “drill-down” to find more information for one or more destination ports, you automatically select those events and the next page in the workflow appears. In this workflow, if you select the check box for the row with 21 (ftp)/tcp and click View, the next page in the workflow appears (in this case, a page showing the number of events with each event message).

In this way, drill-down tables help you reduce the number of events you are analyzing at one time. On the first page, you eliminated all but 4985 events from your analysis. On the second page, if you select the check box for the first row of

Version 4.7


663


Chapter 18

events (FTP MKD overflow attempt (1:1973)) and click View, then the next page in the workflow appears and you have narrowed your list to 362 events. The initial table view of intrusion events lists each intrusion event in its own row. The columns in the table list information such as the time, the source IP address and port, the destination IP address and port, the event priority, the event message, and more. Note that several of the columns were removed from the table view to simplify the following graphic.

When you select events on a table view, instead of selecting events and displaying the next page in the workflow, you add to what are called constraints. Constraints are limits that you impose on the types of events that you want to analyze. In the previous two drill-down pages, the events were constrained in two ways: by destination port (21/tcp) and by event message (FTP MKD overflow attempt (1:1973)). These constraints are carried forward to the table view. You can see the constraints by clicking the orange arrow at the top of the table.

Version 4.7


664


Chapter 18

If you click the close column icon ( ) in the Time column from the table view, you can remove time as one of the columns. To narrow the list of events in your analysis, you can click the link for a value in one of the rows in the table view. For example, to limit your analysis to the events generated from one of the source IP addresses (presumably, a potential attacker), click the IP address in the Source IP Address column. The following graphic shows the result, a single row that provides a count of the number of times the attacker (10.8.12.23) attempted to exploit the specific vulnerability (FTP MKD overflow attempt) against, in this case, a single destination IP address (10.8.11.166).

If you select one or more rows in a table view and then click View, the packet view appears. A packet view provides information about the packet that triggered the rule or the preprocessor that generated the event. Each section of the packet

Version 4.7


665


Chapter 18

view contains information about a specific layer in the packet. You can expand each of these sections to see more information.

IMPORTANT! Because portscan events are triggered by multiple packets, they use a special version of the packet view. See Understanding Portscan Events on page 939 for more information. If the predefined workflows do not meet your specific needs, you can create custom workflows that display only the information you are interested in. Custom intrusion event workflows can include drill-down pages, a table view of events, or both; IPS automatically includes a packet view as the last page. You can easily switch between the predefined workflows and your own custom workflows depending upon how you want to investigate events. TIP! Understanding and Using Workflows on page 1147 explains how to use workflows and the features common to all workflow pages. This chapter also explains how to create and use custom intrusion event workflows.

Version 4.7


666

Working with Intrusion Events Using Drill-Down and Table View Pages

Chapter 18


Using Drill-Down and Table View Pages on page 667, which explains how to use drill-down pages and the table view of events, which share many common features.

•

Using the Packet View on page 673, which explains how to use the features in the packet view.

•

Searching for Intrusion Events on page 689 explains how to search the event database for specific intrusion events.

Using Drill-Down and Table View Pages Requires: IPS or DC/MDC + IPS

The workflows that you can use to investigate intrusion events take advantage of three different types of pages: •

drill-down pages

•

the table view of intrusion events

•

the packet view

Each of these pages is described in Understanding Workflow Pages for Intrusion Events on page 662. The drill-down views and table view of events share some common features that you can use to narrow a list of events and then concentrate your analysis on a group of related events. The Intrusion Event Common Features table describes these features. Intrusion Event Common Features To...

You can...


find more information in Understanding the Intrusion Events Table on page 659.

view a host’s profile

click the host profile icon that appears next to the IP address of the host. This is available on the Defense Center only.




find more information in: • Sorting Workflow Pages and Changing Their Layout on page 1174 • the Constraining Events on Drill-Down Pages table on page 671 • the Constraining Events on the Table View of Events table on page 672

Version 4.7


667


Chapter 18

Intrusion Event Common Features (Continued) To...

You can...





mark events as reviewed to remove them from intrusion event pages, but not the event database.

use one of the following methods: • To review selected intrusion events, select the check boxes next to events you want to review, then click Review. • To review all the intrusion events in the current constrained view, click Review All. For more information, see Viewing Reviewed Intrusion Events on page 661.

delete events from the event database

use one of the following methods: • To delete selected intrusion events, select the check boxes next to events you want to delete, then click Delete. • To delete all the intrusion events in the current constrained view, click Delete All, then confirm you want to delete all the events. IMPORTANT! If you delete an intrusion events on the Defense Center, the event is only removed from the Defense Center database. If you have enabled event storage on a managed 3D Sensor and want to delete events from the sensor database, you must log into the sensor and delete them there.

add events to the clipboard so you can transfer them to an incident at a later time

use one of the following methods: • To copy several intrusion events on a workflow page to the clipboard, select the check boxes next to events you want to copy, then click Copy. • To copy all the intrusion events in the current constrained view to the clipboard, click Copy All. For more information, see Using the Clipboard on page 695.


find more information in Navigating between Workflows on page 1175. This is available on the Defense Center only.



Version 4.7


668


Chapter 18


You can...





mark events as reviewed to remove them from intrusion event pages, but not the event database.

use one of the following methods: • To review selected intrusion events, select the check boxes next to events you want to review, then click Review. • To review all the intrusion events in the current constrained view, click Review All. For more information, see Viewing Reviewed Intrusion Events on page 661.


use one of the following methods: • To delete selected intrusion events, select the check boxes next to events you want to delete, then click Delete. • To delete all the intrusion events in the current constrained view, click Delete All, then confirm you want to delete all the events. IMPORTANT! If you delete an intrusion events on the Defense Center, the event is only removed from the Defense Center database. If you have enabled event storage on a managed 3D Sensor and want to delete events from the sensor database, you must log into the sensor and delete them there.

add events to the clipboard so you can transfer them to an incident at a later time

use one of the following methods: • To copy several intrusion events on a workflow page to the clipboard, select the check boxes next to events you want to copy, then click Copy. • To copy all the intrusion events in the current constrained view to the clipboard, click Copy All. For more information, see Using the Clipboard on page 695.


find more information in Navigating between Workflows on page 1175. This is available on the Defense Center only.



Version 4.7


669


Chapter 18


You can...







The number of intrusion events that appear on the event views can be quite large depending on: •

the time range you select

•

the amount of traffic on your network

•

the intrusion policy you apply

To make it easier to analyze the events generated by IPS, you can constrain the event pages. The constraining processes are slightly different for drill-down views and the table view of intrusion events.

Version 4.7


670


Chapter 18

The Constraining Events on Drill-Down Pages table describes how to use the drilldown pages. Constraining Events on Drill-Down Pages To...

You can...

drill down to the next workflow page constraining on a specific value

click the value.

drill down to the next workflow page constraining on selected events

For example, on the Destination Port workflow, to constrain the events to those with a destination of port 80, click 80/tcp in the DST Port/ICMP Code column. The next page of the workflow, Events, appears and contains only port 80/tcp events. select the check boxes next to the events you want to view on the next workflow page, then click View. For example, on the Destination Port workflow, to constrain the events to those with destination ports 20/tcp and 21/tcp, select the check boxes next to the rows for those ports and click View. The next page of the workflow, Events, appears and contains only port 20/tcp and 21/tcp events. IMPORTANT! If you constrain on multiple rows and the table has more than one column (not including a Count column), you build what is called a compound constraint. Compound constraints ensure that you do not include more events in your constraint than you mean to. For example, if you use the Event and Destination workflow, each row that you select on the first drill-down page creates a compound constraint. If you pick event 1:100 with a destination IP address of 10.10.10.100 and you also pick event 1:200 with a destination IP address of 192.168.10.100, the compound constraint ensures that you do not also select events with 1:100 as the event type and 192.168.10.100 as the destination IP address or events with 1:200 as the event type and 10.10.10.100 as the destination IP address.

drill down to the next workflow page keeping the current constraints

Version 4.7

click View All.


671


Chapter 18

The Constraining Events on the Table View of Events table describes how to use the table view. Constraining Events on the Table View of Events To...

You can...

constrain the view to events with a single attribute

click the attribute.

remove a column from the table

click the X in the column heading. To re-add the column, click the column name in the Disabled Columns list.

For example, to constrain the view to events with a destination of port 80, click 80/tcp in the DST Port/ICMP Code column. Note that the column is removed from the table.

IMPORTANT! When you disable a column, it is disabled until you re-enable it, or you end your session. view the packets associated with one or more events

either: • click the down-arrow icon next to the event whose packets you want to view. • select one or more events whose packets you want to view, and, at the bottom of the page, click View. • at the bottom of the page, click View All to view the packets for all events that match the current constraints.

TIP! At any point in the process, you can save the constraints as a set of search criteria. For example, if you find that over the course of a few days your network is being probed by an attacker from a single IP address, you can save your constraints during your investigation and then use them again later. You cannot, however, save compound constraints as a set of search criteria. For more information, see Performing and Saving Searches on page 1125.

Version 4.7


672

Working with Intrusion Events Using the Packet View

Chapter 18

Using the Packet View Requires: IPS or DC/MDC + IPS

A packet view provides information about the packet that triggered the rule or the preprocessor that generated an intrusion event. IMPORTANT! The packet view on a Defense Center or a Master Defense Center does not contain the payload when the Prohibit Packet Transfer to the Defense Center option is enabled on the event detecting 3D Sensor.

The packet view indicates why a specific packet was captured by providing information about the intrusion event that the packet triggered, including the event’s time stamp, message, classification, priority, and, if the event was generated by a standard text rule, the rule that generated the event. The packet view also provides general information about the packet, such as its size. In addition, the packet view has a section that describes each layer in the packet: data link, network, and transport, as well as a section that describes the packet’s payload. The sections are collapsed by default; expand them to display detailed information. IMPORTANT! Because portscan events are triggered by multiple packets, they use a special version of the packet view. See Understanding Portscan Events on page 939 for more information.

Version 4.7


673


Chapter 18

The Packet View Actions table describes the actions you can take on the packet view. Packet View Actions To...

You can...

modify the date and time range in the packet views


learn more about the information displayed in the packet view

find more information in: • Viewing Event Information on page 676 • Viewing Packet Information on page 680 • Viewing Data Link Layer Information on page 681 • Viewing Network Layer Information on page 681 • Viewing Transport Layer Information on page 684 • Viewing Payload Information on page 686

mark events as reviewed to remove them from event views, but not the event database.

either: • click Review to review the event whose packet you are viewing • click Review All to review all the events whose packets you previously selected For more information, see Viewing Reviewed Intrusion Events on page 661. Note that reviewed events continue to be included in the event statistics on the Intrusion Event Statistics page.


either: • click Delete to delete the event whose packet you are viewing • click Delete All to delete all the events whose packets you previously selected

add events to the clipboard so you can transfer them to the incidents at a later time

Version 4.7

either: • click Copy to add the event whose packet you are viewing • click Copy All to add all the events whose packets you previously selected For more information on the clipboard, see Using the Clipboard on page 695.


674


Chapter 18

Packet View Actions (Continued) To...

You can...

research an intrusion

click View Documentation to learn more about the intrusion that triggered the rule, if the event was generated by a shared object rule or a standard text rule.

download a local copy of the packet (a packet capture file in libpcap format) that triggered the event

click Download pcap file in the Event Information section of the packet view.

edit the rule

click Edit. If you edit the rule, you actually create a new local rule. Make sure you enable the local rule, disable the original rule in the current intrusion policy, and reapply the policy to the appropriate detection engines. See Modifying Existing Rules on page 1011 for more information. IMPORTANT! If the event was generated by a shared object rule, you can edit the rule header (that is, the source and destination ports and IP addresses, the message, the rule classification, and so on), but not the rule content. To display the packet view:


h

On the table view of intrusion events, you have three options: •

click the down-arrow icon next to the event whose packets you want to view

•

select one or more events whose packets you want to view, and, at the bottom of the page, click View

•

at the bottom of the page, click View All to view the packets for all events that match the current constraints

The packet view appears. If you selected more than one event, you can page through the packets by using the page numbers at the bottom of the page.

Version 4.7


675


Chapter 18

Viewing Event Information Requires: IPS or DC/MDC + IPS

On the packet view, click Event Information to view the following information about the packet:

Event Information Name

Description

Timestamp

The time that the packet was captured.

Event

The event message. For rule-based events, this corresponds to the rule message. For other events, this is determined by the decoder or preprocessor. The ID for the event is appended to the message in the format GID:SID. GID is the generator ID of the rules engine, the decoder, or the preprocessor that generated the event. SID is the identifier for the rule, decoder message, or preprocessor message. For more information, refer to Reading Preprocessor Generator IDs on page 851.

Version 4.7

Classification

The event classification. For rule-based events, this corresponds to the rule classification. For other events, this is set to 0.

Priority

The event priority. For rule-based events, this corresponds to either the value of the priority keyword or the value for the classtype keyword. For other events, this is determined by the decoder or preprocessor.

Detection Engine

The name of the detection engine that generated the event. On the Defense Center, the name of the sensor on which it resides is also listed.


676


Chapter 18

Event Information (Continued) Name

Description

Rule

For standard text rule events, the rule that generated the event. You can: • click View Documentation to learn more about the intrusion that triggered the rule • click Edit to modify the rule (if your user account has Rules access) • click Rule Comment to add a text comment to the rule. This allows you to provide additional context and information about the rule and the exploit or policy violation it identifies. You can also add and view rule comments in the rule editor. Note that if the event is based on a shared object rule, the rule is not available. For non-rule-based events, this field is blank. IMPORTANT! If you edit a rule provided by Sourcefire (as opposed to a custom standard text rule), you actually create a new local rule. Make sure you enable the local rule and disable the original rule in the current intrusion policy. Note, however, that you cannot enable local rules in the default policies. For more information, see Modifying Existing Rules on page 1011.

Deactivate Rules

If this event is generated by a rule, you can disable the rule, if necessary. There are two possibilities depending on whether the intrusion policy that was applied to the detection engine that generated the event was created and applied locally. You may be able to: • deactivate this rule in the currently applied intrusion policy • deactivate this rule in all locally created intrusion policies For more information, see Setting Event Preferences on page 35. IMPORTANT! You cannot deactivate shared object rules from the packet view, nor can you deactivate rules in the default policies.

Version 4.7


677


Chapter 18

Event Information (Continued) Name

Description

Set Rule to Drop

If your 3D Sensor is deployed inline on your network and you want to drop packets that trigger this rule, click the option in this field. There are two possibilities depending on whether the intrusion policy that was applied to the detection engine that generated the event was created and applied locally. You may be able to: • set the rule to Drop in the current intrusion policy • set the rule to Drop in all locally created intrusion policies Note that if the rule is not currently enabled, you cannot set it to Drop.

Set Thresholding for This Rule

Use this option to create a threshold for the rule that triggered this event. There are two possibilities depending on whether the intrusion policy that was applied to the detection engine that generated the event was created and applied locally. You may be able to: • set thresholding options in the current policy • set thresholding options in all locally created policies The thresholding options are described in Setting Threshold Options within the Packet View on page 678.

Set Suppression for This Rule

Use this option to create a suppression for the rule that triggered this event. There are two possibilities depending on whether the intrusion policy that was applied to the detection engine that generated the event was created and applied locally. You may be able to: • set suppression options in the current policy • set suppression options in all locally created policies The suppression options are described in Setting Suppression Options within the Packet View on page 679.

Get Packet

Click Download pcap file to save a copy of the captured packet in libpcap format. This format is used by other programs such as Ethereal.

Setting Threshold Options within the Packet View Requires: IPS or DC/MDC + IPS

Version 4.7

You can control the number of events that are generated per rule over time by setting the threshold options from within the packet view of an intrusion event.


678


Chapter 18

To set the threshold options within the packet view: Access: Data + Rules or Admin

1.

Within the packet view of an intrusion event that was generated by an intrusion rule, click one of the two possible options: •

Set Thresholding Options in the current policy

•

Set Thresholding Options in all locally created policies

The thresholding options appear.

2. Select the type of threshold you want to set. •

Select limit to limit notification to the specified number of event instances per time period.

•

Select threshold to provide notification for each specified number of event instances per time period.

•

Select both to provide notification once per time period after a specified number of event instances.

3. Select the appropriate radio button to indicate whether you want the event instances tracked by source or destination IP address. 4. In the Count field, specify the number of event instances you want to use as your threshold. 5. In the Seconds field, specify the number of seconds that make up the time period for which event instances are tracked. 6. If you want to override any current thresholds for this rule in existing intrusion policies, select Override any existing settings for this rule. 7.

Click Save Thresholding Options. IPS adds your threshold and displays a message indicating success. If you chose not to override existing settings, a message appears informing you of any conflicts.

Setting Suppression Options within the Packet View Requires: IPS or DC/MDC + IPS

Version 4.7

You can use the suppression options to suppress intrusion events altogether based on the source or destination IP address.


679


Chapter 18

To suppress intrusion events within the packet view: Access: Data + Rules or Admin

1.

Within the packet view of an intrusion event that was generated by an intrusion rule, click one of the two possible options: •

Set Suppression Options in the current policy

•

Set Suppression Options in all locally created policies

The suppression options appear.

2. Select one of the following Track By options: •

To suppress events generated by packets originating from a specified source IP address, select Source IP.

•

To suppress events generated by packets going to a specified destination IP address, select Destination IP.

3. In the IP address or CIDR block field, enter the IP address or CIDR block you want to specify as the source or destination IP address. 4. If you want to override any current suppressions for this rule in existing intrusion policies, select Override any existing settings for this rule. 5. Click Save Suppression Options. The suppression options within your intrusion policies are modified according to your specifications. If you chose not to override existing settings, a message appears informing you of any conflicts.

Viewing Packet Information Requires: IPS or DC/MDC + IPS

On the packet view, click Packet Information to view the following information about the packet. Packet Information

Version 4.7

Name

Description

Length

The total length of the frame in bytes.

Timestamp

The time that the packet was captured.

Count

The index of this packet in the session.


680


Chapter 18

Viewing Data Link Layer Information Requires: IPS or DC/MDC + IPS

On the packet view, click the data link layer indicator (for example, Ethernet II) to view the data link layer information about the packet, which contains the 48-bit media access control (MAC) addresses for the source and destination hosts. It may also display other information about the packet, depending on the hardware protocol. The packet view reflects the protocol used at the data link layer. The Data Link Layer table describes the information you might see for an Ethernet II or IEEE 802.3 Ethernet packet in the packet view. Data Link Layer Name

Description

Source MAC

The MAC address for the source host.

Destination MAC

The MAC address for the destination host. IMPORTANT! Ethernet can also use multicast and broadcast addresses as the destination address.

Type

For Ethernet II packets, the type of packet that is encapsulated in the Ethernet frame; for example, IP or ARP datagrams. Note that this item only appears for Ethernet II packets.

Length

For IEEE 802.3 Ethernet packets, the total length of the packet, in bytes, not including the checksum. Note that this item only appears for IEEE 802.3 Ethernet packets.

Viewing Network Layer Information Requires: IPS or DC/MDC + IPS

On the packet view, click the network layer indicator (for example, IP or ARP) to view more detailed information about network layer information related to the packet. See the following sections for more information: •

IP Packet View on page 682

•

ARP Packet View on page 683

IMPORTANT! Note that these examples discuss IP or ARP packets; other protocols may also appear.

Version 4.7


681


Chapter 18

IP Packet View Requires: IPS or DC/MDC + IPS

The Network Layer - IP Protocol table describes the protocol-specific information for an IP packet. Network Layer - IP Protocol Name

Description

Source

The IP address for the source host. Click whois to perform a lookup on the IP address.

Destination

The IP address for the destination host. Click whois to perform a lookup on the IP address.

Protocol

The transport protocol that is encapsulated in the IP datagram; for example, ICMP, IGMP, TCP, or UDP.

Time to Live (ttl)

The remaining number of hops that the datagram can make between routers before the datagram expires.

ID

The value that uniquely identifies an IP datagram sent by the source host. This value is used to trace fragments of the same datagram.

Header Length

The number of bytes in the header, including any IP options. An IP header with no options is 20 bytes long.

Data Length

The length of the IP packet, in bytes, minus the IP header.

DS

The values for differentiated services that indicate how the sending host supports Explicit Congestion Notification (ECN): • 0x0 - does not support ECN-Capable Transport (ECT) • 0x1 and 0x2 - supports ECT • 0x3 - Congestion Experienced (CE)

Don’t Fragment

• 0 - the datagram can be fragmented • 1 - the datagram must not be fragmented

More Fragments

• 0 - there are no more fragments associated with the datagram • 1 - there are more fragments associated with the datagram

Version 4.7


682


Chapter 18

Network Layer - IP Protocol (Continued) Name

Description

Fragment Offset

The value for the fragment offset from the beginning of the datagram.

Checksum

The indicator for whether the IP checksum is valid. If the checksum is invalid, the datagram may have been corrupted during transit or may be being used in an intrusion evasion attempt.

ARP Packet View Requires: IPS or DC/MDC + IPS

The Network Layer - ARP Protocol table describes the protocol-specific information for an ARP packet. Network Layer - ARP Protocol

Version 4.7

Abbr.

Name

Description

Source Address

Source Address

The sender’s Ethernet address.

Destination Address

Destination Address

The target’s Ethernet address.

Source Protocol Address

Source Protocol Address

The sender’s IP address.

Destination Protocol Address

Destination Protocol Address

The target’s IP address.

Hardware Type

Hardware Type

The type of hardware address used. The value for Ethernet is 1.

ProtoType

Protocol Type

The type of protocol address being mapped. The value for an IP datagram is 0x0800.

Opcode

OpCode

The type of operation. An ARP request is 1; an ARP reply is 2.


683


Chapter 18

Viewing Transport Layer Information Requires: IPS or DC/MDC + IPS

On the packet view, click the transport layer indicator (for example, TCP, UDP, or ICMP) to view more information about the packet. The contents of the transport layer for each of the following protocols is described below: •

TCP Packet View

•

UDP Packet View

•

ICMP Packet View

TCP Packet View Requires: IPS or DC/MDC + IPS

The TCP Information table describes the protocol-specific information for a TCP packet. TCP Information Name

Description

Source Port

The number that identifies the originating application.

Destination Port

The number that identifies the receiving application.

Flags

The six bits that indicate the TCP segment’s transmission state: • U - the urgent pointer is valid • A - the acknowledgement number is valid • P - the receiver should push data • R - reset the connection • S - synchronize sequence numbers to start a new connection • F - the sender is finished sending data

Version 4.7

Sequence

The value for the first byte in the current TCP segment, keyed to initial sequence number in the TCP stream.

Header Length

The number of bytes in the header.

Ack

The TCP acknowledgement, which is keyed to the sequence number of the previously accepted data.

Window

The amount of unacknowledged data, in bytes, that the receiving host will accept.


684


Chapter 18

TCP Information (Continued) Name

Description

Urgent Pointer

The position in the TCP segment where the urgent data ends. Used in conjunction with the U flag.

Checksum

The indicator for whether the TCP checksum is valid. If the checksum is invalid, the datagram may have been corrupted during transit or may be being used in an in evasion attempt.

UDP Packet View Requires: IPS or DC/MDC + IPS

The UDP Information table describes the protocol-specific information for a UDP packet. UDP Information

Version 4.7

Name

Description

Source Port

The number that identifies the originating application.

Destination Port

The number that identifies the receiving application.

Checksum

The indicator for whether the UDP checksum is valid. If the checksum is invalid, the datagram may have been corrupted during transit.

Length

The combined length of the UDP header and data.


685

Working with Intrusion Events Using Impact Flags to Evaluate Events

Chapter 18

ICMP Packet View Requires: IPS or DC/MDC + IPS

The ICMP Information table describes the protocol-specific information for an ICMP packet. ICMP Information Name

Description

Type

The type of ICMP message: • 0 - echo reply • 3 - destination unreachable • 4 - source quench • 5 - redirect • 8 - echo request • 9 - router advertisement • 10 - router solicitation • 11 - time exceeded • 12 - parameter problem • 13 - timestamp request • 14 - timestamp reply • 15 - information request (obsolete) • 16 - information reply (obsolete) • 17 - address mask request • 18 - address mask reply

Code

The accompanying code for the ICMP message type. ICMP message types 3, 5, 11, and 12 have corresponding codes as described in RFC 792.

Viewing Payload Information Requires: IPS or DC/MDC + IPS

On the packet view, click Payload to view hexadecimal and ASCII versions of the packet payload. For multi-packet sessions, the payload is displayed for each packet in the session.

Using Impact Flags to Evaluate Events Requires: DC/MDC+ IPS + RNA

Version 4.7

When you install 3D Sensors with IPS and RNA on the same network segment and then view the intrusion events on a Defense Center that manages both sensors, you can gain more insight into the risk, or impact, that the events have on your network.


686


Chapter 18

To help you evaluate the impact an event has on your network, the Defense Center displays an impact flag in the table view of intrusion events. For each event, the Defense Center adds an impact flag whose color indicates the correlation between IPS data, RNA data, and vulnerability information. IMPORTANT! Because there is no operating system information available for hosts added to the network map based on NetFlow data, the Defense Center cannot assign red (Vulnerable) impact flags for intrusion events involving those hosts, unless you use the host input feature to manually set the hosts’ operating system identity.

TIP! Before Version 4.7, the Impact Flag field displayed flags for both dropped packets and correlation data, with the flag for dropped packets taking precedence. For example, if IPS dropped packets associated with an event that had a red impact flag, the Impact Flag field displayed a black flag. In Version 4.7 and later, a separate Inline Result field indicates whether packets were dropped and the Impact Flag field displays the correlation between IPS data, RNA data, and vulnerability information. The Impact Flags table describes the possible values for the impact flags. Impact Flags Icon

Impact

Description

gray

Unknown, indicating that neither the source nor the destination host is on a network that is monitored by RNA.

blue

Unknown Target, indicating that either the source or destination host is on a monitored network, but there is no entry for the host in RNA’s network map.

yellow

Currently Not Vulnerable, indicating that either the source or the destination host is in RNA’s network map and one of the following is true: • for port-oriented traffic (for example, TCP or UDP), the port is not open • for non-port-oriented traffic (for example, ICMP), the host does not use the protocol

Version 4.7


687


Chapter 18

Impact Flags (Continued) Icon

Impact

Description

orange

Potentially Vulnerable, indicating that either the source or the destination host is in RNA’s network map and one of the following is true: • for port-oriented traffic, the port is running a service • for non-port-oriented traffic, the host uses the protocol

red

Vulnerable, indicating that either the source or the destination host is in the RNA network map, and a vulnerability is mapped to the host.

To use the impact flag on the table view to evaluate events: Access: Data or Admin

1.

Select Analysis & Reporting > IPS > Intrusion Events. •

If the first page of your default intrusion events workflow appears, continue with your event analysis. See Setting Event Preferences on page 35 for more information on how to specify a default workflow.

•

If the Select Workflow page appears, click the name of the workflow that you want to use and continue with your event analysis. See Selecting Workflows on page 1162 for more information.

2. Constrain the event view to view only those events that you want to evaluate. For more information, see Using Drill-Down and Table View Pages on page 667. 3. At the top of the page, click Table View of Events. The table view of events appears. On the Defense Center, Impact Flag can have any of the values described in the Impact Flags table on page 687. The following graphic shows the Defense Center version of the page. Note that several of the columns were removed from the table view to simplify the graphic.

Version 4.7


688

Working with Intrusion Events Searching for Intrusion Events

Chapter 18

4. To sort the table by the impact flag value, click Impact Flag. The events are sorted by impact flag in descending vulnerability order: from red to gray. High-priority events that are marked with a red icon are the most likely to have an effect on your network. The sort order is red, orange, yellow, blue, and gray. TIP! To sort the table in ascending vulnerability order, click Impact Flag again.

Searching for Intrusion Events Requires: IPS or DC/MDC + IPS

You can search for specific intrusion events by using one of the predefined searches delivered with the Sourcefire 3D System or by creating your own search criteria. The predefined searches serve as examples and can provide quick access to important information about your network. Default searches include:

Version 4.7

•

Searches for events detected on ports reserved for particular services, including FTP, IRC, SSH, and others.

•

High Priority Events, which searches for events that not only have a high priority but also where the event’s impact flag is either orange (potentially vulnerable) or red (vulnerable). Requires: DC/MDC + IPS + RNA

•

Private Addresses Only, which searches for events where both the source IP and destination IP are on internal networks (10.0.0.0/8 or 192.168.1.0/24).

•

Public Addresses Only, which searches for events where neither the source IP nor destination IP is on an internal network (10.0.0.0/8 or 192.168.1.0/24).

•

Reserved Port TCP Scan and Reserved Port UDP Scan, which search for TCP and UDP attacks, respectively, on any of the reserved ports (0-1023), where the message contains the string SCAN or scan.

•

Reserved Ports - All, which searches for any attack on a reserved port (11023).

•

Unreserved Port TCP Scan and Unreserved Port UDP Scan which search for TCP and UDP attacks, respectively, on any of the unreserved ports (1025-65536), where the message contains the string SCAN or scan.

•

Unreserved Ports Only, which searches for any attack on any of the unreserved ports (1025-65536).


689


Chapter 18

You may want to modify specific fields within the default searches to customize them for your network environment, then save them to re-use later. The search criteria you can use are described in the Intrusion Event Search Criteria table. TIP! For information about the syntax for specifying IP addresses and ports in an intrusion event search, see Specifying IP Addresses in Searches on page 1130 and Specifying Ports in Searches on page 1132. Intrusion Event Search Criteria Field


Priority

Specify the priority of the events you want to view. The priority corresponds to either the value of the priority keyword or the value for the classtype keyword. For other intrusion events, the priority is determined by the decoder or preprocessor. Valid values are high, medium, and low.

Protocol

Type the name or number of the transport protocol used in the event, as listed in http://www.iana.org/assignments/protocol-numbers/.

Detection Engine

Specify the name of the detection engine or detection engine group that generated the intrusion events you want to view. For Defense Centers, you can also include the name of the sensor or sensor group. For Master Defense Centers you can also include the Defense Center or Defense Center group name. For more information, see Specifying Detection Engine/Appliance Names on page 1133.

Source IP

Specify the IP address of the source host involved in the intrusion events.

Destination IP

Specify the IP address of the destination host involved in the intrusion events.

Source User

Specify the User ID for a user logged in to the source host.

Destination User

Specify the User ID for a user logged in to the destination host.

Source/Destination IP

Specify the source or destination IP address of the host whose intrusion events you want to view.

Source/Destination User

Specify the User ID for a user logged in to the source or destination host

SRC Port/ICMP Type

Specify the source port associated with the intrusion event. TIP! For ICMP traffic, which does not target ports, you can use this field to search for events with specific ICMP types.

Version 4.7


690


Chapter 18

Intrusion Event Search Criteria (Continued) Field


DST Port/ICMP Code

Specify the destination port associated with the intrusion event. TIP! For ICMP traffic, which does not target ports, you can use this field to search for events with specific ICMP codes.

Message

Specify all or part of the event message for the events you want to view. You can also Snort ID (SID) in this field. For more information on SIDs, see Reading Preprocessor Generator IDs on page 851.

Impact Flag

For Defense Centers, specify the impact flag that the Defense Center has assigned to the intrusion event based on the correlation between IPS and RNA data. Valid values are red, orange, yellow, blue, and gray. TIP! You cannot specify a black flag. To specify events generated by drop rules, use Inline Result. For more information, see Using Impact Flags to Evaluate Events on page 686.

Inline Result

If your detection engine uses an inline interface set, specify dropped to view events where the packet was dropped as part of the event. For more information, see Using the Drop Rule State on page 798.

Reviewed

Specify whether you want to view reviewed (type reviewed) or unreviewed (type unreviewed) events. See Viewing Reviewed Intrusion Events on page 661 for more information.

Generator

Specify the component that generated the events you want to view, as listed in the Generator IDs table on page 851.

Classification

Enter the classification number, or all or part of the classification name or description for the rule that generated the events you want to view. You can also enter a comma-delimited list of numbers, names, or descriptions. Finally, if you add a custom classification, you can also search using all or part of its name or description. See the Rule Classifications table on page 693 for a list of classification numbers, names, and descriptions. For more information on searching, including how to load and delete saved searches, see the Searching for Events table on page 1124.

Version 4.7


691


Chapter 18

To search for intrusion events: Access: Data or Admin

1.

Select Analysis & Reporting > Searches > Intrusion Events. The Intrusion Events search page appears.

TIP! To search the database for a different kind of event, select it from the Table list. 2. Optionally, if you want to save the search, enter a name for the search in the Name field. If you do not enter a name, one is automatically created when you save the search. 3. Enter your search criteria in the appropriate fields, as described in the Intrusion Event Search Criteria table. If you enter multiple criteria, the search returns only the records that match all the criteria. 4. If you want to save the search so that other users can access it, clear the Save As Private check box. Otherwise, leave the check box selected to save the search as private. TIP! If you want to save a search as a restriction for restricted data users, you must save it as a private search.

Version 4.7


692


Chapter 18

5. You have the following options: Click Search to start the search.

•

If you specified a preferred intrusion events workflow, your search results appear, constrained by the current time range. Otherwise, you must select a workflow. For information on specifying a preferred workflow, see Setting Event Preferences on page 35. •


•


Specifying Rule Classifications in Event Searches Requires: IPS or DC/MDC + IPS

The Rule Classifications table lists the name and number for each rule classification. In an event search, you can use the classification number, or all or part of either the classification name or description.

Rule Classifications Number

Classification Name

Description

1

not-suspicious

Not Suspicious Traffic

2

unknown

Unknown Traffic

3

bad-unknown

Potentially Bad Traffic

4

attempted-recon

Attempted Information Leak

5

successful-recon-limited

Information Leak

6

successful-recon-largescale

Large Scale Information Leak

7

attempted-dos

Attempted Denial of Service

8

successful-dos

Denial of Service

9

attempted-user

Attempted User Privilege Gain

10

unsuccessful-user

Unsuccessful User Privilege Gain

11

successful-user

Successful User Privilege Gain

12

attempted-admin

Attempted Administrator Privilege Gain

Version 4.7


693


Chapter 18

Rule Classifications (Continued) Number

Classification Name

Description

13

successful-admin

Successful Administrator Privilege Gain

14

rpc-portmap-decode

Decode of an RPC Query

15

shellcode-detect

Executable Code was Detected

16

string-detect

A Suspicious String was Detected

17

suspicious-filename-detect

A Suspicious Filename was Detected

18

suspicious-login

An Attempted Login Using a Suspicious Username was Detected

19

system-call-detect

A System Call was Detected

20

tcp-connection

A TCP Connection was Detected

21

trojan-activity

A Network Trojan was Detected

22

unusual-client-port-connection

A Client was Using an Unusual Port

23

network-scan

Detection of a Network Scan

24

denial-of-service

Detection of a Denial of Service Attack

25

non-standard-protocol

Detection of a Non-Standard Protocol or Event

26

protocol-command-decode

Generic Protocol Command Decode

27

web-application-activity

Access to a Potentially Vulnerable Web Application

28

web-application-attack

Web Application Attack

29

misc-activity

Misc Activity

30

misc-attack

Misc Attack

31

icmp-event

Generic ICMP Event

32

porn-filters

Pornography was Detected

33

policy-violation

Potential Corporate Privacy Violation

34

default-login-attempt

Attempt to Login By a Default Username and Password

Version 4.7


694

Working with Intrusion Events Locating Whois Information for a Host

Chapter 18

Locating Whois Information for a Host Requires: Any

If your appliance is connected to the Internet, you can use the Whois feature to look up ARIN information about an external host. To use the Whois feature:

Access: Any

1.

Select Operations > Tools > Whois. The Whois page appears.

2. Type the IP address you want to look up and click Search. The results of the lookup appear.

Using the Clipboard Requires: IPS or DC/MDC + IPS

The clipboard is a holding area where you can copy intrusion events from any of the intrusion event views. For information on how to add events to the clipboard, see Using Drill-Down and Table View Pages on page 667 and Using the Packet View on page 673. The contents of the clipboard are sorted by the date and time that the events were generated. Once you add intrusion events to the clipboard, you can delete them from the clipboard as well as generate reports on the contents of clipboard.

Version 4.7


695

Working with Intrusion Events Using the Clipboard

Chapter 18

You can also add intrusion events from the clipboard to incidents, which are compilations of events that you suspect are involved in a possible violation of your security policies. For more information about adding events from the clipboard to an incident, see Creating an Incident on page 712. See the following sections for more information: •

Generating Clipboard Reports on page 696

•

Deleting Events from the Clipboard on page 698

Generating Clipboard Reports Requires: IPS or DC/MDC + IPS

You can generate a report for the events on the clipboard just as you would from any of the event views. To generate a report on intrusion events from the clipboard:


1.

Add one or more events to the clipboard. •

For information on how to add events to the clipboard from a drill-down page or table view of events, see Using Drill-Down and Table View Pages on page 667.

•

For information on how to add events to the clipboard from the packet view, see Using the Packet View on page 673.

2. Select Analysis & Reporting > IPS > Clipboard. The clipboard appears.

Version 4.7


696

Working with Intrusion Events Using the Clipboard

Chapter 18


To include specific events from a page on the clipboard, navigate to that page, select the check box next to the events, and click Generate Report.

•

To include all the events from the clipboard, click Generate Report All.

In either case, the Report Designer page appears.

4. Specify how you want your report to look, then click Generate Report. TIP! For more information about using the Report Designer, see Building and Generating Reports on page 1103. 5. To view the report, click Reports on the toolbar. The Reporting page appears. 6. Click View next to the report you generated. The clipboard report appears in your browser window.

Version 4.7


697

Working with Intrusion Events Sample Event Analysis

Chapter 18

Deleting Events from the Clipboard Requires: IPS or DC/MDC + IPS

If you have intrusion events on the clipboard that you do not want to add to an incident, you can delete the events. IMPORTANT! Deleting an event from the clipboard does not delete the event from the event database. However, deleting an event from the event database does delete the event from the clipboard. To delete events from the clipboard:


1.

Select Analysis & Reporting > IPS > Clipboard. The clipboard appears.


To delete specific intrusion events from a page on the clipboard, navigate to the page, select the check box next to the events, and click Delete. The events are deleted.

•

To delete all the intrusion events from the clipboard, click Delete All. All the events are deleted from the clipboard. Note that if you select the Confirm 'All' Actions option in the Event Preferences, you are first prompted to confirm that you want to delete all the events.

Sample Event Analysis Requires: IPS or DC/MDC + IPS

IPS generates an event when it captures one or more packets that violate the intrusion policy assigned to one of its detection engines. Analysts review events and evaluate how they affect the availability, confidentiality, and integrity of the network and the hosts on it. Consider a scenario in which you arrive in the morning and are charged with analyzing the events generated during the previous 24 hours. You must determine whether they affect your network’s security. You can, of course, create your own process for analyzing events, but the following sections provide one methodology for determining whether an event is important in the context of your network:

Version 4.7

•

Logging in and Setting the Time Frame on page 699

•

Searching for High Priority Events on page 700

•

Evaluating Events on page 703

•

Searching for Related Events on page 705


698


Chapter 18

Logging in and Setting the Time Frame Requires: IPS or DC/MDC + IPS

Begin by logging in, setting a default workflow, and reviewing the activity from the previous 24 hours. To log in and set the time frame:

Access: Any

1.

Log in with a user account that has at least Data access.

2. On the toolbar, click Preferences. The User Preferences page appears. 3. Click Event View Settings. The Event Preferences page appears. The following graphic shows the Defense Center version of the page.

4. Because you will be examining event-related information, select Event-Specific from the Default IS Events Workflow drop-down list and click Save. 5. Check the current event activity by viewing the Event Summary. You can do this by selecting Analysis & Reporting > Event Summary > Intrusion Event Statistics. The Intrusion Event Statistics page appears with event statistics for the past hour.

Version 4.7


699


Chapter 18

6. Review the information in the table under Event (Summary) Overview.

The value for Events shows the number of events in the database. The next row shows the number of events that occurred during the past hour, which is the default time range. To change the time range to the previous 24 hours, click the current time range.

7.

The Date/Time window appears. 8. Click Last 24 Hours and then click Apply Changes. The Event (Summary) Statistics are updated to show the activity in the previous 24 hours. 9. Continue with the next section, Searching for High Priority Events.

Searching for High Priority Events Requires: IPS or DC/MDC + IPS

After setting the time range you want to analyze, filter the events so that you can concentrate on high priority events. Event priority is controlled by either of two values: •

the value that the rule writer set for the priority keyword in rules See Defining the Event Priority on page 958 for more information.

•

the priority of the rule’s classification type See the Rule Classifications table on page 693 for more information.

Version 4.7


700


Chapter 18

To search for high priority events: Access: Data or Admin

Version 4.7

1.

Select Analysis & Reporting > Searches > Intrusion Events. The Event Search page appears.


701


Chapter 18

2. Type high in the Priority field and click Search. The Events drill-down page appears. The Search Constraints indicate that you are viewing only high priority events.

Note that the events are sorted by count. The events with the greatest number of occurrences are listed first.

For this example, the first event is FTP MKD overflow attempt (1:1973). The event name indicates that this event is generated by a standard text rule that looks for a specific FTP exploit (GID of 1 and SID of 1973). Later in the analysis, you can review the rule that generated the event, but for now it is enough to know that this is an FTP exploit. TIP! If your user account also has Rules access, you can search for the rule by SID and review the rule. 3. Continue with the next section, Evaluating Events.

Version 4.7


702


Chapter 18

Evaluating Events Requires: IPS or DC/MDC + IPS

After constraining the list of events to high priority events in your selected time range, you must evaluate those events to determine whether the exploits were directed at vulnerable hosts. To evaluate events:


1.

Click the first event, FTP MKD overflow attempt (1:1973). The Source/Destination IP drill-down page appears. In this example, four different hosts on your network appear in the Destination IP list.

2. Click Table View of Events at the top of the page to view all of the events for these four IPs. The table view for these events appears. Note that the following illustration is truncated for convenience; the table view includes additional events.

Every event in this table has the same event message and priority.

Also, because the exploit uses TCP packets and is directed toward port 21, every event has the same protocol and destination port.

Version 4.7


703


Chapter 18

3. Because it is sometimes more fruitful to investigate possible intrusions by examining the potential targets, click Destination IP to re-sort the table.

In this scenario, assume that you can access a list of IP addresses on your network and can determine that the first four destination IPs (those beginning with 10.2) are assigned to servers in the demilitarized zone (DMZ) on your network. 4. Select the check box next to each of the IPs in the DMZ and then click View to view information about the packets that generated the event. The packet view appears with the information for the first event. 5. For standard text rules, you can expand the Event Information to learn more about the rule that generated the event.

The rule contains references to the Common Vulnerabilities and Exposures database (CAN-1999-0911), the Nessus database (12108), and the Bugtraq database (several IDs).

Version 4.7


704


Chapter 18

6. All four of the hosts in the DMZ were attacked with same exploit. Click View Documentation to see more information about the exploit that triggers the rule. You can also review the information at the two referenced databases to help you determine whether the targeted hosts are vulnerable to the exploit. Also, if your Sourcefire 3D System deployment includes 3D Sensors with RNA monitoring the same network segment, and you are viewing events on your Defense Center’s web interface, you can click the host profile link for the target host to determine if the host is vulnerable. If the hosts are vulnerable, use the incident tracking features to record the steps you take to report the attack and any follow-up you conduct. See Handling Incidents on page 707 for more information. TIP! The packet view includes other important information about the attack. In this case, the attack is fairly straightforward with a string match in the packet payload after the TCP three-way handshake is established. Other events may require that you review other information in the packet view. 7.

In this scenario, assume that the other events were generated for hosts that are not in the DMZ and, according to your internal security policies, are barred from offering FTP services. In these cases, you can use one of the commonly available tools to search for open ports on these hosts. It may be that the owner of the host does not know that the host can be compromised. On the Defense Center, if you have RNA deployed on the same network segment, you can check the host profile to determine if the hosts have open ports whether attackers are connecting to them.

8. Continue with the next section, Searching for Related Events.

Searching for Related Events Requires: IPS or DC/MDC + IPS

Key pieces of information from these events can lead you to your next steps. First, as you can see from the first event, the source IP is an internal address (10.2.12.23). Begin by searching for other events that include this IP address. Also, because the target host (10.2.11.160) may have been compromised, you should search for other events that include this destination IP. To search for related events:


Version 4.7

1.

Select Analysis & Reporting > Searches > Intrusion Events. The Event Search page appears.


705


Chapter 18

2. Type the attacker’s IP address in the Source IP field, then click Search. The Events Drill-Down page appears. A quick glance at the event total shows that 588 different types of events were generated with this source IP.

A disgruntled employee may be attempting to gain access to restricted information, or this host may have been compromised by a Trojan horse program without the owner’s knowledge. In either case, these events require further investigation. 3. Copy the event information to the clipboard by clicking Copy All. 4. You can create a second incident and add these events to it as you move forward in your investigation. See Handling Incidents on page 707 for more information. 5. You should also search for events with 10.10.10.2 as the destination IP. On the Event Search page, type 10.10.10.2 in the Destination IP field and click Search. In this case, the search returns no results. 6. For completeness, you should also search for other events involving the target host, 10.1.2.5, to make sure that it hasn’t been compromised by other exploits. The search with the destination IP set to 10.1.2.5 returns the following results, suggesting that you should add these events to an incident for further investigation.

7.

Version 4.7

After you investigate these events, return to your search for high priority events and repeat your evaluation process for the next event in the list.


706

Chapter 18

Handling Incidents

Incident handling refers to the response an organization takes when a violation of its security policies is suspected. The Sourcefire 3D System includes features to support you as you collect and process information that is relevant to your investigation of an incident. You can use these features to gather intrusion events and packet data that may be related to the incident. You can also use the incident as a repository for notes about any activity that you take outside of Sourcefire 3D System to mitigate the effects of the attack. For example, if your security policies require that you quarantine compromised hosts from your network, you can note that in the incident. The Sourcefire 3D System also supports an incident life cycle, allowing you to change an incident’s status as you progress through your response to an attack. When you close an incident, you can note any changes you have made to your security policies as a result of any lessons learned. See the following sections for more information about handling incidents in the Sourcefire 3D System:

Version 4.7

•

Incident Handling Basics on page 708

•

Creating an Incident on page 712

•

Editing an Incident on page 714

•

Generating Incident Reports on page 715

•

Creating Custom Incident Types on page 716


707

Handling Incidents Incident Handling Basics

Chapter 19

Incident Handling Basics Requires: IPS or DC/MDC + IPS

Each organization is likely to have its own process for discovering, defining, and responding to violations of its security policies. The sections that follow describe some of the basics of incident handling and how you can incorporate the Sourcefire 3D System in your incident response plan. •

Definition of an Incident on page 708

•

Common Incident Handling Processes on page 708

•

Incident Types in the Sourcefire 3D System on page 711

Definition of an Incident Requires: IPS or DC/MDC + IPS

Generally, an incident is defined as one or more intrusion events that you suspect are involved in a possible violation of your security policies. Sourcefire also uses the term to describe the feature you use in Sourcefire 3D System to track your response to an incident. As explained in Working with Intrusion Events on page 651, some intrusion events are more important than others to the availability, confidentiality, and integrity of your network assets. For example, the port scan detection features provided by the Sourcefire 3D System can keep you informed of port scanning activity on your network. Your security policy, however, may not specifically prohibit port scanning or see it as a high priority threat, so rather than take any direct action, you may instead want to keep logs of any port scanning for later forensic study. On the other hand, if IPS generates events that indicate hosts within your network have been compromised and are participating in distributed denial-ofservice (DDoS) attacks, then this activity is likely a clear violation of your security policy, and you should create an incident in the Sourcefire 3D System to help you track your investigation of these events.

Common Incident Handling Processes Requires: IPS or DC/MDC + IPS

Each organization is likely to define its own process for handling security incidents. Most methodologies include some or all of the following phases: •

Preparation

•

Detection and Notification

•

Investigation and Qualification

•

Communication

•

Containment and Recovery

•

Lessons Learned

Each of these phases is described in the sections that follow. The descriptions also explain how Sourcefire 3D System fits into each phase.

Version 4.7


708


Chapter 19

Preparation You can prepare for incidents in two ways: •

by having clear and comprehensive security policies in place, as well as the hardware and software resources to enforce them

•

by having a clearly defined plan to respond to incidents and a properly trained team that can implement the plan

A key part of incident handling is understanding which parts of your network are at the greatest risk. By deploying Sourcefire 3D System components on those network segments, you can increase your awareness of when and how incidents occur. Also, by taking the time to carefully tune the intrusion policy on each detection engine, you can ensure that the events that are generated are of the highest quality.

Detection and Notification You cannot respond to an incident unless you can detect it. Your incident handling process should note the kinds of security-related events that you can detect and the mechanisms, both software and hardware, that you use to detect them. You should also note where you can detect violations of your security policies. If your network includes segments that are not actively or passively monitored, then you need to note that as well. The 3D Sensors with IPS that you deploy on your network are responsible for analyzing the traffic on the segments where they are installed, for detecting intrusions, and for generating events that describe them. Keep in mind that the intrusion policy you apply to each of the IPS detection engines governs what kinds of activity they detect and how it is prioritized. You can also set notification options for certain types of intrusion events so that the incident team does not need to sift through hundreds of events. You can specify that you are notified automatically when certain high priority, high severity events are detected.

Investigation and Qualification Your incident handling process should specify how, after a security incident is detected, an investigation is conducted. In some organizations, junior members of the team triage all the incidents and handle the less severe or lower priority cases themselves. High severity and high priority incidents are handled by more senior members of the team. You should carefully outline the escalation process so that each team member understands the criteria for raising an incident’s importance. Part of the escalation process is tied to understanding how a detected event can affect the security of your network assets. For example, an attack against hosts running Microsoft SQL Server is not a high priority for organizations that use a different database server. Similarly, the attack is less important to you if you use SQL Server on your network, but you are confident that all the servers are patched and are not vulnerable to the attack. However, if someone has recently

Version 4.7


709


Chapter 19

installed a copy of the vulnerable version of the software (perhaps for testing purposes), you may have a greater problem than a cursory investigation would suggest. The Sourcefire 3D System is particularly well suited to supporting the investigation and qualification process. With standalone 3D Sensors with IPS, you can create your own event classifications, and then apply them in a way that best describes the vulnerabilities on your network. When traffic on your network triggers an event, it is automatically prioritized for you. If you also deploy a 3D Sensor with RNA on the same network segment and use a Defense Center to correlate the information from both sensors, then events are automatically qualified for you with special indicators showing which attacks are directed against hosts that are known to be vulnerable. The incident tracking feature in the Sourcefire 3D System also includes a status indicator that you can change to show which incidents have been escalated.

Communication All incident handling processes should specify how an incident is communicated between the incident handling team and both internal and external audiences. For example, you should consider what kinds of incidents require management intervention and at what level. Also, your process should outline how and when you communicate with outside organizations. Will some incidents require that you notify law enforcement agencies? If your hosts are participating in a distributed denial of service (DDoS) against a remote site, will you inform them? Do you want to share information with organizations such as the CERT Coordination Center (CERT/CC) or FIRST? Sourcefire 3D System has features that you can use to gather intrusion data in standard formats such as HTML, PDF, and CSV (comma-separated values) so that you can easily share intrusion data with others. For example, CERT/CC collects standard information about security incidents on its web site. CERT/CC looks for the kinds of information that you can easily extract from Sourcefire 3D System, such as: •

•

•

Version 4.7

information about the affected machines, including: •

the host name and IP

•

the time zone

•

the purpose or function of the host

information about the sources of the attack, including: •

the host name and IP

•

the time zone

•

whether you had any contact with an attacker

•

the estimated cost of handling the incident

a description of the incident, including:


710


Chapter 19

•

dates

•

methods of intrusion

•

the intruder tools involved

•

the software versions and patch levels

•

any intruder tool output

•

the details of vulnerabilities exploited

•

the source of the attack

•

any other relevant information

You can also use the comment section of an incident to record when you communicate issues and with whom.

Containment and Recovery Your incident handling process should clearly indicate what steps are taken when a host or other network component is compromised. The range of containment and recovery options stretches from applying patches to vulnerable hosts to shutting down the target and removing it from the network. You should also consider the importance, depending upon the nature and severity of the attack, of preserving evidence in case you pursue criminal charges. You can use the incident feature of Sourcefire 3D System to maintain a record of the actions you take during the containment and recovery phase of the incident.

Lessons Learned Each security incident, whether or not it is a successful attack, is an opportunity to review your security policies. Do you need to update your firewall rules? Do you need a more structured approach to patch management? Are unauthorized wireless access points a new security issue? Each lesson learned should feed back into your security policies and help you prepare better for the next incident.

Incident Types in the Sourcefire 3D System Requires: IPS or DC/MDC + IPS

Version 4.7

You can assign an incident type to each incident you create. The following types are supported by default in the Sourcefire 3D System: •

Intrusion

•

Denial of Service

•

Unauthorized Root Access

•

Web Site Defacement

•

Compromise of System Integrity

•

Hoax

•

Theft


711

Handling Incidents Creating an Incident

Chapter 19

•

Damage

•

Unknown

You can also create your own incident types as explained in Creating Custom Incident Types on page 716.

Creating an Incident Requires: IPS or DC/MDC + IPS

This section explains how you create an incident.


1.

Version 4.7

To create an incident: Select Analysis & Reporting > IPS > Incidents. The Incident page appears


712

Handling Incidents Creating an Incident

Chapter 19

2. Click Create Incident. The Create New Incident page appears.

If you previously copied intrusion events to the clipboard, they are displayed at the bottom of the page. See Using the Clipboard on page 695 for information about using the clipboard.

3. From the Type drop-down menu, select the option that best describes the incident. The following incident types are available:

Version 4.7

•

Intrusion

•

Denial of Service

•


•

Web Site Defacement

•


•

Hoax

•

Theft


713

Handling Incidents Editing an Incident

Chapter 19

•

Damage

•

Unknown

4. In the Time Spent field, enter the amount of time you spent on the incident in the #d #h #m #s format, where # represents the number of days, hours, minutes, or seconds. 5. In the Summary text box, type a short description (up to 255 alphanumeric characters spaces, and symbols) of the incident. 6. In the Add Comment text box, type a more complete description (up to 8191 alphanumeric characters, spaces and symbols) for the incident. Do you want to add events to the incident?

7.

•

If yes, select the events on the clipboard and click Add to Incident. You can also add all the events from the clipboard by clicking Add All to Incident.

•

If no, click Save.

In either case, the incident is saved with the information you entered. IMPORTANT! If you want to add individual events from more than one page on the clipboard, you must add the events from one page, then add the events from the other pages separately.

Editing an Incident Requires: IPS or DC/MDC + IPS

You can update an incident as you collect more information, including any of the following aspects: •

change the status

•

change the type

•

add events from the clipboard

•

delete events

You can also add or delete events from the incident as your investigation progresses. To edit an incident: Access: Data or Admin

1.

Select Analysis & Reporting > IPS > Incidents. The Incident page appears.

2. Click Edit next to the incident you want to edit.

Version 4.7


714

Handling Incidents Generating Incident Reports

Chapter 19

3. You can edit any of the following aspects of the incident: •

change the status

•

change the type

•

add events from the clipboard

•

delete events

4. In the Time Spent field, enter the amount of additional time you spent on the incident. 5. In the Add Comment text box, indicate your changes to the incident (up to 8191 alphanumeric characters, spaces and symbols) for the incident. 6. Optionally, you can add or delete events from the incident. •

To add events from the clipboard, select the events on the clipboard and click Add to Incident.

•

To add all the events from the clipboard, click Add All to Incident.

•

To delete specific events from the incident, select the events and click Delete.

•

To delete all events from the incident, click Delete All.

•

To update the incident without adding or deleting events, click Save.

Your changes to the incident are saved.

Generating Incident Reports Requires: IPS or DC/MDC + IPS

You can use the Sourcefire 3D System to generate incident reports that can include the incident summary, incident status, and any comments along with information from the events you add to the incident. You can also specify whether you want to include event summary information in the report. To generate an incident report:


1.


2. Click Edit next to the incident you want to include in your report.

Version 4.7


715

Handling Incidents Creating Custom Incident Types

Chapter 19


To include all the events from the incident in the report, click Generate Report All.

•

To include specific events from the incident in the report, select the check boxes next to the events you want and click Generate Report.

In either case, the Report Designer page appears, including the options for incident reports.

4. Type a name for the report. You can use alphanumeric characters, periods, and spaces. 5. In the Incident Report Sections, select the check boxes for the portions of the incident that you want to include in the report: status, summary, and comments. 6. If you want to include event information in the report, select the workflow you want to use and then, in Report Sections, specify whether you want to include event summary information. Select the check boxes next to the workflow pages you want to include in the report.

7.

8. Select the check boxes next to the output formats you want to use for the report: PDF, HTML, and CSV. IMPORTANT! CSV-based incident reports include only event information. They do not include the status, summary, or comments from the incident. 9. Click Generate Report and confirm that you want to update the report profile. The report is generated.

Creating Custom Incident Types Requires: IPS or DC/MDC + IPS

Version 4.7

The Sourcefire 3D System is delivered with the following incident types that you can use to classify your incidents: •


•

Damage


716

Handling Incidents Creating Custom Incident Types

•

Denial of Service

•

Hoax

•

Intrusion

•

Theft

•


•

Unknown

•

Web Site Defacement

Chapter 19

If these incident types do not meet your needs, you can add your own. Note that you cannot delete any custom incident types. To create a new incident type: Access: Data or Admin

1.


2. Click Create Incident. The Create New Incident page appears. 3. In the Type area, click Types. The Incident Management page appears. The default incident types are listed at the bottom of the page.

4. In the Incident Type Name field, type a name for the new incident type. Use alphanumeric characters and spaces. 5. Click Add. The new incident type is added. 6. Click Done to close the pop-up window and return to the Incident page. You can use the new incident type the next time you create or edit an incident.

Version 4.7


717

Chapter 19

Configuring Intrusion Event Responses

While the Sourcefire 3D System provides various views of intrusion events within the web interface, some enterprises prefer to define external intrusion event notification to facilitate constant monitoring of critical systems. If you want to immediately notify a specific person of critical events, you can set up email alerts to do so. You can also enable logging to syslog facilities or send event data to an SNMP trap server. Additionally, you can specify Check Point™ OPSEC™ firewall responses for intrusion events generated when a standard text rule triggers. Within each intrusion policy, you can specify intrusion event notification limits, set up intrusion event notification to external logging facilities, and configure external responses to intrusion events. TIP! Some analysts prefer not to receive multiple alerts for the same intrusion event, but want to control how often they are notified of a given intrusion event occurrence. See Limiting Intrusion Event Notification Per Policy on page 766 for more information.

Version 4.7

•

Understanding Syslog Alerting on page 719 describes the options you can configure to send event data to an external syslog and provides the procedure for specifying the syslog alerting options.

•

Understanding SNMP Alerting on page 722 describes the options you can configure to send event data to specified SNMP trap servers and provides the procedure for specifying the SNMP alerting options.


718

Configuring Intrusion Event Responses Understanding Syslog Alerting

Chapter 20

•

Understanding Email Alerting on page 726 describes the options you can configure to send event data from specified rules and rule groups to specified email addresses and provides the procedure for setting the email alerting options.

•

Responding to Events with a Check Point Firewall on page 730 explains how to configure Check Point OPSEC firewalls to respond to triggered rules with defined responses.

Understanding Syslog Alerting Requires: IPS or DC/MDC + IPS

The system log, or syslog, is the standard logging mechanism for network event logging. You can send syslog alerts, which are intrusion event notifications, to the syslog on an appliance. The syslog allows you to categorize information in the syslog by priority and facility. The priority reflects the severity of the alert and the facility indicates the subsystem that generated the alert. Facilities and priorities are not displayed in the actual message that appears in syslog, but are instead used to tell the system that receives the syslog message how to categorize it. Syslog alerts contain the following information: •

date and time of alert generation

•

event message

•

event data

•

generator ID of the triggering event

•

Snort ID of the triggering event

•

revision

In an intrusion policy, you can turn on syslog alerting and specify the syslog priority and facility associated with intrusion event notifications in the syslog. When you apply the policy to a detection engine, the detection engine then sends syslog alerts for the intrusion events it detects to the syslog facility on the local host or on the logging host specified in the policy. The host receiving the alerts uses the facility and priority information you set when configuring syslog alerting to categorize the alerts. The Available Syslog Facilities table lists the facilities you can select when configuring syslog alerting. Be sure to configure a facility that makes sense based on the configuration of the remote syslog server you use. The syslog.conf file located on the remote system (if you are logging syslog messages to a UNIX- or

Version 4.7


719


Chapter 20

Linux-based system) indicates which facilities are saved to which log files on the server. Available Syslog Facilities

Version 4.7

Facility

Description

KERN

A message generated by the kernel. On many systems, these messages are printed to the console when they appear.

USER

A message generated by a user-level process.

MAIL

A message generated by a mail system.

DAEMON

A message generated by a system daemon.

AUTH

A message associated with security and authorization.

SYSLOG

A message generated by the syslog daemon.

LPR

A message generated by the printing subsystem.

NEWS

A message generated by the network news subsystem.

UUCP

A message generated by the UUCP subsystem.

CRON

A message generated by the clock daemon.

AUTHPRIV

A restricted access message associated with security and authorization. On many systems, these messages are forwarded to a secure file.

FTP

A message generated by the FTP daemon.

LOCAL0LOCAL7

A message generated by an internal process.


720


Chapter 20

Select one of the following standard syslog priority levels to display on all notifications generated by this alert: Syslog Priority Levels Level

Description

EMERG

A panic condition broadcast to all users

ALERT

A condition that should be corrected immediately

CRIT

A critical condition

ERR

An error condition

WARN

Warning messages

NOTICE

Conditions that are not error conditions, but require attention

INFO

Informational messages

DEBUG

Messages that contain debug information

TIP! For more detailed information about how syslog works and how to configure it, refer to the documentation that accompanies your system. If you are logging to a UNIX- or Linux-based system’s syslog, the syslog.conf man file (type man syslog.conf at the command line) and syslog man file (type man syslog at the command line) provide information about how syslog works and how to configure it.

Configuring Syslog Alerting Requires: IPS or DC/MDC + IPS

You can configure syslog alerting in an intrusion policy. After you apply the policy to a detection engine, the detection engine notifies you of any intrusion events it detects via the syslog. For more information on syslog alerting, see Understanding Syslog Alerting on page 719. To configure syslog alerting options:


1.

Select Policy & Response > IPS > Detection & Prevention. The Detection & Prevention page appears.

2. Click Edit next to the intrusion policy where you want to configure alerting options. The Edit Policy page appears.

Version 4.7


721

Configuring Intrusion Event Responses Understanding SNMP Alerting

Chapter 20

3. Click Alerting. The Alerting page appears.

4. Under Syslog Configuration, select on next to State to enable syslog alerting. 5. Select facility and priority levels from the drop-down lists. See Understanding Syslog Alerting on page 719 for details on facility and priority options. 6. Optionally, in the Logging Host field, enter the remote access IP address you want to specify as logging host. Separate multiple hosts with commas. Click Save.

7.

The syslog alerting configuration is saved. TIP! To return to the Policy edit page, click Back. 8. Apply the policy to the appropriate detection engines, as described in Applying an Intrusion Policy on page 764, to put your external alerting configuration into effect.

Understanding SNMP Alerting Requires: IPS or DC/MDC + IPS

Version 4.7

An SNMP trap is a network management notification. You can configure the sensor to send intrusion event notifications as SNMP traps, also known as SNMP alerts. Each SNMP alert includes: •

the name of the server generating the trap

•

the IP address of the sensor that detected it


722


Chapter 20

•

the name of the detection engine that detected it

•

the event data

Intrusion event response SNMP traps use the Message Digest 5 (MD5) authentication protocol and the Data Encryption Standard (DES) privacy protocol. In addition to enabling and disabling SNMP alerting, you can set a variety of parameters. Available parameters vary depending on the version of SNMP you use. TIP! If your network management system requires a management information base file (MIB), you can obtain it from the Defense Center at /etc/sf/DCEALERT.MIB or from the 3D Sensor at /etc/sf/SFALERT.MIB.

SNMP v2 Options For SNMP v2, you can specify the options described in SNMP v2 Options table. SNMP v2 Options Option

Description

Trap Server

The server that will receive SNMP traps notification.

Community String

The community name.

SNMP v3 Options For SNMP v3, you can specify the options described in SNMP v3 Options table. SNMP v3 Options Option

Description

Trap Server

The server that will receive SNMP traps notification.

Authentication Password

The password required for authentication.

Private Password

The SNMP key for privacy.

If you specify an authentication password, authentication is enabled.

If you specify a private password, privacy is enabled. If you specify a private password, you must also specify an authentication password. User Name

Version 4.7

Your SNMP user name.


723


Chapter 20

For information about configuring SNMP Alerting, see Configuring SNMP Alerting on page 724. IMPORTANT! When using SNMPv3, the appliance uses an Engine ID value to encode the message. Your SNMP server requires this value to decode the message. Currently, this Engine ID value will always be the hexadecimal version of the appliance’s IP address with 01 at the end of the string. For example, if the appliance sending the SNMP alert has an IP address of 172.16.1.50, the Engine ID is 0xAC10013201 or if the appliance has an IP address of 10.1.1.77, 0x0a01014D01 is used as the Engine ID.

Configuring SNMP Alerting Requires: IPS or DC/MDC + IPS

You can configure SNMP alerting in an intrusion policy. After you apply the policy to a detection engine, the detection engine notifies you of any intrusion events it detects via SNMP trap. For more details on SNMP alerting, see Understanding SNMP Alerting on page 722. IMPORTANT!

You must select SNMP v2 or SNMP v3.

To configure SNMP alerting options: Access: Rules or Admin

1.


2. Click Edit next to the intrusion policy where you want to configure alerting options. The Edit Policy page appears.

Version 4.7


724


Chapter 20

3. Click Alerting. The Edit Policy Alerting page appears.

4. Under SNMP Configuration, next to State, select on to enable SNMP alerting. 5. Specify the format that you want to use for IP addresses that appear in the alerts, as Binary or as String. IMPORTANT! If your network management system correctly renders the INET_IPV4 address type, then you can use the as Binary option. Otherwise, use the as String option. For example, HP OpenView requires the as String option. 6. Configure either SNMP v2 or SNMP v3 options. •

To configure SNMP v2, enter the IP address and the community name of the trap server you want to use in the corresponding fields. See SNMP v2 Options on page 723.

•

To configure SNMP v3, enter the IP address of the trap server you want to use, an authentication password, a private password, and a user name in the corresponding fields. See SNMP v3 Options on page 723 for more information.

IMPORTANT! When you enter an SNMP v3 password, the password displays in plain text during initial configuration but is saved in encrypted format.

Version 4.7


725

Configuring Intrusion Event Responses Understanding Email Alerting

Chapter 20

Optionally, to enable SNMP alerting per rule, click SNMP Alerting per Rule Configuration.

7.

The rule groups appear. TIP! To enable SNMP alerting for all rules, select the Select All check box. 8. Perform one or both of the following: •

Click All next to rule categories for which you want to receive SNMP alerts for all rules belonging to the category.

•

Click the category folder for the category where you want to specify SNMP alerting on individual rules, then enable the rules for which you want to receive SNMP alerts. Note that shared object rules have a generator ID of 3 (for example, 3:1902) and standard text rules have a generator ID of 1 (for example, 1:1000062).

9. Click Save. The system saves the SNMP alerting configuration. TIP! To return to the Policy edit page, click Back. 10. Apply the policy to the appropriate detection engines as described in Applying an Intrusion Policy on page 764 to put your external alerting configuration into effect.

Understanding Email Alerting Requires: IPS or DC/MDC + IPS

Version 4.7

Email alerts are notifications of intrusion events by email. Email alerts include the following information: •

total number of alerts in the database

•

last email time (the time that the system generated the last email report)

•

current time (the time that the system generated the current email report)

•

total number of new alerts

•

number of events that matched specified email filters (if events are configured for specific rules)


726


•

Chapter 20

timestamp, protocol, event message, and session information (source and destination IPs and ports with traffic direction) for each event (if Summary Output is off) IMPORTANT! If multiple intrusion events originate from the same source IP, a note appears beneath the event that displays the number of additional events.

•

number of events per destination port

•

number of events per source IP

For each rule or rule group, you can enable or disable email alerting on intrusion events. You configure email alerting for any detection engine on the appliance rather than per detection engine. Your email alert settings are used regardless of the policy in place for each detection engine on the sensor. The Email Alerting Parameters table describes the parameters you can set for email alerting. Email Alerting Parameters Parameter

Description

On/Off

Enables or disables email notification.

From Address

Specifies the email address or addresses from which the system sends intrusion events

To Address

Specifies the email address where the system sends intrusion events. To send email to multiple recipients, separate email addresses with commas. For example: [email protected], [email protected]

Max Alerts

Specifies the maximum number of intrusion events the system sends via email in the time frame specified by Frequency (seconds)

Frequency (seconds)

Specifies the maximum number of intrusion events the system sends via email in the time frame specified by Frequency (secondSpecifies how often the system mails intrusion events. The Frequency setting also specifies the frequency with which email settings are saved. Minimum (default) frequency: 300 seconds Maximum frequency: 4 billion seconds

Version 4.7


727


Chapter 20

Email Alerting Parameters (Continued) Parameter

Description

Coalesce Alerts

Enables or disables grouping of intrusion events by source IP and event so that multiple identical intrusion events generated against the same source IP only present one event on the page. Note that alert coalescence (grouping) occurs after events are filtered. Therefore, if you configure email alerting on specific rules, you will only receive a list of events that match the rules you specified in the Mail Alerting Configuration.

Summary Output

Enables or disables brief email alerting, which is suitable for text-limited devices such as pagers. Brief email alerts contain: event timestamp for Defense Centers, the IP address for the sensor that generated the event • event protocol • source IP and port • destination IP and port • event message • the number of intrusion events generated against the same source IP For example, on a 3D Sensor: 2004-05-18 10:35:10 icmp 10.10.10.1:8 -> 10.2.1.3:0 snort_decoder: Unknown Datagram decoding problem! (116:108)

On a Defense Center: 2004-05-18 10:35:10 10.1.1.100 icmp 10.10.10.1:8 -> 10.2.1.3:0 snort_decoder: Unknown Datagram decoding problem! (116:108)

Email Alerting on Specific Rules Configuration

Specifies the rules or rule groups whose events you want mailed to the specified email address or addresses.

For information about configuring email alerting, see Configuring Email Alerting on page 729.

Version 4.7


728


Chapter 20

Configuring Email Alerting Requires: IPS or DC/MDC + IPS

You can configure email alerting so that your appliance notifies you whenever an intrusion event occurs for an specific rule or rule group. Before you can receive email alerts, you must: •

configure your mail host to receive email alerts (see Configuring a Mail Relay Host and Notification Address on page 1201)

•

make sure that both the sensor and the Defense Center can reverse resolve their own IP addresses.

To configure email alerting options: Access: Rules or Admin

1.

Select Policy & Response > IPS > Email. The Edit Email Alerting page appears.

2. Next to State, select on to enable email alerting. 3. In the From Address field, type the address you want to display in the From field in the email alerts. 4. In the To Address field, type the address where you want to receive the email alerts. 5. In the Max Alerts field, type the maximum number of events you want included in a single email. 6. In the Min Frequency field, type the number of seconds for the minimum frequency with which you want to receive email alerts. 7.

To group events by IP address, next to Coalesce Alerts, select on.

8. To send brief email alerts, next to Summary Output, select on. TIP! If you enable Summary Output, consider enabling Coalesce Alerts to reduce the number of alerts generated. Also consider setting Max Alerts to 1 to avoid overflowing your device’s text message buffer.

Version 4.7


729

Configuring Intrusion Event Responses Responding to Events with a Check Point Firewall

Chapter 20

9. To enable email alerting per rule, click Email Alerting per Rule Configuration. The rule groups appear. TIP! To receive email alerts for all rules in all categories, select Select All. 10. Perform one or both of the following: •

Click All next to rule categories for which you want to receive email alerts for all rules belonging to the category.

•

Click the category folder within which you want to specify email alerting on individual rules in that category, then enable the rules for which you want to receive email alerts. Note that shared object rules have a generator ID of 3 (for example, 3:1902) and standard text rules have a generator ID of 1 (for example, 1:1000062).

11. Click Save. The system saves your email alerting configuration. When applicable intrusion events occur, you receive email alerts.

Responding to Events with a Check Point Firewall Requires: IPS or DC/MDC + IPS

You can configure an intrusion policy to initiate Check Point™ OPSEC™ Suspicious Activity Monitor (SAM) firewall responses whenever specified intrusion rules are triggered. By applying the policy to a detection engine, you integrate with the Check Point firewall, causing the 3D Sensor to start a firewall response whenever the rules enabled in the policy trigger. See the following sections for more information: •

Creating the OPSEC SAM Application on page 730

•

Connecting the 3D Sensor and the SAM Server on page 734

•

Configuring Firewall Responses on page 738

•

Enabling and Disabling the SAM Client on page 744

•

Viewing Sourcefire SAM Client System Information on page 745

•

Viewing OPSEC Debug Messages on page 745

Creating the OPSEC SAM Application Before setting up OPSEC properties in the web interface, you must first configure a Check Point OPSEC SAM application that communicates with the 3D Sensor. After creating the Check Point application, you configure the connection between the 3D Sensor and the SAM server, associate firewall responses with existing rules within a custom intrusion policy, and then apply that policy to a detection

Version 4.7


730


Chapter 20

engine. See Connecting the 3D Sensor and the SAM Server on page 734 for detailed information about configuring connectivity and setting firewall responses for rules. If you are configuring multiple 3D Sensors with IPS for use with a Defense Center, repeat this procedure to create an application for each managed sensor. IMPORTANT! The default port number for an OPSEC SAM server is 18183/tcp. For more information on modifying the default port for an OPSEC SAM server, as well as more detailed information about using Check Point OPSEC SAM and the Check Point SmartDashboard™, see the Check Point documentation. To create and configure an OPSEC SAM application connection to the 3D Sensor: 1.

Open the Check Point SmartDashboard and, from the Manage menu, select OPSEC Applications. The OPSEC Applications dialog box appears.

Version 4.7


731


Chapter 20

2. Click New and, from the choices that appear, select OPSEC Application. The OPSEC Application Properties dialog box appears.

3. Fill in the fields as follows: •

In the Name field, type the name for the new OPSEC application that you will use to connect to the 3D Sensor (for example, you could use sf_sam as the application name). Note the name that you specify. You will need to enter it later on the 3D Sensor when configuring connectivity.

•

Optionally, enter a comment in the Comment text box and select a color from the Color list. The Comment and Color features are only used by Check Point management software and have no effect on the connection with the 3D Sensor.

Version 4.7


732


•

Chapter 20

In the Host list, select the 3D Sensor with which the firewall will communicate.

IMPORTANT! If you are managing your 3D Sensor with a Defense Center, you must configure the sensor, not the Defense Center, as the host. The Defense Center pushes the OPSEC configuration to managed 3D Sensors by applying policies that contain the OPSEC settings, but does so by managing the peer trust between the sensor and the firewall. If the 3D Sensor does not appear in the list, click New, enter the sensor’s fully qualified domain name and IP address and click OK. •

Make no changes to the Vendor list; it should be set to User Defined.

•

Make no changes to the Server Entities box; all check boxes should remain disabled.

•

In the Client Entities box, select the SAM check box to indicate that this application will implement Suspicious Activity Monitoring.

4. Click Communication. The Communication dialog box appears.

5. In the Activation Key and Confirm Activation Key text boxes, enter a password. The Communication dialog box allows you to specify an activation key to be used to ensure a secure transfer of authentication certificates between the appliance and the Check Point application. IMPORTANT! Remember the Activation Key that you use. You must also enter it on the appliance where you are configuring the response) to ensure a secure transfer of authentication certificates between the 3D Sensor and the Check Point application.

Version 4.7


733


Chapter 20

6. Click Initialize to create authentication certificates for the application, and then click Close. The Communication dialog box closes and you return to the OPSEC Application Properties page. 7.

Click OK to close the OPSEC Application Properties dialog box, and then click Close to close the OPSEC Applications dialog box.

8. From the Policy menu on the Check Point Smart Dashboard, select Install. The Install Policy dialog box appears.

9. Select the module, enable Install on each selected Module independently, and click OK. The new policy is installed on the firewall. 10. Click Close to close the Installation Process dialog box. Your Check Point system is configured for OPSEC SAM communication with the configured sensor. Proceed to Connecting the 3D Sensor and the SAM Server on page 734 to configure the 3D Sensor connection to the Check Point OPSEC SAM. TIP! If you are managing other 3D Sensors with a Defense Center, repeat this procedure with the other sensors where it is required for your deployment.

Connecting the 3D Sensor and the SAM Server Requires: IPS or DC/MDC + IPS

Version 4.7

You can configure your 3D Sensor to initiate Check Point OPSEC Suspicious Activity Monitor (SAM) firewall responses when rules configured for IPS are triggered. To manage this interaction, you must configure how the 3D Sensor communicates with the specified OPSEC SAM server and define the appropriate firewall responses. You can perform this procedure on the standalone sensor web interface or on the web interface of the Defense Center managing your sensors.


734


Chapter 20

You need to configure both the Check Point firewall and the 3D Sensor, and you must set up the Check Point firewall first.For details on configuring your Check Point firewall for use with the 3D Sensor, see Creating the OPSEC SAM Application on page 730. If you are using the Defense Center to manage your 3D Sensor, you can use the Defense Center web interface to configure OPSEC settings for the sensor. After configuring your Check Point firewall, you must configure your sensor’s connection to the SAM server and configure a peer trust for the sensor. To set up communication between the 3D Sensor and the SAM server: Access: Rules or Admin

1.

Select Policy & Response > IPS > OPSEC > Peer. The Peer page appears. TIP! You can also access the Peer page by selecting SAM response then clicking SAM server on the OPSEC Response policy page.

2. Click Add New Peer. The OPSEC Peers section expands. 3. In the Server field, enter the IP address of the firewall server. 4. Locate your Check Point module distinguished name: •

If you do not know the Check Point module name, continue with step 5 for instructions on locating it.

•

If you already know the Check Point module name, skip to step 9 to enter it.

WARNING! The Check Point module distinguished name is not the same as the Check Point application distinguished name that was created in Creating the OPSEC SAM Application on page 730. The following procedures provide detailed information about accessing the module distinguished name. 5. Open the Check Point Smart Dashboard.

Version 4.7


735


Chapter 20

6. From the Manage menu, select Network Objects. The Network Objects dialog box appears.

7.

Select the Check Point module (typically cpmodule), and click Edit. The General Properties page for the module appears.

8. Under Secure Internal Communication, select and copy the module’s distinguished name. In this example, the Check Point module DN name is cn=cp_mgmt,o=cpmodule..v6xzhr. This will be different for your Check Point server, but the format should be similar.

Version 4.7


736


Chapter 20

9. In the Check Point module DN field on the Add New Peer page, enter the Check Point firewall server distinguished name (also known as the Secure Internal Communication, or SIC, name). WARNING! The Check Point module DN name is not the same as the distinguished name for the application. If you are unsure of the module name, follow steps 5 through 8 of this procedure to locate it. 10. Click Add. The OPSEC Peers section collapses and refreshes to show the Peers dropdown list with the new peer added to the list. TIP! To delete a peer, select the IP address of the SAM server from the Peers list and click Delete. Note that you cannot delete a peer that you are using to respond to intrusion events within a custom policy; you must first either disable SAM responses (see Disabling SAM Responses on page 744) or set your SAM server to “none” (see Configuring Firewall Responses on page 738). 11. Click Peer Trust. The Trust page appears.

12. Requires: DC/MDC If you are using the Defense Center web interface to configure OPSEC settings, select the 3D Sensor that you want to set up peer trust for from the Please select a sensor to configure Peer Trust list. 13. Select the peer for which you want to configure trust from the Current Peers drop-down list. 14. In the OPSEC Application Name field, type the name of the OPSEC application with which you are integrating the sensor. TIP! This is the name of the OPSEC application you created in Creating the OPSEC SAM Application on page 730. 15. In the Activation Key field, type the Activation key that you specified in the Communication dialog box of your Check Point module.

Version 4.7


737


Chapter 20

16. Click Establish Trust. This connects to the Check Point module and transfers the authentication certificate. You can now configure firewall responses within a custom policy and apply it to a detection engine.

Configuring Firewall Responses Requires: IPS or DC/MDC + IPS

You can configure how your Check Point firewall responds when specific standard text rules within an intrusion policy trigger. You must configure the SAM Response independently for each rule. This configuration is saved separately from the rule within a policy, so that any changes to the rule do not change the configured response. If you are using your Defense Center, the firewall responses are pushed to your managed 3D Sensors when you apply the affected intrusion policy. IMPORTANT! policies.

You can only configure firewall responses in custom (non-default)

To configure a SAM response to an intrusion event: Access: Rules or Admin

1.


2. Click Edit next to the intrusion policy where you want to configure OPSEC response options. The Edit Policy page appears. Note that you cannot use a default policy for OPSEC integration because the default policy cannot be modified. You must instead use a custom policy. For more information about creating custom policies, see Creating Intrusion Policies on page 747. 3. Click OPSEC Response. The OPSEC Response page appears.

Version 4.7


738


Chapter 20

4. Click the SAM response check box. The SAM Response page expands to display rules for configuration.

5. From the Select a SAM server list, select the firewall that you want to respond to triggered rules and click Save. TIP! If you have not yet created a SAM server, click the Select a SAM server link. For more information, see Connecting the 3D Sensor and the SAM Server on page 734. 6. Navigate to the rule for which you want to configure a response by clicking the rule category, then clicking the rule. Note that shared object rules have a generator ID of 3 (for example, 3:1902) and standard text rules have a generator ID of 1 (for example, 1:1000062). The SAM Rule Response Configuration page appears.

7.

Click the Enabled check box.

8. From the fwhost list, select the firewall object that receives this response. You can use the defaults of All, Gateways, or Localhost, or can create additional firewall objects using the SAM Control Panel. For details, refer to Adding and Deleting FWHosts on page 742.

Version 4.7


739


Chapter 20

9. From the Logging list, select one of the following log types: Log Type

Description

None


Long


Long w/ Alert


10. From the Action list, select the action you want the firewall to take. You can select one of the following actions: Action

Description

Notify

All connection attempts are logged as specified by the logging attribute. Traffic is not impeded.

Inhibit


Inhibit and Close


Drop


Drop and Close


11. In the Timeout field, specify the number of seconds that the specified action continues after it is initiated by the firewall. IMPORTANT! The maximum value is 2,147,483 seconds. Specifying a value of 0 causes the action to continue until it is manually disabled by a firewall administrator. 12. From the Filter Type list, select the filter type you want to apply from the dropdown list. Sourcefire supports 15 different filter types. For details, refer to Understanding Filter Options on page 742.

Version 4.7


740


Chapter 20

13. Depending on the filter type you selected, the Dest Mask, Source Mask, or Mask fields may appear. If they appear, enter the appropriate network mask value (for example, 255.255.255.0). 14. To install the filter with reversed source and destination information from the packet that triggered the rule, check Source is Target. 15. Click Save. The SAM Response page appears. 16. Click Save. The response is saved. You must apply the policy to a detection engine to activate SAM responses to triggered rules. See Applying an Intrusion Policy on page 764 for details.

Disabling Individual OPSEC SAM Responses Requires: IPS or DC/MDC + IPS

You can disable individual OPSEC SAM responses.


1.

To clear an OPSEC SAM response: Click the rule that you want to deactivate on the SAM Rule Response Configuration page. The SAM Rule Response Configuration page appears. 2. Clear the Enabled check box and click Save. 3. Repeat steps 1 and 2 for each response that you want to disable. 4. Apply the policy to the appropriate detection engines as described in Applying an Intrusion Policy on page 764.

Clearing All OPSEC SAM Responses for a Detection Engine Requires: IPS or DC/MDC + IPS

You can clear applied or active OPSEC SAM responses from the Check Point OPSEC SAM server. IMPORTANT! Clearing OPSEC SAM responses clears rule configurations from the firewall, but does not change the rule configuration on the detection engine. To clear SAM rule configurations from a firewall:


Version 4.7

1.

Select Policy & Response > IPS > OPSEC > Response. The Response page appears.


741


Chapter 20

2. Select the detection engines where you want to clear OPSEC SAM responses from the firewalls with which they communicate and click Clear SAM Responses. WARNING! Clicking Clear SAM Responses clears all rules installed on the firewall and therefore may clear rules that were installed on your firewall by other detection engines using the same peer. Responses are cleared from the firewall communicating with the selected detection engine.

Adding and Deleting FWHosts Requires: IPS or DC/MDC + IPS

You can add or delete firewall objects for the fwhost list.


1.

To add or delete firewall objects for the fwhost list: Select Policy & Response > IPS > OPSEC > Peer. The Peer page appears. 2. Perform one of the following: •

To add a new firewall object, type the name of the firewall object in the field and click Add.

•

To delete a user-defined firewall object, select the firewall object you want to delete from the list and click Delete.

Understanding Filter Options Requires: IPS or DC/MDC + IPS

Version 4.7

When configuring firewall responses, you must specify a filter. Filters define parameters of traffic against which the specified action is taken. The supported filters apply information from packets that trigger intrusion rules to traffic at the firewall, and take the specified action against those packets. The following list describes the available filters: •

Source IP performs the specified action against network traffic that has the same source IP address as the packet that triggered the intrusion rule.

•

Destination IP performs the specified action against network traffic that has the same destination IP address as the packet that triggered the intrusion rule.

•

Source or Destination IP performs the specified action against network traffic that has either the same source or destination IP address as the source IP address of the packet that triggered the intrusion rule.

•

Source IP, Destination IP, and Service performs the specified action against network traffic that has the same source IP address, destination IP address, IP protocol, and destination port as the packet that triggered the intrusion rule.


742


Version 4.7

Chapter 20

•

Destination IP and Service performs the specified action against network traffic that has the same destination IP address, IP protocol, and destination port as the packet that triggered the intrusion rule.

•

Source IP and Protocol performs the specified action against network traffic that has the same source IP address and IP protocol as the packet that triggered the intrusion rule.

•

Destination IP and Protocol performs the specified action against network traffic that has the same destination IP address and IP protocol as the packet that triggered the intrusion rule.

•

Source Network performs the specified action against network traffic identified as coming from the same source network as the packet that triggered the intrusion rule, calculated using the Source Network Mask attribute specified in the Check Point OPSEC SAM response configuration.

•

Destination Network performs the specified action against traffic whose source address matches the destination network, calculated using the Network Mask attribute, of the packet that triggered the intrusion rule.

•

Source or Destination Network performs the specified action against any packet whose source or destination network, calculated using the Network Mask attribute, matches the address of the packet that triggered the intrusion rule.

•

Source Network and Protocol performs the specified action against any network traffic whose source network, calculated using the Source Network Mask attribute, and IP protocol match the source network and IP protocol of the packet that triggered the intrusion rule.

•

Destination Network and Protocol performs the specified action against any network traffic whose destination network, calculated using the Destination Network Mask attribute, and IP protocol match the destination network and IP protocol of the packet that triggered the intrusion rule.

•

Destination Network and Service performs the specified action against any network traffic with the same destination network, calculated by comparing the Destination Network Mask attribute, IP protocol, and destination port to those of the packet that triggered the intrusion rule.

•

Source Network, Destination IP and Service performs the specified action against any network traffic with the same source network, calculated by comparing the Source Network Mask, destination IP address, IP protocol, and destination port to those of the packet that triggered the intrusion rule.

•

Source IP, Destination Network and Service performs the specified action against any network traffic with the same source IP address, destination network, calculated by comparing the Destination Network Mask, IP protocol, and destination port to those of the packet that triggered the intrusion rule.


743


Chapter 20

Enabling and Disabling the SAM Client Requires: IPS or DC/MDC + IPS

You can enable or disable the SAM client after you have configured it. See the following sections for more information: •

Disabling SAM Responses on page 744

•

Activating the SAM Client on page 744

Disabling SAM Responses Requires: IPS or DC/MDC + IPS

You can disable SAM responses within a policy. This stops the SAM Client (also referred to as SFReactD) until you reactivate it. To disable SAM responses:


1.


2. Click Edit next to the intrusion policy where you want to disable SAM responses. The Edit Policy page appears. 3. Click OPSEC Response. The OPSEC Response page appears. 4. Clear the SAM response check box. SAM responses are disabled. 5. Apply the policy to the appropriate detection engines as described in Applying an Intrusion Policy on page 764.

Activating the SAM Client Requires: IPS or DC/MDC + IPS

Re-activating disabled SAM responses restarts the SAM Client (also referred to as SFReactD). You can re-activate a response by editing the affected intrusion policy and re-applying it. Note that you cannot use a default intrusion policy for OPSEC integration because default policies cannot be modified. You must instead use a custom intrusion policy. For more information about creating custom policies, see Creating Intrusion Policies on page 747. To activate SAM responses:


1.


2. Click Edit next to the intrusion policy where you want to enable SAM responses. The Edit Policy page appears.

Version 4.7


744


Chapter 20

3. Click OPSEC Response. The OPSEC Response page appears. 4. Select the SAM response check box. SAM responses are activated, and the list of rules for which you can configure responses appears. 5. Apply the policy to the appropriate detection engines as described in Applying an Intrusion Policy on page 764.

Viewing Sourcefire SAM Client System Information Requires: IPS or DC/MDC + IPS

You can view system log messages for the Sourcefire SAM client from the web interface. The SAM Client module name is SFReactD. To view the status associated with the SAM Client:

Access: Maintenance or Admin

1.

Select Operations > Monitoring > Syslog. A list of system log messages appears.

2. In the Filter box, type SFReactD and click Go. Messages associated with the Sourcefire SAM client appear.

Viewing OPSEC Debug Messages Requires: IPS

Version 4.7

To view OPSEC debug messages, you must be connected to the 3D Sensor via ssh and logged in using the root user. The debug messages are sent to the screen rather than to the web interface.


745


Chapter 20

To view OPSEC debug messages: Access: root

1.

Connect to the sensor via ssh and log in using the root account.

2. Run the following to set the OPSEC debugging environment variables: source /opt/Sourcefire_Sensor-4.6.1-#### (where #### is the software build number) 3. Use the following commands (where DE_UUID is the UUID that you determined in the previous step) to stop the SFReactD daemon and start it again in the foreground: pmtool disablebyid de_uuid-react and then, all on one line, enter: SFReactD --nodaemon -X /var/sf/detection_engines/de_uuid/SFReactD.pid -c /var/sf/de_uuid/SFReactD.conf

The debug messages are directed to the screen. 4. Use the following command to restart the SFReactD daemon: pmtool enablebyid de_uuid-react

Version 4.7


746

Chapter 20

Creating Intrusion Policies

An intrusion policy is a defined set of decoder, preprocessor, and rule configurations that you can apply to an IPS detection engine on a 3D Sensor that is licensed for the IPS component. You can use a copy of any of the default intrusion policies that Sourcefire provides, or you can tailor your own policies to inspect the traffic that traverses your network. The components of an intrusion policy include: •

packet decoders and preprocessors that process traffic so that the rules engine can inspect it

•

intrusion rules that inspect the protocol header values, payload content, and other packet characteristics

•

tools that allow you to control how often events are logged and displayed

Depending upon how you configure the detection engine and the interface set that it uses, you can apply a passive intrusion policy or an inline intrusion policy. An interface set deployed using an inline or inline with fail open configuration allows you to deploy the detection engine inline within your network. With an inline deployment of IPS, you can affect the flow of network traffic by setting up intrusion rules to drop malicious packets before they reach potentially vulnerable hosts. An IPS detection engine using a passive interface set can detect and alert you to malicious traffic packets but cannot affect the flow of network traffic.

Version 4.7


747

Creating Intrusion Policies

Chapter 21

Depending on your network, and the subnet you want to monitor, the kinds of traffic that traverse it differ, as do the kinds of events you most want to see. Intrusion policies allow you to: •

specify the policy mode, either passive (for detection engines that use passive interface sets) or inline (for detection engines that use inline or inline with fail open interface sets)

•

configure packet decoders and preprocessors

•

create and edit variables for IP addresses and ports

•

create a reserved variable to configure features not otherwise accessible through the user interface

•

in passive intrusion policies, set intrusion rules to Enable or Disable; in inline intrusion policies, set intrusion rules to Enable, Disable, or Drop

•

create custom intrusion rules

Sourcefire provides two types of intrusion rules: shared object rules and standard text rules. In addition to the standard text rules they create, the Sourcefire Vulnerability Research Team (VRT) can also create shared object rules that detect attacks against vulnerabilities in ways that standard text rules do not. See the following sections for more information about intrusion policies:

Version 4.7

•

Default Intrusion Policies on page 749 describes the Sourcefire-provided intrusion policies that you can use as a basis for your own custom intrusion policies.

•

Planning and Implementing an Intrusion Policy on page 750 describes, at a high level, the process you use to create a policy.

•

Creating an Inline Intrusion Policy on page 752 explains how to create a custom inline intrusion policy for inline IPS deployments.

•

Creating a Passive Intrusion Policy on page 756 explains how to create a custom passive intrusion policy for passive IPS deployments.

•

Managing Intrusion Policies on page 760 explains how to modify and delete existing intrusion policies.

•

Applying an Intrusion Policy on page 764 explains how to apply a new or updated intrusion policy to the appropriate IPS detection engines.

•

Limiting Intrusion Event Notification Per Policy on page 766 explains how to use suppression and thresholding to limit the number of notifications you receive for intrusion events that are generated on a frequent basis.

•

Defining IP Addresses and Ports for Your Network on page 773 provides the syntax used to specify IP addresses and port numbers within the variables and rules in your policy.


748

Creating Intrusion Policies Default Intrusion Policies

Chapter 21

•

Configuring Variables on page 778 explains how to create and manage variables that you can use within intrusion policies.

•

Configuring Non-Standard Intrusion Policy Features on page 787 describes how to use a reserved variable to configure IPS features that are not accessible through the user interface.

•

Configuring Rule States on page 789 explains how to enable and disable intrusion rules within an intrusion policy. This section also explains how to configure rules in inline intrusion policies so that they drop malicious packets.

•

Using Latency Thresholding on page 803 explains how you can use packet and rule latency thresholding to balance security with connectivity on your network.

•

Using RNA Recommended Rules on page 811 explains how you can use RNA data to recommend intrusion rule states.

•

Importing SEUs and Rule Files on page 833 explains how to download and import Security Enhancement Updates (SEUs) that contain new intrusion rules. Note that SEUs can also contain new and updated decoders and preprocessors.

Default Intrusion Policies Requires: IPS or DC/MDC + IPS

Five default intrusion policies are delivered with the Sourcefire 3D System. By using the policies provided by Sourcefire as a basis for your intrusion policy, you can take advantage of the experience of the VRT. The default intrusion policies are: •

Balanced Security and Connectivity (provided by Sourcefire) This policy is built for both speed and detection. It serves as a good starting point for most organizations. It is also a good starting point for any type of deployment. Also, note that this policy is roughly equivalent to the Suggested Inline Rules policy in previous versions of the product.

•

Connectivity over Security (provided by Sourcefire) This policy is built for organizations where connectivity (being able to get to all resources) takes precedence over network infrastructure security. This policy enables a far fewer rules than those enabled in the Security over Connectivity policy. Only the most critical rules that block traffic are enabled.

Version 4.7


749

Creating Intrusion Policies Planning and Implementing an Intrusion Policy

•

Chapter 21

No Rules Active (provided by Sourcefire) All the intrusion rules in this policy are set to Disable by default. This policy is a convenient starting point if you want to enable only a few intrusion rules during testing.

•

Passive - Default Policy (provided by Sourcefire) This policy includes a large number of enabled rules. This policy is best suited for passive monitoring environments and should not be used as a starting point for an inline deployment.

•

Security over Connectivity (provided by Sourcefire) This policy is built for organizations where network infrastructure security takes precedence over user convenience. This policy enables numerous network anomaly rules that could alert on or drop legitimate traffic.

You can use copies of those or create your own policy with a tuned rule set and preprocessor configuration to inspect traffic in the way that matters most to you. By doing this, you can improve both the performance of your sensor and your ability to respond effectively to the events it generates.

Planning and Implementing an Intrusion Policy Requires: IPS or DC/MDC + IPS

Version 4.7

Building custom intrusion policies can improve the performance of IPS in your environment and can provide a focused view of the malicious traffic and policy violations occurring on your network.


750

Creating Intrusion Policies Planning and Implementing an Intrusion Policy

Chapter 21

The following illustrates the process you use to define your intrusion policy and tune your system.

1.

Decide where to place your 3D Sensors with IPS on the network. There are a variety of deployment options in tuning your sensor. For details on deciding where to place your 3D Sensors to best monitor the traffic that matters to you, see the Installation Guide for your sensor.

2. Understand the traffic that traverses the network segment. Before tuning your intrusion policy, it pays to understand the traffic it will monitor. For example, if you are monitoring traffic in the DMZ, you may want to pay special attention to web servers and verify that all applicable web server rules are active. If you are monitoring an internal subnet with no external facing servers, you may want to tune your system differently. For an example of how to assess traffic to verify that you have the proper rules in place or to write a new rule, see Rule-Writing Examples and Tips on page 1018. 3. Define your security policies. Security policies include your internal security guidelines, as well as your variable, preprocessor, and rules configuration. •

Define the security guidelines that govern the hosts on that subnet. Your internal security policies guide how you tune the decoder engine, preprocessor engine, and rules engine. For example, if your security policies prohibit instant messaging, you may want to identify instant message traffic traversing your network.

Version 4.7


751

Creating Intrusion Policies Creating an Inline Intrusion Policy

•

Chapter 21

Configure your preprocessors, enabling and disabling options as appropriate. For more information on the preprocessors provided in Sourcefire 3D System, as well as details on how to configure them, see Tuning Preprocessors on page 846.

•

Set your variables to accurately reflect your home and external networks. Defining system variables makes rule inspection more effective and efficient by directing rules to inspect the traffic to and from specific IPs and ports. Setting these at the variable level allows you to tune the system without editing every rule. For details on managing system variables, see Configuring Variables on page 778. You can also tune your variables for each detection engine. For more information, see Using Variables within Detection Engines on page 110.

•

Disable shared object rules and standard text rules that do not apply to your environment and verify that all rules that do apply to your environment are enabled. For sensors with inline detection engines, carefully choose the intrusion rules that you want to drop packets rather than simply generate events. For more information on setting rule states, see Configuring Rule States on page 789.

4. If none of the existing intrusion rules meet your needs, write new rules that inspect for intrusion attempts. For information on the rule keywords you can use to construct custom standard text rules, and their syntax, see Understanding and Writing Intrusion Rules on page 948. Rule-Writing Examples and Tips on page 1018 includes two examples of intrusion rules, one basic and one more advanced, that illustrate the rule-writing process. Examples of replace rules, which you may want to use with an inline detection engine, are also provided. 5. Test your configuration.

Creating an Inline Intrusion Policy Requires: IPS or DC/MDC + IPS

Version 4.7

If you deploy a detection engine that uses an inline or inline with fail open interface set, then you can use what is called an inline intrusion policy. In an inline intrusion policy, you can set the state of an intrusion rule to one of three options: Enable, Disable, or Drop. Enable and Disable rules in an inline intrusion policy function the same way as they do in a passive intrusion policy. When a rule is enabled and a packet triggers the rule, IPS generates an intrusion event. When a rule is disabled, packets are not examined to determine whether they attempt to exploit the vulnerability. A drop rule, however, allows you to take advantage of the interface set’s inline deployment. An intrusion rule whose state is set to Drop


752


Chapter 21

generates an intrusion event and also drops the packet that triggered the rule. The packet never reaches its target. IMPORTANT! Your inline intrusion policies can also include rules that use the replace keyword. For information, see Understanding Replace Rules on page 1044.

TIP! You can also import intrusion policies from other Defense Centers and 3D Sensors in your deployment. See Importing and Exporting Objects on page 1248 for more information.

WARNING! Use copies of default inline intrusion policies with caution. Certain intrusion rules are set to Drop by default. If you do not want to automatically drop malicious packets, you must edit your copy of the policy. You can use the following procedure to create a custom inline intrusion policy, based on the default inline policy that meets the needs of your networking environment. To create an inline intrusion policy: Access: Rules or Admin

1.



3. Use the Copy Policy drop-down list to select the policy on which you want to base the new policy. You can select any of the three default Sourcefire inline policies or any user-defined policy as the basis for your new policy. 4. Type a name and description for the policy. TIP! You can create multiple intrusion policies with the same name. To avoid confusion, choose unique names for policies.

Version 4.7


753


Chapter 21

5. Select Inline from the Policy Mode drop-down list. TIP! Inline is the default drop-down list selection for copies of Sourcefire supplied inline rules. 6. Click Save to create the new policy. The Edit Policy page appears, including a list of pages (called sections) that you can use to modify different parts of the intrusion policy.

Note that your policy becomes available, but does not take effect until you apply it to an inline detection engine. IMPORTANT! All features are only available if you first import an SEU containing Snort 2.8.1 or later. 7.

Optionally, you can modify each section of your intrusion policy. IMPORTANT! Sourcefire can use SEU updates to add new functionality and features to intrusion policies. To learn more about features that are not discussed in the main online help, click the Help link on the feature page to view additional SEU-based online help. See the following for information about each section:

Version 4.7

•

Configuring Intrusion Event Responses on page 718 describes how to set up external alerting based on intrusion events.

•

Understanding DCE/RPC Traffic Reassembly on page 921 explains how to configure the DCE/RPC preprocessor to reassemble DCE/RPC traffic.


754


Version 4.7

Chapter 21

•

Detecting Exploits in DNS Name Server Responses on page 924 describes the DNS preprocessor and explains how to configure it to alert when it detects any of three specific exploits in DNS name server responses.

•

Decoding FTP and Telnet Traffic on page 909 describes the FTP Telnet preprocessor and provides details on specifying preprocessor configuration.

•

Decoding HTTP Traffic on page 891 explains how to define HTTP inspection settings.

•

Using Latency Thresholding on page 803 explains how to balance security with the need to maintain sensor latency at an acceptable level.

•

Configuring Firewall Responses on page 738 explains how to configure the 3D Sensor to communicate with a Check Point firewall.

•

Detecting Portscans on page 933 explains how to define portscan detection options.

•

Tuning Preprocessors on page 846 also describes additional preprocessor settings.

•

Using RNA Recommended Rules on page 811 explains how to use RNA data to associate intrusion rules with the hosts and services on your network and accept recommended rule states. For information about permanently accepting recommended rule states, see Configuring Rule States on page 789.

•

Configuring RNA Recommended Rules on page 816 explains how to use the network map to associate hosts and services on your network with rules specifically designed to protect those hosts and services.

•

Configuring Rule States on page 789 and Using the Drop Rule State on page 798 explain how to enable rules, disable rules, set rules to automatically drop malicious packets and, for the RNA Recommended Rules feature, how to permanently accept rule state recommendations. For information about rule anatomy, rule keywords and their options, and rule writing syntax, see Understanding and Writing Intrusion Rules on page 948. For information about creating rules that replace all or part of the packet content, see Understanding Replace Rules on page 1044. For information about how to base intrusion rule states on RNA data, see Using RNA Recommended Rules on page 811.

•

Decoding SMTP Traffic on page 905 explains how to customize SMTP preprocessor settings.

•

Detecting Encrypted Traffic Using the SSL Preprocessor on page 928 explains how you can use the SSL preprocessor to identify encrypted traffic and eliminate false positives by stopping IPS inspection of that traffic.


755

Creating Intrusion Policies Creating a Passive Intrusion Policy

Chapter 21

•

Understanding Transport-Layer Preprocessors on page 873 describes stateful inspection and stream reassembly of TCP traffic, and UDP session tracking.

•

Configuring Thresholding per Policy on page 766 and Configuring Suppression Per Intrusion Policy on page 771 explains how to limit the number of intrusion events that are generated by enabled intrusion rules.

•

Configuring Variables on page 778 explains how to tailor rules for your specific network environment. Make sure you accurately specify the values for $HOME_NET, which represents the IP addresses on the network segment protected by IPS, and $EXTERNAL_NET, which represents all the IP addresses that are not on the network segment. For example, if you set the rule state to Drop for a rule that uses these variables and the variables themselves are not set correctly, your policy could drop the wrong packets or pass packets that you expect to drop.

8. After you modify each section of your policy, click Save to save your changes and then click Back to return to the Edit Policy page. The new intrusion policy is available, but does not go into effect until you apply it to a detection engine. You can click the Apply Policy link to display the Apply Policy page and apply your new inline intrusion policy to a detection engine. For more information, see Applying an Intrusion Policy on page 764.

Creating a Passive Intrusion Policy Requires: IPS or DC/MDC + IPS

Passive intrusion policies are intrusion policies designed for IPS detection engines that use passive interface sets. The intrusion rules in a passive intrusion policy are set to one of two rule states: Enable or Disable. If you enable a rule, then the rule triggers whenever the rules engine detects a packet that matches the rule and the rules engine generates an intrusion event. If you disable the rule, then packets matching the rule pass by the rules engine without generating an event. IMPORTANT! Inline intrusion policies can use a third type of rule state called Drop that allows you to drop malicious packets in addition to generating alerts. See Creating an Inline Intrusion Policy on page 752 for more information.

IMPORTANT! Enabling what is called a pass rule has a different effect. For information, see Specifying Rule Actions on page 952. You can use the following procedure to create a custom passive intrusion policy, based on the default passive intrusion policy that meets the needs of your networking environment.

Version 4.7


756


Chapter 21

To create a passive intrusion policy: Access: Rules or Admin

1.



3. Use the Copy Policy drop-down list to select the policy on which you want to base the new policy. You can select either of the two default Sourcefire passive intrusion policies or any user-defined passive policy as the basis for your new policy. 4. Type a name and description for the policy. TIP! You can create multiple intrusion policies with the same name. To avoid confusion, choose unique names for policies. 5. Select Passive from the Policy Mode drop-down list. TIP! Passive is the default drop-down list selection for copies of Sourcefire supplied passive rules.

Version 4.7


757


Chapter 21

6. Click Save to create the new policy. The Edit Policy page appears, including a list of pages (called sections) that you can use to modify different parts of the intrusion policy.

Note that your policy becomes available, but does not take effect until you apply it to a passive detection engine. 7.

Optionally, you can modify each section of your intrusion policy. IMPORTANT! Sourcefire can use SEU updates to add new functionality and features to intrusion policies. To learn more about features that are not discussed in the main online help, click the Help link on the feature page to view additional SEU-based online help. See the following for information about each section: •

Configuring Intrusion Event Responses on page 718 describes how to set up external alerting based on intrusion events.

•

Understanding DCE/RPC Traffic Reassembly on page 921 explains how to configure the DCE/RPC preprocessor to reassemble DCE/RPC traffic.

•


IMPORTANT! This features is only available if you first import an SEU containing Snort 2.8.1 or later. •

Version 4.7

Decoding FTP and Telnet Traffic on page 909 describes the FTP Telnet preprocessor and provides details on specifying preprocessor configuration.


758


Chapter 21

•

Decoding HTTP Traffic on page 891 explains how to define HTTP inspection settings.

•

Using Latency Thresholding on page 803 explains how to balance security with the need to maintain sensor latency at an acceptable level.

•

Configuring Firewall Responses on page 738 explains how to configure the 3D Sensor to communicate with a Check Point firewall.

•

Detecting Portscans on page 933 explains how to define portscan detection options.

•

Tuning Preprocessors on page 846 also describes additional preprocessor settings.

•

Using RNA Recommended Rules on page 811 explains how to use RNA data to associate intrusion rules with the hosts and services on your network and accept recommended rule states. For information about permanently accepting recommended rule states, see Configuring Rule States on page 789.

•

Configuring RNA Recommended Rules on page 816 explains how to use the network map to associate hosts and services on your network with rules specifically designed to protect those hosts and services.

•

Configuring Rule States on page 789 explains how to enable and disable rules. For information about rule anatomy, rule keywords and their options, and rule writing syntax, see Understanding and Writing Intrusion Rules on page 948. For information about how to base intrusion rule states on RNA data, see Using RNA Recommended Rules on page 811.

•

Decoding SMTP Traffic on page 905 explains how to customize SMTP preprocessor settings.

•


IMPORTANT! This features is only available if you first import an SEU containing Snort 2.8.1 or later. •

Version 4.7

Understanding Transport-Layer Preprocessors on page 873 describes stateful inspection and stream reassembly of TCP traffic and UDP session tracking.


759

Creating Intrusion Policies Managing Intrusion Policies

Chapter 21

•

Configuring Thresholding per Policy on page 766 and Configuring Suppression Per Intrusion Policy on page 771 explains how to limit the number of intrusion events that are generated by enabled intrusion rules.

•

Configuring Variables on page 778 explains how to tailor rules for your specific network environment. Make sure you accurately specify the values for $HOME_NET, which represents the IP addresses on the network segment protected by IPS, and $EXTERNAL_NET, which represents all the IP addresses that are not on the network segment.

8. After you modify each section of your policy, click Save to save your changes and then click Back to return to the Edit Policy page. The new intrusion policy is available, but does not go into effect until you apply it to a detection engine. You can click the Apply Policy link to display the Apply Policy page and apply your new passive intrusion policy to a detection engine. For more information, see Applying an Intrusion Policy on page 764.

Managing Intrusion Policies Requires: IPS or DC/MDC + IPS

The Sourcefire 3D System allows you to modify or delete any of the intrusion policies that you have created. You cannot modify or delete any of the default intrusion policies. See the following sections for more information about how to modify and delete existing intrusion policies: •

Modifying Intrusion Policies on page 760 explains how to edit an existing policy.

•

Deleting Intrusion Policies on page 764 explains how to delete an existing intrusion policy.

Modifying Intrusion Policies Requires: IPS or DC/MDC + IPS

You can modify any part of an existing policy’s configuration. TIP! Sourcefire can use SEU updates to add new functionality and features to intrusion policies. To learn more about features that are not discussed in the main online help, click the Help link on the feature page to view additional SEU-based online help. For more information on SEU updates, see Importing SEUs and Rule Files on page 833.

Version 4.7


760


Chapter 21

To modify a policy’s configuration: Access: Rules or Admin

1.


2. Click Edit next to the policy you want to edit. The Edit Policy page appears, including a list of pages (called sections) that you can use to modify different parts of the intrusion policy.

IMPORTANT! Some features are only available if you first import an SEU containing Snort 2.8.1 or later. 3. Optionally, to define external alerting options, click Alerting. For information about configuring alerting, see Configuring Intrusion Event Responses on page 718. 4. Optionally, to customize DCE/RPC preprocessor settings, click DCE/RPC. For information on DCE/RPC preprocessor behavior and details on specifying preprocessor configuration, see Understanding DCE/RPC Traffic Reassembly on page 921.

Version 4.7


761


Chapter 21

5. Optionally, to customize DNS preprocessor settings, click DNS. For information on DNS preprocessor behavior and details on specifying preprocessor configuration, see Detecting Exploits in DNS Name Server Responses on page 924. IMPORTANT! This features is only available if you first import an SEU containing Snort 2.8.1 or later. 6. Optionally, to customize FTP Telnet preprocessor settings, click FTP Telnet. For information on FTP Telnet preprocessor behavior and details on specifying preprocessor configuration, see Decoding FTP and Telnet Traffic on page 909. 7.

Optionally, to define your HTTP inspection settings, click HTTP Inspection. For information about the types of data that the HTTP inspection preprocessor can normalize and detect, see Tuning Preprocessors on page 846.

8. Optionally, to balance security with the need to maintain sensor latency at an acceptable level, click Latency Thresholding. For information about configuring latency thresholding, see Using Latency Thresholding on page 803. 9. Optionally, to configure the 3D Sensor to communicate with a Check Point firewall, click OPSEC Response to configure OPSEC settings. For more information about configuring firewall responses, see Configuring Firewall Responses on page 738. 10. Optionally, to define portscan detection options, click Portscan Detection. For information on configuring portscan detection, see Detecting Portscans on page 933. 11. Optionally, to define standard preprocessor settings, click Preprocessors. For information on preprocessor behavior and details on specifying preprocessor configuration, see Tuning Preprocessors on page 846. 12. Optionally, to associate intrusion rules with the hosts and services on your network and accept recommended rule states based on RNA data, see Using RNA Recommended Rules on page 811. For information about permanently accepting recommended rule states, see Configuring Rule States on page 789. 13. Optionally, to use the network map to associate hosts and services on your network with the rules specifically designed to protect those hosts and services, see Configuring RNA Recommended Rules on page 816.

Version 4.7


762


Chapter 21

14. Optionally, to enable and disable rules or to set a rule to drop traffic, click Rule State. For information on how to activate and deactivate existing rules, see Configuring Rule States on page 789. For information on setting a rule to a drop state, see Using the Drop Rule State on page 798. For information about rule anatomy, rule keywords and their options, and rule writing syntax, see Understanding and Writing Intrusion Rules on page 948. For information about how to base intrusion rule states on RNA data, see Using RNA Recommended Rules on page 811. 15. Optionally, to customize SMTP preprocessor settings, click SMTP. For information on SMTP preprocessor behavior and details on specifying preprocessor configuration, see Decoding SMTP Traffic on page 905. 16. Optionally, to customize SSL preprocessor settings, click SSL. For information on SSL preprocessor behavior and details on specifying preprocessor configuration, see Detecting Encrypted Traffic Using the SSL Preprocessor on page 928. IMPORTANT! This features is only available if you first import an SEU containing Snort 2.8.1 or later. 17. Optionally, to customize stream preprocessor settings, click Stream Configuration. For information on stream preprocessor behavior and details on specifying preprocessor configuration, see Understanding Transport-Layer Preprocessors on page 873. 18. Optionally, to define event suppression, click Suppression. For information about configuring suppressions, see Configuring Suppression Per Intrusion Policy on page 771. 19. Optionally, to define any event thresholds you want to establish, click Threshold. For information about setting thresholds, see Configuring Thresholding per Policy on page 766. 20. Optionally, to customize system variables, click Variables. For a complete description of system variables, and a description of how to define them, see Configuring Variables on page 778. 21. Click the Apply Policy link to display the Apply Policy page and apply the updated policy to a detection engine.

Version 4.7


763

Creating Intrusion Policies Applying an Intrusion Policy

Chapter 21

Deleting Intrusion Policies Requires: IPS or DC/MDC + IPS

You can delete custom intrusion policies that are no longer in use.


1.

To delete a policy: Select Policy & Response > IPS > Detection & Prevention. The Detection & Prevention page appears.

2. Click Delete next to the policy you want to delete. The policy is deleted.

Applying an Intrusion Policy Requires: IPS or DC/MDC + IPS

After making any changes to any intrusion policy, you must apply the policy to a detection engine to enable the configuration changes. Note that applying an intrusion policy causes the detection engines on the sensor to restart, which can cause a short pause in processing and, for detection engines with inline interface sets, may cause a few packets to be dropped. Make sure you plan these actions for times when they will have the least impact on your deployment. IMPORTANT! Make sure you match the policy type (passive or inline) to the detection engine’s interface set (passive or inline). If you apply an inline policy to a detection engine that uses a passive interface set, drop rules will generate events, but will not drop any packets or block any attacks. To apply an intrusion policy:


Version 4.7

1.



764

Creating Intrusion Policies Applying an Intrusion Policy

Chapter 21

2. Click Apply next to the policy you want to apply. The Apply Policy page appears.

3. Optionally, select a sort order from the drop-down list. You can choose from the following options: •

By Group (that is, by detection engine group)

•

By Sensor (for the Defense Center only)

•

By Policy (that is, by the currently applied policy)

•

By DE Type (that is, by detection engine type: IPS or RNA)

•

By Set Type (that is, by interface set type: passive, inline, or inline with fail open)

4. In the Available Detection Engines list, select the detection engines where you want to apply the policy. You have two options: •

To apply the policy to all detection engines within a specific category, select the check box for the category. For example, if you want to apply a policy to all the inline detection engines, sort by Set Type, then select the check box next to its label.

•

To apply the policy to unrelated detection engines, select the check boxes next to those detection engines.

Requires: MDC If you apply an intrusion policy from a Master Defense Center and there are any SEUs older than the MDC’s residing on Defense Center(s) managing those detection engines, those SEUs are updated. Therefore, a warning message with check box appears. Acknowledge the message by clicking its check box. That activates the Apply button.

5. Click Apply. It can take several minutes for the policy to be updated and applied to your detection engines.

Version 4.7


765

Creating Intrusion Policies Limiting Intrusion Event Notification Per Policy

Chapter 21

Limiting Intrusion Event Notification Per Policy Requires: IPS or DC/MDC + IPS

The importance of an intrusion event can be based on frequency of occurrence, or source or destination IP address. In some cases you may not care about an event until it has occurred a certain number of times. For example, you may not be concerned if someone attempts to log into a server until they fail a certain number of times. In other cases, you may only need to see a few occurrences to know there is a widespread problem. For example, if a DoS attack is launched against your web server, you may only need to see a few occurrences of an intrusion event to know that you need to address the situation. Seeing hundreds of the same event only overwhelms your system. See the following sections for more information: •

Configuring Thresholding per Policy on page 766 explains how to set thresholds that dictate how often (based on the number of occurrences) an event is displayed. You can configure thresholding per event, per policy.

•

Configuring Suppression Per Intrusion Policy on page 771 explains how to suppress notification of specified events per source or destination IP address per policy.

Configuring Thresholding per Policy Requires: IPS or DC/MDC + IPS

You can set thresholds for individual rules per intrusion policy to limit the number of times the system logs and displays an intrusion event based on how many times the event is generated within a specified time period. This can prevent you from being overwhelmed with a large number of identical events. You can set event notification thresholds in two ways:

Version 4.7

•

You can use the threshold keyword within a custom standard text rule to limit the instances of an event that is logged and displayed per specified time period and per tracking IP address for any rule. For more information, see Limiting Event Notification on page 1003.

•

You can set thresholds per shared object rule or standard text rule in your intrusion policy configuration, as described in this section. Note that the threshold is applied to rules regardless of whether they are enabled or disabled.


766


Chapter 21

First, you must specify the thresholding type. You can select from the following. Thresholding Options Option

Description

limit

Logs and displays events for the specified number of packets (specified by the count argument) that trigger the rule during the specified time period. For example, if you set the type to limit, the count to 10, and the seconds to 60, and 14 packets trigger the rule, IPS stops logging events for the rule after displaying the first 10 that occur within the same minute.

threshold

Logs and displays a single event for every specified number of occurrences during the time period defined by the seconds argument. For example, if you set the type to threshold, the count to 10, and the seconds value to 60, IPS generates an event for every 10 instances that the rule triggers during each minute.

both

Logs and displays an event once per specified time period, after the specified number (count) of packets trigger the rule. For example, if you set the type to both, the count to 2, and the seconds value to 10, the following event counts would result: • If the rule is triggered twice in 10 seconds, one event is generated (the threshold is met once) • If the rule is triggered four times in 10 seconds, two events are generated (the threshold is met twice) • If the rule is triggered six times in 10 seconds, two events are generated (the threshold is met twice and the limit of two events is reached)

Next, you must specify the tracking, which determines whether the event threshold is calculated per source or destination IP address. Select one of the following to specify how IPS tracks event instances. Thresholding IP Options

Version 4.7

Option

Description

Source IP

Calculates event instance count per source IP address.

Destination IP

Calculates the event instance count per destination IP address.


767


Chapter 21

Finally, you must specify the number of instances and time period that define the threshold. Thresholding Instance/Time Options Option

Description

Count

The number of event instances per specified time period per tracking IP address required to meet the threshold.

Seconds

The number of seconds that elapse before the count resets. If you set the threshold type to limit, the tracking to Source IP, the count to 10, and the seconds to 10, IPS logs and displays the first 10 events that occur in 10 seconds from a given source port. If only 7 events occur in the first 10 seconds, the system logs and displays those, if 40 events occur in the first 10 seconds, the system logs and displays 10, then begins counting again when the 10-second time period elapses.


Adding a New Intrusion Event Threshold on page 768

•

Viewing and Deleting Intrusion Event Thresholds on page 770

TIP! You can also add thresholds from within the packet view of an intrusion event. See Viewing Event Information on page 676 for more information.

Adding a New Intrusion Event Threshold Requires: IPS or DC/MDC + IPS

You can set system-wide thresholds or set a threshold for specific rules. If you apply a policy containing a threshold to a detection engine running on a sensor with multiple CPUs, you may receive a higher number of events than expected. To create a global threshold that applies to all rules and preprocessor-generated events, select System Wide Threshold from the Global folder. A Global by Destination IP threshold is configured by default. You can view the configured settings for the threshold to see if they are appropriate for your system. If they are not, you must delete the threshold configuration before replacing it with a new global by destination IP threshold setting. The Global by Destination IP thresholding values are as follows:

Version 4.7

•

Type - limit

•

Track By - Destination IP

•

Count - 1

•

Seconds - 60


768


Chapter 21

For more information on viewing and deleting threshold configurations, see Viewing and Deleting Intrusion Event Thresholds on page 770. To configure event thresholds: Access: Rules or Admin

1.


2. Click Edit next to the intrusion policy where you want to configure thresholding options. The Edit Policy page appears. 3. Click Threshold. The Thresholds page appears.

Version 4.7


769


Chapter 21

4. Open the rule category folders containing the rules where you want to set a threshold and select the rules whose event notification you want to limit. Note that shared object rules have a generator ID of 3 (for example, 3:1902) and standard text rules have a generator ID of 1 (for example, 1:1000062). Preprocessor events have the generator ID for the preprocessor. For more information on preprocessor GIDs and SIDs, see Reading Preprocessor Generator IDs on page 851. 5. Select the type of threshold you want to set. •

Select limit to limit notification to the specified number of event instances per time period.

•

Select threshold to provide notification for each specified number of event instances per time period.

•

Select both to provide notification once per time period after a specified number of event instances.

6. Select the appropriate radio button to indicate whether you want the event instances tracked by source or destination IP address. 7.

In the Count field, specify the number of event instances you want to use as your threshold.

8. In the Seconds field, specify the number of seconds that make up the time period for which event instances are tracked. 9. Click Add. IPS adds your threshold and displays a message indicating success. 10. Click Back to return to the Edit Policy page. Remember to apply the policy to the appropriate detection engines to put your changes into effect. For more information, see Applying an Intrusion Policy on page 764.

Viewing and Deleting Intrusion Event Thresholds Requires: IPS or DC/MDC + IPS

You may want to view or delete an existing threshold setting. For example, a Global by Destination IP threshold is configured by default. You can view the configured settings for the threshold to see if they are appropriate for your system. If they are not, you must delete the threshold configuration to replace it with a new global by destination IP threshold setting. To view or delete a threshold:


1.


2. Click Edit next to the intrusion policy for which you want to configure Thresholding options. The Edit Policy page appears.

Version 4.7


770


Chapter 21

3. Click Threshold. The Thresholds page appears. 4. In the list of configured thresholds, select the threshold that you want to view or delete. 5. To delete the threshold, click Delete. The threshold is deleted from the intrusion policy. 6. Click Save to save changes to the policy. Remember to apply the policy to the appropriate detection engines to put your changes into effect. For more information, see Applying an Intrusion Policy on page 764.

Configuring Suppression Per Intrusion Policy Requires: IPS or DC/MDC + IPS

You can suppress intrusion event notification when a specific IP address or range of IP addresses trigger a specific rule or preprocessor. This is useful for eliminating false positives. For example, if you have a mail server that transmits packets that look like a specific exploit, you can suppress event notification for that event when it is triggered by your mail server. The rule triggers for all packets, but you only see events for legitimate attacks. See the following sections for more information. •

Suppressing Intrusion Events on page 771

•

Viewing and Deleting Suppression Conditions on page 773

TIP! You can also add suppressions from within the packet view of an intrusion event. See Viewing Event Information on page 676 for more information. You can also access suppression settings by using the right-click context menu on the Rule Configuration page, on any intrusion event page (if the event was triggered by an intrusion rule), and on any of the intrusion policy pages where individual rules are listed.

Suppressing Intrusion Events Requires: IPS or DC/MDC + IPS

You can suppress intrusion event notification.


1.

To suppress event display: Select Policy & Response > IPS > Detection & Prevention. The Detection & Prevention page appears. 2. Click Edit next to the intrusion policy where you want to configure suppression options. The Edit Policy page appears.

Version 4.7


771


Chapter 21

3. Click Suppression. The Suppression page appears.

4. From the rule category folders, select the rules you want to suppress for a given source or destination IP address.

Note that standard text rules have a generator ID of 1 (for example, 1:1000062) and shared object rules have a generator ID of 3 (for example, 3:1902). You can also expand the Preprocessors folder and select the preprocessor events that you want to suppress. 5. Select one of the following Track By options: •

To suppress events generated by packets originating from a specified source IP address, select Source IP.

•

To suppress events generated by packets going to a specified destination IP address, select Destination IP.

6. In the IP address or CIDR block field, enter the IP address or CIDR block you want to specify as the source or destination IP address. 7.

Click Add. The newly defined suppression condition appears in the View/Delete Suppressions list.

8. Click Back to return to the Edit Policy page. Remember to apply the policy to the appropriate detection engines to put your changes into effect. For more information, see Applying an Intrusion Policy on page 764.

Version 4.7


772

Creating Intrusion Policies Defining IP Addresses and Ports for Your Network

Chapter 21

Viewing and Deleting Suppression Conditions Requires: IPS or DC/MDC + IPS

You may want to view or delete an existing suppression condition. For example, you might suppress event notification for packets originating from a mail server IP address because the mail server normally transmits packets that look like exploits. If you then decommission that mail server and reassign the IP address to another host, you should delete the suppression conditions for that source IP address. To view or delete a defined suppression condition:


1.


2. Click Edit next to the intrusion policy where you want to configure suppression options. The Edit Policy page appears. 3. Click Suppression. The Suppression page appears. 4. In the list of configured suppression conditions, select the suppression condition you want to view or delete.

The Track By and CIDR Block options configured for that suppression appear below the suppression condition list. 5. To delete the suppression, click Delete. IPS deletes the suppression condition you selected. 6. Click Save to save changes to the policy. Remember to apply the policy to the appropriate detection engines to put your changes into effect. For more information, see Applying an Intrusion Policy on page 764.

Defining IP Addresses and Ports for Your Network Requires: IPS or DC/MDC + IPS

Version 4.7

When tuning your system, you can define IP addresses and ports in both variables and rules. This lets you specify the level of granularity of inspection so


773


Chapter 21

that rules execute against the IP addresses and ports appropriate to your network needs. Within variables, you can define specific IP addresses for the following: •

your home network

•

the external network

•

AOL Instant Messenger (AIM) servers

•

domain name service (DNS) servers

•

HTTP servers (or Web servers)

•

SQL database servers

•

SMTP servers

•

SNMP servers

•

Telnet servers

You can define specific port numbers for the following: •

ports susceptible to shell code exploits

•

HTTP (or web server) ports

•

Oracle database server ports

For details on defining system variables, see Configuring Variables on page 778. Within standard text rules, you can specify the source and destination IP addresses and ports the rule uses to determine whether or not it executes against a packet. For more information on defining IP addresses and port values in rule headers, see Understanding Rule Headers on page 951. You can set IP addresses and definitions in a variety of ways. See the following sections for more information: •

Defining IP Addresses in Variables and Rules on page 774 describes the syntax you can use to define single IP addresses, IP address ranges and lists, and any IP address in variables and rules.

•

Defining Ports in Variables and Rules on page 777 describes the syntax you can use to define single and multiple ports in variables and rules.

Defining IP Addresses in Variables and Rules Requires: IPS or DC/MDC + IPS

Version 4.7

When configuring variables and writing standard text rules, you can specify both IP addresses and port numbers. You can specify values in a variety of ways, depending on your needs. You can enter a single IP address directly, or you can use any, IP address lists, or CIDR notation. Additionally, you can indicate that you want to exclude a specific IP address or set of IP addresses.


774


Chapter 21

See the following sections for more information on how to specify IP addresses: •

Specifying Any IP Address on page 775

•

Using CIDR Notation to Define IP Ranges on page 775

•

Excluding IP Addresses on page 776

Specifying Any IP Address Requires: IPS or DC/MDC + IPS

You can specify that the rule evaluate packets with any source IP address and any destination IP address using the argument any. For example: alert tcp any any -> any any

Within the Sourcefire 3D System web interface, you can specify this by typing the word any in the Source IP or Destination IP field.

Specifying Multiple IP Addresses Using a List Requires: IPS or DC/MDC + IPS

You can list individual IP addresses by surrounding the IP address list with brackets and separating the IP addresses with commas, as shown in the following example: [192.168.1.100,192.168.1.103,192.168.1.105]

WARNING! Make sure there are no spaces between IP addresses. You can combine an IP address list with CIDR notation to define multiple IP addresses, and can also use negation.

Using CIDR Notation to Define IP Ranges Requires: IPS or DC/MDC + IPS

You can use Classless Inter-Domain Routing (CIDR) notation to define IP address ranges. CIDR notation uses a network IP address combined with a bit mask that signifies the subnet mask to define the number of IP addresses in the specified range. For example, to define the network described by 192.168.1.0 with a subnet mask of 255.255.255.0, use 192.168.1.0/24, where 24 signifies the number of bits in the subnet mask. The CIDR Bit Mask table displays a list of subnet masks for Class C networks, with the corresponding bit mask used to signify the subnet mask. CIDR Bit Mask

Version 4.7

Bit Mask

Subnet Mask

Number of IPs

Example Syntax

/14

255.252.0.0

262,144

192.168.0.0/14

/15

255.254.0.0

131,072

192.168.0.0/15


775


Chapter 21

CIDR Bit Mask (Continued) Bit Mask

Subnet Mask

Number of IPs

Example Syntax

/16

255.255.0.0

65,536

192.168.0.0/16

/17

255.255.128.0

32,768

192.168.1.0/17

/18

255.255.192.0

16,384

192.168.1.0/18

/19

255.255.224.0

8192

192.168.1.0/19

/20

255.255.240.0

4096

192.168.1.0/20

/21

255.255.248.0

2048

192.168.1.0/21

/22

255.255.252.0

1024

192.168.1.0/22

/23

255.255.254.0

512

192.168.1.0/23

/24

255.255.255.0

256

192.168.1.0/24

/25

255.255.255.128

128

192.168.1.0/25

/26

255.255.255.192

64

192.168.1.0/26

/27

255.255.255.224

32

192.168.1.0/27

/28

255.255.255.240

16

192.168.1.0/28

Excluding IP Addresses Requires: IPS or DC/MDC + IPS

You can use an exclamation point (!) to negate a specified IP address. That is, you can match any IP address with the exception of the specified IP address or addresses. For example, !192.168.1.1 specifies any IP address other than 192.168.1.1. To negate a list of IP addresses, place ! before the bracketed list of IP addresses. For example, ![192.168.1.1,192.168.1.5] would define any IP address other than 192.168.1.1 or 192.168.1.5. Be careful when using the negation character with IP address lists. For example, if you use [!192.168.1.1,!192.168.1.5] to match any IP address that is not 192.168.1.1 or 192.168.1.5, the system interprets this syntax as “anything that is not 192.168.1.1, or anything that is not 192.168.1.5.” Because 192.168.1.5 is not 192.168.1.1, and 192.168.1.1 is not 192.168.1.5, both IP addresses match the IP address value of [!192.168.1.1,!192.168.1.5], and it is essentially the same as using “any.”

Version 4.7


776


Chapter 21

Instead, use ![192.168.1.1,192.168.1.5]. The system interprets this as “not 192.168.1.1 and not 192.168.1.5,” which matches any IP address other than those listed between brackets.

Defining Ports in Variables and Rules Requires: IPS or DC/MDC + IPS

The Sourcefire 3D System uses a specific type of syntax to define the port numbers that a variable uses. The Port Syntax for Variables and Rules table describes the syntax you can use. Port Syntax for Variables and Rules Syntax

Description

Example

any

Specifies any port.

any

port

Specifies a single port

80

first_port-last_port

Indicates a range of ports, where first_port represents the first port in the range, and last_port specifies the last port.

20-21

-port

Indicates all ports less than or equal to port.

-21

port-

Indicates all ports greater than or equal to port.

80-

!

Indicates all ports except the specified port, port list, or range of ports. Note that you can logically use negation with all port designations except any, which if negated would indicate no port.

!80

TIP! You can currently substitute a colon (:) for the hyphen (-) in any port definition, although eventually the colon will be deprecated You can list ports by surrounding the port list with brackets and separating the ports with commas, as shown in the following example: [80, 8080, 8138, 8600-9000, !8650-8675]

Note that the string PORT_ or _PORT must appear somewhere in the name of a variable when the variable contains a port list. You can, for example, include a port list in any of the predefined variables named HTTP_PORTS,

Version 4.7


777

Creating Intrusion Policies Configuring Variables

Chapter 21

SHELLCODE_PORTS, and ORACLE_PORTS, or in custom variables with names you define, such as A_PORTLIST, MY_PORTS, or PORT_LIST.

Configuring Variables Requires: IPS or DC/MDC + IPS

Variables represent values that are commonly used within intrusion rules. You can view, modify, and create variables. You can also delete variables if they are not used in any active or inactive rules. Variables are important for several reasons. The following list describes why it is important to review, modify, and even add new system variables: •

Most of the shared object rules and standard text rules that the Sourcefire 3D System provides use predefined variables to define networks and port numbers. The majority of the rules use these variables to specify the protected network ($HOME_NET) and the unprotected (or outside) network ($EXTERNAL_NET). In addition, specialized rules often use other predefined variables. For example, rules that detect exploits against web servers use the $HTTP_SERVERS and $HTTP_PORTS variables.

•

Rules are more effective when system variables more accurately reflect your network environment. By ensuring that a variable such as $HOME_NET correctly defines your entire network and $HTTP_SERVERS includes all web servers on your network, you can be sure that processing is optimized and all relevant systems are monitored for suspicious activity.

•

If you create custom standard text rules, you can use variables as shortcuts to simplify the rule creation process. For example, if you create a rule that you want to inspect traffic in the “demilitarized zone” (or DMZ) only, you can create a variable named $DMZ whose value lists the server IP addresses that are exposed. You can then use the $DMZ variable in any rule written for this zone.

•

Variables make it easier to edit pre-existing shared object rules, because values are not hard-coded in many of these. You only have to change the variable value, rather than creating your own rules. This is also effective when you have multiple policies in place, as you can maintain multiple variable definitions that are unique to each policy.


Version 4.7

•

Understanding Existing Variables on page 779 describes the default variables provided with Sourcefire 3D System and includes information about how and why to modify them.

•

Modifying Variables on page 781 explains the syntax used for IP- and port-based variables, and describes how to modify existing variables.

•

Creating New Variables on page 784 describes how to create new variables for use in rules and system configuration.


778


Chapter 21

•

Deleting Unused Variables on page 786 describes how to delete unused variables.

•

Using Variables within Detection Engines on page 110 explains how you can use detection engine-based variables to tailor your detection capabilities to more closely match your infrastructure.

Understanding Existing Variables Requires: IPS or DC/MDC + IPS

Version 4.7

The Sourcefire 3D System provides predefined variables for use within rules. You should set appropriate values for these variables to optimize system performance across your network. Variables can use values that include: •

any, to specify any value

•

specific IP addresses or ports (see Defining IP Addresses and Ports for Your Network on page 773 for more information about acceptable syntax for IP addresses and ports in variables)

•

other variables

•

a negation of any of the above (excluding any), using !


779


Chapter 21

The Variable Descriptions table describes the predefined variables. Variable Descriptions Variable Name

Description

Default Value

Modify?

$AIM_SERVERS

Defines known AOL Instant Messenger (AIM) servers, and is used in chat-based rules and rules that look for AIM exploits.

[64.12.31.136 32, 64.12.46.140/32, 64.12.186.85/32, 205.188.1.132/32, 205.188.11.228/32, 205.188.11.253/32, 205.188.11.254/32, 205.188.210.203/32 , 64.12.24.0/23, 64.12.28.0/23, 64.12.161.0/24, 64.12.163.0/24, 64.12.200.0/24, 205.188.3.0/24, 205.188.5.0/24, 205.188.7.0/24, 205.188.9.0/24, 205.188.153.0/24, 205.188.179.0/24, 205.188.248.0/24]

Not required

$DNS_SERVERS

Defines Domain Name Service (DNS) servers. If you create a rule that affects DNS servers specifically, you can use the $DNS_SERVERS variable as a destination or source IP.

$HOME_NET

Not required in current rule set

$EXTERNAL_NET

Defines the network that the Sourcefire 3D System views as the unprotected network, and is used in many rules to define the external network.

any

Yes, you should adequately define $HOME_NET and then use !$HOME_NET as the value for $EXTERNAL_NET

$HOME_NET

Defines the network that the active policy monitors, and is used in many rules to define the internal network.

any

Yes, to include the IP address range for your internal network

$HTTP_PORTS

Defines the ports of Web servers on your network, and is used for Web server exploit rules.

80

Yes, if your Web servers use ports other than 80

Version 4.7


780


Chapter 21

Variable Descriptions (Continued) Variable Name

Description

Default Value

Modify?

$HTTP_SERVERS

Defines the Web servers on your network. Used in Web server exploit rules.

$HOME_NET

Yes, if you run HTTP servers

$ORACLE_PORTS

Defines Oracle database server ports on your network, and is used in rules that scan for attacks on Oracle databases.

1521

Yes, if your Oracle servers use ports other than 1521

$SHELLCODE_PORTS

Defines the ports you want the system to scan for shell code exploits, and is used in rules that detect exploits that use shell code.

!80

Not required

$SMTP_SERVERS

Defines SMTP servers on your network, and is used in rules that address exploits that target mail servers.

$HOME_NET

Yes, if you run SMTP servers

$SNMP_SERVERS

Defines SNMP servers on your network, and is used in rules that scan for attacks on SNMP servers.

$HOME_NET

Yes, if you run SNMP servers

$SQL_SERVERS

Defines database servers on your network, and is used in rules that address database-targeted exploits.

$HOME_NET

Yes, if you run SQL servers

$TELNET_SERVERS

Defines known Telnet servers on your network, and is used in rules that address Telnet server-targeted exploits.

$HOME_NET

Yes, if you run Telnet servers

Modifying Variables Requires: IPS or DC/MDC + IPS

Version 4.7

Modifying variables is an essential step in tuning your intrusion policy. By customizing preconfigured variables to closely match your network configuration, you can optimize system performance and ensure that the system evaluates relevant network traffic.


781


Chapter 21

You can also modify variables that you create. For information on creating variables, see Creating New Variables on page 784 and Creating New Variables for Detection Engines on page 112. IMPORTANT! For more information about pre-configured variables and what they are used for, see Understanding Existing Variables on page 779. To modify an existing system variable: Access: Rules or Admin

1.


2. Click Edit next to the policy you want to edit. The Edit Policy page appears, including a list of pages (called sections) that you can use to modify different parts of the intrusion policy.

Version 4.7


782


Chapter 21

3. Click Variables. The Variable List page appears.

4. Click Edit next to the variable you want to modify. The Variable page appears.

5. Type the new value for the variable in the Variable Binding field: •

If you are modifying an IP-based variable, use the syntax described in Defining IP Addresses in Variables and Rules on page 774.

•

If you are modifying a port-based variable, use the syntax described in Defining Ports in Variables and Rules on page 777.

TIP! For a description of each predefined variable, see the Variable Descriptions table on page 780. 6. Click Save. The variable value changes.

Version 4.7


783


7.

Chapter 21

To put the changes you made into effect, apply or re-apply the intrusion policy to the appropriate detection engines as described in Applying an Intrusion Policy on page 764.

Creating New Variables Requires: IPS or DC/MDC + IPS

If you create your own Sourcefire 3D System rules, you can also create new variables to use within the rules. Variables can be policy-specific or detection engine-specific, but creating a variable in an intrusion policy or detection engine also adds the same variable to all other intrusion policies with the value set to any, and to all other detection engines with the value set to Policy Defined, which means that the value specified in the policy will be used when you apply the policy. Optionally, you can modify the variable in the intrusion policies and detection engines where it is added automatically to give it a specific definition. A variable defined in the detection engine takes precedence over a definition in the intrusion policy. If you disable the variable definition in the detection engine by resetting the variable, the definition reverts to the definition in the intrusion policy the next time you apply the policy. Variables use the same syntax and must follow the same guidelines regardless of whether you create or define them in intrusion policies or detection engines. Note that nested, negated variables are not supported. For example, if you want to create a variable, NONCORE_NET, that represents the IP addresses that are outside of your protected networks, you could not create it using the following procedure: 1.

Define HOME_NET as [10.1.0.0/16,10.2.0.0/16,10.3.0.0/16].

2. Define EXTERNAL_NET as !$HOME_NET. 3. Create a new variable called DMZ_NET and define it as 10.4.0.0/16. 4. Create a new variable called NOTDMZ_NET and define it as !$DMZ_NET. 5. Create the NONCORE_NET variable and define it as [$EXTERNAL_NET,$NOTDMZ_NET]. Instead, create NONCORE_NET as follows: 1.

Define HOME_NET as [10.1.0.0/16,10.2.0.0/16,10.3.0.0/16].

2. Create a new variable called DMZ_NET and define it as 10.4.0.0/16.

Version 4.7


784


Chapter 21

3. Create a new variable called NONCORE_NET and define it as ![$HOME_NET,$DMZ_NET]. IMPORTANT! When you create a new variable, the variable is added to all intrusion policies. However, you need to set the value for the variable in each policy. For example, suppose you create a custom variable, set the value to 80,8080 and use it in a rule enabled in one of your custom policies. If you then decide to use the variable in a rule in another policy, you have to set the value to 80,8080 in the second policy as well. In any intrusion policy where you do not explicitly set the value for the variable, the value is set to any. To create a new variable: Access: Rules or Admin

1.


2. Click Edit next to the policy you want to edit. The Edit Policy page appears. 3. Click Variables. The Variable List page appears. 4. Click Add Variable. The Variable page appears.

5. In the Variable Name field, enter a name for the new variable. For example, if you are creating a variable that defines all Apache Web servers on your network, you might decide to name the variable APACHE_SERVERS. TIP! The Variable Name box accepts only alphanumeric characters and underscores. Variable names cannot contain spaces or punctuation characters. In addition, the system automatically precedes each variable name with a dollar sign ($), and you receive an error if you use $ in a variable name.

Version 4.7


785


Chapter 21

6. Enter a value for the new variable in the Variable Binding field. •

If the new variable describes IP addresses, see Defining IP Addresses in Variables and Rules on page 774 for information about the syntax you can use.

•

If the new variable describes port numbers, see Defining Ports in Variables and Rules on page 777 for information about the syntax you can use.

•

If the new variable is another variable or negation of a variable, enter it in the value field (for example, $HOME_NET or !$HOME_NET).

IMPORTANT! A variable can include up to 8192 characters. Keep in mind, however, that this limit applies to the size of the expanded value of the variable. If you use one or more variables to define another variable, the total number of characters and spaces of all the variable values cannot exceed 8192 characters. 7.

Click Save. The variable is created and added to all policies and detection engines. IMPORTANT! Variable values can be policy-specific or detection engine-specific, but each new variable is added to all your intrusion policies and IPS detection engines. In any intrusion policy where you do not explicitly set the value for your custom variable, the value is set to any. In any detection engine where you do not explicitly set the value for your custom variable, the value is set to Policy Defined, which means that the value specified in the policy will be used when you apply the policy.

8. To put the changes you made into effect, apply or re-apply the intrusion policy to the appropriate detection engines as described in Applying an Intrusion Policy on page 764.

Deleting Unused Variables Requires: IPS or DC/MDC + IPS

If a variable is not used in any active or inactive rule, you can delete it. You can also delete pre-configured variables, but only if they are not used in any active or inactive rule within the system. You cannot delete variables that are used in any rule, regardless of whether the rule is set to Enable, Disable, or Drop. If you attempt to delete variables that are in use, an error message appears and the variable is not deleted. To delete a variable:


Version 4.7

1.



786

Creating Intrusion Policies Configuring Non-Standard Intrusion Policy Features

Chapter 21

2. Click Edit next to the policy you want to edit. The Edit Policy page appears. 3. Click Variables. The Variable List page appears. 4. Click Delete next to the variable that you want to delete. The variable is deleted. 5. To put the changes you made into effect, apply or re-apply the intrusion policy to the appropriate detection engines as described in Applying an Intrusion Policy on page 764.

Configuring Non-Standard Intrusion Policy Features Requires: IPS or DC/MDC + IPS

You can use a variable with the reserved name USER_CONF to configure features not otherwise available via the web interface. WARNING! Do not use the reserved variable USER_CONF to configure an IPS feature unless you are instructed to do so in the feature description or by Sourcefire Support. Conflicting or duplicate configurations will halt IPS. When you apply an intrusion policy, IPS stores the configuration settings in the policy on the sensor in a file named snort.conf. IPS then implements the settings in snort.conf and, if they exist, the settings in USER_CONF. If USER_CONF does not exist, IPS implements any settings in the file user.conf. You can create USER_CONF with a Version 4.7 or later Defense Center or 3D Sensor with IPS. You cannot create USER_CONF with an earlier version. You can, however, create a policy that includes USER_CONF on a Version 4.7 Defense Center and apply the policy to a Version 4.6.x 3D Sensor with IPS that the Defense Center manages. You can create USER_CONF as an intrusion policy variable or as an IPS detection engine variable. Creating it using either method adds a disabled copy of USER_CONF to all other intrusion policies and IPS detection engines on the appliance where you created it. Optionally, you can define USER_CONF in each intrusion policy or detection engine by adding specific feature configurations. Regardless of whether you create or define USER_CONF in an intrusion policy or detection engine, IPS recognizes only one definition of USER_CONF for each detection engine, and that definition takes effect when you apply an intrusion policy to the detection engine. As with other variables, a definition of USER_CONF in the detection engine takes precedence over a USER_CONF definition in the intrusion policy. If you disable USER_CONF in a detection engine by resetting it, the definition of USER_CONF reverts to the definition in the intrusion policy the next

Version 4.7


787

Creating Intrusion Policies Configuring Non-Standard Intrusion Policy Features

Chapter 21

time you apply the policy. For more information on detection engine variables, see Configuring Non-Standard Detection Engine Features on page 121. IMPORTANT! In a policy-defined variable, any might mean, for example, any port or any address, but any disables USER_CONF. You can include any number of valid directives or lines and configure any number of features in USER_CONF until you reach a physical limit such as disk space. You can modify USER_CONF to remove or add directives as needed. The syntax for each directive is provided in the feature description or by Sourcefire Support. WARNING! Deleting USER_CONF from any intrusion policy or detection engine deletes it from all intrusion policies and detection engines. You can disable a single USER_CONF variable by setting it to any within an individual intrusion policy, or by resetting it in the detection engine. To create the USER_CONF variable in an intrusion policy: Access: Rules or Admin

1.


2. Click Edit next to the policy where you want to add the variable. The Edit Policy page appears. 3. Click Variables. The Variable List page appears. 4. Click Add Variable. The Variable page appears.

5. Enter USER_CONF in the Variable Name field. The system automatically precedes each variable name with a dollar sign ($), and you receive an error if you use $ in a variable name.

Version 4.7


788

Creating Intrusion Policies Configuring Rule States

Chapter 21

6. In the Variable Binding field, enter the configuration directives provided by Sourcefire Support or in the feature description. You can type up to 4096 total characters on a single line; the line wraps automatically. You can also use the backslash (\) line continuation character after any complete argument in the command directive. Click Save.

7.

The USER_CONF variable definition is added to the intrusion policy you are editing, and a disabled USER_CONF variable added to all other intrusion policies and IPS detection engines. The variable takes effect the next time you apply the policy as described in Applying an Intrusion Policy on page 764. IMPORTANT! Variable values can be policy-specific or detection engine-specific, but each new variable is added to all your intrusion policies and IPS detection engines. In any intrusion policy where you do not explicitly set the value for your custom variable, the value is set to any. In any detection engine where you do not explicitly set the value for your custom variable, the value is set to Policy Defined, which means that the value specified in the policy will be used when you apply the policy.

Configuring Rule States Requires: IPS or DC/MDC + IPS

You can edit, enable, and disable rules in intrusion policies. Enabling a rule causes the rules engine to alert on traffic matching the rule. Disabling a rule stops processing of the rule. For inline intrusion policies you can set the rule state to Drop. A rule with a Drop state alerts on and drops matching traffic. Requires: DC + IPS + RNA You can also permanently accept recommended rule states that you have accepted on the RNA Recommended Rules page. For more information, see Using RNA Recommended Rules on page 811. See the following sections for more information: •

Understanding Rule Categories on page 789 describes each rule category that appears on the Rule State page and explains the types of rules that reside within each category.

•

Enabling and Disabling Intrusion Rules on page 794 describes how to activate rule categories and individual rules from the Rule State page.

Note that shared object rules and standard text rules appear on the Rule State page.

Understanding Rule Categories Requires: IPS or DC/MDC + IPS

Version 4.7

Sourcefire 3D System places rules in categories based on the type of traffic the rule detects. On the Rule State page, you can deactivate or activate rules


789


Chapter 21

individually, or by rule category. For example, if you do not have any IIS web servers on your network, you might deactivate the entire Web IIS category instead of deactivating individual rules within the category. IMPORTANT! The Sourcefire VRT may use the Security Enhancement Update (SEU) mechanism to add new rule categories. The Rule Categories table lists each rule category and describes the types of events the rules in that category detect. Rule Categories Rule Category

Contents

Attack Responses

Rules that detect common attack responses.

Backdoor

Rules that detect backdoor-type exploits and activity.

Bad Traffic

Rules that detect anomalous traffic.

Chat

Rules that detect the use of unauthorized instant messaging programs.

Content Replace

Rules that use the replace keyword to neutralize attacks but not drop them in inline deployments, and to stop instant messaging and peer-to peer file transfers without adversely affecting the other allowed functionality of these applications.

Distributed Denial of Service (DDoS)

Rules that detect Distributed Denial of Service (DDoS) attacks.

Deleted

Deleted rules that have not yet been removed from the product. These rules exist for historical purposes.

DNS

Rules that detect DNS-based exploits.

Denial of Service (DoS)

Rules that detect Denial of Service (DoS) attacks.

Exploit

Rules that detect known exploits.

Finger

Rules that detect finger-based exploits.

FTP

Rules that detect FTP-based exploits.

ICMP

Rules that detect ICMP-based exploits.

ICMP Info

Rules that detect exploits that use ICMP information requests.

Version 4.7


790


Chapter 21

Rule Categories (Continued) Rule Category

Contents

IMAP

Rules that detect IMAP-based exploits.

Info

Rules that detect possible reconnaissance activity.

Local

Custom rules that you have created. The Local category only appears if custom rules exist. See Writing New Rules on page 1008 for more information about creating custom rules.

Misc

Miscellaneous rules that do not fall under other categories.

Multimedia

Rules that detect the use of authorized multimedia applications.

MySQL

Rules that detect exploits that target MySQL database servers.

Netbios

Rules that detect NETBIOS/SMB-based exploits.

NNTP

Rules that detect NNTP-based exploits.

Oracle

Rules that detect exploits that target Oracle database servers and ports.

Other IDS

Rules that detect connections from other intrusion systems.

(P2P) Peer to Peer

Rules that detect the use of unauthorized peer-to-peer downloading applications.

Policy

Rules that detect miscellaneous suspicious activity.

POP2

Rules that detect POP2-based exploits.

POP3

Rules that detect POP3-based exploits.

RPC

Rules that detect RPC-based exploits.

Rservices

Rules that detect UNIX or Linux-based remote services (rlogin, rsh) login exploits.

Scan

Rules that generate events when scanning activity is detected.

Shellcode

Rules that detect shell code.

SMTP

Rules that detect exploits that target mail servers.

SNMP

Rules that detect SNMP-based exploits.

Version 4.7


791


Chapter 21

Rule Categories (Continued) Rule Category

Contents

Specific Threats

Rules that alert on high-profile network threats that have widely recognized names such “sasser” and “netsky”.

Spyware- PUT

Rules that detect attempts to infect hosts with spyware, key loggers, trojans, and other potential unwanted technology (PUT). These rules also detect hosts that are already infected. IMPORTANT! You should read the rule documentation accompanying these rules because many are resource-intensive and can produce performance problems.

SQL

Rules that detect attacks on Microsoft SQL Servers.

Telnet

Rules that detect exploits that target or originate from telnet servers.

TFTP

Rules that detect TFTP-based exploits.

VoIP

Rules targeted at detection of threats in Voice Over IP traffic.

Virus

Rules that detect known worms and viruses.

Web CGI

Rules that detect attacks that exploit CGI scripts.

Web Client

Rules that detect suspicious traffic sent to or from Web servers.

Web Coldfusion

Rules that detect attacks that exploit Cold Fusion scripts.

Web Frontpage

Rules that detect attacks that exploit FrontPage scripts.

Web IIS

Rules that detect attacks against IIS Web servers.

Web Misc

Rules that detect miscellaneous exploits targeting Web servers.

Web PHP

Rules that detect attacks that exploit PHP scripts.

X11

Rules that detect X11-based exploits.

Understanding Rule Groups Requires: IPS or DC/MDC + IPS

Version 4.7

IPS offers additional filters, called rule groups, to help you find the rules you want to activate or deactivate. The same rule may appear in more than one group. For example, the DOS Cisco attempt rule (SID 1545) appears in the DOS category if


792


Chapter 21

rules are grouped by category and under High priority if the rules are grouped by priority. IMPORTANT! groups.

The Sourcefire VRT may use the SEU mechanism to add new rule

You can select how rules are grouped. Some rule groups contain smaller sub-groups so that you can more easily find the specific rules you are looking for. Some of the rule groups have multiple levels that you expand to drill down to individual rules. Note that the rules on the Rule State page may be either shared object rules (generator ID 3) or standard text rules (generator ID 1). The Rule Groups table describes the different rule groups: Rule Groups Group

Description

Accepted Recommendations

Requires: DC + IPS + RNA Groups rules on the Rule State page according to accepted activations and accepted deactivations. Note that these groups include recommendations that have been accepted at the RNA Recommended Rule page but have not been permanently accepted at the Rule State page. For example, if no recommendations have been accepted at the RNA Recommended Rule page, or all recommendations have been permanently accepted at the Rule State page, these groups will be empty.

Category

Groups rules according to the rule categories used by the rule editor. Note that local rules appear in the Local sub-group.

Microsoft Vulnerabilities

Groups rules according to Microsoft bulletin number.

Microsoft Worms

Contains sub-groups based on specific worms that affect Microsoft Windows hosts.

Platform Specific

Groups rules according to their relevance to specific versions of operating systems. Note that a rule may affect more than one operating system or more than one version of an operating system. For example, enabling SID 2260 affects multiple versions of Mac OS X, IBM AIX, and other operating systems.

Version 4.7


793


Chapter 21

Rule Groups (Continued) Group

Description

Priority

Groups rules according to high, medium, and low priorities. The classification assigned to a rule determines its priority. These groups are further grouped into rule categories. Note that local rules (that is, rules that you create) do not appear in the priority groups.

SANS Top 20

Groups rules according to the top 20 Internet security vulnerabilities as determined by a consensus of security experts on behalf of the SANS Institute. There are two versions of the SANS Top 20 group: version 5.0 and version 6.01. These rules are further divided into version-specific sub-groups.

Suggested Inline Rules

Shows rules that are likely to improve the security of your network without causing false positives when used in inline mode. These rules are further grouped by priority.

Enabling and Disabling Intrusion Rules Requires: IPS or DC/MDC + IPS

You can enable or disable rules individually or for entire categories. Note that this section discusses rule states for rules within passive intrusion policies. For information about setting rule state for inline intrusion policies, see Using the Drop Rule State on page 798. TIP! For information about the types of rules that reside within each category, see Understanding Rule Categories on page 789. Requires: DC +IPS + RNA You can permanently accept recommended rule states for individual rules or entire categories. The system treats permanently accepted rule states the same way it treats rule states you set manually. See Using RNA Recommended Rules on page 811 for more information. To change the rule state for one or more rules:


1.


2. Click Edit next to the policy you want to edit. The Edit Policy page appears.

Version 4.7


794


Chapter 21

3. Click Rule State. The Rule State page appears. By default, the page lists the rules by category, indicating the total number of rules and the number of enabled rules in each category. Note that for any grouping method, the total at the top of the list indicates the number of unique rules. Because a rule can appear in more than one sub-group, the combined total for all sub-groups can exceed the total number of unique rules.

Version 4.7


795


Chapter 21

4. Optionally, select a different grouping method from the Group Rules By list and, at the prompt, confirm that you have saved any changes that you want to make to the rule state. See the Rule Groups table on page 793 for information about the rule groups. For example, select Microsoft Worms to display the sub-groups for the Microsoft Worms grouping method.

Version 4.7


796


Chapter 21

5. Optionally, click the folder next to a group that you want to expand. TIP! Some of the folders contain thousands of rules and may take a significant amount of time to open. During this time, if your web browser displays a message that a script has become unresponsive, make sure you allow the script to continue until it finishes. The folder expands to show the rules in that group. Note that some rule groups have sub-groups that you can also expand. Enabled rules appear in normal text with a green bullet. Disabled rules appear in italic gray text with a red bullet. Requires: DC +IPS + RNA A status icon ( ) appears next to a rule whose current state is the result of accepting a recommendation made by the RNA Recommended Rules feature. The status icon disappears when you permanently accept the recommended state, as described in step 6. For information on accepting RNA recommended rule states, see Accepting Rule State Recommendations on page 819.

6. You have the following options:

Version 4.7

•

To change the state for an entire group, select the Disable or Enable check box next to the name of the folder.

•

To change the state for an individual rule, select Disable or Enable next to the individual rule.


797


Chapter 21

•

Requires: DC +IPS + RNA To permanently accept the recommended state for an entire group and remove the acceptance check box, select the Accept Recommendations check box next to the name of the group.

•

Requires: DC +IPS + RNA To permanently accept the recommended state for an individual rule and remove the acceptance check box, select the Accept check box next to the rule.

•

To disable any enabled rules that are not included in the current grouping method, select the Disable the x enabled out of y rules not shown checkbox. In the checkbox name, x is the number of enabled rules that are not included in the current grouping method, and y is the total number of enabled and disabled rules not included. This checkbox appears when a grouping method does not include all rules.

TIP! The total number of rules in a grouping method, plus the total number of rules not shown, plus the total number of rules in the deleted category on the Rules page equals the current total number of all rules in the rule database. Note that the deleted category is not included on the Rule State page. See the Rule Categories table on page 790 for more information. 7.

Click Save. The rule states are updated. To put the changes you made into effect, apply the intrusion policy to the appropriate detection engines as described in Applying an Intrusion Policy on page 764.

Using the Drop Rule State Requires: IPS or DC/MDC + IPS

If you assign inline or inline with fail open interface sets to your IPS detection engines, you can take advantage of inline intrusion policies that feature drop rules. A drop rule is another name for an intrusion rule whose rule state is set to Drop rather than Enable or Disable. Consider these two scenarios. In the first scenario, the rule state for a specific intrusion rule is set to Enable. When a malicious packet crosses your network and triggers the rule, the packet is sent to its destination and IPS generates an intrusion event. In the second scenario, assume that the rule state for the same rule is set to Drop. In this case, when the malicious packet crosses the network, IPS drops the malicious packet and generates an intrusion event. The packet never reaches its target. IMPORTANT! For drop rules, like alert or pass rules, you must add the flow keyword with an Established argument to any rules that should ignore traffic that does not have an established state.

Version 4.7


798


Chapter 21

To use drop rules, you must: 1.

Assign an inline or inline with fail open interface set to an inline IPS detection engine.

2. Create an inline intrusion policy. 3. Set the rule state to Drop for any intrusion rules that should drop all packets that match the rule. 4. Apply the inline policy to your inline detection engine. The rule groups on the Rule State page can help you find the rules you want to set as drop rules. For more information, see Understanding Rule Groups on page 792. In an inline intrusion policy, an intrusion rule can have one of three states: •

Set the rule state to Enable if you want IPS to detect a specific intrusion attempt and generate an intrusion event when it finds matching traffic.

•

Set the rule state to Drop if you want IPS to detect a specific intrusion attempt, drop the packet containing the attack, and generate an intrusion event when it finds matching traffic.

•

Set the rule state to Disable if you do not want IPS to evaluate matching traffic.

Requires: DC +IPS + RNA You can permanently accept rule states recommended by the RNA Recommended Rules feature for individual rules or entire categories. The system treats rules states you permanently accept the same way it treats rule states you set manually. See Using RNA Recommended Rules on page 811 for more information. To set the rule state to Drop: Access: Rules or Admin

1.


2. You can open a new or existing policy to edit the rule state setting: •

To create a new policy with the rule state set to Drop for rules in the policy, click Create Policy. Type a name and description for the policy. Select Inline for the policy mode and click Save.

•

To set the rule state to Drop for rules in an existing policy, click Edit next to the inline policy you want to edit.

The Edit Policy page appears.

Version 4.7


799


Chapter 21

3. Click Rule State. The Rule State page appears. Initially, the rules are grouped by rule category. By default, the page lists the rules by category, indicating the total number of rules and the number of enabled rules in each category. Note that for any grouping method, the total at the top of the list indicates the number of unique rules. Because a rule can appear in more than one sub-group, the combined total for all sub-groups can exceed the total number of unique rules.

Version 4.7


800


Chapter 21

4. Optionally, select a different grouping method from the Group Rules By list and, at the prompt, confirm that you have saved any changes that you want to make to the rule state. See the Rule Groups table on page 793 for information about the rule groups. For example, select Microsoft Worms to display the sub-groups for the Microsoft Worms grouping method.

Version 4.7


801


Chapter 21

5. Click the folder next to the group that you want to expand. The folder expands to show the rules in that group. Note that some rule groups have sub-groups that you can also expand. Drop rules appear in normal text with a black bullet. Enabled rules appear in normal text with a green bullet. Disabled rules appear in italic gray text with a red bullet. Requires: DC +IPS + RNA A status icon ( ) appears next to a rule whose current state is the result of accepting the state recommended by the RNA Recommended Rules feature. The status icon disappears when you permanently accept the recommended state, as described in step 6. For information on accepting RNA recommended rule states, see Accepting Rule State Recommendations on page 819.

6. You have the following options:

Version 4.7

•

To change the state for an entire group, select the Disable, Enable, or Drop check box next to the name of the group.

•

To change the state for an individual rule, select the Disable, Enable, or Drop check box next to the individual rule.


802

Creating Intrusion Policies Using Latency Thresholding

Chapter 21

•

Requires: DC +IPS + RNA To permanently accept the recommended states for an entire group and remove the acceptance check box, select the Accept Recommendations check box next to the name of the group.

•

Requires: DC +IPS + RNA To permanently accept the recommended state for an individual rule and remove the acceptance check box, select the Accept check box next to the rule.

•

To disable any enabled rules that are not included in the current grouping method, select the Disable the x enabled out of y rules not shown checkbox. In the checkbox name, x is the number of enabled rules that are not included in the current grouping method, and y is the total number of enabled and disabled rules not included. This checkbox appears when a grouping method does not include all rules.

TIP! The total number of rules in a grouping method, plus the total number of rules not shown, plus the total number of rules in the deleted category on the Rules page equals the current total number of all rules in the rule database. Note that the deleted category is not included on the Rule State page. See the Rule Categories table on page 790 for more information. Click Save.

7.

The rule state for the policy is saved. To put the changes you made into effect, apply the intrusion policy to the appropriate detection engines as described in Applying an Intrusion Policy on page 764.

Using Latency Thresholding Requires: IPS or DC/MDC + IPS

You can use packet latency thresholding and rule latency thresholding to balance security with the need to maintain sensor latency at an acceptable level by enabling either or both of the following latency thresholding features: •

Packet latency thresholding measures the total elapsed time taken to process a packet by applicable decoders, preprocessors, and rules, and ceases inspection of the packet if the processing time exceeds a configurable threshold.

•

Rule latency thresholding measures the elapsed time each rule takes to process an individual packet, suspends a rule for a specified time if the processing time exceeds the rule latency threshold a configurable consecutive number of times, and restores the rule when the suspension expires.

Packet and rule latency thresholding measure elapsed time, not just processing time, in order to more accurately reflect the actual time required for the rule to

Version 4.7


803


Chapter 21

process a packet. However, latency thresholding is a software-based latency implementation that does not enforce strict timing Packet and rule latency thresholding operate independently. You can enable neither, either, or both. The trade-off for the performance and latency benefits derived from latency thresholding is that uninspected packets could contain attacks. However, the packet and rule latency thresholding features give you tools you can use to balance security with connectivity. See the following sections for more information: •

Adjusting Latency Thresholds for Your Network on page 804

•

Understanding Packet Latency Thresholdng on page 804

•

Understanding Rule Latency Thresholdng on page 807

•

Configuring Latency Thresholding on page 810

Adjusting Latency Thresholds for Your Network Requires: IPS or DC/MDC + IPS

Many factors affect measurements of system performance and packet latency, such as CPU speed, data rate, packet size, and protocol type. For this reason, Sourcefire recommends that, if you enable latency thresholding, you use the threshold settings in the Minimum Packet Latency Threshold Settings table on page 806 and the Minimum Rule Latency Threshold Settings table on page 810 until your own calculations provide you with settings tailored to your particular network environment. Determine the following when calculating your settings: •

average packets per second

•

average microseconds per packet

Multiply the average microseconds per packet for your network by a significant safety factor to ensure that you do not unnecessarily suspend rules or discontinue packet inspections. For example, the Minimum Packet Latency Threshold Settings table on page 806 recommends a minimum packet latency threshold of 100 microseconds in a one gigabit environment. This minimum recommendation is based on test data showing an average of 250,000 packets per second, which is 0.25 packets per microsecond or, said differently, 4 microseconds per packet. Multiplying by a factor of twenty-five results in a recommended minimum threshold of 100 microseconds.

Understanding Packet Latency Thresholdng Requires: IPS or DC/MDC + IPS

Version 4.7

When you enable packet latency thresholding, a timer starts for each packet when decoder processing begins. Timing continues either until all processing


804


Chapter 21

ends for the packet or until the processing time exceeds the threshold at a timing test point.

As illustrated in the above figure, packet latency timing is tested at the following test points: •

after the completion of all decoder and preprocessor processing and before rule processing begins

•

after processing by each rule

If the processing time exceeds the threshold at any test point, packet inspection ceases. TIP! Total packet processing time does not include routine TCP stream or IP fragment reassembly times. Packet latency thresholding has no effect on events triggered by a decoder, preprocessor, or rule processing the packet. Any applicable decoder, preprocessor, or rule triggers normally until a packet is fully processed, or until packet processing ends because the latency threshold is exceeded, whichever comes first. If a drop rule detects an intrusion, the drop rule triggers an event and the packet is dropped. IMPORTANT! No rules are evaluated against a packet after processing for that packet ceases because of a packet latency threshold violation. A rule that would have triggered an event cannot trigger that event, and for drop rules, cannot drop the packet. For more information on drop rules, see Using the Drop Rule State on page 798.

Version 4.7


805


Chapter 21

The Benefits of Packet Latency Thresholding Requires: IPS or DC/MDC + IPS

Packet latency thresholding can improve system performance in both passive and inline deployments, and can reduce latency in inline deployments, by stopping inspection of packets that require excessive processing time. These performance benefits might occur when, for example: •

for both passive and inline deployments, sequential inspection of a packet by multiple rules requires an excessive amount of time

•

for inline deployments, a period of poor network performance, such as when someone downloads an extremely large file, slows packet processing

In a passive deployment, stopping the processing of packets might not contribute to restoring network performance since processing simply moves to the next packet.

Setting Packet Latency Thresholding Options Requires: IPS or DC/MDC + IPS

The Packet Latency Thresholding Options table describes the options you can set to configure packet latency thresholding. Packet Latency Thresholding Options Option

Description

Packet Latency Thresholding

Enables or disables dropping a packet when inspection of the packet exceeds the time specified by Threshold.

Threshold

Specifies the time in microseconds when inspection of a packet ceases. See Minimum Packet Latency Threshold Settings on page 806 for recommended minimum threshold settings.

Because of the uncertainties inherent in measuring latency, Sourcefire recommends that you use the settings in the Minimum Packet Latency Threshold Settings table until your calculations provide settings more suitable for your network. Minimum Packet Latency Threshold Settings

Version 4.7

For this data rate...

Set threshold microseconds to at least...

1 Gbps

100

100 Mbps

250

5 Mbps

1000


806


Chapter 21

Understanding Rule Latency Thresholdng Requires: IPS or DC/MDC + IPS

When you enable rule latency thresholding, a timer measures the processing time each time the rule processes a packet. Any time the rule processing time exceeds a specified rule latency threshold, IPS increments a counter. If the number of consecutive threshold violations reaches a specified number that must occur before the rule is suspended, IPS takes the following actions: •

suspends the rule for the specified period

•

triggers an event indicating the rule has been suspended

•

re-enables the rule when the suspension expires

•

triggers an event indicating the rule has been re-enabled

IPS zeroes the counter when the rule is suspended, or when rule violations are not consecutive. Permitting some consecutive violations before suspending a rule lets you ignore occasional rule violations that might have negligible impact on performance and focus instead on the more significant impact of rules that repeatedly exceed the rule latency threshold. The example in the following illustration shows five consecutive rule processing times that do not result in suspension of the rule processing the packets.

In the above example, the time required to process each of the first three packets violates the rule latency threshold of 1000 microseconds, and the violations counter increments with each violation. Processing of the fourth packet does not violate the threshold, and the violations counter resets to zero. The fifth packet violates the threshold and the violations counter restarts at one.

Version 4.7


807


Chapter 21

The example in the following illustration shows five consecutive rule processing times that do result in suspension of the rule processing the packets.

In the second example, the time required to process each of the five packets violates the rule latency threshold of 1000 microseconds. The rule is suspended because the rule processing time of 1100 microseconds for each packet violates the threshold of 1000 microseconds for the specified five consecutive violations. The suspended rule does not examine any subsequent packets, represented in the figure as packets 6 and n, if they occur, until the suspension expires. If the rule examines more packets after being re-enabled, the violations counter begins again at zero. You can easily identify events triggered when IPS suspends or re-enables rules because IPS modifies the rule generator ID (GID) in intrusion event table views. An event for a suspended standard text rule uses a GID of 1001 (1000 plus the normal GID of 1 for a standard text rule) and the same Signature ID (SID) as the rule. An event for a re-enabled standard text rule uses a GID of 2001 and the same SID. A event triggered, for example, when a standard text rule with the GID:SID combination of 1:3741 would use the GID:SID 1001:3741, and an event triggered with the rule is re-enabled would use 2001:3741. An event for a suspended shared object rule uses a GID of 1003 (1000 plus the normal GID of 3 for a shared object rule) and the same SID as the rule. An event re-enabling the rule uses a GID of 2003 and the same SID as the rule. A suspension event for a shared object rule with the GID:SID combination of 3:3725, for example, uses the GID:SID 1003:3725, and the event re-enabling the rule uses 2003:3725. Rule latency thresholding has no effect on intrusion events triggered by the rule processing the packet. The rule triggers an event for any intrusion detected in the packet, regardless of whether the rule processing time exceeds the threshold. If the rule detecting the intrusion is a drop rule, the packet is dropped. When a drop rule detects an intrusion in a packet that results in the rule being suspended, the drop rule triggers an intrusion event, the packet is dropped, and the rule is

Version 4.7


808


Chapter 21

suspended. For more information on drop rules, see Using the Drop Rule State on page 798. IMPORTANT! Suspended rules are not evaluated against packets. A suspended rule that would have triggered an event cannot trigger that event, and for drop rules, cannot drop the packet.

The Benefits of Rule Latency Thresholding Requires: IPS or DC/MDC + IPS

Rule latency thresholding can improve system performance in both passive and inline deployments, and can reduce latency in inline deployments, by suspending rules that take the most time to process packets. A suspended rule does not process packets again until a configurable time expires, giving the overloaded sensor time to recover. These performance benefits might occur when, for example: •

a hastily written, largely untested rule created by someone other than the Sourcefire Vulnerability Research Team (VRT) requires an excessive amount of time to process a packet

•

a period of poor network performance, such as when someone downloads an extremely large file, causes slow packet inspection by any rule, whether written by the VRT or someone else

Setting Rule Latency Thresholding Options Requires: IPS or DC/MDC + IPS

The Rule Latency Thresholding Options table describes the options you can set to configure rule latency thresholding. Rule Latency Thresholding Options

Version 4.7

Option

Description

Rule Latency Thresholding

Enables or disables suspending a rule for the time specified by Suspension Time when the time the rule takes to process a packet exceeds Threshold for the consecutive number of times specified by Consecutive Threshold Violations Before Suspending Rule.

Threshold

Specifies the time in microseconds that a rule should not exceed when examining a packet. See Minimum Rule Latency Threshold Settings on page 810 for recommended minimum threshold settings.


809


Chapter 21

Rule Latency Thresholding Options Option

Description

Consecutive Threshold Violations Before Suspending Rule

Specifies the consecutive number of times a rule can take longer than the time set for Threshold to inspect packets before the rule is suspended.

Suspension Time

Specifies the number of seconds to suspend a rule.

Because of the uncertainties inherent in measuring latency, Sourcefire recommends that you use the settings in the Minimum Rule Latency Threshold Settings table until your calculations provide settings more suitable for your network. Minimum Rule Latency Threshold Settings For this data rate...

Set threshold microseconds to at least...

1 Gbps

100

100 Mbps

250

5 Mbps

1000

Configuring Latency Thresholding Requires: IPS or DC/MDC + IPS

You can enable or disable packet latency thresholding and modify the latency threshold. You can enable or disable rule latency thresholding, and modify the rule latency threshold, the suspension time for a suspended rule, and the number of consecutive threshold violations that must occur before suspending the rule. To configure latency thresholding:


1.


2. Click Edit next to the policy whose latency thresholding options you want to configure. The Edit Policy page appears.

Version 4.7


810

Creating Intrusion Policies Using RNA Recommended Rules

Chapter 21

3. Click Latency Thresholding. The Latency Thresholding page appears.

4. You can modify any of the options in the Packet Configuration section. See Setting Packet Latency Thresholding Options on page 806 for a description of each option. See the Minimum Packet Latency Threshold Settings table on page 806 for recommended minimum threshold settings. 5. You can modify any of the options in the Rule Configuration section. See Setting Rule Latency Thresholding Options on page 809 for a full description of each available option. See the Minimum Rule Latency Threshold Settings table on page 810 for recommended minimum Threshold settings. 6. Click Save. 7.

Click Back to return to the Edit Policy page. You must apply the policy containing your rule latency thresholding configuration to implement your changes. See Applying an Intrusion Policy on page 764 for procedures.

Using RNA Recommended Rules Requires: DC + IPS + RNA

The RNA Recommended Rules feature recommends rules for you to activate or deactivate based on vulnerabilities associated with the hosts and services on your network. When you configure RNA recommended rules, you associate hosts and services on your network with rules written to protect those hosts and services. The RNA Recommended Rules feature begins by searching through a subset of all intrusion rules that includes all rules related to vulnerabilities in hosts and services. It searches this subset for all rules related to vulnerabilities specific to the hosts and services on the selected network. Next, the feature determines which rules are enabled and disabled in the current intrusion policy. Finally, this feature

Version 4.7


811


Chapter 21

recommends that you activate all rules related to vulnerabilities on your network that are currently disabled, and deactivate all others. You accept rule state recommendations at the RNA Recommended Rules page and, optionally, permanently accept the same state recommendations at the Rule State page. An accepted rule state functions the same as a permanently accepted rule state. The difference is that a rule remains eligible for handling by the RNA Recommended Rules feature unless you permanently accept the recommended state.The policy applies recommended rule states that you accept or permanently accept the same as rule states you set manually, and ignores recommended states that you do not accept. The RNA Recommended Rule Examples table describes reasons for using different methods to set the rule state: RNA Recommended Rule Examples You might...

In order to...

And you can reverse the state by...

accept a recommended state

test the state while retaining the ability to undo it along with other accepted recommendations

• undoing it

permanently accept the recommended state

remove rules with known required states from the overhead of the recommending feature

• setting it manually

manually set the rule state

permanently set its known required state



You can accept none, any, or all of rule state recommendations. You can also undo all recommended activations, deactivations, or both that you have accepted unless you have permanently accepted them. No rule states change based on recommendations unless you specifically accept the recommendations. The policy immediately reflects any rule state changes you accept, and the changes take effect when you apply the policy. You might, for example, create an intrusion policy with no rules and let RNA determine which rules are best suited for the hosts and services on your network. You can also create an intrusion policy with the rules enabled that you know you want enabled, or a policy based on any of the base policies provided by Sourcefire, and then let RNA recommend additional activations and deactivations based on the hosts and services on your network. To clear all current recommendations, you can choose to ignore recommendations. This makes it easier to identify any new recommendations. You can restore recommendations you have set to ignore to display them again.

Version 4.7


812


Chapter 21

You can permanently accept any or all of the recommended rule states at the Rule State page. The system treats a rule state you permanently accept the same way it treats a rule state you set manually. For information on permanently accepting recommended rule states, see Enabling and Disabling Intrusion Rules on page 794. You can undo recommendations you have accepted but have not permanently accepted. Undoing recommendations restores the rules to the state they had before you accepted the recommendations. You can schedule a task to automatically accept all currently recommended activations, deactivations, or both. The scheduled task does not permanently accept rule state recommendations. For information on scheduling a task to automatically accept recommended rule states, see Automating Acceptance of Recommended Rule States on page 1327. See the following sections for more information: •

Configuring RNA Recommended Rules on page 816

•

Accepting Rule State Recommendations on page 819

•

Blacklisting RNA Rule Recommendations on page 829

Understanding the Network to Examine Requires: DC + IPS + RNA

You configure the RNA Recommended Rules feature by identifying a network in the network map to examine for hosts and services. The feature then recommends the rules you can activate to protect a network comprised of those hosts and services. For information on the network map, see Using the Network Map on page 149. TIP! For optimal protection, apply your intrusion policy to the same network that you examine for hosts and services. For more information, see Matching Recommended Rules to a Single Network on page 814. You can use either or both of the following methods to configure the network to examine in the network map for hosts and services:

Version 4.7

•

manually configure a single IP address or CIDR block, or a comma-separated list comprised of individual and block addresses, optionally using ! for negation of any individual or block address

•

use the value of the $HOME_NET variable for one or more detection engines. The value for $HOME_NET can be unique for each detection engine; see Defining IP Addresses in Variables and Rules on page 774 and Using Variables within Detection Engines on page 110 for more information


813


Chapter 21

Consider how the following example configuration of the network to examine for hosts and services combines a manual configuration with a $HOME_NET variable for two detection engines:

The example uses this method...

To configure this network to examine...

Manual

10.11.10.10, 10.12.0.0/16, !10.12.1.0/24

$HOME_NET for DE 1

10.13.0.0/16

$HOME_NET for DE 2

10.14.0.0/16

When you use both a manual configuration and one or more values for $HOME_NET, the system links multiple addresses within each individual configuration with an AND operation, and links the separate configurations with an OR operation. The combined example configuration would be linked as follows: [10.11.10.10 AND 10.12.0.0/16 AND !10.12.1.0/24] OR 10.13.0.0/16 OR 10.14.0.0/16

Note that although the above explanation uses brackets for clarity to group manually configured addresses, you do not use brackets in the manual configuration. The example configuration examines the network map for host operating systems and services on the following hosts: •

individual host 10.11.10.10

•

all hosts on network 10.12.0.0/16 except for hosts on 10.12.1.0/24

•

all hosts on network 10.13.0.0/16

•

all hosts on network 10.14.0.0/16.

Note also in the example that you would configure !10.12.1.0/24 using the same method, manually or in the same $HOME_NET variable, that you use to configure 10.12.0.0/16. You cannot use one method to configure a negation for a value that you configure using the other method because of the OR operation that links the different methods. You could not, for example, reduce the manually configured 10.12.0.0/16 with a $HOME_NET value of !10.12.1.0/24, because this would configure the feature to both examine and exclude 10.12.1.0/24.

Matching Recommended Rules to a Single Network Requires: DC + IPS + RNA

Version 4.7

You receive maximum benefit from RNA recommended rules when you examine a single network in the network map for hosts and services, and then apply the intrusion policy with the accepted state values to a detection engine that


814


Chapter 21

monitors the same network. See Applying an Intrusion Policy on page 764 for information on applying an intrusion policy. Consider the following two examples:

Apply this policy...

Containing this network to examine...

To this network...

Policy A

10.11.10.0/24

10.11.10.0/24

Policy B

10.12.10.0/24

10.12.10.0/24

In Policy A, you would configure RNA recommended rules, either manually or using $HOME_NET, to examine the network map for hosts and services on network 10.11.10.0/24, and you would apply Policy A to the detection engine monitoring 10.11.10.0/24. In Policy B, you would configure RNA recommended rules to examine network 10.12.10.0/24, and you would apply the policy to the detection engine monitoring 10.12.10.0/24. In both cases, recommendations are based specifically on the hosts and services on the monitored network.

Broadening the Recommending and Monitoring Networks Requires: DC + IPS + RNA

Version 4.7

You can, for convenience, configure more than one network to examine for hosts and services. You can also apply the intrusion policy that includes your accepted recommendations to more than one network. You trade convenience for specificity, however, when the hosts and services on your examined network do not match those on the network where you apply the policy. You could experience false positives from rules triggered by unrelated traffic. You might also experience additional processing time because of resources required to monitor traffic with rules that do not apply to the hosts and services in the monitored traffic.


815


Chapter 21

Consider the scenario in the following graphic where you apply a single policy to two example networks:

Hosts on network 10.10.10.0/24 run Microsoft Windows, use DHCP to acquire network addresses, and use Active Directory authentication. Hosts on network 10.10.11.0/24 run Linux, have statically assigned network addresses, provide intranet servers that use various web services, and use NIS authentication. The network to examine for hosts and services includes both networks, and you apply Policy A to both networks. The combined recommendations for both networks include rules associated with Windows, DHCP, Active Directory, Linux, various web services, and NIS. To protect both networks, you must accept the combined recommendations for both networks even though traffic on 10.10.11.0/24 requires none of the recommended rules relating to Windows, DHCP, or Active Directory, and traffic on 10.10.10.0/24 requires none of the recommended rules relating to Linux, web services, or NIS.

Configuring RNA Recommended Rules Requires: DC + IPS + RNA

You must do the following before configuring the RNA Recommended Rules feature: •

Create and apply an RNA detection policy to a 3D Sensor with RNA. The RNA detection policy populates your network map. For information on creating and applying an RNA detection policy, see Configuring RNA Detection Policies on page 134.

•

Identify a network in the RNA network map whose hosts and services you want to use as the basis for recommending intrusion rule states. For information on the network map, see Using the Network Map on page 149.

You configure the RNA Recommended Rules feature by identifying a network in the network map to examine for hosts and services.

Version 4.7


816


Chapter 21

After configuring the network to examine, you can display recommended rule states and, optionally, accept any recommendations. See Accepting Rule State Recommendations on page 819 for more information. You can also undo all recommended activations, deactivations, or both that you have accepted. When you undo recommendations, the RNA Recommended Rules page displays the affected rules again as recommendations, and displays the rule category again if you accepted all recommendations in a category. The Rule State page displays the state that existed before you accepted the recommendation, and removes any indication that the rule state was based on an accepted recommendation. Undoing accepted recommendations does not affect rule states that you permanently accept at the Rule State page. See Enabling and Disabling Intrusion Rules on page 794 for information on permanently accepting recommendations based on RNA data. To configure RNA Recommended Rules: Access: Rules or Admin

1.


2. Click Edit next to the policy where you want to configure RNA recommended rules. The Edit Policy page appears. 3. Click RNA Recommended Rules Configuration. The RNA Recommended Rules Configuration page appears.

Version 4.7


817


Chapter 21

4. Optionally, select a sort order from the dropdown list. You can choose from the following options: •

By Group (that is, by detection engine group)

•

By Sensor (for the Defense Center only)

•

By Policy (that is, by the currently applied policy)

•

By DE Type (that is, by detection engine type: IPS or RNA)

•

By Set Type (that is, by interface set type: passive, inline, or inline with fail open)

5. Optionally, to display a read-only view of the Edit Policy page for a detection engine, click the policy name for the detection engine. 6. Optionally, to configure the value of the $HOME_NET, or any other, detection engine variable for an individual detection engine, click Variables next to the detection engine. Note that this selection provides a convenient alternative link to the Variable Link page, where you can configure $HOME_NET. Use the web browser Back button to return to the RNA Recommended Rules Configuration page after configuring $HOME_NET. For information on configuring detection engine variables, see Using Variables within Detection Engines on page 110. 7.

In the Select the network to examine section, specify the network to examine for hosts and services. You have the following options: •

To use the value of the $HOME_NET variable for a detection engine, select the check box next to the detection engine.

•

To use the value of the $HOME_NET variable for all detection engines within a specific category, select the check box for the category. For example, if you want to use the value of the $HOME_NET detection engine variable for all detection engines on a sensor, select By Sensor from the drop-down list, then select the check box next to the sensor.

•

To manually configure the network to examine, enter a single IP address, CIDR block, or comma-separated list comprised of either or both, including negation, in the Manually field. See Understanding the Network to Examine on page 813 for more information.

Note that you can configure the network manually, as the value of the $HOME_NET variable for one or more detection engines, or combine the two. Multiple configurations of the network to examine are linked an OR operation. See Understanding the Network to Examine on page 813 for more information. TIP! For optimal protection, apply your intrusion policy to the same network that you examine for hosts and services.

Version 4.7


818


Chapter 21

8. Optionally, in the Undo approved RNA recommendations section you can undo any recommended activations and deactivations that you have previously approved at the RNA Recommended Rules page but have not permanently accepted at the Rule State page. You have three choices: •

Click Undo all approved recommendations to undo all recommendations

•

Click Undo approved activations to undo all recommended activations

•

Click Undo approved deactivations to undo all recommended deactivations

Undoing recommendations immediately modifies the policy. For information on approving RNA Recommended Rule activations and deactivations, see Accepting Rule State Recommendations on page 819. 9. Click Save to save your network configuration changes. The system displays the number of hosts on the network you specify at the bottom of the Select the network to examine section. 10. Click Back to return to the Edit Policy page. Remember to apply the policy to the appropriate detection engines to put any recommendations you have accepted into effect. For more information, see Applying an Intrusion Policy on page 764.

Accepting Rule State Recommendations Requires: DC + IPS + RNA

After you configure RNA recommended rules, the Sourcefire 3D System updates recommendations each time you access the RNA Recommended Rules page. The Sourcefire 3D System recommends that you activate all rules not currently enabled that are associated with the hosts and services on the network you configured to examine in the RNA network map, and deactivate all rules associated with other hosts and services. A brief description beneath each recommended activation provides context for the recommendation such as, 13 instances of netbios-ns or Microsoft Windows Plug and Play Buffer Overflow Vulnerability on 16 hosts and 13 services. No such brief description is provided for recommended deactivations since the reason is always that the rule is not associated with the hosts and services on the examined network. Note that RNA does not recommend a rule state for an intrusion rule that is based on a vulnerability that you disable using the Impact Qualification feature. For more information, see Setting the Vulnerability Impact Qualification on page 199. Accepting a recommendation on the RNA Recommended Rules page to activate a rule changes the rule state in the current policy from disabled to enabled on the Rule State page, and accepting a recommendation to deactivate a rule changes the state from enabled to disabled. In both cases, an icon on the Rule State page indicates that the rule state is the result of an accepted recommendation. For more information on displaying accepted rule states and permanently accepting

Version 4.7


819


Chapter 21

rules on the Rule State page, see Enabling and Disabling Intrusion Rules on page 794. TIP! RNA always recommends that you activate a local rule associated with a third party vulnerability mapped to a host if the rule is not already enabled. RNA does not make state recommendations for unmapped local rules. For more information, see Managing Third-Party Product Mappings on page 561. When you accept the recommended state for a rule, or for all rules in a category, the RNA Recommended Rules page no longer displays that rule or category. You can ignore, that is, acknowledge and no longer display, recommendations you have not accepted. Ignoring recommendations clears the display so you can readily see any new recommendations that occur due to changes to the hosts and services on the monitored network. When you return to the page, it displays only new recommendations since the last time you ignored recommendations, and you can display, accept, or ignore the additional recommendations. You can also restore all recommendations that you have set to ignore. See the following sections for more information: •

Accepting Recommendations in a Passive Intrusion Policy on page 820

•

Accepting Recommendations in an Inline Intrusion Policy on page 824

Accepting Recommendations in a Passive Intrusion Policy Requires: DC + IPS + RNA

In a passive intrusion policy, you can accept a recommended activation to change the state of a rule from disabled to enabled, or a recommended deactivation to change the state from enabled to disabled. You can also ignore current recommendations and restore all ignored recommendations. To accept recommendations in a passive policy:


1.


2. Click Edit next to the policy whose recommended rule states you want to accept. The Edit Policy page appears.

Version 4.7


820


Chapter 21

3. Click RNA Recommended Rules. The RNA Recommended Rules page appears. By default, the page lists recommended state changes for rules by category, indicating the total number of recommended activations and deactivations and the totals for each category. Note that for any grouping method, the total at the top of the list indicates the number of unique rules. Because a rule can appear in more than one sub-group, the combined total for all sub-groups can exceed the total number of unique rules. TIP! For information about the types of rules that reside within each category, see Understanding Rule Categories on page 789.

Version 4.7


821


Chapter 21

4. Optionally, select a different grouping method from the Group Rules By list and, at the prompt, confirm that you have saved any recommended activations or deactivations that you want to make to the rule state. See the Rule Groups table on page 793 for information about the rule groups. For example, select Microsoft Worms to display the sub-groups for the Microsoft Worms grouping method.

Version 4.7


822


Chapter 21

5. Optionally, click the folder next to a group that you want to expand. TIP! Folders can take a significant amount of time to open when you have a very high number of intersecting hosts between your network map and the network you examine for hosts and services. During this time, if your web browser displays a message that a script has become unresponsive, make sure you allow the script to continue until it finishes. The folder expands to show the rules in that group. Note that some rule groups have sub-groups that you can also expand. Recommended activations appear in normal text with a green bullet, and recommended deactivations appear in italic gray text with a red bullet.

Version 4.7


823


Chapter 21


To accept the recommendations for an entire group, select the Activations or Deactivations check box, or both, next to the name of the group.

•

To change the state for an individual rule, select the Activation or Deactivation check box next to the individual rule.

•

To view the technical details of the vulnerability for rules recommended because of a known vulnerability, click the vulnerability name beneath the rule. See Viewing Vulnerability Details on page 197 for more information.

TIP! A rule that is included in more than one group has the same recommended state in all groups where it is a member. Accepting the recommended state in one group accepts the state for that rule in all groups containing the rule. 7.

Optionally, to ignore the current recommendations, click Ignore These Recommendations. The page refreshes and no longer displays the current recommendations, and a message notifies you that the current recommendations will be ignored.

8. Optionally, to restore all recommendations that you have set to ignore, click Show All Recommendations. The page refreshes and displays all recommendations for the current grouping method. A message notifies you that all recommendations are displayed. 9. Click Save to save your accepted recommendations. The page refreshes and no longer displays rules or groups whose recommended states you have accepted. The Rule State page will display the rule state for accepted activations as enabled and for accepted deactivations as disabled, and display an icon next to the rule to indicate that the rule state is the result of an accepted recommendation on the RNA Recommended Rules page. See Enabling and Disabling Intrusion Rules on page 794 for more information, including how to permanently accept recommended rule states. 10. Click Back to return to the Edit Policy page. Remember to apply the policy to one or more detection engines to put your changes into effect. For more information, see Applying an Intrusion Policy on page 764.

Accepting Recommendations in an Inline Intrusion Policy Requires: DC + IPS + RNA

Version 4.7

In an inline intrusion policy, you can accept a recommended activation to change the state of a rule from disabled to either enabled or drop, or accept a recommended deactivation to change the state from enabled or drop to disabled.


824


Chapter 21

You can also ignore current recommendations and restore all ignored recommendations. See Using the Drop Rule State on page 798 for more information on setting the rule state in an inline intrusion policy. To accept recommendations in an inline policy: Access: Rules or Admin

1.


2. Click Edit next to the policy whose recommended rule states you want to accept. The Edit Policy page appears. 3. Click RNA Recommended Rules. The RNA Recommended Rules page appears. By default, the page lists recommended state changes for rules by category, indicating the total number of recommended activations and deactivations and the totals for each category. Note that for any grouping method, the total at the top of the list indicates the number of unique rules. Because a rule can appear in more than one sub-group, the combined total for all sub-groups can exceed the total number of unique rules. TIP! For information about the types of rules that reside within each category, see Understanding Rule Categories on page 789.

Version 4.7


825


Chapter 21

4. Optionally, select a different grouping method from the Group Rules By list and, at the prompt, confirm that you have saved any recommended activations or deactivations that you want to make to the rule state. See the Rule Groups table on page 793 for information about the rule groups. For example, select Microsoft Worms to display the sub-groups for the Microsoft Worms grouping method.

Version 4.7


826


Chapter 21

5. Optionally, click the folder next to a group that you want to expand. TIP! Folders can take a significant amount of time to open when you have a very high number of intersecting hosts between your network map and the network you examine for hosts and services. During this time, if your web browser displays a message that a script has become unresponsive, make sure you allow the script to continue until it finishes. The folder expands to show the rules in that group. Note that some rule groups have sub-groups that you can also expand. Recommended activations appear in normal text with a green bullet, and recommended deactivations appear in italic gray text with a red bullet.

Version 4.7


827


Chapter 21


To accept the recommended activations for an entire group, select either the Activations (to set to Enable) or Activations as Drop (to set to Drop) check box next to the name of the group.

•

To accept the recommended deactivations for an entire group, select the Deactivations check box next to the name of the group.

•

To accept the recommended activation for an individual rule, select the Activations (to set to Enable) or Activations as Drop (to set to Drop) check box next to the rule.

•

To accept the recommended deactivation for an individual rule, select the Deactivation check box next to the rule.

•

To view the technical details of the vulnerability for rules recommended because of a known vulnerability, click the vulnerability name beneath the rule. See Viewing Vulnerability Details on page 197 for more information.

TIP! A rule that is included in more than one group has the same recommended state in all groups where it is a member. Accepting the recommended state in one group accepts the state for that rule in all groups containing the rule. 7.

Optionally, to ignore the current recommendations, click Ignore These Recommendations. The page refreshes and no longer displays the current recommendations, and a message notifies you that the current recommendations will be ignored.

8. Optionally, to restore recommendations that you have selected to be ignored, click Show All Recommendations. The page refreshes and displays all recommendations for the current grouping method. A message notifies you that all recommendations are displayed. 9. Click Save to save your accepted recommendations. The page refreshes and no longer displays rules or groups whose recommended states you have accepted. The Rule State page will display the rule state for accepted activations as enabled, for accepted drops as drop, and for accepted deactivations as disabled, and display an icon next to the rule to indicate that the rule state is the result of an accepted recommendation on the RNA Recommended Rules page. See Enabling and Disabling Intrusion Rules on page 794 for more information. 10. Click Back to return to the Edit Policy page. Remember to apply the policy to one or more detection engines to put your changes into effect. For more information, see Applying an Intrusion Policy on page 764.

Version 4.7


828


Chapter 21

Blacklisting RNA Rule Recommendations Requires: DC + IPS + RNA

Blacklisting a rule or rule group excludes it from future state recommendation and removes it from any current recommendation. The RNA Recommended Rules page does not display state recommendations for a rule that you blacklist. In a Microsoft environment, for example, you might blacklist all rules in the Microsoft Worms win32/sasser group on a network where you have protected your existing hosts from the Sasser worm and do not intend to add new hosts. Blacklisting a rule does not changes its current state. You can, for example, accept a recommended activation, then blacklist the rule, and then permanently accept it. The policy retains the blacklist and enforces it if you undo approved recommendations, unless you have permanently accepted a recommendation or manually configured the rule state. The blacklist is restored, for example, if you accept a recommended activation, then blacklist the rule, and then undo approved recommendations. To manage the RNA recommended rules blacklist:


1.


2. Click Edit next to the policy where you want to exclude rules from state recommendations. The Edit Policy page appears. 3. Click RNA Recommended Rules Configuration. The RNA Recommended Rules Configuration page appears.

Version 4.7


829


Chapter 21

4. Click RNA Recommended Rules Blacklist. The RNA Recommended Rules Blacklist page appears. By default, the page lists rules by category, indicating the total number of blacklisted rules and the totals in each category. TIP! For information about the types of rules that reside within each category, see Understanding Rule Categories on page 789.

Version 4.7


830


Chapter 21

5. Optionally, select a different grouping method from the Group Rules By list and, at the prompt, confirm that you have saved any selections. See the Rule Groups table on page 793 for information about the rule groups. For example, select Microsoft Worms to display the sub-groups for the Microsoft Worms grouping method.

Version 4.7


831


Chapter 21

6. Optionally, click the folder next to a group that you want to expand. TIP! Folders can take a significant amount of time to open when you have a very high number of intersecting hosts between your network map and the network you examine for hosts and services. During this time, if your web browser displays a message that a script has become unresponsive, make sure you allow the script to continue until it finishes. The folder expands to show the rules in that group. Note that some rule groups have sub-groups that you can also expand. Rules available for recommendation appear with a green bullet. Blacklisted rules appear with a tan negation bullet.

Version 4.7


832

Creating Intrusion Policies Importing SEUs and Rule Files

7.

Chapter 21

You have the following options: •

To blacklist an entire group, select the Disallow check box next to the name of the folder.

•

To remove all rules in an entire group from a previously configured blacklist and permit them to be included again in recommendations, select the Allow check box next to the name of the folder.

•

To blacklist an individual rule, select the Disallow check box next to the individual rule.

•

To remove an individual rule from a previously configured blacklist and permit it to be included again in recommendations, select the Allow check box next to the individual rule.

TIP! When a blacklisted rule is included in more than one group, blacklisting the rule in one group blacklists the rule in all groups where it is a member. 8. Click Save to save your selections and then click Back to return to the RNA Recommended Rules Configuration page. All blacklisted rules and categories are excluded from RNA recommendations and will not be displayed in the RNA Recommended Rules page. For more information on RNA Recommended Rule, see Accepting Rule State Recommendations on page 819. TIP! You can enable or disable rules at the Rule State page regardless of whether they are blacklisted from state recommendations.

Importing SEUs and Rule Files Requires: IPS or DC/MDC + IPS

As new vulnerabilities become known, the Sourcefire Vulnerability Research Team (VRT) releases SEUs. An SEU contains new and updated standard text rules and shared object rules that you can use to detect potential attacks against your network and its assets. In addition, an SEU can also provide IPS with an updated version of Snort®, as well as features such as new preprocessors and decoders. SEUs are cumulative, so the newest SEU contains the intrusion rules and new features of all previous SEUs. You cannot import an SEU with a version number lower than the version currently installed SEU. If your Sourcefire 3D System deployment includes two Defense Centers configured as a high availability pair, you only need to import and apply the SEU

Version 4.7


833


Chapter 21

on one of the Defense Centers. The second Defense Center receives the SEU as part of the regular synchronization process. IMPORTANT! SEUs can contain new binaries. Make sure your process for uploading and installing SEUs complies with your security policies. There are two methods that you can use to import SEUs. •

Manually Importing SEUs on page 834 explains how to download an SEU from the Sourcefire Support web site to your local machine and then manually upload the SEU.

•

Automatically Importing SEUs on page 836 explains how to use an automated feature on the web interface to search the Sourcefire Support site for new SEUs and upload them.

TIP! You can use the scheduling feature to automatically import SEUs at off-peak hours. See Automating SEU Updates on page 1315 for more information. The Sourcefire 3D System also has a feature that you can use to import a copy of a standard text rules file that you have created on a local machine. See Importing Local Rule Files on page 837 for more information.

Manually Importing SEUs Requires: IPS or DC/MDC + IPS

The following procedure explains how to import a new SEU manually. This procedure is especially useful if your Defense Center or 3D Sensor does not have Internet access. To update SEUs manually: 1.

From a computer that can access the Internet, access and log into Sourcefire Support (https://support.sourcefire.com/).

2. Click Downloads. 3. Navigate to the latest SEU. TIP! SEUs are cumulative, so the newest SEU contains the intrusion rules and new features of all previous SEUs. You cannot import an SEU with a version number lower than the version currently installed SEU. 4. Click the SEU file that you want to download and save it to your computer. 5. Log into your appliance’s web interface.

Version 4.7


834


Chapter 21

6. Select Policy & Response > IPS > SEU. The SEU page appears.

7.

Click Import Rules. The Import Rules page appears.

TIP! You can also click Import Rules from the Rules page, which you access by selecting Policy & Response > IPS > Rules. 8. Select SEU or text rule file to upload and apply and click Browse to navigate to and select the SEU file. 9. For any new rules in the SEU, the VRT sets the default rule state to either Enable, Disable, or Drop. For example, if the vulnerability that the rule detects is relatively innocuous and unlikely to affect many networks, the VRT may set the rule state to Disable. However, if the rule detects a widespread vulnerability that has a known exploit, the VRT may set the rule state to Enable. Specify how you want to set the rule state for new rules after import: •

If you want any new rules to use the default rule state set by Sourcefire in your existing policies, select In the default state.

•

If you want to disable new rules, select In the disabled state.

TIP! If you import an SEU using the In the default state option, any old or deprecated rules that the VRT marked for deletion in the SEU are automatically disabled and then moved to the deleted.rules file. You can enable these rules under the Deleted Rules category on the Rule State page as part of a custom intrusion policy. You can also copy a deleted rule and use it as the basis for a custom intrusion rule.

Version 4.7


835


Chapter 21

10. Click Update. The SEU is installed and the rules are updated. The system displays the SEU Detail View workflow. See Understanding the SEU Detail View Table on page 842 for more information. The rules are not activated until the next time you apply the affected intrusion policies. See Applying an Intrusion Policy on page 764 for procedures. IMPORTANT! Contact technical support if you receive an error message while installing the SEU.

Automatically Importing SEUs Requires: IPS or DC/MDC + IPS

The following procedure explains how to import a new SEU by automatically connecting to the Sourcefire Support site. You can use this procedure only if the appliance has Internet access. To update SEUs automatically:


1.

Select Policy & Response > IPS > SEU. The SEU page appears.

2. Click Import Rules. The Import Rules page appears.

TIP! You can also click Import Rules from the Rules page, which you access by selecting Policy & Response > IPS > Rules. 3. Select Download new SEU (from the support site).

Version 4.7


836


Chapter 21

4. For any new rules in the SEU, the VRT sets the default rule state to either Enable, Disable, or Drop. For example, if the vulnerability that the rule detects is relatively innocuous and unlikely to affect many networks, the VRT may set the rule state to Disable. However, if the rule detects a widespread vulnerability that has a known exploit, the VRT may set the rule state to Enable. Specify how you want to set the rule state for new rules after import: •

If you want any new rules to use the default rule state set by Sourcefire in your existing policies, select In the default state.

•

If you want to disable new rules, select In the disabled state.

TIP! If you import an SEU using the In the default state option, any old or deprecated rules that the VRT marked for deletion in the SEU are automatically disabled and then moved to the deleted.rules file. You can enable these rules under the Deleted Rules category on the Rule State page as part of a custom intrusion policy. You can also copy a deleted rule and use it as the basis for a custom intrusion rule. 5. Click Update. The SEU is installed and the rules are updated. However, the rules are not activated until the next time you apply the affected intrusion policies. See Applying an Intrusion Policy on page 764 for procedures. IMPORTANT! Contact technical support if you receive an error message while installing the SEU.

Importing Local Rule Files Requires: IPS or DC/MDC + IPS

The following procedure explains how to import standard text rules that you have created on a local machine. TIP! You must make sure that the rules in the file do not contain any escape characters. Note that all imported local rules are automatically saved in the Local rule category. To import local rule files:


Version 4.7

1.

Select Policy & Response > IPS > Rules. The Rules page appears.


837


Chapter 21

2. Click Import Rules. The Import Rules page appears.

TIP! You can also click Import Rules from the SEU page, which you access by selecting Policy & Response > IPS > SEU. 3. Select SEU or text rule file to upload and apply and click Browse to navigate to the rule file. Note that all rules uploaded in this manner are saved in the Local rule category. 4. Click Update. The rule file is imported. Make sure you enable the appropriate rules in your intrusion policies. The rules are not activated until the next time you apply the affected policies. IMPORTANT! 3D Sensors do not use the new rule set for inspection until after you apply their intrusion policies. See Applying an Intrusion Policy on page 764 for procedures.

Viewing the SEU Import Log Requires: IPS or DC/MDC + IPS

The Defense Center or 3D Sensor with IPS generates a record for each SEU and local rule file that you import. Each record includes a time stamp, the name of the user who imported the file, and a status icon indicating whether the import succeeded or failed. You can maintain a list of all SEUs and local rule files that you import, delete any record from the list, and access detailed records for all imported rules and SEU

Version 4.7


838


Chapter 21

components. The fields in the SEU Import Log table are described in the SEU Import Log Actions table. SEU Import Log Actions To...

You can...


find more information in Understanding the SEU Import Log Table on page 839.

delete an import file record from the import log, including detailed records for all objects included with the file

click Delete next to the file name for the import file.

view details for each object imported in an SEU or local rule file

IMPORTANT! Deleting the file from the log does not delete any object imported inthe import file, but only deletes the import log records. click View next to the file name for the import file.

To view the SEU import log: Access: Rules or Admin

h


Understanding the SEU Import Log Table Requires: IPS or DC/MDC + IPS

The fields in the list of SEUs and local rule files that you import are described in the SEU Import Log Fields table. SEU Import Log Fields

Version 4.7

Field

Description

Summary

The name of the import file. If the import fails, a brief statement of the reason for the failure appears under the file name.

Time

The time and date that the import started.


839


Chapter 21

SEU Import Log Fields (Continued) Field

Description

User ID

The user name of the user that triggered the import.

Status

Whether the import succeeded (

) or failed (

).

TIP! The red status icon indicating an unsuccessful import appears on the SEU page during the import and is replaced by the green icon only when the import has successfully completed. Action

Allows you to view the SEU Details page for an SEU or local rule file by clicking View, or delete the file record and all detailed object records imported with the file by clicking Delete.

Viewing SEU Details Requires: IPS or DC/MDC + IPS

The SEU Detail View lists a detailed record for each object imported in an SEU or local rule file. You can also create a custom workflow or report from the records listed that includes only the information that matches your specific needs. The SEU Detail View Actions table below describes specific actions you can perform on an SEU Detail View workflow page. SEU Detail View Actions

Version 4.7

To...

You can...


find more information in Understanding the SEU Detail View Table on page 842.

sort and constrain records on the current workflow page



click Workflows. For information on selecting workflows, see Selecting Workflows on page 1162. For information on creating custom workflows, see Creating Custom Workflows on page 1179.




840


Chapter 21

SEU Detail View Actions (Continued) To...

You can...





search the entire SEU log database for SEU import records

click Search. From more information, see Searching the SEU Import Log on page 842.

open a search page pre-populated with the current single constraint

select Edit Search or Save Search next to Search Constraints. From more information, see the Table View and Drill-down Page Features table on page 1166.

To view the SEU Details page: Access: Rules or Admin

1.


2. Click View next to the file whose detailed records you want to view. The table view of detailed records appears.

Version 4.7


841


Chapter 21

Understanding the SEU Detail View Table Requires: IPS or DC/MDC + IPS

You can view a detailed record for each object imported in an SEU or local rule file. The fields in the SEU Detail View are described in the SEU Detail View Fields table. SEU Detail View Fields Field

Description

Time

The time and date the import began.

Name

The name of the imported object, which for rules corresponds to the rule Message field, and for SEU components is the component name, such as online help, or Snort.

Type

The type of imported object, such as rule or SEU component.

Action

An indication that the object is either new (this is the first time it has been stored on this appliance), changed (the object has been modified and, for rules has a higher revision number and the same GID and SID), or deleted (the object has been deleted from the SEU).

GID

The generator ID for a rule as either 1 (standard text rule) or 3 (shared object rule).

SID

The SID for a rule.

Rev

The revision number for a rule.

Policy

All, indicating that a rule is included in all default policies.

Default state

Whether a rule is set by default to Enable, Disable, or Drop.

Details

A string unique to the component or rule. For rules, the GID, SID, and previous revision number for a changed rule, displayed as previously (GID:SID:Rev). This field is blank for a rule that has not changed.

Count

The count (1) for each record.The Count field appears in a table view when the table is constrained, and the SEU Detail View is constrained by default to SEU records.

Searching the SEU Import Log Requires: IPS or DC/MDC + IPS

Version 4.7

You can search the import log for specific records or for all records matching the search criteria.


842


Chapter 21

You may want to create customized searches and save them to re-use later. TIP! You search the entire SEU import log database even when you initiate a search by clicking Search on the toolbar from the SEU Detail View with only the records for a single import file displayed. Make sure you set your time constraints to include all objects you want to include in the search. See Specifying Time Constraints in Searches on page 1130 for more information. The search criteria you can use are described in the SEU Import Log Search Criteria table. Note that record searches are case-insensitive. For example, searching for RULE or rule yields the same results. SEU Import Log Search Criteria Search Field

Description

Example

Time

Specify the date and time the record was generated. See Specifying Time Constraints in Searches on page 1130 for the syntax for entering time.

> 2006-01-15 13:30:00 returns all rule

Name

Specify all or part of the content of the rule Message field. You can use an asterisk (*) as a wildcard character in this field.

*dhcp* returns all rule records with DHCP in the Message field.

Type

Specify the type of record.

seu* returns all imported SEU components, such as updated online help or updated versions of Snort.

Action

Specify whether the imported rule is new, changed, or has been deleted (from the rule pack).

new returns all rules imported for the first

GID

Specify the generator ID for the rule.

3 returns all shared object rules.

SID

Specify a single signature ID for a rule. You cannot specify a list of SIDs.

923 returns the record for the rule with

Rev

Specify the revision number for the rule.

3 returns rules with the revision number 3.

Policy

Specify the default policy the rules is imported into.

All returns rules imported into all default

Version 4.7

records imported after January 15, 2006 at 1:30pm.

time on the appliance.

the SID 923.

policies.


843


Chapter 21

SEU Import Log Search Criteria (Continued) Search Field

Description

Example

Default state

Specify a default rule state of enabled or disabled.

enabled returns all enabled rules.

SEU

Specify the SEU filename.

filename returns all records for the specified import file.

Details

Specify details on the imported object.

previously* returns the record for all

rules that have changed

For more information on searching, including how to load and delete saved searches, see Searching for Events on page 1124. To search the SEU Import Log: Access: Data or Admin

1.

Select Analysis & Reporting > Searches > SEU Import Log. The SEU Import Log search page appears.

2. Optionally, if you want to save the search, enter a name for the search in the Name field. If you do not enter a name, the web interface automatically creates one when you save it. 3. Enter your search criteria in the appropriate fields, as described in the SEU Import Log Search Criteria table. If you enter multiple criteria, the search returns the records that match all the criteria.

Version 4.7


844


Chapter 21

4. If you want to save the search so that other users can access it, clear the Save As Private check box. Otherwise, leave the check box selected to save the search as private. TIP! If you want to save a search as a restriction for restricted data users, you must save it as a private search. 5. You have the following options: •

Click Search to start the search. Your search results appear in the default SEU Detail View workflow. If you created a custom workflow and did not specify a preferred workflow, you must select one. For information on specifying a preferred workflow, see Setting Event Preferences on page 35.

Version 4.7

•


•



845

Chapter 21

Tuning Preprocessors

3D Sensors with IPS use preprocessors to reformat traffic to make sure the rules engine reads the traffic in the same format it will be received by the host. Without preprocessing, the IPS component cannot appropriately evaluate traffic because protocol differences make pattern matching impossible. Sourcefire preprocessors normalize traffic and help identify network layer and transport layer protocol anomalies by identifying inappropriate header options, defragmenting IP datagrams, providing TCP stateful inspection and stream reassembly, providing UDP session tracking, resolving application command syntax, and validating checksums. You can configure these preprocessors to ensure that the packets IPS analyzes resemble, as closely as possible, the packets processed by the hosts on your network. Each preprocessor has a variety of options and settings that you can configure to meet the needs of your network environment, allowing you to minimize both false positives and false negatives and to optimize performance by executing only those preprocessors appropriate to your network traffic. In general, as intrusion detection and prevention systems become important components in securing networks, the systems themselves become targets for attackers. For example, attackers sometimes attempt to purposefully create denial of service attacks by sending SYN packets with spoofed source IP addresses, causing the recipient server to allocate memory for the pending TCP connection. The server then sends a SYN-ACK to the originating IP address to establish a TCP session. Because attackers do not use legitimate IP addresses, the SYN-ACK message times out and the server resends it, keeping memory allocated for a longer period of time. These half-open TCP connections drain system resources. Because most systems attempt to perform stateful inspection on TCP sessions, the system may go into a denial-of-service condition while attempting to establish the state of these open TCP sessions. However, the

Version 4.7


846

Tuning Preprocessors

Chapter 22

transport layer preprocessor, included as part of IPS, detects the state of a TCP connection, and can dispense with half-open connections and prevent overloading the rules engine with false connections. If you deploy your Sourcefire 3D System inline, you can set the rule state for intrusion rules in your inline intrusion policy to drop malicious packets. Note, however, that with the exception of SMTP packets that contain X-Link2State attacks, you cannot use preprocessors to block incoming packets, even with a 3D Sensor deployed inline. For more information on configuring rules to drop packets, see Using the Drop Rule State on page 798. For more information on SMTP preprocessing, see Decoding SMTP Traffic on page 905. Preprocessor options can protect you from attacks against the 3D Sensor itself, ensuring higher availability and better security for your network. See the following sections for more information:

Version 4.7

•

Challenges to Inspecting Traffic on page 848 describes both normal traffic and the inspection challenges experienced at the network layer, transport layer, and application layer.

•

Understanding Preprocessor Execution Order on page 849 explains the order of execution in Sourcefire 3D System preprocessors.

•

Reading Preprocessor Events on page 850 illustrates preprocessor events and explains the information they contain.

•

Understanding Packet Decoding on page 864 illustrates preprocessor events and explains the information they contain.

•

Understanding Network and Link-Layer Preprocessors on page 868 describes, in detail, the preprocessors that inspect network layer protocols.

•

Understanding Transport-Layer Preprocessors on page 873 describes stateful inspection and stream reassembly of TCP traffic, and UDP session tracking.

•

Understanding Application-Layer Preprocessors on page 889 describes the HTTP normalizer, RPC normalizer, SMTP decoder, FTP Telnet decoder, DNS preprocessor, SSL preprocessor, and DCE/RPC reassembly preprocessors.

•

Reporting Decoding Errors on page 932 describes how to configure event generation when errors occur during packet decoding.

•

Monitoring Performance on page 932 explains the basic parameters you can configure to manage how 3D Sensors monitor and report on their own performance.

•

Detecting Back Orifice on page 932 explains detection of back orifice attacks.

•

Detecting Portscans on page 933 describes the different types of portscans and explains how you can use portscan detection to identify threats to your networks before they develop into attacks.


847

Tuning Preprocessors Challenges to Inspecting Traffic

Chapter 22

•

Constraining Regular Expressions on page 942 explains how to configure the rules engine to log more than one event per packet or packet stream when multiple events are generated.

•

Configuring Standard Preprocessor Options on page 943 explains how to configure standard preprocessor options, HTTP decoding options, event notification options, and portscan detection options.

TIP! Sourcefire can use SEU updates to add new preprocessors and to add new functionality and features to existing preprocessors. To learn more about features that are not discussed in the main online help, select a feature and then click the Help link on the page for that feature to view additional SEU-based online help. For more information on SEU updates, see Importing SEUs and Rule Files on page 833.

Challenges to Inspecting Traffic Requires: IPS or DC/MDC + IPS

The IPS component is responsible for inspecting the traffic that traverses the segment of your network that you want to monitor. Although this seems straightforward, variations in the way data is represented and the characteristics inherent in the way data is transmitted can make the inspection of any traffic more complex. The Sourcefire 3D System mitigates the challenges inherent in normal traffic, as well as those inherent in packets designed to cause damage or to evade inspection. Each layer of TCP/IP provides challenges: •

Network and Link Layers Normal traffic at the network layer can be fragmented. That is, IP datagrams can exceed the maximum transmission unit and must be transported in smaller fragments. IP Datagrams that are fragmented must be reconstructed before meaningful attack analysis can occur. Additionally, attackers can use malicious IP fragmentation, including overlapping fragments, multiple zero-offset fragments (the Jolt2 denial of service, or DoS, attack), and fragmented protocol headers, all of which mask traffic you might not normally allow on your network. Additionally, the network layer can be attacked by crafting packets with invalid, zero-length IP options, used to cause DoS attacks.

•

Transport Layer The transport layer is subject to TCP stream-based attacks, such as sending TCP packets with overlapping sequence numbers to force IPS to determine which sequence number is valid. The transport layer can be open to TCP header option attacks such as spoofing a TCP packet and changing header values to choke the TCP connection and propagate further attacks. Additionally, TCP is subject to state-related attacks such as those produced by stick or snot, which generate TCP packets that are not part of an

Version 4.7


848

Tuning Preprocessors Understanding Preprocessor Execution Order

Chapter 22

established connection and which can trigger a large volume of rules, creating a DoS against both IPS and the analyst. Attackers can also launch subterfuge attacks by transmitting TCP, UDP and ICMP packets with invalid checksums in an attempt to cause IPS to inspect packets that the destination host never receives. Reassembling TCP sessions provides context for each packet, supporting effective analysis of traffic. Additionally, tracking associated UDP user datagrams allows IPS greater specificity in detecting attacks. •

Application Layer Application layer protocols like HTTP, Telnet, FTP, SMTP, and RPC may have multiple ways of representing the same data. This causes rules designed to check for specific packet payload content to fail because the payload is represented differently in a packet than in the rule. Decoding HTTP, Telnet, FTP, SMTP, and RPC packets and then normalizing their data to a standard representation mitigates this challenge.

Understanding Preprocessor Execution Order Requires: IPS or DC/MDC + IPS

Protocol decoders, preprocessors, and rules run in a specific order so that they can perform IP transfer layer protocol decoding first, then perform data normalization if needed, and then evaluate the resulting packets against the currently enabled rules. The default policy configuration sets the preprocessors to perform IP transfer layer protocol decoding first, then perform data normalization as needed.

This approach provides the following benefits:

Version 4.7

•

IPS can generate an intrusion event against fragmented IP datagrams that cannot be defragmented, and then stop inspecting those packets.

•

IPS can generate an event against TCP packets whose state cannot be validated, and then stop inspecting those packets.


849

Tuning Preprocessors Reading Preprocessor Events

Chapter 22

•

IPS can generate events against related UDP packets.

•

Only packets that can be appropriately tested by rules are normalized, optimizing performance by ignoring TCP packets that cannot be reassembled and are not part of a valid TCP session.

•

After preprocessing, traffic can be analyzed by the rules engine in the same way that it is analyzed by the receiving host.

WARNING! Preprocessors are executed based on your configuration. If you change the default configuration, the system will not execute the preprocessors you disabled. If, for example, you disable transport layer protocol preprocessors, the system runs content rules against packets that may have been logged and removed from inspection by transport layer protocol preprocessors had they inspected the packets. Note this does not change the order of execution.

Reading Preprocessor Events Requires: IPS or DC/MDC + IPS

Preprocessors provide two functions: performing the specified action on the packet (for example, decoding and normalizing HTTP traffic) and reporting the execution of specified preprocessor options by generating an event whenever a packet triggers that preprocessor option (for example, you can enable the double_decode HTTP Inspect option to generate an event when it encounters IIS double-encoded traffic). Generating events to report the execution of preprocessors helps you detect anomalous protocol exploits. For example, attackers can craft overlapping IP fragments to cause a DoS on a host. The IP defragmentation preprocessor can detect this type of attack and generate an intrusion event for it. See the following sections for more information: •

Understanding the Preprocessor Event Packet Display on page 850 describes the information contained in a preprocessor-generated event.

•

Reading Preprocessor Generator IDs on page 851 details the information provided by the preprocessor generator ID.

Understanding the Preprocessor Event Packet Display Requires: IPS or DC/MDC + IPS

Version 4.7

Preprocessor events differ from rule events in that the packet display does not include a rule for the event. Instead, the packet display shows the event message, the generator ID, the packet header data, and the packet payload. This allows you to analyze the packet’s header information, determine if its header options are being used and if they can exploit your system, and inspect the packet payload. After the preprocessors analyze each packet, the rules engine executes appropriate rules against it (if the preprocessor was able to defragment it and establish it as part of a valid session) to further analyze potential content-level threats and report on them.


850


Chapter 22

Reading Preprocessor Generator IDs Requires: IPS or DC/MDC + IPS

Each preprocessor has its own Generator ID number, or GID, that indicates which preprocessor was triggered by the packet. Some of the preprocessors also have related SIDs, which are ID numbers that classify potential attacks. This helps you analyze events more effectively by categorizing the type of event much the way a rule’s Snort ID (SID) can offer context for packets triggering rules. IMPORTANT! Events generated by standard text rules have a generator ID of 1. The event’s SID indicates which specific rule triggered. For shared object rules, the events have a generator ID of 3 and a SID that indicates which specific rule was triggered. The GID and SID values are described in the following tables: •

Generator IDs on page 851

•

Back Orifice Detector SIDs on page 854

•

RPC Decoder SIDs on page 854

•

Stream 4 Stateful Inspection and Stream Reassembly SIDs on page 855

•

Packet Decoder SIDs on page 856

•

HTTP Inspection SIDs on page 859

•

Portscan Detector SIDs on page 860

•

IP Defragmentor SIDs on page 861

•

SMTP Decoder SIDs on page 862

•

FTP Decoder SIDs on page 862

•

Telnet Decoder SIDs on page 863

•

Stream 5 Stateful Inspection and Stream Reassembly SIDs on page 863

•

DNS SIDs on page 864

The Generator IDs table describes the types of events that generate each GID. Generator IDs

Version 4.7

ID

Component

Description

1

Standard Text Rule

The event was generated when the packet triggered a standard text rule.

2

Tagged Packets

The event was generated by the Tag generator, which generates packets from a tagged session. This occurs when the tag rule option is used. For more information, see Evaluating Post-Attack Traffic on page 1005.


851


Chapter 22

Generator IDs (Continued)

Version 4.7

ID

Component

Description

3

Shared Object Rule

The event was generated when the packet triggered a shared object rule.

102

HTTP Decoder

The decoder engine decoded HTTP data within the packet.

105

Back Orifice Detector

The Back Orifice Detector identified a Back Orifice attack associated with the packet. For details on the issues detected during Back Orifice detection, see the Back Orifice Detector SIDs table on page 854.

106

RPC Decoder

The RPC decoder decoded the packet. For details on the issues detected during RPC decoding, see the RPC Decoder SIDs table on page 854.

111

Stream 4 Stateful Inspection and Stream Reassembly

The event was generated during stateful inspection or stream reassembly by the Stream 4 preprocessor, noting a problem with the stateful inspection of the payload. For details on the issues detected during stateful inspection and stream reassembly, see the Stream 4 Stateful Inspection and Stream Reassembly SIDs table on page 855.

116

Packet Decoder

The event was generated by the packet decoder. For details about the issues detected in decoding, see the Packet Decoder SIDs table on page 856.

119

HTTP Inspection Preprocessor

The event was generated by the HTTP Inspection preprocessor. For information about the issues detected with the HTTP Inspection preprocessor, see the HTTP Inspection SIDs table on page 859.

120

HTTP Inspection Anomalous Server Preprocessor

The event was generated by the HTTP Inspection anomalous server preprocessor. This processor contains a single SID (1), which generates an event when HTTP traffic is received by ports not specified as web server ports in your intrusion policy.

122

Portscan Detector

The event was generated by the portscan flow detector. For information about these issues, see the Portscan Detector SIDs table on page 860.


852


Chapter 22

Generator IDs (Continued)

Version 4.7

ID

Component

Description

123

IP Defragmentor

The event was generated when a fragmented IP datagram could not be properly reassembled. For details on the issues detected, see the IP Defragmentor SIDs table on page 861.

124

SMTP Decoder

The event was generated when the SMTP preprocessor detected an exploit against an SMTP verb. See Decoding SMTP Traffic on page 905 for more information.

125

FTP Decoder

The event was generated when the FTP Telnet decoder detected an exploit within FTP traffic. See Decoding FTP and Telnet Traffic on page 909 for more information.

126

Telnet Decoder

The event was generated when the FTP Telnet decoder detected an exploit within telnet traffic. See Decoding FTP and Telnet Traffic on page 909 for more information.

129

Stream 5 Stateful Inspection and Stream Reassembly

The event was generated during stateful inspection or stream reassembly by the Stream 5 preprocessor, noting a problem with the stateful inspection of the payload. For details on the issues detected during stateful inspection and stream reassembly, see the Stream 5 Stateful Inspection and Stream Reassembly SIDs table on page 863.

130

DCE/RPC Preprocessor

The event was generated by the DCE/RPC preprocessor. This preprocessor contains a single SID (1), which generates an event when the maximum memory allocated to the preprocessor for reassembling fragments is reached.

131

DNS Preprocessor

[]The event was generated by the DNS preprocessor. For information about the issues detected with the DNS preprocessor, see the DNS SIDs table on page 864.

1001

Suspended Standard Text Rule

The event was generated when the rule latency feature suspended a standard text rule. For more information, see Understanding Rule Latency Thresholdng on page 807.


853


Chapter 22

Generator IDs (Continued) ID

Component

Description

2001

Re-enabled Standard Text Rule

The event was generated when the rule latency feature re-enabled a suspended standard text rule. For more information, see Understanding Rule Latency Thresholdng on page 807.

1003

Suspended Shared Object Rule

The event was generated when the rule latency feature suspended a shared object rule. For more information, see Understanding Rule Latency Thresholdng on page 807.

2003

Re-enabled Shared Object Rule

The event was generated when the rule latency feature re-enabled a suspended shared object rule. For more information, see Understanding Rule Latency Thresholdng on page 807.

The Back Orifice Detector SIDs table describes the types of packets that generate each Back Orifice Detector SID. Back Orifice Detector SIDs SID

Description

1

Back Orifice traffic detected

2

Back Orifice client traffic detected

3

Back Orifice server traffic detected

4

Back Orifice Snort buffer attack

The RPC Decoder SIDs table describes the types of packets that generate each RPC-related SID. RPC Decoder SIDs

Version 4.7

SID

Description

1

Fragmented RPC records detected

2

Multiple instances of the same RPC record detected


854


Chapter 22

RPC Decoder SIDs (Continued) SID

Description

3

Abnormally large RPC record fragment detected

4

RPC segment with missing fragments detected

5

Zero-length RPC fragment

The Stream 4 Stateful Inspection and Stream Reassembly SIDs table describes the types of packets that generate each Stream 4 stateful inspection and stream reassembly SID. Stream 4 Stateful Inspection and Stream Reassembly SIDs

Version 4.7

SID

Description

1

Stealth activity detected

2

Evasive TCP reset segment detected

3

Evasive retransmission detected

4

Window violation detected

5

Data detected on the SYN flag

6

Stealth full XMAS attack (TCP packets with all TCP flags set) detected.

7

Stealth SAPU

8

Stealth FIN scan (unsolicited TCP packets with a FIN flag set used to determine if a TCP port is open) detected

9

Stealth null scan (TCP packets with no TCP flags set) detected

10

Stealth NMAP XMAS scan (TCP packets with FIN, URG, And PUSH TCP flags set send by NMAP tool) detected

11

Stealth Vecna scan detected

12

Stealth Nmap fingerprint detected

13

Stealth SYN FIN scan detected


855


Chapter 22

Stream 4 Stateful Inspection and Stream Reassembly SIDs (Continued) SID

Description

14

Forward overlap detected

15

Time To Live evasion detected

16

Evasive retransmission of data detected

17

Evasive retransmission data split

18

Multiple ACKed

19

Emergency

20

Suspend

21

TCP Timestamp option has value of zero

22

Too many overlapping TCP packets

23

Packet in established TCP stream missing ACK

24

Evasive FIN packet

25

SYN on established

The Packet Decoder SIDs table describes the types of packets that generate each SID related to the packet decoder. Packet Decoder SIDs

Version 4.7

SID

Description

1

Packet is not an IPV4 datagram

2

Invalid IPV4 header length detected

3

IPV4 datagram longer than IP header

4

IPV4 bad option length detected

5

Truncated IPV4 option detected

45

TCP datagram longer than TCP header


856


Chapter 22

Packet Decoder SIDs (Continued)

Version 4.7

SID

Description

46

Invalid TCP offset detected

47

Large TCP offset detected

54

TCP Option with a bad length value detected

55

Truncated TCP option detected

56

TTCP option detected

57

Obsolete TCP option detected

58

Experimental TCP option detected

95

UDP datagram longer than UDP header

96

Invalid UDP datagram length detected

97

Short UDP datagram packet detected

105

ICMP datagram longer than ICMP header

106

ICMP datagram longer than timestamp header

107

ICMP datagram longer than address header

108

Unknown IPV4 datagram detected

109

Truncated address resolution protocol (ARP) detected

110

Truncated EAPOL header detected

111

Truncated EAP key detected

112

Truncated EAP header detected

120

Bad PPPOE frame detected

130

Bad VLAN frame detected

131

Bad VLAN LLC header detected

132

Bad VLAN extra LLC information detected


857


Chapter 22

Packet Decoder SIDs (Continued)

Version 4.7

SID

Description

133

Bad 802.11 LLC header detected

134

Bad 802.11 extra LLC information detected

140

Bad token ring header detected

141

Bad token ring ETHLLC header detected

142

Bad token ring MRLEN header detected

143

Bad token ring MR header detected

150

Traffic with either the source or destination IP address set to the loopback address (127.0.0.0/8) detected

151

Traffic with identical source and destination IP addresses detected

160

Invalid GRE header length detected

161

Multiple GRE encapsulations detected in packet

162

Invalid GRE version (not 0 or 1)

163

Invalid GRE version 0 header detected

164

Invalid GRE version 1 header detected

165

Invalid Transparent Ethernet Bridging header length detected in GRE encapsulation

250

ICMP original IP header truncated

251

ICMP original IP header not IPv4

252

ICMP oriiginal datagram length less than original IP header length

253

ICMP original IP payload les than 64 bits

254

ICMP original IP payload greater than 576 bytes

255

ICMP original IP fragmented and offset not 0


858


Chapter 22

The HTTP Inspection SIDs table describes the types of packets that generate each SID related to the HTTP Inspection preprocessor. HTTP Inspection SIDs

Version 4.7

SID

Description

1

Encoded ASCII HTTP data detected

2

Double encoded HTTP data detected

3

%U encoded HTTP data detected

4

Bare byte encoded HTTP data detected

5

Base-36 encoded HTTP data detected

6

UTF-8 encoded HTTP data detected

7

IIS Unicode data mapped to Unicode codepoints detected in HTTP data

8

HTTP data using multiple slash obfuscation detected

9

HTTP data using backslash obfuscation detected

10

HTTP data containing self-referential directory obfuscation detected

11

HTTP data containing directory traversal obfuscation detected

12

HTTP data containing tab characters detected

13

HTTP data containing linebreaks detected

14

HTTP data containing the Non-RFC character specified in your intrusion policy detected

15

HTTP data containing an oversized directory length detected

16

HTTP data containing abnormally large data chunk sizes detected

17

HTTP data proxy use detected

18

Web root directory traversal


859


Chapter 22

The Portscan Detector SIDs table describes the types of packets that generate each SID related to the portscan flow detector. Portscan Detector SIDs

Version 4.7

SID

Description

1

TCP Portscan

2

TCP Decoy Portscan

3

TCP Portsweep

4

TCP Distributed Portscan

5

TCP Filtered Portscan

6

TCP Filtered Decoy Portscan

7

TCP Filtered Distributed Portscan

8

TCP Filtered Portsweep

9

IP Portscan

10

IP Decoy Portscan

11

IP Portsweep

12

IP Distributed Portscan

13

IP Filtered Portscan

14

IP Filtered Decoy Portscan

15

IP Filtered Distributed Portscan

16

IP Filtered Portsweep

17

UDP Portscan

18

UDP Decoy Portscan

19

UDP Portsweep

20

UDP Distributed Portscan


860


Chapter 22

Portscan Detector SIDs (Continued) SID

Description

21

UDP Filtered Portscan

22

UDP Filtered Decoy Portscan

23

UDP Filtered Distributed Portscan

24

UDP Filtered Portsweep

25

ICMP Portsweep

26

ICMP Filtered Portsweep

27

Open port

The IP Defragmentor SIDs table describes the types of packets that generate each IP fragmentation-related SID. IP Defragmentor SIDs

Version 4.7

SID

Description

1

IP fragment with header options detected

2

Teardrop attack detected

3

Short fragment detected; possible DoS attack

4

Oversized IP fragment detected; fragment ends after reassembled packet

5

Zero-byte IP fragment detected

6

IP fragment of negative length detected

7

IP fragment of length greater than 65536 bytes detected

8

Overlapping fragments detected


861


Chapter 22

The SMTP Decoder SIDs table describes the types of packets that generate each SID related to the SMTP decoder. SMTP Decoder SIDs SID

Description

1

Attempted command buffer overflow

2

Attempted data header buffer overflow

3

Attempted response buffer overflow

4

Attempted specific command buffer overflow

5

Unknown command

6

Illegal command

7

Attempted header name buffer overflow

The FTP Decoder SIDs table describes the types of packets that generate each SID related to the FTP decoding functionality of the FTP Telnet decoder. FTP Decoder SIDs

Version 4.7

SID

Description

1

Telnet command on FTP command channel

2

Invalid FTP command

3

FTP parameter length overflow

4

FTP malformed parameter

5

Possible string/format attempt in FTP command/parameter

6

FTP response length overflow

7

FTP command channel encrypted

8

FTP bounce attack

9

Evasive Telnet command on FTP command channel


862


Chapter 22

The Telnet Decoder SIDs table describes the types of packets that generate each SID related to the Telnet decoding functionality of the FTP Telnet decoder. Telnet Decoder SIDs SID

Description

1

Telnet consecutive Are You There (AYT) overflow

2

Telnet data encrypted

3

Subnegotiation Begin without matching Subnegotiation End

The Stream 5 Stateful Inspection and Stream Reassembly SIDs table describes the types of packets that generate each Stream 5 stateful inspection and stream reassembly SID. Stream 5 Stateful Inspection and Stream Reassembly SIDs

Version 4.7

SID

Description

1

SYN on established session

2

Data on SYN packet

3

Data sent on stream not accepting data

4

TCP Timestamp is outside of PAWs window

5

Bad segment

6

Window size (after scaling) larger than policy allows

7

Limit on number of overlapping TCP segments

8

Data sent in stream after TCP reset

9

TCP client possibly hijacked, different Ethernet address

10

TCP server possibly hijacked, different Ethernet address


863

Tuning Preprocessors Understanding Packet Decoding

Chapter 22

The DNS SIDs table describes the types of packets that generate each SID related to the DNS preprocessor. DNS SIDs SID

Description

1

Obsolete DNS RData type

2

Experimental DNS RData type

3

Client RData text overflow

Understanding Packet Decoding Requires: IPS or DC/MDC + IPS

Before sending captured packets to a preprocessor, the detection engine first sends the packets to the packet decoder. The packet decoder takes the packet data and converts the packet headers and payloads into a format that can be easily used by the preprocessors and the rules engine. Each layer of the stack is decoded in turn, beginning with the data link layer and continuing through the network and transport layers. For more information on packet decoding, see Capturing and Decoding Packets on page 641. For details on the GID and SIDs associated with the packet decoder, see the Generator IDs table on page 851 and the Packet Decoder SIDs table on page 856. For details on how to edit your configuration, see Configuring Standard Preprocessor Options on page 943.

Validating Checksums Requires: IPS or DC/MDC + IPS

By default, IPS validates all protocol-level checksums to ensure that complete IP, TCP, UDP, and ICMP transmissions are received, and that, at a basic level, packets have not been tampered with or accidentally altered in transit. A checksum uses an algorithm to validate the integrity of a protocol in the packet. If the detection engine and the end host compute the same value, the packet is considered to be unchanged. You can enable or disable IP, TCP, UDP, ICMP or all checksum verification on IPS. Enabling checksum verification allows the rules engine to verify that the header and payload data was not corrupted in transit. Disabling checksums can leave your network susceptible to insertion attacks. For details on how to edit your configuration, see Configuring Standard Preprocessor Options on page 943.

Version 4.7


864


Chapter 22

Disabling Decoding Event Alerting Requires: IPS or DC/MDC + IPS

You can disable alerting on events generated by the packet decoder during the decoding phase of preprocessing. For example, if the decoder detects a malformed protocol header and generates an event to alert on the header condition, selecting Disable Decode Events will suppress that event. For details on how to edit your configuration, see Configuring Standard Preprocessor Options on page 943.

Disabling Decode Drops Requires: IPS or DC/MDC + IPS

You can configure the system to drop packets that trigger events when packet decoder events are enabled for an IPS with an inline intrusion policy. IPS generates events for packets dropped during decoding. When you disable decode packet dropping, decoding events are generated for enabled decoding options and IPS does not drop packets during decoding. Enabling or disabling decode drops determines whether packets are dropped for TCP options with invalid lengths, which is not configurable, and for the following configurable packet decoder options: •

Disable Decode Events. For more information, see Disabling Decoding Event Alerting on page 865.

•

Disable Events on Invalid IP Options. For more information, see Detecting Invalid IP Options on page 865.

•

Disable Events on All Other TCP Options. For more information, see Detecting Invalid TCP Options on page 866.

•

Disable Events for Experimental TCP Options. For more information, see Detecting Experimental TCP Options on page 866.

•

Disable Events on Obsolete TCP Options. For more information, see Detecting Obsolete TCP Options on page 867.

•

Disable Events on T/TCP. For more information, see Detecting T/TCP Options on page 868.

For details TCP options with invalid lengths, which is not configurable, see Detecting TCP Options with Invalid Lengths on page 868. For details on how to edit your configuration, see Configuring Standard Preprocessor Options on page 943.

Detecting Invalid IP Options Requires: IPS or DC/MDC + IPS

Version 4.7

IPS can detect invalid IP header options to identify exploits that use invalid IP options. For example, there is a denial of service attack against a firewall which causes the system to freeze. The firewall attempts to parse invalid Timestamp and Security IP options and fails to check for a zero length, which causes an


865


Chapter 22

irrecoverable infinite loop. The rules engine identifies the zero length option, and provides information you can use to mitigate the attack at the firewall. For details on how to edit your configuration, see Configuring Standard Preprocessor Options on page 943.

Detecting Uncommon TCP Options Requires: IPS or DC/MDC + IPS

IPS allows you to detect the variety of types of TCP header options that may cause problems. See the following sections for more information: •

Detecting Invalid TCP Options on page 866

•

Detecting Experimental TCP Options on page 866

•

Detecting Obsolete TCP Options on page 867

•

Detecting T/TCP Options on page 868

•

Detecting TCP Options with Invalid Lengths on page 868

Detecting Invalid TCP Options Requires: IPS or DC/MDC + IPS

You can configure the system to generate events when it encounters TCP headers with invalid TCP options. For details on how to edit your configuration, see Configuring Standard Preprocessor Options on page 943.

Detecting Experimental TCP Options Requires: IPS or DC/MDC + IPS

You can configure the system to generate events when it encounters TCP headers with experimental TCP options. The Experimental TCP Options table lists and describes these options. Experimental TCP Options

Version 4.7

TCP Option

Description

9

Partial Order Connection Permitted

10

Partial Order Service Profile

14

Alternate Checksum Request

15

Alternate Checksum Data

18

Trailer Checksum

19

MD5 Signature Option


866


Chapter 22

Experimental TCP Options (Continued) TCP Option

Description

20

Space Communications Protocol Standards (SCPS)

21

Selective Negative Acknowledgements (SCPS)

22

Record Boundaries (SCPS)

23

Corruption (SPCS)

24

SNAP

26

TCP Compression Filter

Because these are experimental options, some systems do not account for them and can be open to exploits. IMPORTANT! In addition to the experimental options listed in the Experimental TCP Options table, the system considers any TCP option with an option number greater than 26 to be experimental. For details on configuring TCP option detection, see Configuring Standard Preprocessor Options on page 943. For a list of the GIDs and SIDs associated with detecting TCP options, see the Packet Decoder SIDs table on page 856.

Detecting Obsolete TCP Options Requires: IPS or DC/MDC + IPS

You can configure the system to generate events when it encounters TCP headers with obsolete TCP options. The Obsolete TCP Options table lists and describes these options. Obsolete TCP Options

Version 4.7

TCP Option

Description

6

Echo

7

Echo Reply

16

Skeeter


867

Tuning Preprocessors Understanding Network and Link-Layer Preprocessors

Chapter 22

Obsolete TCP Options (Continued) TCP Option

Description

17

Bubba

25

Unassigned

Because these are obsolete options, some systems do not account for them and can be open to exploits. For details on configuring TCP option detection, see Configuring Standard Preprocessor Options on page 943. For a list of the GIDs and SIDs associated with detecting TCP options, see the Packet Decoder SIDs table on page 856.

Detecting T/TCP Options Requires: IPS or DC/MDC + IPS

You can configure the system to generate events when it encounters TCP headers with the CC.ECHO option. The CC.ECHO option confirms that TCP for Transactions (T/TCP) is being used. Because T/TCP header options are not in widespread use, some systems do not account for them and can be open to exploits. For details on configuring TCP option detection, see Configuring Standard Preprocessor Options on page 943. For a list of the GIDs and SIDs associated with detecting TCP options, see the Packet Decoder SIDs table on page 856.

Detecting TCP Options with Invalid Lengths Requires: IPS or DC/MDC + IPS

IPS generates an event when it encounters TCP options with either the incorrect length or a length that places the option data outside the TCP header. Many operating systems and hardware devices drop these packets, but some systems do not account for them and are open to exploits. TIP! IPS always inspects for TCP options with invalid lengths. This is not a configurable option. For more information on the GIDs and SIDs associated with detecting TCP options, see the Packet Decoder SIDs table on page 856.

Understanding Network and Link-Layer Preprocessors Requires: IPS or DC/MDC + IPS

Version 4.7

Sourcefire provides preprocessors to detect attacks that exploit IP fragmentation and IP checksum validation. You can enable or disable the event generation


868


Chapter 22

without disabling the defragmentation, checksum validation, or detection of invalid IP header options. See the following sections for more information: •

Defragmenting IP Packets on page 869 describes IP fragmentation in normal traffic and IP fragmentation exploits, and explains how IPS reassembles IP fragments and generates events against packets with questionable fragmentation.

•

Validating Checksums on page 864 explains how to detect invalid IP checksums.

•

Disabling Decoding Event Alerting on page 865 describes how to disable alerting on events generated by the packet decoder.

•

Detecting Invalid IP Options on page 865 describes some of the exploits created using invalid IP options and explains how to detect them.

Defragmenting IP Packets Requires: IPS or DC/MDC + IPS

When an IP datagram is broken into two or more smaller IP datagrams because it is larger than the maximum transmission unit (MTU), it is fragmented. A single IP datagram fragment may not contain enough information to identify a hidden attack. Attackers may attempt to evade detection by transmitting attack data in fragmented packets. The IP defragmentation preprocessor reassembles fragmented IP datagrams before the rules engine executes rules against them so that the rules can more appropriately identify attacks in those packets. If fragmented datagrams cannot be reassembled, rules do not execute against them. See the following sections for more information: •

Understanding IP Fragmentation Exploits on page 869

•

Target-Based Defragmentation Policies on page 870

•

Selecting Defragmentation Options on page 871

Understanding IP Fragmentation Exploits Requires: IPS or DC/MDC + IPS

Enabling IP defragmentation helps you detect attacks against hosts on your network, like the teardrop attack, and resource consumption attacks against IPS itself, like the Jolt2 attack. The Teardrop attack exploits a bug in certain operating systems that causes them to crash when trying to reassemble overlapping IP fragments. When enabled and configured to do so, the IP defragmentation preprocessor identifies the overlapping fragments and generates an event against the packets.The IP defragmentation preprocessor generates an event for the first packets in an overlapping fragment attack such as Teardrop, but does not generate subsequent events for the same attack.

Version 4.7


869


Chapter 22

The Jolt2 attack sends a large number of copies of the same fragmented IP packet in an attempt to overuse IP defragmentors and cause a denial of service attack. A memory usage cap disrupts this and similar attacks in the IP defragmentation preprocessor, and places IPS self-preservation above exhaustive inspection. IPS is not overwhelmed by the attack, remains operational, and continues to inspect network traffic. Different operating systems reassemble fragmented packets in different ways. Attackers who can determine which operating systems your hosts are running can also fragment malicious packets so that a target host reassembles them in a specific manner. Because IPS does not know what operating systems the hosts on your monitored network are running, the preprocessor may reassemble and inspect the packets incorrectly, thus allowing an exploit to pass through undetected. To mitigate this kind of attack, you can configure the defragmentation preprocessor to use the appropriate method of defragmenting packets for each host on your network. See Target-Based Defragmentation Policies on page 870 for more information.

Target-Based Defragmentation Policies Requires: IPS or DC/MDC + IPS

A host's operating system uses three criteria to determine which packet fragments to favor when reassembling the packet: the order in which the fragment was received by the operating system, its offset (the fragment's distance, in bytes, from the beginning of the packet), and its beginning and ending position compared to overlap fragments. Although every operating system uses these criteria, different operating systems favor different fragments when reassembling fragmented packets. Therefore, two hosts with different operating systems on your network could reassemble the same overlapping fragments in entirely different ways. An attacker, aware of the operating system of one of your hosts, could attempt to evade IPS and exploit that host by sending malicious content hidden in overlapping packet fragments. This packet, when reassembled and inspected by IPS, seems innocuous, but when reassembled by the target host, contains a malicious exploit. However, if you configure the IP defragmentation preprocessor to be aware of the operating systems running on your monitored network segment, it will reassemble the fragments the same way that the target host does, allowing it to identify the attack. You can configure the IP defragmentation preprocessor to use one of seven defragmentation policies, depending on the operating system of the target host. The Target-Based Defragmentation Policies table lists the seven policies and the

Version 4.7


870


Chapter 22

operating systems that use each one. The First and Last policy names reflect whether those policies favor original or subsequent overlapping packets. Target-Based Defragmentation Policies Policy

Operating Systems • AIX

BSD

• FreeBSD • IRIX • VAX/VMS BSD-right

• HP JetDirect

First

• Mac OS • HP-UX

Linux

• Linux • OpenBSD

Last

• Cisco IOS

Windows

• Windows

Solaris

• SunOS

Selecting Defragmentation Options Requires: IPS or DC/MDC + IPS

Version 4.7

You can choose to simply enable or disable IP defragmentation; however, Sourcefire recommends that you specify the behavior of the enabled IP defragmentation preprocessor at a more granular level.


871


Chapter 22

The General Defragmentation Options table describes the global options you can configure for the IP defragmentation preprocessor. General Defragmentation Options Option

Description

IP Defragmentation

Enables IP defragmentation.

Preallocated Fragments

The maximum number of individual fragments that the preprocessor can process at once. Specifying the number of fragment nodes to preallocate enables static memory allocation. WARNING! Processing an individual fragment uses approximately 1550 bytes of memory. If the preprocessor requires more memory to process the individual fragments than the predetermined allowable memory limit for the 3D Sensor, the memory limit for the 3D Sensor takes precedence.

The Defragmentation Policy Options table describes the options you can configure for each IP defragmentation policy. Defragmentation Policy Options Option

Description

Policy

The defragmentation policy you want to use for a set of hosts on your monitored network segment. You can choose among seven policies: BSD, BSD-Right, First, Linux, Last, Windows, and Solaris. See Target-Based Defragmentation Policies on page 870 for detailed information on these policies.

Bind To

The IP address of the host or hosts to which you want to apply the defragmentation policy. You can specify multiple IP addresses separated by commas or use CIDR notation. See Specifying IP Addresses in Searches on page 1130 for detailed information about entering IP addresses. Note that the default policy covers all IP addresses on your monitored network segment that are not covered by a target-based policy. Therefore, you do not need to specify IP addresses for the default policy.

Version 4.7


872

Tuning Preprocessors Understanding Transport-Layer Preprocessors

Chapter 22

Defragmentation Policy Options (Continued) Option

Description

Timeout

The maximum amount of time, in seconds, that the preprocessor engine can use when reassembling a fragmented packet. If the packet cannot be reassembled within the specified time period, the preprocessor engine stops attempting to reassemble the packet and discards received fragments.

Minimum TTL

Specifies the minimum acceptable TTL value a packet may have without causing an alert. Use this to avoid TTL-based insertion attacks against IPS.

Detect Anomalies

Identifies and generates events against fragmentation problems such as overlapping fragments.

For details on how to edit your configuration, see Configuring Standard Preprocessor Options on page 943. For details on the GID and SIDs associated with IP defragmentation, see the Generator IDs table on page 851 and the IP Defragmentor SIDs table on page 861.

Understanding Transport-Layer Preprocessors Requires: IPS or DC/MDC + IPS

IPS detects and mitigates transport-layer protocol-based attacks by allowing you to configure it to perform stateful inspection of TCP packets, to reassemble TCP streams, to validate TCP, UDP, and ICMP checksums, to detect anomalous TCP traffic, and with the Stream 5 preprocessor, to track UDP sessions. These tools allow you to detect subterfuge attacks, and to mitigate DoS attacks like stick and snot, and to focus on evaluating your network traffic for intrusions and policy violations. See the following sections for more information:

Version 4.7

•

Comparing the Stream 4 and Stream 5 Preprocessors on page 874 compares the Stream 4 and Stream 5 transport-layer preprocessors.

•

Performing Stateful Inspection on TCP Packets on page 875 describes state-related exploits and explains how to monitor them by performing stateful packet inspection.

•

Reassembling TCP Streams on page 876 describes stream-related exploits and explains how to monitor them by inspecting complete client or server TCP streams.

•

Understanding the Stream 4 Preprocessor on page 877 describes the Stream 4 transport-layer preprocessor.


873


Chapter 22

•

Understanding the Stream 5 Preprocessor on page 882 describes the Stream 5 transport-layer preprocessor.

•

Detecting Encrypted Traffic Using the SSL Preprocessor on page 928 explains how the SSL preprocessor can be used to detect encrypted traffic and disable inspection of that traffic.


Comparing the Stream 4 and Stream 5 Preprocessors Requires: IPS or DC/MDC + IPS

IPS provides two transport-layer data stream preprocessors, Stream 4 and Stream 5. You can enable only one TCP stream preprocessor at a time. IMPORTANT! Sourcefire recommends that you migrate to the Stream 5 preprocessor to take advantage of its improved performance and IPS capabilities. The Stream 4 preprocessor was known as the Stateful Inspection and Stream Reassembly preprocessor until the introduction of Stream 5. Both preprocessors provide stateful inspection and reassembly of TCP packets, validation of TCP, UDP, and ICMP checksums, and TCP anomaly detection, although Stream 5 has the advantage of significantly improved performance and additional features. Stream 4 lets you configure only a single set of TCP detection and reassembly options to determine how IPS inspects and reassembles traffic for all hosts and all operating systems on your monitored network segment. Since different operating systems implement TCP differently and reassemble TCP traffic differently, treating all traffic in the same way could result in IPS not detecting some attacks. Stream 5 lets you configure multiple TCP policies that target particular operating systems on your network hosts. You can fine tune IPS to more precisely identify TCP anomalies and to reassemble streams the same way the receiving operating system reassembles them. Targeted anomaly detection and stream reassembly greatly improve the ability of IPS to detect attacks that try to take advantage of the characteristics of different operating systems. Stream 4 reassembles streams specified by a single list of reassembly ports for the client side, the server side, or both sides. Stream 5, in contrast, allows you to identify port lists individually for each side of the traffic. Finally, you can configure Stream 4 for stateful inspection of TCP traffic only. Stream 5, however, also gives you the option of tracking UDP sessions based on the source and destination IP addresses and UDP ports. UDP session tracking

Version 4.7


874


Chapter 22

lets you use the flow and flowbits keywords to determine the direction and state of UDP traffic and coordinate multiple UDP packets in a session. The Stream 4 and Stream 5 Features and Performance Comparison table compares major performance characteristics and features of the Stream 4 and Stream 5 preprocessors. Stream 4 and Stream 5 Features and Performance Comparison Feature

Stream 4

Stream 5

Performance

Legacy

Improved

TCP stateful inspection

Legacy

Improved

Target-based TCP policies

No

Yes

TCP reassembly ports

One port list for client, server, or both

Independent port lists for client, server, and both

Configure UDP session tracking

No

Yes

For more information on the Stream 4 preprocessor, see Understanding the Stream 4 Preprocessor on page 877. For more information on the Stream 5 preprocessor, see Understanding the Stream 5 Preprocessor on page 882.

Performing Stateful Inspection on TCP Packets Requires: IPS or DC/MDC + IPS

The TCP protocol defines various states in which connections can exist. Each TCP connection is identified by the source and destination IP addresses and source and destination ports. TCP permits only one connection with the same connection parameter values to exist at a time. See the following sections for more information: •

Understanding State-Related TCP Exploits on page 875.

•

Selecting Stream 4 Stateful Inspection Options on page 878.

Understanding State-Related TCP Exploits Requires: IPS or DC/MDC + IPS

Version 4.7

If you add the flow keyword with the established attribute to a rule, the rules engine inspects packets matching the rule and the flow directive in stateful mode. Stateful mode evaluates only the traffic that is part of a TCP session established


875


Chapter 22

with a legitimate three-way handshake between a client and server. The following diagram illustrates a three-way handshake.

You can configure the system so that the preprocessor generates an event for any TCP traffic that cannot be identified as part of an established TCP session, although this is not recommended for typical use because the events would quickly overload the system and not provide meaningful IPS data. Attacks like stick and snot use IPS’s extensive rule sets and packet inspection against itself. These tools generate packets based on the patterns in Snort-based intrusion rules, and send them across the network. If you do not enable stateful inspection in your rules, each packet triggers the rule, overwhelming the system. Stateful inspection allows you to ignore these packets because they are not part of an established TCP session and do not provide meaningful information. When performing stateful inspection, the rules engine generates events against only those attacks that are part of an established TCP session, allowing analysts to focus on these events rather than the volume of events caused by stick or snot. Additionally, stateful inspection allows you to detect SYN and FIN scans against your network because they are not part of an established session. You can configure the preprocessor to alert on unusual combinations of TCP flags that indicate this type of scan.

Reassembling TCP Streams Requires: IPS or DC/MDC + IPS

Version 4.7

The Stream 4 TCP stream preprocessor collects and reassembles all the packets that are part of a TCP session’s server-to-client communication stream or clientto-server communication stream. Stream 5 also collects and reassembles TCP packets and, in addition, lets you optionally select reassembled packets for inspection for different ports in client and server traffic. Reassembly by either


876


Chapter 22

preprocessor allows inspection of the stream as a single, reassembled entity rather than inspecting only the individual packets that are part of a given stream. WARNING! You must ensure that the Stream 4 or Stream 5 preprocessor remains enabled to use the FTP Telnet, HTTP, and SMTP preprocessors, as well as many intrusion rules that require stream reassembly.

IMPORTANT! Any ports you add to the server-level FTP ports list, the HTTP ports list, or the SMTP ports list should also be added to the TCP stream reassembly port list. For more information on configuring server-level FTP ports, see Understanding Server-Level FTP Options on page 914. For more information on configuring HTTP ports, see Selecting Server-Level HTTP Normalization Options on page 894. For more information on configuring SMTP ports, see Decoding SMTP Traffic on page 905. See the following sections for more information: •

Understanding Stream-Based Attacks on page 877

•

Selecting Stream 4 Reassembly Options on page 880

•

Selecting Stream 5 Stream Reassembly Options on page 886

Understanding Stream-Based Attacks Requires: IPS or DC/MDC + IPS

Stream reassembly allows the rules engine to identify stream-based attacks, which it may not detect when inspecting individual packets. You can specify which communication streams the rules engine reassembles based on your network needs. For example, when monitoring traffic on your web servers, you may only want to inspect client traffic since you are much less likely to receive malicious traffic from your own web server.

Understanding the Stream 4 Preprocessor Requires: IPS or DC/MDC + IPS

If you add the flow:established keyword to a rule, Stream 4 stateful inspection occurs when the Stream 4 preprocessor is enabled and the rules engine processes packets against that rule. The Stream 4 preprocessor collects state information from packets for use by the rules engine. For more information, see the following sections:

Version 4.7

•

Selecting Stream 4 Stateful Inspection Options on page 878

•

Selecting Stream 4 Reassembly Options on page 880

•

Configuring the Stream 4 Preprocessor on page 880


877


Chapter 22

Selecting Stream 4 Stateful Inspection Options Requires: IPS or DC/MDC + IPS

You can set parameters to explicitly control stateful inspection. The Stream 4 Stateful Inspection Options table describes these parameters for the Stream 4 preprocessor. Stream 4 Stateful Inspection Options Option

Description

Disable Inspection for Unreassembled Packets

Disables stateful inspection. By default, Sourcefire disables this option so the rules engine performs stateful inspection.

Detect Stateful Inspection Anomalies

Generates events when the stream preprocessor detects anomalous behavior in the TCP stack. This can generate many events if TCP/IP stacks are poorly written. By default, Sourcefire disables this option.

Disable Evasion Alerts

Disables alerting on packets with possible evasion techniques such as TCP payloads with the SYN flag set or overlapping TCP segments. By default, Sourcefire enables this option.

Enforce State

Causes preprocessor to ignore TCP traffic that is not part of a correctly established session. By default, Sourcefire disables this option. TIP! Select this option in asynchronous TCP traffic environments to mitigate issues with detection engine overload.

Zero Flushed Packets

Causes preprocessor to zero out memory used to store packets for reassembly between session reassemblies. Select this option to help eliminate false positives due to residual data from previous reassemblies. By default, Sourcefire disables this option. WARNING! Enabling this option may have a performance impact, resulting in dropped packets during the CPU time used to zero out the memory.

Flush on Alert

Flushes the reassembly buffer and forces stream reassembly when an individual packet in the stream triggers an alert. By default, Sourcefire disables this option. IMPORTANT! The option is only available if you first import an SEU containing Snort 2.8.1 or later.

Version 4.7


878


Chapter 22

Stream 4 Stateful Inspection Options (Continued) Option

Description

Timeout

The amount of time, in seconds, the rules engine keeps an inactive stream in the state table. If the stream is not reassembled in the specified amount of time, the rules engine deletes it from the state table. By default, Sourcefire sets this option to 180 seconds. IMPORTANT! If your 3D Sensor is deployed on a segment where the network traffic is likely to reach the sensor’s bandwidth limits, you should consider setting this value higher (for example, to 600 seconds) to lower the amount of processing overhead.

TTL Variance

The delta that the system alerts on when receiving multiple packets with differing TTLs in a single session. By default, Sourcefire disables TTL variance by leaving it blank.

Overlap Limit

Triggers an alert when the number of overlapping packets exceeds the configured threshold. Specifying a number between 1 and 256 of overlapping packets to permit before triggering an alert enables the overlap limit. By default, Sourcefire disables setting an overlap limit by leaving it blank. IMPORTANT! Enabling this option could lead to a large number of alerts. IMPORTANT! The option is only available if you first import an SEU containing Snort 2.8.1 or later.

For details on configuring the Stream 4 preprocessor, see Configuring the Stream 4 Preprocessor on page 880.

Version 4.7


879


Chapter 22

Selecting Stream 4 Reassembly Options Requires: IPS or DC/MDC + IPS

You can specify the stream or streams the rules engine reassembles. The Stream 4 Stream Reassembly Options table describes the options you can select. Stream 4 Stream Reassembly Options Option

Description

Client

Enables stream reassembly for the client side of the connection only. In other words, it reassembles streams destined for web servers, mail servers, or other IP addresses typically defined by the IP addresses specified in $HOME_NET. Use this option when you expect malicious traffic to originate solely from clients. By default, Sourcefire uses client only.

Server

Enables stream reassembly for the server side of the connection only. In other words, it reassembles streams originating from web servers, mail servers, or other IP addresses typically defined by the IP addresses specified in $EXTERNAL_NET. Use this option when you want to watch for server side attacks.

Both

Enables stream reassembly for both the client and server side of the connection. Use this option when you expect that malicious traffic may travel in either direction between clients and servers.

Additionally, you can specify the ports whose traffic the preprocessor engine reassembles. Use the ports option to specify a white-space-separated list of ports for reassembly; specify all as the argument to provide reassembly for all ports. Sourcefire does not recommend setting ports to all because it can increase the amount of traffic inspected by this preprocessor and slow performance unnecessarily. By default, the ports option specifies client ports 21, 23, 25, 42, 53, 80, 110, 111, 135, 136, 137, 139, 143, 445, 513, 514, 1433, 1521, 2401, and 3306. For details on configuring the Stream 4 preprocessor, see Configuring the Stream 4 Preprocessor on page 880.

Configuring the Stream 4 Preprocessor Requires: IPS or DC/MDC + IPS

You can configure stateful inspection and stream reassembly options for the Stream 4 preprocessor. To configure Stream 4 options:


1.


2. Click Edit next to the policy whose preprocessor options you want to configure. The Edit Policy page appears.

Version 4.7


880


Chapter 22

3. Click Stream Configuration. The Stream Configuration page appears. Which stream configuration settings appear depends on whether the Stream 4 or Stream 5 preprocessor is currently selected. Either: •

the Stream 5 preprocessor is currently selected; select Stream 4 next to Stream Version

•

the Stream 4 preprocessor is currently selected

The Stream 4 Configuration section appears.

4. You can do any of the following: •

Select or clear Stateful Inspection and Stream Reassembly to enable or disable stream preprocessing.

WARNING! You cannot disable Stateful Inspection and Stream Reassembly when the FTP Telnet, HTTP, or SMTP preprocessor is enabled, and you should not disable it when you have rules enabled that use the flow or flowbits keyword since these rules will not trigger unless a stream preprocessor is enabled. •

Select Stream 5 to select the Stream 5 preprocessor.

•

Modify any of the Stream 4 configuration settings. See the Stream 4 Stateful Inspection Options table on page 878 for a description of the Stateful Inspection options you can configure. See the Stream 4 Stream Reassembly Options table on page 880 for a description of the Stream Reassembly options you can configure.

5. Click Save. 6. Click Back to return to the Edit Policy page. You must apply the policy containing your preprocessor configuration to implement your changes. See Applying an Intrusion Policy on page 764 for procedures.

Version 4.7


881


Chapter 22

Understanding the Stream 5 Preprocessor Requires: IPS or DC/MDC + IPS

If you add the flow:established keyword to a TCP or UDP rule, Stream 5 stream tracking occurs when the Stream 5 preprocessor is enabled and the rules engine processes packets against that rule. The Stream 5 preprocessor collects state information from packets for use by the rules engine. For more information, see the following sections: •

Understanding Target-Based TCP Policies on page 882

•

Selecting TCP Policy Options on page 884

•

Selecting Stream 5 Stream Reassembly Options on page 886

•

Understanding UDP Session Tracking on page 887

•

Configuring the Stream 5 Preprocessor on page 887

Understanding Target-Based TCP Policies Requires: IPS or DC/MDC + IPS

Different operating systems implement TCP in different ways. For example, Windows and some other operating systems require a TCP reset segment to have a precise TCP sequence number to reset a session, while Linux and other operating systems permit a range of sequence numbers. In this example, Stream 5 must understand exactly how the destination host will respond to the reset based on the sequence number. Stream 5 stops tracking the session only when the destination host considers the reset to be valid, so an attack cannot evade IPS by sending packets after Stream 5 stops inspecting the stream. Other variations in TCP implementations include such things as whether an operating system employs a TCP timestamp option and, if so, how it handles the timestamp, and whether an operating system accepts or ignores data in a SYN packet. Different operating systems also reassemble overlapping TCP segments in different ways. Overlapping TCP segments could reflect normal retransmissions of unacknowledged TCP traffic. They could also represent an attempt by an attacker, aware of the operating system of one of your hosts, to evade IPS and exploit that host by sending malicious content hidden in overlapping segments. However, you can configure the Stream 5 preprocessor to be aware of the operating systems running on your monitored network segment so it reassembles segments the same way the target host does, allowing it to identify the attack. You can create one or more TCP policies to tailor Stream 5 inspection and reassembly to the different operating systems on your monitored network segment. For each policy, you identify one of thirteen operating system policies. You bind each TCP policy to a specific IP address or CIDR block, using as many TCP policies as you need to identify any or all of the hosts using a different operating system. The default TCP policy applies to any hosts on the monitored network that you do not identify in any other TCP policy, so there is no need to specify an IP address or CIDR block for the default TCP policy.

Version 4.7


882


Chapter 22

The TCP Operating System Policies table lists the thirteen operating system policies and the host operating systems that use each. TCP Operating System Policies Policy

Operating Systems

First

• unknown OS

Last

• Cisco IOS

BSD

• AIX • FreeBSD • OpenBSD

Linux

• Linux 2.4 kernel • Linux 2.6 kernel

Old Linux

• Linux 2.2 and earlier kernel

Windows

• Windows 98 • Windows NT • Windows 2000 • Windows XP

Windows 2003

• Windows 2003

Windows Vista

• Windows Vista

Solaris

• Solaris OS • SunOS

IRIX

• SGI Irix

HPUX

• HP-UX 11.0 and later

HPUX 10

• HP-UX 10.2 and earlier

Mac OS

• Mac OS 10 (Mac OS X)

TIP! The First operating system policy could offer some protection when you do not know the host operating system. However, it may result in missed attacks. You should edit the policy to specify the correct operating system when you know

Version 4.7


883


Chapter 22

it.

Selecting TCP Policy Options Requires: IPS or DC/MDC + IPS

The Stream 5 TCP Policy Options table describes the options you can set to identify and control traffic that the Stream 5 preprocessor inspects. Stream 5 TCP Policy Options Option

Description

TCP Policy OS

Identifies the TCP policy operating system of the target host or hosts. For more information, see Understanding TargetBased TCP Policies on page 882.

Timeout

The number of seconds between 1 and 86400 the rules engine keeps an inactive stream in the state table. If the stream is not reassembled in the specified time, the rules engine deletes it from the state table. IMPORTANT! If your 3D Sensor is deployed on a segment where the network traffic is likely to reach the sensor’s bandwidth limits, you should consider setting this value higher (for example, to 600 seconds) to lower the amount of processing overhead.

Min TTL

Specifies the minimum acceptable TTL value between 1 and 255 a packet may have without causing an alert. Use this to avoid TTL-based insertion attacks against a 3D Sensor.

Maximum TCP Window

Specifies the maximum TCP window size between 1 and 1073725440 bytes allowed by IPS as specified by a receiving host. Setting the value to 0 disables checking for the TCP window size. WARNING! The upper limit is the maximum window size permitted by RFC, and is intended to prevent an attacker from evading detection, but setting a significantly large maximum window size could result in a self-imposed denial of service.

Overlap Limit

Version 4.7

Specifies that when the configured number between 0 (unlimited) and 255 of overlapping segments in a session has been detected, segment reassembly stops for that session and, if Stateful Inspection Anomalies is enabled, an alert is logged.


884


Chapter 22

Stream 5 TCP Policy Options (Continued) Option

Description

Stateful Inspection Anomalies

Generates events when the stream preprocessor detects anomalous behavior in the TCP stack. This can generate many events if TCP/IP stacks are poorly written.

Require TCP 3-Way Handshake

Specifies that sessions are treated as established only upon completion of a TCP three-way handshake. Disable this option to increase performance, protect from SYN flood attacks, and permit operation in a partially asynchronous environment. Enable it to avoid attacks that attempt to generate false positives by sending information that is not part of an established TCP session.

Alternate Timeout

Specifies the number of seconds between 0 (unlimited) and 86400 (twenty-four hours) by which a handshake must be completed when Require TCP 3-Way Handshake is enabled.

Performance Boost

Sets the preprocessor to not queue large packets in the reassembly buffer. This performance improvement could result in missed attacks. Disable this option to protect against evasion attempts using small packets of one to twenty bytes. Enable it when you are assured of no such attacks because all traffic is comprised of very large packets.

Legacy Reassembly

Sets the Stream 5 preprocessor to emulate the Stream 4 preprocessor when reassembling packets, which lets you compare events on a sensor using the Stream 5 preprocessor to events based on the same data stream on a sensor using the Stream 4 preprocessor.

IP/CIDR

Specifies a valid IP address or CIDR block notation that identifies the host or hosts to which you want to apply the TCP stream reassembly policy. IMPORTANT! The preprocessor applies any additional policies in reverse order, starting with the most recently added policy. The blank field in the default policy specifies all IP addresses (0.0.0.0/0) on your monitored network segment that are not covered by another target-based policy. Therefore, you cannot and do not need to specify an IP address or CIDR block for the default policy, and you cannot specify 0.0.0.0/0 or leave this setting blank in another policy.

Version 4.7


885


Chapter 22

Selecting Stream 5 Stream Reassembly Options Requires: IPS or DC/MDC + IPS

You can specify a white-space-separated list of ports to identify the traffic for Stream 5 to reassemble. The Stream 5 Stream Reassembly Options table describes the options you can select. Stream 5 Stream Reassembly Options Option

Description

Client Ports

Enables stream reassembly for the client side of the connection. In other words, it reassembles streams destined for web servers, mail servers, or other IP addresses typically defined by the IP addresses specified in $HOME_NET. Use this option when you expect malicious traffic to originate from clients. By default, IPS uses client ports 21, 23, 25, 42, 53, 80, 110, 111, 135, 136, 137, 139, 143, 445, 513, 514, 1433, 1521, 2401, and 3306.

Server Ports

Enables stream reassembly for the server side of the connection only. In other words, it reassembles streams originating from web servers, mail servers, or other IP addresses typically defined by the IP addresses specified in $EXTERNAL_NET. Use this option when you want to watch for server side attacks. By default, Sourcefire disables this option by not specifying ports.

Both Ports

Enables stream reassembly for both the client and server side of the connection. Use this option when you expect that malicious traffic for the same ports may travel in either direction between clients and servers. By default, Sourcefire disables this option by not specifying ports.

You can specify separate lists of ports for any combination of client ports, server ports, and both. For example, assume that you wanted to reassemble the following: •

SMTP (port 25) traffic from the client

•

FTP server responses (port 21)

•

telnet (port 23) traffic in both directions

You could configure the following: •

For Client Ports, specify 23 25

•

For Server Ports, specify 21 23

Or, instead, you could configure the following:

Version 4.7

•

For Client Ports, specify 25

•

For Server Ports, specify 21

•

For Both Ports, specify 23


886


Chapter 22

You can also specify all as the argument to provide reassembly for all ports. Sourcefire does not recommend setting ports to all because it can increase the amount of traffic inspected by this preprocessor and slow performance unnecessarily. For details on configuring the Stream 5 preprocessor, see Configuring the Stream 5 Preprocessor on page 887.

Understanding UDP Session Tracking Requires: IPS or DC/MDC + IPS

If you add the flow:established keyword to a UDP rule, Stream 5 stream tracking occurs when the rules engine processes packets against that rule. UDP is a connectionless protocol. It does not provide a means for two endpoints to establish a communication channel, exchange data, and close the channel. UDP data streams are not typically thought of in terms of sessions. However, the Stream 5 preprocessor uses the source and destination IP address fields in the encapsulating IP datagram header and the port fields in the UDP header to determine the direction of flow and identify a session. A session ends when a configurable timer is exceeded, or when either endpoint receives an IMCP message that the other endpoint is unreachable or the requested service is unavailable. The UDP Session Tracking Options table describes the Stream 5 parameters you can set to explicitly control UDP session tracking. UDP Session Tracking Options

Timeout

The amount of time, in seconds, the rules engine keeps an inactive stream in the state table. If additional datagrams are not seen in the specified amount of time, the rules engine deletes it from the state table. By default, Sourcefire sets this option to 30 seconds.

Performance Boost

Sets the preprocessor to ignore UDP traffic for all ports that are not specified in enabled rules, except when a UDP rule with both the source and destination ports set to any has a flow or flowbits option. This performance improvement could result in missed attacks.

Configuring the Stream 5 Preprocessor Requires: IPS or DC/MDC + IPS

Version 4.7

You can configure TCP stateful inspection, TCP stream reassembly, and UDP session tracking options for the Stream 5 preprocessor.


887


Chapter 22

To configure Stream 5 options: Access: Rules or Admin

1.


2. Click Edit next to the policy whose preprocessor options you want to configure. The Edit Policy page appears. 3. Click Stream Configuration. The Stream Configuration page appears. Which stream configuration settings appear depends on whether the Stream 4 or Stream 5 preprocessor is currently selected. Either: •

the Stream 4 preprocessor is currently selected; select Stream 5 next to Stream Version

•

the Stream 5 preprocessor is currently selected

The Stream 5 Configuration section appears.

Version 4.7


888

Tuning Preprocessors Understanding Application-Layer Preprocessors

Chapter 22

4. Optionally, you can do any of the following: •

Select or clear Stateful Inspection and Stream Reassembly to enable or disable stream preprocessing.

WARNING! You cannot disable Stateful Inspection and Stream Reassembly when the FTP Telnet, HTTP, or SMTP preprocessor is enabled, and you should not disable it when you have rules enabled that use the flow or flowbits keyword since these rules will not trigger unless a stream preprocessor is enabled. •

Select Stream 4 to select the Stream 4 preprocessor.

•

Select or clear the Track TCP option to enable or disable TCP stateful inspection and stream reassembly. For more information, see Performing Stateful Inspection on TCP Packets on page 875 and Reassembling TCP Streams on page 876.

•

Click the orange arrow beside the TCP Policy (Default -) option to toggle display of the default TCP policy and any additional TCP policies; you can modify any of the options in a TCP policy. For more information see Selecting TCP Policy Options on page 884.

•

Click Add TCP Policy to add a target-based policy. For more information, see Understanding Target-Based TCP Policies on page 882.

•

Click Delete beneath a TCP policy to delete the policy.

•

Select or clear Track UDP to enable or disable UDP session tracking. For more information, see Understanding UDP Session Tracking on page 887.

•

Modify any of the UDP session tracking options. For more information, see the UDP Session Tracking Options table on page 887.


Understanding Application-Layer Preprocessors Requires: IPS or DC/MDC + IPS

Version 4.7

Application-layer protocols can represent the same data in a variety of ways. Sourcefire provides data normalization preprocessors, or application-layer protocol decoders, to render specific types of packet data in a format that the rules engine can analyze. Normalizing application-layer protocol encodings allows the rules engine to effectively apply the same content-related rules to packets whose data is represented differently and obtain meaningful results.


889


Chapter 22

Another application-layer preprocessor, the DCE/RPC preprocessor, reassembles fragmented DCE/RPC packets for the rules engine to analyze. See the following sections for more information: •

Decoding RPC Traffic on page 890 describes the RPC decoder and explains how to configure it to normalize RPC traffic.

•

Decoding HTTP Traffic on page 891 describes the HTTP decoder and explains how to configure it to normalize HTTP traffic.

•

Decoding SMTP Traffic on page 905 describes the SMTP decoder and explains how to configure it to normalize SMTP traffic.

•

Decoding FTP and Telnet Traffic on page 909 describes the FTP Telnet decoder and explains how to configure it to normalize and decode FTP and Telnet traffic.

•

Understanding DCE/RPC Traffic Reassembly on page 921 describes the DCE/RPC preprocessor and explains how to configure it to reassemble DCE/RPC traffic.

•


•


Decoding RPC Traffic Requires: IPS or DC/MDC + IPS

IPS provides RPC (Remote Procedure Call) normalization, which takes fragmented RPC records and normalizes them to a single record so the rules engine can inspect the complete record. For example, an attacker may attempt to discover the port where RPC admind runs. Some UNIX hosts use RPC admind to perform remote distributed system tasks. If the host performs weak authentication, a malicious user could take control of remote administration. SID 575 detects this attack by searching for content in specific locations to identify inappropriate portmap GETPORT requests. See the following sections for more information:

Version 4.7

•

Selecting RPC Normalization Options on page 891.

•

Configuring Standard Preprocessor Options on page 943.


890


Chapter 22

Selecting RPC Normalization Options Requires: IPS or DC/MDC + IPS

By default, Sourcefire enables this preprocessor. You can enable or disable RPC normalization, and you can configure the options described in the RPC Normalization Options table. RPC Normalization Options Option

Description

Alert on Fragments

Generates events against all RPC fragmented records it finds.

Disable Alerts on Large Fragments

Suppresses alerts on large fragments when the reassembled fragment record length exceeds the current packet length.

Disable Alerts on Incomplete Fragments

Suppresses alerts when a partial record is found.

Disable Alerts on Multiple Requests

Suppresses alerts when there is more than one RPC request per packet (or reassembled packet).

Additionally, you can specify the ports whose traffic you want to normalize. In the interface, list multiple ports separated by spaces. Sourcefire sets the port defaults to ports 111 and 32771. If your network has open ports above 32771, consider adding them. IMPORTANT! Any ports you add to the RPC ports list should also be added to the TCP Reassembly port list. For more information on configuring TCP Reassembly ports, see Reassembling TCP Streams on page 876. For details on configuring preprocessors, see Configuring Standard Preprocessor Options on page 943. For a description of the GID and SIDs associated with RPC normalization, see the RPC Decoder SIDs table on page 854.

Decoding HTTP Traffic Requires: IPS or DC/MDC + IPS

Version 4.7

The HTTP Inspect preprocessor is responsible for: •

decoding and normalizing URI data sent to and received from web servers on your network

•

detecting and generating events against possible URI-encoding attacks

•

making the normalized data available for additional rule processing


891


Chapter 22

HTTP traffic can be encoded in a variety of formats, making it difficult for rules to appropriately inspect. HTTP Inspect decodes 14 types of encoding, ensuring that your HTTP traffic gets the best inspection possible. You can configure HTTP Inspect options globally, or on a server-by-server basis. You can also disable or enable each available alert independently, as needed. The preprocessor engine performs HTTP normalization statelessly. That is, it normalizes HTTP strings on a packet-by-packet basis, and can only process HTTP strings that have been reassembled by the TCP stream preprocessor. See the following sections for more information: •

Selecting Global HTTP Normalization Options on page 892

•

Configuring Global HTTP Inspection Options on page 893

•

Selecting Server-Level HTTP Normalization Options on page 894

•

Default Server Profiles on page 897

•

Configuring Server-Level HTTP Inspection Options on page 901

Selecting Global HTTP Normalization Options Requires: IPS or DC/MDC + IPS

The global HTTP options provided for the HTTP Inspect preprocessor control how the preprocessor functions. Use these options to enable or disable HTTP normalization and to generate events when ports not specified as web server ports receive HTTP traffic. The Global HTTP Normalization Options table describes the options you can specify globally for HTTP normalization. Global HTTP Normalization Options Option

Description

Detect Anomalous Server

Generates an event on HTTP traffic sent to or received by ports not specified as web server ports. WARNING! If you turn this option on, make sure to list all ports that do receive HTTP traffic in a server profile on the HTTP Inspection page. If you do not, normal traffic to and from the server will generate alerts. The default server profile contains all ports normally used for HTTP traffic, but if you modified or deleted that profile, you may need to add those ports to another profile to prevent alerts from occurring.

Alert on HTTP Proxy Servers

Version 4.7

Generates an event on HTTP traffic using proxy servers not defined by the Allow HTTP Proxy option.


892


Chapter 22

For details on configuring the global HTTP normalization options, see Configuring Global HTTP Inspection Options on page 893.

Configuring Global HTTP Inspection Options Requires: IPS or DC/MDC + IPS

You can configure alerting on HTTP traffic to non-standard ports and on HTTP traffic using proxy servers. To configure global HTTP inspection options:


1.


2. Click Edit next to the policy you want to edit. The Edit Policy page appears. 3. Click HTTP Inspection. The HTTP Inspection page appears.

4. Select the global inspection options you want to enable. See the Global HTTP Normalization Options table on page 892 for details on global inspection options.

Version 4.7


893


Chapter 22

5. Click Save. 6. Click Back to return to the Edit Policy page.

Selecting Server-Level HTTP Normalization Options Requires: IPS or DC/MDC + IPS

You can set server-level options for all servers, or you can configure specific options for each server you monitor. Additionally, you can use a predefined server profile to set these options, or you can set them individually to meet the needs of your environment. Use these options, or one of the default profiles that set these options, to specify the HTTP server ports whose traffic you want to normalize, the amount of server response payload you want to normalize, and the types of encoding you want to normalize and generate alerts against. The Server-Level HTTP Normalization Options table describes the normalization options you can set for custom server profiles. Server-Level HTTP Normalization Options Option

Description

Ports

The ports whose HTTP traffic the preprocessor engine normalizes. Separate multiple port numbers with spaces. IMPORTANT! Any ports you add to the server-level HTTP ports list should also be added to the TCP Reassembly port list. For more information on configuring TCP Reassembly ports, see Reassembling TCP Streams on page 876.

Oversize Dir Length

Generates an event against URL directories longer than the specified value.

Flow Depth

The amount of server response payload to inspect, in bytes. IMPORTANT! Most HTTP server rules inspect the HTTP header and a few bytes after that. Setting the flow depth to 150-300 bytes, in most cases, causes these rules to inspect the relevant part of the payload.

Maximum Header Length

Generates an event against an HTTP client request header field longer than the specified maximum number of bytes. The default value of 0 disables the alert. Specify a value of 1 to 65535 to enable it. IMPORTANT! This feature is only available if you first import an SEU containing Snort 2.8.1 or later.

No Alerts

Disables all HTTP Inspect events. IMPORTANT! This option does not disable HTTP rules.

Version 4.7


894


Chapter 22

Server-Level HTTP Normalization Options (Continued) Option

Description

Inspect URL Only

Inspects the URL portion of the packet only.

Allow HTTP Proxy Use

Allows the monitored web server to be used as an HTTP proxy.

Additionally, you can select server-level HTTP normalization options to specify the types of encoding that are normalized for HTTP traffic, and to cause the system to generate events against traffic containing this type of encoding. The Server-Level HTTP Normalization Encoding Options table describes the types of decoding you can enable in custom server profiles. Server-Level HTTP Normalization Encoding Options Option

Description

ASCII Encoding

Decodes encoded ASCII characters and specifies whether the rules engine generates an event on ASCII-encoded URIs

UTF-8 Encoding

Decodes standard UTF-8 Unicode sequences in the URI

Microsoft %U Encoding

Decodes and generates an event on the IIS %u encoding scheme that uses %u followed by four characters where the 4 characters are a hex encoded value that correlates to an IIS Unicode codepoint. TIP! Legitimate clients rarely use %u encodings, so Sourcefire recommends decoding and generating events against HTTP traffic encoded with %u encodings.

Bare Byte UTF-8 Encoding

Decodes and generates an event on bare byte encoding, which uses nonASCII characters as valid values in decoding UTF-8 values. TIP! Bare byte encoding allows the user to emulate an IIS server and interpret non-standard encodings correctly. Sourcefire recommends enabling this option because no legitimate clients encode UTF-8 this way.

Base 36 Encoding

Decodes and generates an event on base 36 encoding, which mainly appears in Asian versions of IIS. This option does not work with %u or utf_8 options enabled.

Microsoft IIS Encoding

Decodes using Unicode codepoint mapping and generates events against traffic that uses IIS Unicode TIP! Sourcefire recommends enabling this option, because it is seen mainly in attacks and evasion attempts.

Version 4.7


895


Chapter 22

Server-Level HTTP Normalization Encoding Options (Continued) Option

Description

Double Encoding

Generates events against IIS double encoded traffic and decodes it by making two passes through the request URI performing decodes in each one. Sourcefire recommends enabling this option because it is usually only found in attack scenarios.

Multi-Slash Obfuscation

Normalizes multiple slashes in a row into a single slash

IIS Backslash Obfuscation

Normalizes backslashes to forward slashes

Directory Traversal

Normalizes directory traversals and self-referential directories. If you enable alerting against this type of traffic, it may generate false positives because some web sites refer to files using directory traversals.

Tab Obfuscation

Normalizes the non-RFC standard of using a tab for a space delimiter. Apache and other non-IIS web servers use the tab character (0x09) as a delimiter in URLs. IMPORTANT! Regardless of the configuration for this option, the HTTP Inspect preprocessor treats a tab as whitespace if a space character (0x20) precedes it.

Invalid RFC Delimiter

Normalizes line breaks (\n) in URI data

Non-RFC characters

Generates events against the non-RFC character list you add in the corresponding field when it appears within incoming or outgoing URI data. When modifying this field, use the hexadecimal format that represents the byte character. If and when you configure this option, set the value with care. Using a character that is very common may overwhelm you with events.

Webroot Directory Traversal

Generates events against directory traversals that traverse past the initial directory in the URL

Maximum Chunk Encoding Size

Generates events against abnormally large chunk sizes in URI data.

Disable Request Pipeline Decoding

Disables HTTP decoding for pipelined requests. When this option is disabled, performance is enhanced because HTTP requests waiting in the pipeline are not decoded or analyzed, and are only inspected using generic pattern matching.

Non-Strict URI Parsing

Enables non-strict URI parsing. Use this option only on servers that will accept non-standard URIs in the format "GET /index.html abc xo qr \n". Using this option, the decoder assumes that the URI is between the first and second space, even if there is no valid HTTP identifier after the second space.

Version 4.7


896


Chapter 22

For details on configuring the global HTTP normalization options, see Configuring Server-Level HTTP Inspection Options on page 901.

Default Server Profiles Requires: IPS or DC/MDC + IPS

IPS provides a default profile appropriate for most servers, default profiles for Apache servers and IIS servers, and custom default settings that you can tailor to meet the needs of your monitored traffic. The Common Profile Defaults table describes global and server HTTP options that have the same default settings for all three server profiles. Common Profile Defaults Option

Setting

HTTP Inspection Global Configuration

Detect Anomalous HTTP Servers: disabled

HTTP Server Configuration

Ports: 80 2301 3128 8000 8080 8180 8888

IMPORTANT! The Maximum Header Length option is only available if you first import an SEU containing Snort 2.8.1 or later.

Oversize Dir Length: 500

Alert on HTTP Proxy Servers: disabled

Flow Depth: 300 Maximum Header Length: 0 (disabled) No Alerts: disabled Inspect URI only: disabled Allow HTTP Proxy Use: disabled Tab URI Delimiter: disabled

Version 4.7

Non-RFC Characters

0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07

Maximum Chunk Encoding Size

generate events on chunks larger than 500000 bytes

Disable Request Pipeline Decoding

no

Non-Strict URI Parsing

enabled


897


Chapter 22

The All Profile Encodings and Obfuscations Settings table describes the default settings for HTTP encoding and obfuscation options that are appropriate for most servers. All Profile Encodings and Obfuscations Settings Option

State

Alert

ASCII Encoding

enabled

no

UTF-8 Encoding

enabled

no


enabled

yes


enabled

yes

Base 36 Encoding

disabled

disabled


enabled

yes

Double Encoding

enabled

yes


enabled

no


enabled

no

Directory Traversal

enabled

no

Tab Obfuscation

enabled

yes


enabled

yes


enabled

yes

TIP! The horizontal tab, vertical tab, new page, and carriage return ASCII characters are treated as white space by default.

Version 4.7


898


Chapter 22

The Apache Profile Encodings and Obfuscations Settings table describes the default HTTP encoding and obfuscation settings for the Apache server profile. Apache Profile Encodings and Obfuscations Settings Option

State

Alert

ASCII Encoding

enabled

no

UTF-8 Encoding

enabled

no


disabled

disabled


disabled

disabled

Base 36 Encoding

disabled

disabled


disabled

disabled

Double Encoding

disabled

disabled


enabled

no


disabled

disabled

Directory Traversal

enabled

no

Tab Obfuscation

enabled

yes


enabled

no


enabled

yes


The IIS Profile Encodings and Obfuscations Settings table describes the default HTTP encoding and obfuscation settings for the IIS server profile. IIS Profile Encodings and Obfuscations Settings

Version 4.7

Option

State

Alert

ASCII Encoding

enabled

no

UTF-8 Encoding

enabled

no


899


Chapter 22

IIS Profile Encodings and Obfuscations Settings (Continued) Option

State

Alert


enabled

yes


enabled

yes

Base 36 Encoding

disabled

disabled


enabled

yes

Double Encoding

enabled

yes


enabled

no


enabled

no

Directory Traversal

enabled

no

Tab Obfuscation

enabled

yes


enabled

yes


enabled

yes


The Custom Profile Encodings and Obfuscations Settings table describes the default settings that you can modify to meet the needs of your monitored traffic. These also are the default settings for these options when you do not select the All, IIS, or Apache server profile. Custom Profile Encodings and Obfuscations Settings

Version 4.7

Option

State

Alert

ASCII Encoding

enabled

no

UTF-8 Encoding

disabled

disabled


enabled

no


enabled

no


900


Chapter 22

Custom Profile Encodings and Obfuscations Settings (Continued) Option

State

Alert

Base 36 Encoding

disabled

disabled


enabled

no

Double Encoding

enabled

no


enabled

no


enabled

no

Directory Traversal

enabled

no

Tab Obfuscation

enabled

no


enabled

no


enabled

no


Configuring Server-Level HTTP Inspection Options Requires: IPS or DC/MDC + IPS

Use the following procedure to configure server-level HTTP inspection options.


1.

To configure server-level HTTP inspection options: Select Policy & Response > IPS > Detection & Prevention. The Detection & Prevention page appears. 2. Click Edit next to the policy you want to edit. The Edit Policy page appears.

Version 4.7


901


Chapter 22

3. Click HTTP Inspection. The HTTP Inspection page appears.

IMPORTANT! The Maximum Header Length option is only available if you first import an SEU containing Snort 2.8.1 or later. 4. Select a server from the Current list, or specify a server in the New Server Address field and click Add. 5. In the Ports field, list the ports whose traffic you want to inspect with HTTP Inspect. 6. Select a server profile as follows:

Version 4.7

•

Select Custom to create your own server profile (see Selecting ServerLevel HTTP Normalization Options on page 894 for more information).

•

Select All to use the standard default profile, appropriate for all servers.


902


•

Select IIS to use the default IIS profile.

•

Select Apache to use the default Apache profile.

Chapter 22

See Default Server Profiles on page 897 for details on each default server profile.

Version 4.7


903


7.

Chapter 22

If you selected Custom, the custom options appear.

IMPORTANT! The Maximum Header Length option is only available if you first import an SEU containing Snort 2.8.1 or later.

Version 4.7


904


Chapter 22

8. Configure the HTTP decoding options you want in your profile. Enable event generation as needed. See Selecting Server-Level HTTP Normalization Options on page 894 for details on available normalization options. 9. Click Save. The system saves your custom profile. 10. Click Back to return to the Edit Policy page.

Decoding SMTP Traffic Requires: IPS or DC/MDC + IPS

The SMTP decoder instructs the rules engine to normalize SMTP commands. By default, Sourcefire enables this preprocessor. You can enable or disable SMTP decoding and normalization, and you can configure options to control when the SMTP decoder triggers alerts in response to SMTP traffic. WARNING! If you added a preprocessor xlink2state directive to the user.conf file on your appliance to enable the xlink2state preprocessor for a release prior to Version 4.5.x, delete that directive before attempting to configure SMTP preprocessing in Version 4.7.

Version 4.7


905


Chapter 22

The configurable options for this decoder are described in the SMTP Decoding Options table: SMTP Decoding Options Option Ports

Description Specifies the ports whose SMTP traffic you want to normalize. Separate multiple ports with spaces. Sourcefire sets the port defaults to ports 25, 465, 587, and 691. IMPORTANT! Any ports you add to the SMTP ports list should also be added to the TCP Reassembly port list. For more information on configuring TCP Reassembly ports, see Reassembling TCP Streams on page 876.

Inspection Type

When set to Stateful, causes SMTP decoder to save state and provide session context for individual packets and only inspects reassembled sessions. When set to Stateless, analyzes each individual packet without session context.

Normalize

When set to All, normalizes all commands. Checks for more than one space character after a command. When set to None, normalizes no commands. When set to Cmds, normalizes the listed commands. The option includes a default list of commands: ATRN AUTH BDAT DATA DEBUG EHLO EMAL ESAM ESND ESOM ETRN EVFY EXPN HELO HELP IDENT MAIL NOOP ONEX QUEU QUIT RCPT RSET SAML SEND SIZE SOML STARTTLS TICK TIME TURN TURNME VERB VRFY XADR XAUTH XCIR XEXCH50 X-EXPS XGEN XLICENSE X-LINK2STATE XQUE XSTA XTRN XUSR. Specify commands which should be normalized in the text box. Checks for more than one space character after a command. The space (ASCII 0x20) and tab (ASCII 0x09) characters count as space characters for normalization purposes.

Ignore Data

Does not process mail data; only processes MIME mail header data.

Ignore TLS Data

Does not process data encrypted under the Transport Layer Security protocol.

No Alerts

Does not alert for this preprocessor.

Alert Unknown Commands

Alerts when unknown commands occur in SMTP traffic.

Max Command Line Len

Alerts when an SMTP command line is longer than this value. Specify 0 to never alert on command line length. RFC 2821, the Network Working Group specification on the Simple Mail Transfer Protocol, recommends 512 as a maximum command line length.

Version 4.7


906


Chapter 22

SMTP Decoding Options (Continued) Option

Description

Max Header Line Len

Alerts when an SMTP data header line is longer than this value. Specify 0 to never alert on data header line length.

Max Response Line Len

Alerts when an SMTP response line is longer than this value. Specify 0 to never alert on response line length. RFC 2821 recommends 512 as a maximum response line length.

Alt Max Command Line Len

Alerts when the SMTP command line for any of the specified commands is longer than this value. Specify 0 to never alert on command line length for the specified commands. Different default line lengths are set for numerous commands. This setting overrides the Max Command Line Len setting for the specified commands.

Invalid Commands

Alerts if these commands are sent from the client side.

Valid Commands

Does not alert for commands in this list. Even if this list is empty, the preprocessor does not alert on the following valid commands: ATRN AUTH BDAT DATA DEBUG EHLO EMAL ESAM ESND ESOM ETRN EVFY EXPN HELO HELP IDENT MAIL NOOP ONEX QUEU QUIT RCPT RSET SAML SEND SIZE SOML STARTTLS TICK TIME TURN TURNME VERB VRFY XADR XAUTH XCIR XEXCH50 X-EXPS XGEN XLICENSE XLINK2STATE XQUE XSTA XTRN XUSR

xlink2state

Detects and alerts on packets that are part of X-Link2State Microsoft Exchange buffer data overflow attacks. For inline 3D Sensors with IPS, can also drop those packets.

IMPORTANT! RCPT TO and MAIL FROM are SMTP commands. The preprocessor configuration uses command names of RCPT and MAIL, respectively. Within the code, the preprocessor maps RCPT and MAIL to the correct command name. For details on configuring preprocessors, see Configuring Standard Preprocessor Options on page 943. For a description of the GID and SIDs associated with SMTP normalization, see the SMTP Decoder SIDs table on page 862. To configure SMTP decoding options: Access: Rules or Admin

Version 4.7

1.



907


Chapter 22

2. Click Edit next to the policy you want to edit. The Edit Policy page appears. 3. Click SMTP. The SMTP page appears. IMPORTANT! For more information on SMTP decoding options, see the SMTP Decoding Options table on page 906. 4. Check SMTP (Select to enable) to enable preprocessing of SMTP packets. 5. Specify the Ports where SMTP traffic should be decoded, separated by spaces. The ports 25, 465, 587, and 691 are listed by default. 6. Select the Inspection Type:

7.

•

To examine reassembled TCP streams containing SMTP packets, select Stateful.

•

To inspect only unreassembled SMTP packets, select Stateless.

Configure the Normalization options: •

To normalize all commands, select All.

•

To normalize only specific commands, select Cmds and specify the commands to normalize. Separate commands with spaces.

•

To normalize no commands, select None.

•

To ignore mail data except for MIME mail header data, check Ignore Data.

•

To ignore data encrypted under the Transport Security Layer protocol, check Ignore TLS Data.

•

To disable alerting on SMTP streams, check No Alerts.

•

To alert on unknown commands in SMTP data, check Alert Unknown Commands.

8. Specify a maximum command line length in the Max Command Line Len field. 9. Specify a maximum data header line length in the Max Header Line Len field. 10. Specify a maximum response line length in the Max Response Line Len field. IMPORTANT! RCPT TO and MAIL FROM are SMTP commands. The preprocessor configuration uses command names of RCPT and MAIL, respectively. Within the code, the preprocessor maps RCPT and MAIL to the correct command name.

Version 4.7


908


Chapter 22

11. If needed, click Add next to Alt Max Command Line Len to add commands where you want to specify an alternate maximum command line length, then specify the line length and the command or commands, separated by spaces, where you want that length to be enforced. 12. Specify any commands that you want to treat as invalid and alert on in the Invalid Commands field. Separate commands with spaces. 13. Specify any commands that you want to treat as valid and never alert on in the Valid Commands field. Separate commands with spaces. IMPORTANT! Even if the Valid Commands list is empty, the preprocessor does not alert on the following valid commands: ATRN, AUTH, BDAT, DATA, DEBUG, EHLO, EMAL, ESAM, ESND, ESOM, ETRN, EVFY, EXPN, HELO, HELP, IDENT, MAIL, NOOP, QUIT, RCPT, RSET, SAML, SOML, SEND, ONEX, QUEU, STARTTLS, TICK, TIME, TURN, TURNME, VERB, VRFY, X-EXPS, XLINK2STATE, XADR, XAUTH, XCIR, XEXCH50, XGEN, XLICENSE, XQUE, XSTA, XTRN, or XUSR. 14. To detect and alert on packets that are part of X-Link2State Microsoft Exchange buffer data overflow attacks, check Enable next to xlink2state. To drop detected packets (supported in inline deployments), check Drop. 15. Click Save to save the SMTP decoder settings. 16. Click Back to return to the Edit Policy page.

Decoding FTP and Telnet Traffic Requires: IPS or DC/MDC + IPS

The FTP Telnet decoder analyzes FTP and telnet data streams, normalizing FTP and telnet commands prior to processing by the rules engine. If FTP- or telnet-based exploits are detected, the decoder can be configured to alert on those exploits. You can also configure the decoder to alert when it encounters encrypted traffic. For more information, see the following topics:

Version 4.7

•

Understanding Global FTP and Telnet Options on page 910

•

Enabling FTP and Telnet Decoding and Configuring Global Options on page 911

•

Understanding Telnet Options on page 912

•

Configuring Telnet Options on page 913

•

Understanding Server-Level FTP Options on page 914

•

Configuring Server-Level FTP Options on page 917


909


Chapter 22

•

Understanding Client-Level FTP Options on page 919

•

Configuring Client-Level FTP Options on page 920


Understanding Global FTP and Telnet Options Requires: IPS or DC/MDC + IPS

You can set global options to determine whether the FTP Telnet decoder performs stateful or stateless inspection of packets, whether the decoder alerts on encrypted FTP or telnet sessions, and whether the decoder continues to check a data stream after it encounters encrypted data. Global FTP and Telnet Decoding Options Option

Description

Default Setting

Inspection Type

When set to Stateful, causes FTP Telnet decoder to save state and provide session context for individual packets and only inspects reassembled sessions. When set to Stateless, analyzes each individual packet without session context.

Stateful

To check for FTP data transfers, the global FTP Telnet Inspection Type option must be set to Stateful.

Version 4.7

Alert on Encrypted Traffic

Detects and alerts on encrypted telnet and FTP sessions.

No

Continue to inspect encrypted data

Instructs the preprocessor to continue checking a data stream after it is encrypted, looking for eventual decrypted data.

Disabled


910


Chapter 22

Enabling FTP and Telnet Decoding and Configuring Global Options Requires: IPS or DC/MDC + IPS

You need to configure global options for the FTP Telnet decoder to control whether stateless or stateful inspection is performed, whether or not alerts are triggered by encrypted traffic, and whether the decoder should continue to check for decrypted data in a data stream that it has identified as encrypted. For more information on global settings, see Understanding Global FTP and Telnet Options on page 910. To enable FTP and telnet decoding and configure global options:


1.


2. Click Edit next to the policy you want to edit. The Edit Policy page appears. 3. Click FTP Telnet. The FTP Telnet page appears. TIP! For more information on configuring the other options on this page, see Configuring Telnet Options on page 913, Configuring Server-Level FTP Options on page 917, and Configuring Client-Level FTP Options on page 920. 4. Select or clear FTP Telnet (Select to enable) to enable or disable FTP and telnet decoding. 5. Select the Inspection Type: •

To examine reassembled TCP streams containing FTP packets, select Stateful.

•

To inspect only unreassembled packets, select Stateless.

WARNING! If you disable Stateful Inspection and Stream Reassembly in an intrusion policy (not recommended), FTP and telnet processing becomes implicitly stateless even if you select Stateful here, because the TCP layer does not pass on any state information. For more information on stateful inspection and stream reassembly settings, see Performing Stateful Inspection on TCP Packets on page 875 and Reassembling TCP Streams on page 876. 6. Select the Alert on Encrypted Traffic setting:

7.

Version 4.7

•

To detect and alert on encrypted traffic, select On.

•

To ignore encrypted traffic, select Off.

If needed, select Continue to inspect encrypted data to continue checking a stream after it becomes encrypted, in case it becomes decrypted again and can be processed.


911


Chapter 22

8. Click Save to save global FTP and Telnet settings. 9. Click Back to return to the Edit Policy page, or continue editing FTP or telnet options. For more information on telnet options, see Understanding Telnet Options on page 912. For more information on additional FTP options, see Understanding Server-Level FTP Options on page 914 and Understanding Client-Level FTP Options on page 919.

Understanding Telnet Options Requires: IPS or DC/MDC + IPS

You can enable or disable normalization of telnet commands by the FTP Telnet decoder, enable or disable a specific anomaly case, and set the threshold number of Are You There (AYT) attacks to trigger an alert. Telnet Normalization Options Option

Description

Default Setting

Normalize

Normalizes telnet traffic to the specified ports.

Enabled

Detect Anomalies

Enables alerting on Telnet SB (subnegotiation begin) without the corresponding SE (subnegotiation end).

Enabled

Telnet supports subnegotiation, which begins with SB (subnegotiation begin) and must end with an SE (subnegotiation end). However, certain implementations of Telnet servers will ignore the SB without a corresponding SE. This is anomalous behavior that could be an evasion case. Since FTP uses the Telnet protocol on the control connection, it is also susceptible to this behavior. Are You There Attack Threshold Number

Detects and alerts when the number of consecutive AYT commands exceeds the specified threshold. Sourcefire recommends that you set the AYT threshold to a value no higher than 20.

20

Additionally, you can specify the Ports whose telnet traffic you want to normalize. In the interface, list multiple ports separated by spaces. IMPORTANT! Any ports you add to the telnet Ports list should also be added to the TCP Reassembly port list. For more information on configuring TCP Reassembly ports, see Reassembling TCP Streams on page 876.

Version 4.7


912


Chapter 22

Configuring Telnet Options Requires: IPS or DC/MDC + IPS

You can enable or disable normalization, enable or disable a specific anomaly case, and control the threshold number of Are You There (AYT) attacks to trigger an alert. For additional information on telnet options, see Understanding Telnet Options on page 912. To configure telnet options:


1.


2. Click Edit next to the policy you want to edit. The Edit Policy page appears. TIP! For more information on configuring the other options on this page, see Enabling FTP and Telnet Decoding and Configuring Global Options on page 911, Configuring Server-Level FTP Options on page 917, and Configuring Client-Level FTP Options on page 920. 3. Click FTP Telnet. The FTP Telnet page appears. 4. Specify the Ports where telnet traffic should be decoded. IMPORTANT! Add the same list of ports indicated here to the TCP Reassembly port list. For more information on configuring TCP Reassembly ports, see Reassembling TCP Streams on page 876.

WARNING! Because encrypted traffic (SSL) cannot be decoded, adding port 22 (SSH) could yield unexpected results. 5. Select or clear the Normalize Telnet Protocol Option to enable or disable telnet normalization. 6. Select or clear the Detect Anomalies Telnet Protocol Option to enable or disable anomaly detection. 7.

Specify an Are You There Attack Threshold Number of consecutive AYT commands that should trigger an alert. TIP! Sourcefire recommends that you set the AYT threshold to a value no higher than 20.

8. Click Save to save the FTP Telnet decoder settings.

Version 4.7


913


Chapter 22

9. Click Back to return to the Edit Policy page, or continue editing FTP options. For more information on additional FTP options, see Understanding ServerLevel FTP Options on page 914 and Understanding Client-Level FTP Options on page 919.

Understanding Server-Level FTP Options Requires: IPS or DC/MDC + IPS

You can set options for decoding on multiple FTP servers. Each server profile you create contains the server IP address and the ports on the server where traffic should be monitored. You can specify which FTP commands to validate and which to ignore for a particular server, and set maximum parameter lengths for commands. You can also set the specific command syntax the decoder should validate against for particular commands and set alternate maximum command parameter lengths.

Server-Level FTP Options Option

Description

Default Setting

IP

Use this option to specify the IP address of the FTP server.

default

ports

Use this option to specify the ports on the FTP server where the sensor should monitor traffic.

21

IMPORTANT! Any ports you add to the server-level FTP ports list should also be added to the TCP Reassembly port list. For more information on configuring TCP Reassembly ports, see Reassembling TCP Streams on page 876. log FTP command validation configuration

Use this option to turn on printing of the configuration information for each ftp command listed for this server.

Disabled

Add FTP Cmds

Click Add FTP Cmds to add lines where you can specify additional FTP commands the decoder should detect and alert on, in addition to those checked by default by the FTP Telnet preprocessor.

N/A

ftp commands

Use these lines to specify the additional commands that the decoder should detect and alert on.

USER PASS ACCT CWD SDUP SMNT QUIT REIN PORT PASV TYPE STRU MODE RETR STOR STOU APPE ALLO REST RNFR RNTO ABOR DELE RMD MKD PWD LIST NLST SITE SYST STAT HELP NOOP AUTH ADAT PROT PBSZ CONF ENC FEAT OPTS MDTM REST SIZE MLST MLSD

Version 4.7


914


Chapter 22

Server-Level FTP Options (Continued) Option

Description

Default Setting

default max param len

Use this option to detect and alert on the maximum parameter length for commands where an alternate maximum parameter length has not been set.

100

Add Alt Max Param Len

Use this option to add lines where you can specify a different maximum parameter length to detect and alert on for particular commands.

N/A

alt max parameter len

Use this option to specify commands where you want to detect and alert on a different maximum parameter length, and to specify the maximum parameter length for those commands.

0 for the following commands: CDUP QUIT

Check commands for String Format Attacks

Use this option to check the specified commands for string format attacks.

Blank

Add Cmd Validity

Use this option to add a command validation line.

N/A

cmd validity

Use this option to enter a valid format for a specific command. See the paragraphs that follow this table for more information on creating FTP command parameter validation statements to validate the syntax of a parameter received as part of an FTP communication.

For the MODE command,

REIN PASV STOU ABOR PWD SYST NOOP

char SBC

For the STRU command, char FRP

For the ALLO command, int [ char R int ]

For the TYPE command, {

char AE [ char NTC ] | char I | char L [ number ] }

For the PORT command, host_port

Alert on Telnet Escape codes within FTP commands

Use this option to detect and alert when telnet commands are used over the FTP command channel.

Disabled

Ignore FTP transfers

Use this option to improve performance on FTP data transfers by disabling all inspection other than state inspection on the data transfer channel.

Disabled

Version 4.7


915


Chapter 22

When setting up a validation statement for an FTP command, you can specify a group of alternative parameters by surrounding the parameters with curly brackets ({}) in the validation statement. You can also create a binary OR relationship between two parameters by separating them with a pipe character (|) in the validation statement. Surrounding parameters by square brackets ([]) indicates that those parameters are optional. You can create FTP command parameter validation statements to validate the syntax of a parameter received as part of an FTP communication. Any of the parameters listed in the following table can be used in FTP command parameter validation statements:

If you use...

The following validation occurs...

int

The represented parameter must be an integer.

number

The represented parameter must be an integer between 1 and 255.

char _chars

The represented parameter must be a single character and a member of the characters specified in the _chars argument. For example, defining the command validity for MODE with the validation statement char SBC checks that the parameter for the MODE command comprises the character S (representing Stream mode), the character B (representing Block mode), or the character C (representing Compressed mode).

date _datefmt

If _datefmt contains #, the represented parameter must be a number. If _datefmt contains C, the represented parameter must be a character. If _datefmt contains literal strings, the represented parameter must match the literal string.

string

The represented parameter must be a string.

host_port

The represented parameter must be a valid host port specifier as defined by RFC 959, the File Transfer Protocol specification by the Network Working Group.

You can combine the syntax in the table above as needed to create parameter validation statements that correctly validate each FTP command where you need to validate traffic.

Version 4.7


916


Chapter 22

To group multiple parameters: Access: Rules or Admin

h

Separate the parameters by commas and enclose the parameter options in curly brackets ({}). For example, to evaluate the MODE command parameter to see if it is a character that represents both the Stream mode and the Block mode, type this command validation statement char {S,B}.

To accept one or the other of two parameters: Access: Rules or Admin

h

Separate the parameters by a pipe character (|). For example, to evaluate the MODE command parameter to see if it is a character that represents either the Stream mode or the Block mode, type this command validation statement char S|B.

To designate a parameter as optional: Access: Rules or Admin

h

Enclose the parameter in square brackets ([]).

Configuring Server-Level FTP Options Requires: IPS or DC/MDC + IPS

You can configure several options at the server level. For each FTP server you add, you can specify the ports to be monitored, the commands to validate, the default maximum parameter length for commands, alternate parameter lengths for specific commands, and validation syntax for particular commands. You can also choose whether to check for string format attacks and telnet commands on the FTP channel and whether to print configuration information with each command. For additional information on server-level FTP options, see Understanding Server-Level FTP Options on page 914. To configure server-level FTP options:


1.


2. Click Edit next to the policy you want to edit. The Edit Policy page appears. 3. Click FTP Telnet. The FTP Telnet page appears. TIP! For more information on configuring the other options on this page, see Enabling FTP and Telnet Decoding and Configuring Global Options on page 911, Configuring Telnet Options on page 913, and Configuring ClientLevel FTP Options on page 920. 4. Click Add FTP Server. A new FTP Server definition section appears below the existing FTP Servers.

Version 4.7


917


Chapter 22

5. Specify the IP address of the server. 6. Specify any Ports that should be monitored for FTP traffic. Port 21 is the wellknown port for FTP traffic. IMPORTANT! Add the same list of ports indicated here to the TCP Reassembly port list. For more information on configuring TCP Reassembly ports, see Reassembling TCP Streams on page 876. 7.

To turn on printing of the configuration information for each FTP command listed for this server, check log FTP command validation configuration.

8. To detect and alert on additional FTP commands outside of those checked by default by the FTP Telnet preprocessor, click Add FTP Cmds and specify the commands, separated by spaces. You can add as many rows of additional FTP commands as needed. IMPORTANT! Additional commands you may want to add include XPWD, XCWD, XCUP, XMKD, and XRMD. For more information on these commands, see RFC 775, the Directory oriented FTP commands specification by the Network Working Group. 9. Specify the default maximum number of bytes for a command parameter in the default max param len field. If the parameter length for a command exceeds this threshold, the preprocessor generates an alert. 10. To detect and alert on a different maximum parameter length for particular commands, click Add Alt Max Param Len. In the first text box of the row that appears, specify the maximum parameter length. In the second text box, specify the commands, separated by spaces, where this alternate maximum parameter length should apply. You can add as many alternative maximum parameter lengths as needed. 11. To check for string format attacks on particular commands, specify the commands, separated by spaces, in the Check commands for String Format attacks text box. 12. To specify the valid format for a command, click Add Cmd Validity. Specify the command you want to validate, then type a validation statement for the command parameter. For more information on the validation statement syntax, see Understanding Server-Level FTP Options on page 914. 13. To detect and alert when telnet commands are used over the FTP command channel, enable Alert on Telnet Escape codes within FTP commands.

Version 4.7


918


Chapter 22

14. To improve performance on FTP data transfers by disabling all inspection other than state inspection on the data transfer channel, enable Ignore FTP transfers. IMPORTANT! To inspect data transfers, the global FTP Telnet Inspection Type option must be set to Stateful. For more information on setting global options, see Understanding Global FTP and Telnet Options on page 910. 15. Click Save to save the FTP server settings. 16. Click Back to return to the Edit Policy page, or continue editing FTP or telnet options. For more information on global FTP and telnet options, see Understanding Global FTP and Telnet Options on page 910. For more information on telnet options, see Understanding Telnet Options on page 912. For more information on additional FTP options, see Understanding Client-Level FTP Options on page 919.

Understanding Client-Level FTP Options Requires: IPS or DC/MDC + IPS

You can create profiles for FTP clients. Within each profile, you can specify the maximum response length for an FTP response from a client. You can also configure whether or not the decoder detects and alerts on bounce attacks and use of telnet commands on the FTP command channel for a particular client. FTP Client-level Options

Version 4.7

Option

Description

Default

IP

Use this option to specify the IP address of the FTP client.

default

max response len

Use this option to specify the maximum length of a response string from the FTP client.

100

Alert on FTP Bounce attempts

Use this option to detect and alert on FTP bounce attacks.

Disabled

Allow FTP Bounce to

Use this option to configure a list of additional hosts and ports on those hosts on which FTP PORT commands should not be treated as FTP bounce attacks.

Blank

Alert on Telnet Escape codes within FTP commands

Use this option to detect and alert when telnet commands are used over the FTP command channel.

Disabled


919


Chapter 22

Configuring Client-Level FTP Options Requires: IPS or DC/MDC + IPS

You can configure client profiles for FTP clients to monitor FTP traffic from clients. For additional information on the options you can set for monitoring clients, see Understanding Client-Level FTP Options on page 919. To configure client-level FTP options:


1.


2. Click Edit next to the policy you want to edit. The Edit Policy page appears. TIP! For more information on configuring the other options on this page, see Enabling FTP and Telnet Decoding and Configuring Global Options on page 911, Configuring Telnet Options on page 913, and Configuring ServerLevel FTP Options on page 917. 3. Click FTP Telnet. The FTP Telnet page appears. 4. Click Add FTP Client. A new FTP Client section appears below the default FTP client section. 5. Specify the IP address of the client. 6. Specify, in bytes, the maximum length of responses from the FTP client in the max response len field. If a response exceeds this length, the FTP Telnet decoder generates an alert. 7.

To detect and alert on FTP bounce attacks, enable Alert on FTP Bounce attempts. If an FTP PORT command is issued and the specified host does not match the specified host of the client, the FTP Telnet decoder generates an alert.

Version 4.7


920


Chapter 22

8. To configure a list of additional hosts and ports where FTP PORT commands should not be treated as FTP bounce attacks, specify each host (or network in CIDR format) followed by a colon (:) or a comma (,) and the port or port range in the Allow FTP Bounce to field. To enter a range of ports for a host, separate the beginning port in the range and the final port in the range with a colon (:) or a comma (,). You can enter multiple hosts by separating the entries for the hosts with a space. For example, to prevent alerts on FTP PORT commands directed to the host 192.168.1.1 at port 21 and commands directed to the host 10.10.1.1 at any of the ports from 22 to 1024, type either 192.168.1.1:21 10.10.1.1:22:1024 or 192.168.1.1,21 10.10.1.1,22,1024. IMPORTANT! To specify multiple individual ports for a host, you must repeat the host IP address for each port definition. For example, to specify the ports 22 and 25 on 192.168.1.1, type 192.168.1.1:22 192.168.1.1:25. 9. To detect and alert when telnet commands are used over the FTP command channel, enable Alert on Telnet Escape codes within FTP commands. 10. Click Save to save the FTP client settings. 11. Click Back to return to the Edit Policy page, or continue editing FTP or telnet options. For more information on global FTP and telnet options, see Understanding Global FTP and Telnet Options on page 910. For more information on telnet options, see Understanding Telnet Options on page 912. For more information on additional FTP options, see Understanding Server-Level FTP Options on page 914.

Understanding DCE/RPC Traffic Reassembly Requires: IPS or DC/MDC + IPS

The DCE/RPC preprocessor examines DCE/RPC traffic for fragmented request packets, and reassembles them so the rules engine can inspect the complete packets. DCE/RPC (Distributed Computing Environment/Remote Procedure Calls) is an application-layer protocol widely used in Microsoft environments to make function calls on a remote computer as if the calls were local. DCE/RPC can run directly on top of TCP or UDP, or it can run on top of the SMB (Server Message Block) application-layer protocol, which is also widely used by Microsoft Windows for file sharing and standard messaging. Many of the intrusion rules in the NetBIOS rule category examine DCE/RPC traffic for exploits that attempt to take advantage of DCE/RPC packets, which assist in remote session negotiation, or request packets, which make function calls. To prevent these exploits from going undetected in fragmented packets, the

Version 4.7


921


Chapter 22

DCE/RPC preprocessor reassembles fragmented DCE/RPC request packets so the rules engine can inspect the complete packets. IMPORTANT! Sourcefire strongly recommends that you enable the DCE/RPC preprocessor in a Microsoft environment. DCE/RPC normally runs on TCP or UDP port 135, or over SMB. DCE/RPC can also run on arbitrary high ports, generally around 1024. SMB usually runs on TCP port 445, or on top of NetBIOS on TCP port 139; however, SMB can run on any port and is used on many different ports. When the DCE/RPC preprocessor is configured to automatically detect ports, it ignores configured ports and examines all TCP traffic for SMB or DCE/RPC packets. The configurable options for this preprocessor are described in the DCE/RPC Reassembly Options table on page 922. DCE/RPC Reassembly Options

Version 4.7

Option

Description

Autodetect Ports

Sets the preprocessor to ignore configured port numbers and examine all traffic to identify SMB or DCE/RPC traffic.

Maximum Reassembled Fragment Size

Sets the maximum size of a reassembled DCE/RPC or SMB fragment, in bytes.

Memcap

Sets the maximum memory allocated to the preprocessor for reassembling fragments. If the maximum is exceeded, reassembly is truncated or skipped.

Alert on Memcap

Generates an event when the maximum memory allocated to the preprocessor is exceeded.

SMB Ports

Specifies the ports the preprocessor inspects for SMB traffic. This option is disabled by default and can be enabled by disabling Autodetect Ports. Default ports are pre-configured in case you disable Autodetect Ports.

DCE/RPC Ports

Specifies the ports the preprocessor inspects for DCE/RPC traffic. This option can be enabled by disabling Autodetect Ports.

Disable Packet Reassembly

Disables the reassembly of SMB or DCE/RPC fragments.


922


Chapter 22

For details on configuring preprocessors, see Configuring Standard Preprocessor Options on page 943. For a description of the GID and SID associated with DCE/RPC reassembly, see the Generator IDs table on page 851. TIP! Sourcefire can use SEU updates to add new preprocessors and to add new functionality and features to existing preprocessors. To learn more about features that are not discussed in the main online help, select a feature and then click the Help link on the page for that feature to view additional SEU-based online help. For more information on SEU updates, see Importing SEUs and Rule Files on page 833.

Configuring DCE/RPC Traffic Reassembly Requires: IPS or DC/MDC + IPS

You can configure how the DCE/RPC preprocessor examines DCE/RPC traffic for fragmented request packets and whether and how it reassembles them so the rules engine can inspect the complete packets. For a description of the DCE/RPC reassembly options, see Understanding DCE/RPC Traffic Reassembly on page 921. To configure DCE/RPC reassembly options:


1.


2. Click Edit next to the policy you want to edit. The Edit Policy page appears. 3. Click DCE/RPC. The DCE/RPC page appears. IMPORTANT! For more information on DCE/RPC preprocessor options, see the DCE/RPC Reassembly Options table on page 922. 4. Select or clear the DCE/RPC check box to enable or disable the DCE/RPC preprocessor. 5. Optionally, specify the ports you want the preprocessor to inspect for SMB or DCE/RPC traffic. Separate multiple ports with spaces only. IMPORTANT! Disable Autodetect Ports if you wish to specify the ports you want the preprocessor to inspect for SMB and DCE/RPC traffic. 6. Optionally, revise any other default settings. 7.

Version 4.7

Click Save to save the DCE/RPC preprocessor settings.


923


Chapter 22

8. Click Back to return to the Edit Policy page. The Edit Policy page appears.

Detecting Exploits in DNS Name Server Responses Requires: IPS or DC/MDC + IPS

The DNS preprocessor inspects DNS name server responses for the following specific exploits: •

Overflow attempts on RData text fields

•

Obsolete DNS resource record types

•

Experimental DNS resource record types

IMPORTANT! This feature is only available if you first import an SEU containing Snort 2.8.1 or later. See the following sections for more information: •

Understanding DNS Preprocessor Resource Record Inspection on page 924

•

Detecting Overflow Attempts in RData Text Fields on page 926

•

Detecting Obsolete DNS Resource Record Types on page 926

•

Detecting Experimental DNS Resource Record Types on page 927

•

Configuring the DNS Preprocessor on page 927

Understanding DNS Preprocessor Resource Record Inspection Requires: IPS or DC/MDC + IPS

The most common type of DNS name server response provides one or more IP addresses that correspond to domain names in the query that prompted the response. Other types of server responses provide, for example, the destination for an email message or the location of a name server that can provide information not available from the server originally queried. A DNS response is comprised of a message header, a Question section that contains one or more requests, and three sections that respond to requests in the Question section (Answer, Authority, and Additional Information). Responses in these three sections reflect the information in resource records (RR) maintained on the name server. The DNS Name Server RR Responses table describes these three sections.

Version 4.7


924


Chapter 22

There are many types of resource records, all adhering to the structure shown in DNS Name Server RR Responses This section...

Includes...

For example...

Answer

Optionally, one or more resource records that provide a specific answer to a query

The IP address corresponding to a domain name

Authority

Optionally, one or more resource records that point to an authoritative name server

The name of an authoritative name server for the response

Additional Information

Optionally, one or more resource records that provided additional information related to the Answer sections

The IP address of another server to query

the following figure:

Theoretically, any type of resource record can be used in the Answer, Authority, or Additional Information section of a name server response message. The DNS preprocessor inspects any resource record in each of the three response sections for the exploits it detects. The Type and RData resource record fields are of particular importance to the DNS preprocessor. The Type field identifies the type of resource record. The RData (resource data) field provides the response content. The size and content of the RData field differs depending on the type of resource record. DNS messages typically use the UDP transport protocol but also use TCP when the message type requires reliable delivery or the message size exceeds UDP capabilities. The DNS preprocessor inspects DNS server responses in both UDP and TCP traffic. To inspect TCP traffic, a TCP stream preprocessor must be enabled. For information on enabling a stream preprocessor, see Understanding Transport-Layer Preprocessors on page 873. The DNS preprocessor takes no action unless you enable alerting for at least one of the exploits it detects. It does not inspect TCP sessions picked up in

Version 4.7


925


Chapter 22

midstream, and ceases inspection if a session loses state because of dropped packets. The default port for the DNS preprocessor is well-known port 53, which DNS name servers use for DNS messages in both UDP and TCP.

Detecting Overflow Attempts in RData Text Fields Requires: IPS or DC/MDC + IPS

When the resource record type is TXT (text), the RData field is a variable-length ASCII text field. You can enable the DNS preprocessor Alert on Overflow attempts on RData Text fields option to alert on a specific vulnerability identified by entry CVE-2006-3441 in MITRE’s Current Vulnerabilities and Exposures database. This is a known vulnerability in Microsoft Windows 2000 Service Pack 4, Windows XP Service Pack 1 and Service Pack 2, and Windows Server 2003 Service Pack 1. An attacker can exploit this vulnerability and take complete control of a host by sending or otherwise causing the host to receive a maliciously crafted name server response that causes a miscalculation in the length of an RData text field, resulting in a buffer overflow. You should enable this feature when your network might include hosts running operating systems that have not been upgraded to correct this vulnerability.

Detecting Obsolete DNS Resource Record Types Requires: IPS or DC/MDC + IPS

RFC 1035 identifies several resource record types as obsolete. Because these are obsolete record types, some systems do not account for them and can be open to exploits. You would not expect to encounter these record types in normal DNS responses unless you have purposely configured your network to include them. You can configure the system to generate events when it detects known obsolete resource record types. The Obsolete DNS Resource Record Types table lists and describes these record types. Obsolete DNS Resource Record Types RR Type

Code

Description

3

MD

a mail destination

4

MF

a mail forwarder

For details on configuring DNS obsolete record detection, see Configuring the DNS Preprocessor on page 927. For the GID and SIDs associated with detecting DNS record types, see the Generator IDs table on page 851 and the DNS SIDs table on page 864.

Version 4.7


926


Chapter 22

Detecting Experimental DNS Resource Record Types Requires: IPS or DC/MDC + IPS

RFC 1035 identifies several resource record types as experimental. Because these are experimental record types, some systems do not account for them and can be open to exploits. You would not expect to encounter these record types in normal DNS responses unless you have purposely configured your network to include them. You can configure the system to generate events when it detects known experimental resource record types. The Experimental DNS Resource Record Types table lists and describes these record types. Experimental DNS Resource Record Types RR Type

Code

Description

7

MB

a mailbox domain name

8

MG

a mail group member

9

MR

a mail rename domain name

10

NUL

a null resource record

For details on configuring DNS experimental record detection, see Configuring the DNS Preprocessor on page 927. For the GID and SIDs associated with detecting experimental DNS record types, see the Generator IDs table on page 851 and the DNS SIDs table on page 864.

Configuring the DNS Preprocessor Requires: IPS or DC/MDC + IPS

Use the following procedure to configure the DNS preprocessor.


1.

To configure the DNS preprocessor: Select Policy & Response > IPS > Detection & Prevention. The Detection & Prevention page appears. 2. Click Edit next to the policy whose preprocessor options you want to configure. The Edit Policy page appears.

Version 4.7


927


Chapter 22

3. Click DNS. The DNS page appears.

4. Click the DNS check box to enable or disable DNS. 5. Optionally, modify the source ports the DNS preprocessor should monitor for DNS server responses. 6. Optionally, click on the Alert on Overflow attempts on RData Text fields check box to alert on buffer overflow attempts in RData text fields. See Detecting Overflow Attempts in RData Text Fields on page 926 for more information. 7.

Optionally, click on the Alert on Obsolete DNS RR types check box to alert on obsolete resource record types. See Detecting Obsolete DNS Resource Record Types on page 926 for more information.

8. Optionally, click on the Alert on Experimental DNS RR types check box to alert on experimental resource record types. See Detecting Experimental DNS Resource Record Types on page 927 for more information. 9. Click Save. 10. Click Back to return to the Edit Policy page. You must apply the policy containing your preprocessor configuration to implement your changes. See Applying an Intrusion Policy on page 764 for procedures.

Detecting Encrypted Traffic Using the SSL Preprocessor Requires: IPS or DC/MDC + IPS

Although IPS cannot analyze the contents of encrypted traffic, by default it continues to attempt to inspect the traffic, occasionally generating false positives and wasting detection resources. Using the SSL preprocessor, however, IPS can analyze the contents of the handshake and key exchange messages exchanged at the beginning of an SSL session to determine when the session becomes encrypted. When SSL preprocessing is active, you can cause IPS to suspend inspection of a session as soon as it becomes encrypted. IMPORTANT! This feature is only available if you first import an SEU containing Snort 2.8.1 or later.

Version 4.7


928


Chapter 22


Understanding SSL Preprocessing on page 929

•

Configuring the SSL Preprocessor on page 930

Understanding SSL Preprocessing Requires: IPS or DC/MDC + IPS

The SSL preprocessor stops inspection of encrypted data, which can help to eliminate false positives. The SSL preprocessor maintains state information as it inspects the SSL handshake, tracking both the state and SSL version for that session. Once the preprocessor detects that a session state is encrypted, IPS marks the traffic in that session as encrypted. You can configure IPS to stop processing on all packets in an encrypted session once encryption is established.

For each packet, the SSL preprocessor verifies that the traffic contains an IP header, a TCP header, and a TCP payload, and that it occurs on the ports specified for SSL preprocessing. For qualifying traffic, IPS uses the following scenarios to determine whether the traffic is encrypted:

Version 4.7

•

IPS observes all packets in a session, Server side data is trusted is not enabled, and the session includes a Finished message from both the server and the client and at least one packet from each side with an Application record and without an Alert record

•

IPS misses some of the traffic, Server side data is trusted is not enabled, and the session includes at least one packet from each side with an Application record that is not answered with an Alert record

•

IPS observes all packets in a session, Server side data is trusted is enabled, and the session includes a Finished message from the client and at least one packet from the client with an Application record and without an Alert record

•

IPS misses some of the traffic, Server side data is trusted is enabled, and the session includes at least one packet from the client with an Application record that is not answered with an Alert record


929


Chapter 22

If you choose to stop processing on encrypted traffic, IPS ignores future packets in a session once it marks the session as encrypted. Note that when you import an SEU containing Snort 2.8.1 or later, only port 443 is added by default to existing policies. When you create a new policy after applying an SEU containing Snort 2.8.1 or later, the SSL preprocessor checks for the following protocols by default, by monitoring the associated ports: Ports for Encrypted Traffic Protocol

Port

HTTPS

443

SMTPS

465

NNTPS

563

LDAPS

636

FTPS

989

TelnetS

992

IMAPS

993

IRCS

994

POPS

995

SSL

8443

IMPORTANT! You can add the ssl_state and ssl_version keywords to a rule to use SSL state or version information within the rule. For more information, see Extracting SSL Information from a Session on page 993. Note that you must enable the SSL preprocessor to allow processing of rules that contain SSL keywords.

Configuring the SSL Preprocessor Requires: IPS or DC/MDC + IPS

Version 4.7

By default, the SSL preprocessor is disabled, and IPS attempts to inspect encrypted traffic. When you enable the SSL preprocessor, it detects when a session becomes encrypted. Once the SSL preprocessor is enabled, the rules engine can invoke the preprocessor to obtain SSL state and version information. If you enable rules using the ssl_state and ssl_version keywords in an IPS policy, you should also enable the SSL preprocessor in that policy.


930


Chapter 22

In addition, you can enable the Stop inspecting encrypted traffic option to cause IPS to disable inspection and reassembly for encrypted sessions. The SSL preprocessor maintains state for the session so it can disable inspection of all traffic in the session. IPS only stops inspecting traffic in encrypted sessions if SSL preprocessing is enabled and the Stop inspecting encrypted traffic option is selected. To base identification of encrypted traffic only on client traffic, you can enable the Server side data is trusted option. The SSL preprocessor typically checks for specific packets within both client traffic and the server responses to that traffic. However, IPS may not mark a transaction as encrypted if it cannot detect the server side of a session. Note that you should enable the Stop inspecting encrypted traffic option when you enable Server side data is trusted. You can specify the ports where the preprocessor monitors traffic for encrypted sessions. All the ports in the Ports for Encrypted Traffic table on page 930 are listed by default. IMPORTANT! If the SSL preprocessor detects non-SSL traffic over the ports specified for SSL monitoring in policies created after you import an SEU containing Snort 2.8.1 or later, it tries to decode the traffic as SSL traffic, and then flags it as corrupt. To configure the SSL preprocessor: Access: Rules or Admin

1.


2. Click Edit next to the policy whose preprocessor options you want to configure. The Edit Policy page appears. 3. Click SSL. The SSL page appears.

4. Click the SSL check box to enable or disable identification of encrypted traffic. 5. Type the ports, separated by spaces, where the SSL preprocessor should monitor traffic for encrypted sessions. Only ports included in the SSL Ports field will be checked for encrypted traffic. 6. Click the Stop inspecting encrypted traffic check box to enable or disable inspection of traffic in a session after the session is marked as encrypted. 7.

Version 4.7

Click the Server side data is trusted check box to enable or disable identification of encrypted traffic based only on the client-side traffic,


931

Tuning Preprocessors Reporting Decoding Errors

Chapter 22


Reporting Decoding Errors Requires: IPS or DC/MDC + IPS

You can specify whether you want IPS to generate events when errors occur during packet decoding. You can enable and disable these alerts. To configure the reporting of decoding errors, see Configuring Standard Preprocessor Options on page 943.

Monitoring Performance Requires: IPS or DC/MDC + IPS

You can configure the basic parameters of how 3D Sensors with IPS monitor and report on their own performance. This allows you to specify the intervals at which the system updates performance statistics on your 3D Sensors by configuring the following: •

number of seconds

•

number of packets analyzed

WARNING! Do not apply a policy with the Performance Monitor Enable debugging check box selected unless directed to do so by Sourcefire Support. Note that this feature is only available if you first import an SEU containing Snort 2.8.1 or later. When the number of seconds specified has elapsed since the last performance statistics update, the system verifies that the specified number of packets has been analyzed. If so, the system updates performance statistics. If not, the system waits until the specified number of packets has been analyzed. To configure performance monitoring, see Configuring Standard Preprocessor Options on page 943.

Detecting Back Orifice Requires: IPS or DC/MDC + IPS

Version 4.7

IPS provides a preprocessor that detects the existence of the Back Orifice program. This program can be used to gain root access to your Windows hosts. The Back Orifice preprocessor analyzes UDP traffic for the Back Orifice magic cookie, "*!*QWTY?", which is located in the first eight bytes of the packet and is XOR-encrypted, and generates an event packet that contains it. You can enable or disable Back Orifice detection.


932

Tuning Preprocessors Detecting Portscans

Chapter 22

For details on the GID and SIDs associated with the Back Orifice preprocessor, see the Generator IDs table on page 851 and the Back Orifice Detector SIDs table on page 854. To configure back orifice detection, see Configuring Standard Preprocessor Options on page 943.

Detecting Portscans Requires: IPS or DC/MDC + IPS

A portscan is a form of network reconnaissance that is often used by attackers as a prelude to an attack. In a portscan, an attacker sends specially crafted packets to a targeted host. By examining the packets that the host responds with, the attacker can often determine which ports are open on the host and, either directly or by inference, which services are running on these ports. By itself, a portscan is not evidence of an attack. In fact, some of the portscanning techniques used by attackers can also be employed by legitimate users on your network. Sourcefire’s portscan detector is designed to help you determine which portscans might be malicious by detecting patterns of activity and generating events accordingly. Attackers are likely to use several methods to probe your network. Often they use different protocols to draw out different responses from a target host, hoping that

Version 4.7


933


Chapter 22

if one type of protocol is blocked, another may be available. The Protocol Types table describes the protocols you can activate in the portscan detector. Protocol Types Protocol

Description

TCP

Detects TCP probes such as SYN scans, ACK scans, TCP connect() scans, and scans with unusual flag combinations such as Xmas tree, FIN, and NULL

UDP

Detects UDP probes such as zero-byte UDP packets

ICMP

Detects ICMP echo requests (pings)

IP

Detects IP protocol scans. These scans differ from TCP and UDP scans because the attacker, instead of looking for open ports, is trying to discover which IP protocols are supported on a target host.

IMPORTANT! For events generated by the portscan flow detector, the protocol number is set to 255. Because portscan does not have a specific protocol associated with it by default, the Internet Assigned Numbers Authority (IANA) does not have a protocol number assigned to it. IANA designates 255 as a reserved number, so that number is used in portscan events to indicate that there is not an associated protocol for the event.

Version 4.7


934


Chapter 22

Portscans are generally divided into four types based on the number of targeted hosts, the number of scanning hosts, and the number of ports that are scanned. The Portscan Types table describes the kinds of portscan activity you can detect: Portscan Types Type

Description

Portscan

A one-to-one portscan in which an attacker uses one or a few hosts to scan multiple ports on a single target host. One-to-one portscans are characterized by: • a low number of scanning hosts • a single host that is scanned • a high number of ports scanned The portscan option detects TCP, UDP, and IP protocol portscans.

Portsweep

A one-to-many portsweep in which an attacker uses one or a few hosts to scan a single port on multiple target hosts. Portsweeps are characterized by: • a low number of scanning hosts • a high number of scanned hosts • a low number of unique ports scanned The portsweep option detects TCP, UDP, ICMP, and IP protocol portsweeps.

Version 4.7


935


Chapter 22

Portscan Types (Continued) Type

Description

Decoy Portscan

A one-to-one portscan in which the attacker mixes spoofed source IP addresses with the actual scanning IP address. Decoy portscans are characterized by: • a high number of scanning hosts • a low number of ports that are scanned only once • a single (or a low number of) scanned hosts The decoy portscan option detects TCP, UDP, and IP protocol portscans.

Distributed Portscan

A many-to-one portscan in which multiple hosts query a single host for open services. Distributed portscans are characterized by: • a high number of scanning hosts • a high number of ports that are scanned only once • a single (or a low number of) scanned hosts The distributed portscan option detects TCP, UDP, and IP protocol portscans.

The information that the portscan detector learns about a probe is largely based on seeing negative responses from the probed hosts. For example, when a web client tries to connect to a web server, the client uses port 80/tcp and the server can be counted on to have that port open. However, when an attacker probes a server, the attacker does not know in advance if it offers web services. When the portscan detector sees a negative response (that is, an ICMP unreachable or TCP RST packet), it records the response as a potential portscan. The process is more difficult when the targeted host is on the other side of a device such as a firewall or router that filters negative responses. In this case, the portscan detector generates filtered portscan events based on the sensitivity level that you select.

Version 4.7


936


Chapter 22

The Sensitivity Levels table describes the three different sensitivity levels you can choose from. Sensitivity Levels Level

Description

Low

Generates events based on only negative responses from targeted hosts. Select this sensitivity level to suppress false positives, but keep in mind that some types of portscans (slow scans, filtered scans) might be missed. This level uses the shortest time window for portscan detection.

Medium

Generates portscan events based on the number of connections to a host, which means that you can detect filtered portscans. However, very active hosts such as network address translators and proxies may generate false positives. Note that you can add the IP addresses of these active hosts to the Ignore Scanned field to mitigate this type of false positive. This level uses a longer time window for portscan detection.

High

Generates portscan events based on a time window, which means that you can detect time-based portscans. However, if you use this option, you should be careful to tune the detector over time by specifying IP addresses in the Ignore Scanned and Ignore Scanner fields. This level uses a much longer time window for portscan detection.


Configuring Portscan Detection on page 937

•

Understanding Portscan Events on page 939

Configuring Portscan Detection Requires: IPS or DC/MDC + IPS

The portscan detection configuration options allow you to finely tune how the portscan detector reports scan activity. You can configure portscan detection options using the policy wizard or by editing an existing custom policy.

Version 4.7


937


Chapter 22

To configure portscan detection: Access: Rules or Admin

1.


2. Click Edit next to the policy you want to edit. The Edit Policy page appears. 3. Click Portscan Detection. The Portscan Configuration page appears.

4. Click the Portscan check box to enable the portscan detection options. TIP! For more information about the values you can configure, see the Portscan Types table on page 935. 5. In the Protocol field, specify which of the following protocols you want to enable: •

tcp

•

udp

•

icmp

•

ip

Use Ctrl or Shift while clicking to select multiple protocols or clear individual protocols. See the Protocol Types table on page 934 for more information. 6. In the Scan Type field, specify which of the following portscans you want to detect:

Version 4.7

•

portscan

•

portsweep


938


Chapter 22

•

decoy portscan

•

distributed portscan

Use Ctrl or Shift while clicking to select or de-select multiple protocols. See the Portscan Types table on page 935 for more information. 7.

In the Sensitivity Level list, specify which level you want to use: low, medium, or high. See the Sensitivity Levels table on page 937 for more information.

8. Optionally, in the Watch IP field, specify which hosts you want to watch for signs of portscan activity, or leave the field blank to watch all network traffic. You can enter a comma-delimited list of IP addresses or use CIDR notation up to 255 characters. 9. Optionally, in the Ignore Scanner field, specify which hosts you want to ignore as scanners. Use this field to indicate hosts on your network that are especially active. You may need to modify this list of hosts over time. You can enter a comma-delimited list of IP addresses or use CIDR notation up to 255 characters. 10. Optionally, in the Ignore Scanned field, specify which hosts you want to ignore as the target of a scan. Use this field to indicate hosts on your network that are especially active. You may need to modify this list of hosts over time. You can enter a comma-delimited list of IP addresses or use CIDR notation up to 255 characters. 11. Optionally, disable Detect Ack Scans to discontinue monitoring of sessions picked up in mid-stream. IMPORTANT! Detection of mid-stream sessions helps to identify ACK scans, but can cause false alerts, particularly on networks with heavy traffic and dropped packets. 12. Click Save. The portscan detector settings are saved. 13. Click Back to return to the Edit Policy page. You must apply the policy containing your preprocessor configuration to implement your changes. See Applying an Intrusion Policy on page 764 for procedures.

Understanding Portscan Events Requires: IPS or DC/MDC + IPS

Version 4.7

The portscan detector generates intrusion events that you can view just as you would any other intrusion event. However, the information presented on the packet view is different from the other types of intrusion events. This section describes the fields that appear on the packet view for a portscan event and how


939


Chapter 22

you can use that information to understand the types of probes that occur on your network. Begin by using the intrusion event views to drill down to the packet view for a portscan event. You can follow the procedures in Working with Intrusion Events on page 651. A packet view of a TCP portscan appears. For example, this graphic illustrates the packet view for a TCP portscan event:

IMPORTANT! For events generated by the portscan flow detector, the protocol number is set to 255. Because portscan does not have a specific protocol associated with it by default, the Internet Assigned Numbers Authority (IANA) does not have a protocol number assigned to it. IANA designates 255 as a reserved number, so that number is used in portscan events to indicate that there is not an associated protocol for the event. The Portscan Packet View table describes the information provided in the packet view for portscan events. Portscan Packet View

Version 4.7

Information

Description

Detection Engine

The detection engine that detected the event.

Time

The time when the event occurred.

Message

The event message generated by the preprocessor.


940


Chapter 22

Portscan Packet View (Continued) Information

Description

Source IP

The IP address of the scanning host.

Destination IP

The IP address of the scanned host.

Priority Count

The number of negative responses (for example, TCP RSTs and ICMP unreachables) from the scanned host. The higher the number of negative responses, the higher the priority count.

Connection Count

The number of active connections on the hosts. This value is more accurate for connection-based scans such as TCP and IP.

IP Count

The number of times that the IP addresses that contact the scanned host changes. For example, if the first IP address is 10.1.1.1, the second IP is 10.1.1.2, and the third IP is 10.1.1.1, then the IP count is 3. This number is less accurate for active hosts such as proxies and DNS servers.

Scanner/Scanne d IP Range

The range of IP addresses for the scanned hosts or the scanning hosts, depending on the type of scan. For portsweeps, this field shows the IP range of scanned hosts. For portscans, this shows the IP range of the scanning hosts.

Port/Proto Count

For TCP and UDP portscans, the number of times that the port being scanned changes. For example, if the first port scanned is 80, the second port scanned is 8080, and the third port scanned is again 80, then the port count is 3. For IP protocol portscans, the number of times that the protocol being used to connect to the scanned host changes.

Port/Proto Range

For TCP and UDP portscans, the range of the ports that were scanned. For IP protocol portscans, the range of IP protocol numbers that were used to attempt to connect to the scanned host.

Open Ports

Version 4.7

The TCP ports that were open on the scanned host. This field appears only when the portscan detects one or more open ports.


941

Tuning Preprocessors Constraining Regular Expressions

Chapter 22

Constraining Regular Expressions Requires: IPS or DC/MDC + IPS

You can override default match and recursion limits on PCRE regular expressions that are used in intrusion rules to examine packet payload content. See Searching for Content Using PCRE on page 973 for information on using the PCRE keyword in intrusion rules. The default limits ensure a minimum level of performance. Overriding these limits could increase security, but could also significantly impact performance by permitting packet evaluation against inefficient regular expressions. WARNING! Do not override default PCRE limits unless you are an experienced intrusion rule writer with knowledge of the impact of degenerative patterns.

IMPORTANT! This feature is only available if you first import an SEU containing Snort 2.8.1 or later. The Regular Expression Constraint Options table describes the options you can configure to override the default limits. Regular Expression Constraint Options Option

Description

Override default PCRE match limit

Overrides the default limit of 1500 attempts to match a pattern defined in a PCRE regular expression. After selecting Override, you have two options: • select Unlimited to permit an unlimited number of attempts • select Defined limit and specify either a limit of 1 or greater, or specify 0 to completely disable PCRE match evaluation

Override default PCRE recursion limit

Overrides the default limit of 1500 recursions when evaluating a PRCE regular expression against the packet payload. After selecting Override, you have two options: • select Unlimited to permit an unlimited number of recursions • select Defined limit and specify a limit of 1 or greater, or specify 0 to completely disable PCRE recursions Note that for the recursion limit to be meaningful, it must be smaller than the match limit.

To configure PCRE overrides, see Configuring Standard Preprocessor Options on page 943.

Version 4.7


942

Tuning Preprocessors Logging Multiple Events per Packet or Stream

Chapter 22

Logging Multiple Events per Packet or Stream Requires: IPS or DC/MDC + IPS

When the rules engine evaluates traffic against rules, it places the events generated for a given packet or packet stream in an event queue, then reports the top events in the queue to the user interface. You can elect to have the rules engine log more than one event per packet or packet stream when multiple events are generated. Logging these events allows you to collect information beyond the reported event. When configuring this option, you can specify how many events can be placed in the queue and how many are logged, and select the criteria for determining event order within the queue. The Event Queue Configuration Options table describes the options you can configure to determine how many events are logged per packet or stream. Event Queue Configuration Options Option

Description

Max Events

The maximum number of events that can be stored for a given packet or packet stream.

Log Events

The number of events logged for a given packet or packet stream. This cannot exceed the Max Events value.

Order Events

The value used to determine event ordering within the event queue. The highest ordered event is reported through the user interface. You can select from: • priority, which orders events in the queue by the event priority. • content_length, which orders events by the longest identified content match. When events are ordered by content length, rule events always take precedence over decoder and preprocessor events.

Configuring Standard Preprocessor Options Requires: IPS or DC/MDC + IPS

Preprocessor settings, along with the default active rule set, make up the default policy. IMPORTANT! For information on the Stream 4 preprocessor, also known as the Stateful Inspection and Stream Reassembly preprocessor, see Understanding the Stream 4 Preprocessor on page 877.

Version 4.7


943

Tuning Preprocessors Configuring Standard Preprocessor Options

Chapter 22

To configure standard preprocessor options: Access: Rules or Admin

1.


2. Click Edit next to the policy whose preprocessor options you want to configure. The Edit Policy page appears. 3. Click Preprocessors. The Preprocessors page appears.

4. You can modify the following options in the Global Configuration section:

Version 4.7

•

Type a value for the maximum number of events for preprocessors to allow in queue in the Maximum Queued Events field..

•

To inspect packets which will be rebuilt into larger streams of data before and after stream reassembly, select Disable content checks that will be inserted through the stream reassembly process. Inspection before and after reassembly requires more processing overhead and may decrease performance.

•

To disable inspection of packets which will be rebuilt into larger streams of data before and after stream reassembly, clear Disable content checks that will be inserted through the stream reassembly process. Disabling inspection decreases the processing overhead for inspection of stream inserts and may boost performance.


944


Chapter 22

5. You can modify the following options in the Protocol Normalization section: •

Select or clear Back Orifice Detection. For more information, see Detecting Back Orifice on page 932.

•

Select or clear RPC Normalization, then enable the following options as needed: Alert on Fragments, Disable Alerts on Large Fragments, Disable Alerts on Incomplete Fragments, and Disable Alerts on Multiple Requests. In the Ports field, type the port numbers where you want to decode RPC traffic. Separate multiple ports with spaces. For more information, see the RPC Normalization Options table on page 891.

6. You can select one of the following options in the Checksum Verification section: •

Disable IP Checksums

•

Disable UDP Checksums

•

Disable Checksums

•

Disable ICMP Checksums

•

Disable TCP Checksums

•

Enable all Checksums

For more information about IP and ICMP checksums, see Validating Checksums on page 864. For more information about TCP and UDP checksums, see Validating Checksums on page 864.

7.

Version 4.7

You can modify any of the following options in the Decoding section: •

Disable Decode Events; see Disabling Decoding Event Alerting on page 865 for more information.

•

Disable Decode Drops; see Disabling Decode Drops on page 865 for more information.

•

Disable Events on Invalid IP Options; see Detecting Invalid IP Options on page 865 for more information.


945


Chapter 22

•

Disable Events on all Other TCP Options; see Detecting Invalid TCP Options on page 866 for more information.

•

Disable Events for Experimental TCP Options; see Detecting Experimental TCP Options on page 866 for more information.

•

Disable Events for Obsolete TCP Options; see Detecting Obsolete TCP Options on page 867 for more information.

•

Disable Events on T/TCP; see Detecting T/TCP Options on page 868 for more information.

8. You can modify any of the options in the IP Defragmentation section (you must select the IP Defragmentation check box to enable the IP defragmentation preprocessor). To add a target-based policy, click Add Target-Based Policy. You can have up to 255 target-based policies, including the default policy. To delete an existing target-based policy, click Remove next to the policy you want to remove. See Defragmenting IP Packets on page 869 for a full description of each available option.

Version 4.7


946


Chapter 22

9. You can modify any of the options in the Performance Monitor section. WARNING! Do not apply a policy with the Performance Monitor Enable debugging check box selected unless directed to do so by Sourcefire Support. Note that this feature is only available if you first import an SEU containing Snort 2.8.1 or later.[ See Monitoring Performance on page 932 for a description of each available option.

10. You can modify any of the options in the Regular Expression Constraint section. See Constraining Regular Expressions on page 942 for a description of each option. IMPORTANT! This feature is only available if you first import an SEU containing Snort 2.8.1 or later.

11. You can modify any of the options in the Event Queue Configuration section. See Constraining Regular Expressions on page 942 for a description of each option. 12. Click Save. 13. Click Back to return to the Edit Policy page. You must apply the policy containing your preprocessor configuration to implement your changes. See Applying an Intrusion Policy on page 764 for procedures.

Version 4.7


947

Chapter 22

Understanding and Writing Intrusion Rules

An intrusion rule is a specified set of keywords and arguments on a 3D Sensor with the IPS component that detects attempts to exploit vulnerabilities on your network by analyzing network traffic to check if it matches the criteria in the rule. IPS compares packets against the conditions specified in each rule and, if the packet data matches all the conditions specified in a rule, the rule triggers. If a rule is an alert rule, it generates an intrusion event. If it is a pass rule, it ignores the traffic. You can view and evaluate intrusion events from the 3D Sensor web interface or, in the case of a managed 3D Sensor, from the Defense Center web interface. WARNING! Make sure you use a controlled network environment to test any intrusion rules that you write before you use the rules in a production environment. Poorly written intrusion rules can seriously affect the performance of your Sourcefire 3D System.

IMPORTANT! For a drop rule, IPS drops the packet and generates an event. For more information on drop rules, see Using the Drop Rule State on page 798.

IMPORTANT! Sourcefire provides two types of rules: shared object rules and standard text rules. The Sourcefire Vulnerability Research Team can use shared object rules to detect attacks against vulnerabilities in ways that traditional standard text rules cannot. You cannot create shared object rules. When you write your own intrusion rule, you are creating a standard text rule.

Version 4.7


948

Understanding and Writing Intrusion Rules Understanding Rule Anatomy

Chapter 23

You can write custom standard text rules to tune the types of events you are likely to see. Note that while this documentation sometimes discusses rules targeted to detect specific exploits, the most successful rules target traffic that may attempt to exploit known vulnerabilities rather than specific known exploits. By writing rules and specifying the rule’s event message, you can more easily identify traffic that indicates attacks and policy evasions. For more information about evaluating events, see Working with Intrusion Events on page 651. See the following sections for more information. •

Understanding Rule Anatomy on page 949 describes the components, including the rule header and rule options, that make up a valid standard text rule.

•

Understanding Rule Headers on page 951 provides a detailed description of the parts of a rule header.

•

Understanding Keywords and Arguments in Rules on page 956 explains the usage and syntax of the intrusion rule keywords available in the Sourcefire 3D System.

•

Constructing a Rule on page 1008 explains how to build a new rule using the Rules Editor.

•

Searching for Rules on page 1014 explains how to search for existing rules.

Understanding Rule Anatomy Requires: IPS or DC/MDC + IPS

All standard text rules contain two logical sections: the rule header and the rule options. The rule header contains: •

the rule's action or type

•

the protocol

•

the source and destination IP addresses and netmasks

•

direction indicators showing the flow of traffic from source to destination

•

the source and destination ports

The rule options section contains:

Version 4.7

•

event messages

•

keywords and their parameters and arguments

•

patterns that a packet’s payload must match to trigger the rule

•

specifications of which parts of the packet the rules engine should inspect


949

Understanding and Writing Intrusion Rules Understanding Rule Anatomy

Chapter 23

The following diagram illustrates the parts of a rule:

Note that the options section of a rule is the section enclosed in parentheses. The Rule Editor provides an easy-to-use interface to help you build standard text rules. The following displays the same standard text rule within the Rule Editor:

Version 4.7


950

Understanding and Writing Intrusion Rules Understanding Rule Headers

Chapter 23

Understanding Rule Headers Requires: IPS or DC/MDC + IPS

Every standard text rule has parameters and arguments that make up the rule header. For example, the following illustrates the parts of a rule header:

The Rule Header Values table describes each part of the rule header shown above. Rule Header Values Rule Header Component

Example Value

This Value...

Action

alert

Generates an intrusion event when triggered.

Protocol

tcp

Tests TCP traffic only.

Source IP Address

$EXTERNAL_NET

Tests traffic coming from any host that is not on your internal network.

Source Ports

any

Tests traffic coming from any port on the originating host.

Operator

->

Tests external traffic (destined for the web servers on your network).

Destination IP Address

$HTTP_SERVERS

Tests traffic to be delivered to any host specified as a web server on your internal network.

Destination Ports

$HTTP_PORTS

Tests traffic delivered to an HTTP port on your internal network.

IMPORTANT! The previous example uses system variables, as do most rules. See Configuring Variables on page 778 for more information about variables, what they mean, and how to configure them.

Version 4.7


951


Chapter 23

See the following sections for more information about rule header parameters: •

Specifying Rule Actions on page 952 describes rule types and explains how to specify the action that occurs when the rule triggers.

•

Specifying Protocols on page 953 explains how to define the traffic protocol for traffic that the rule should test.

•

Specifying Source and Destination IP Addresses on page 953 explains how to define the individual IP addresses and IP ranges in the rule header.

•

Specifying Source and Destination Ports on page 954 explains how to define the individual ports and port ranges in the rule header.

•

Specifying Direction on page 956 describes the available operators and explains how to specify the direction traffic must be traveling to be tested by the rule.

Specifying Rule Actions Requires: IPS or DC/MDC + IPS

Each rule header includes a parameter that specifies the action the system takes when a packet triggers a rule. Rules with the action set to alert generate an intrusion event against the packet that triggered the rule and log the details of that packet. Rules with the action set to pass do not generate an event against, or log the details of, the packet that triggered the rule. IMPORTANT! In an inline intrusion policy, rules with the rule state set to drop generate an intrusion event against the packet that triggered the rule. Also, if you apply a drop rule to a passive intrusion policy, the rule acts as an alert rule. For more information on drop rules, see Using the Drop Rule State on page 798. By default, pass rules override alert rules. You can create pass rules to prevent packets that meet criteria defined in the pass rule from triggering the alert rule in specific situations, rather than disabling the alert rule. For example, you might want a rule that looks for attempts to log into an FTP server as the user “anonymous” to remain active. However, if your network has one or more legitimate anonymous FTP servers, you could write and activate a pass rule that specifies that, for those specific servers, anonymous users do not trigger the original rule. Within the Rule Editor, you select the rule type from the Action list. For more information about the procedures you use to build a rule header using the Rule Editor, see Constructing a Rule on page 1008.

Version 4.7


952


Chapter 23

Specifying Protocols Requires: IPS or DC/MDC + IPS

In each rule header, you must specify the protocol of the traffic the rule inspects. You can specify the following network protocols for analysis: •

ICMP (Internet Control Message Protocol)

•

IP (Internet Protocol)

•

TCP (Transmission Control Protocol)

•

UDP (User Datagram Protocol)

Use IP as the protocol type to examine all protocols assigned by IANA, including TCP, UDP, ICMP, IGMP, and many more. See http://www.iana.org/assignments/protocol-numbers for a full list of IANAassigned protocols. IMPORTANT! You cannot currently write rules that match patterns in the next header (for example, the TCP header) in an IP payload. Instead, content matches begin with the last decoded protocol. As a workaround, you can match patterns in TCP headers by using rule options. Within the Rule Editor, you select the protocol type from the Protocol list. See Constructing a Rule on page 1008 for more information about the procedures you use to build a rule header using the Rule Editor.

Specifying Source and Destination IP Addresses Requires: IPS or DC/MDC + IPS

Rule headers include the source and destination IP addresses of traffic that the rule inspects. You can restrict packet inspection to the packets originating from specific IP addresses or those destined to a specific IP address. This reduces the amount of packet inspection the system must perform. This also reduces false positives by making the rule more specific and removing the possibility of the rule triggering against packets whose source and destination IP addresses do not indicate suspicious behavior. WARNING! The system recognizes only IP addresses and will not accept host names for source or destination IP addresses.

Version 4.7


953


Chapter 23

The Source/Destination IP Address Syntax table describes the various ways you can specify source and destination IP addresses. Source/Destination IP Address Syntax To Specify...

Use...

Example

any IP address

any

any

a specific IP address

the IP address

192.168.1.1

a list of IP addresses

brackets ([]) to enclose the IP addresses and commas to separate them

[192.168.1.1,192.168.1.15]

a range of IP addresses

CIDR block notation

192.168.1.0/24

anything except a specific IP address or set of addresses

the ! character before the IP address or addresses you want to negate

!192.168.1.15

IMPORTANT! In the same rule, you cannot mix IP addresses that use the ! character with IP addresses that do not use it. You should create another rule. For more in-depth information about the syntax you can use to specify source and destination IP addresses, and for information about using variables to specify IP addresses, see Defining IP Addresses in Variables and Rules on page 774. Within the Rule Editor, you specify source and destination IP addresses in the Source IP and Destination IP fields. See Constructing a Rule on page 1008 for more information about the procedures you use to build a rule header using the Rule Editor.

Specifying Source and Destination Ports Requires: IPS or DC/MDC + IPS

Version 4.7

Rule headers specify the source and destination ports of the traffic the rule inspects. You can restrict packet inspection to packets originating from or destined to specific ports. This reduces the amount of packet inspection the system must perform. This also reduces false positives, making the rule more specific and removing the possibility for the rule to trigger against packets whose source and destination ports do not indicate suspicious behavior.


954


Chapter 23

The Source/Destination Port Syntax table describes the different ways you can specify source and destination ports. Source/Destination Port Syntax To Specify...

Use

Example

any port

any

any

a specific port

the port number

80

a range of ports

a dash between the first and last port number in the range

80-443

all ports less than or equal to a specific port

a dash before the port number

-21

all ports greater than or equal to a specific port

a dash after the port number

80-

all ports except a specific port or range of ports

the ! character before the port, port list, or range of ports you want to negate

!20

Note that you can logically use negation with all port designations except any, which if negated would indicate no port.

TIP! You can currently substitute a colon (:) for the hyphen (-) in any port definition, although eventually the colon will be deprecated. You can list ports by surrounding the port list with brackets and separating the ports with commas, as shown in the following example: [80, 8080, 8138, 8600-9000, !8650-8675]

For information about using variables to specify ports, see Defining Ports in Variables and Rules on page 777. Within the Rule Editor, you specify source and destination ports in the Source Port and Destination Port fields. See Constructing a Rule on page 1008 for more information about the procedures you use to build a rule header using the Rule Editor.

Version 4.7


955

Understanding and Writing Intrusion Rules Understanding Keywords and Arguments in Rules

Chapter 23

Specifying Direction Requires: IPS or DC/MDC + IPS

Within the rule header, you can specify the direction that the packet must travel for the rule to inspect it. The Directional Options in Rule Headers table describes these options. Directional Options in Rule Headers Use...

To Test...

Directional

only traffic from the specified source IP address to the specified destination IP address

Bidirectional

all traffic traveling between the specified source and destination IP addresses

See Constructing a Rule on page 1008 for more information about the procedures you use to build a rule header using the Rule Editor.

Understanding Keywords and Arguments in Rules Requires: IPS or DC/MDC + IPS

Using the rules language, you can specify the behavior of a rule by combining keywords. Keywords and their associated values (called arguments) dictate how the system evaluates packets and packet-related values that the rules engine tests. The Sourcefire 3D System currently supports keywords that allow you to perform inspection functions, such as content matching, protocol-specific pattern matching, and state-specific matching. You can combine any number of compatible keywords to create highly specific rules. This helps decrease the chance of false positives and false negatives and focus the intrusion information you receive. See the following sections for more information: •

Defining Intrusion Event Details on page 957 describes the syntax and use of keywords that allow you to define the event’s message, priority information, and references to external information about the exploit the rule detects.

•

Searching for Content Matches on page 962 describes how to use the content keyword to test the content of the packet payload.

•

Constraining Content Matches on page 964 describes how to use modifying keywords for the content keyword.

•

Using Byte_Jump and Byte_Test on page 968 describes how to use the

byte_jump and byte_test keywords to calculate where in a packet the

rules engine should begin testing for a content match, and which bytes it should evaluate.

Version 4.7


956


Chapter 23

•

Searching for Content Using PCRE on page 973 describes how to use the pcre keyword to use Perl-compatible regular expressions in rules.

•

Adding Metadata to a Rule on page 981 describes how to use the metada keyword to add information to a rule.

•

Inspecting IP Header Values on page 982 describes the syntax and use of keywords that test values in the packet’s IP header.

•

Inspecting ICMP Header Values on page 986 describes the syntax and use of keywords that test values in the packet’s ICMP header.

•

Inspecting TCP Header Values and Stream Size on page 987 describes the syntax and use of keywords that test values in the packet’s TCP header.

•

Extracting SSL Information from a Session on page 993 describes the use and syntax of keywords that extract version and state information from encrypted traffic.

•

Inspecting Application Layer Protocol Values on page 996 describes the use and syntax of keywords that test application layer protocol properties.

•

Inspecting Packet Characteristics on page 999 describes the use and syntax of the dsize, sameIP, isdataat, fragoffset, and cvs keywords.

•

Closing Offending Connections with Flexible Response on page 1002 explains how to use the resp keyword to actively close connections when rules containing the resp keyword trigger.

•

Limiting Event Notification on page 1003 describes how to set thresholds that limit the number of event instances that appear in the Event View when a rule triggers multiple times.

Defining Intrusion Event Details Requires: IPS or DC/MDC + IPS

As you construct a standard text rule, you can include contextual information that describes the vulnerability that the rule detects attempts to exploit. You can also include external references to vulnerability databases and define the priority that the event holds in your organization. When analysts see the event, they then have information about the priority, exploit, and known mitigation readily available. See the following sections for more information about event-related keywords: •

Defining the Event Message on page 957

•

Defining the Event Priority on page 958

•

Defining the Event Classification on page 958

•

Defining the Event Reference on page 962

Defining the Event Message Requires: IPS or DC/MDC + IPS

Version 4.7

You can specify meaningful text that appears as a message when the rule triggers. The message gives immediate insight into the nature of the vulnerability


957


Chapter 23

that the rule detects attempts to exploit. You can define almost any alphanumeric string, up to 63 characters long, as the event message. TIP! You must specify a rule message. Also, the message cannot consist of white space only, one or more quotation marks only, one or more apostrophes only, or any combination of just white space, quotation marks, or apostrophes. To define the event message in the Rule Editor, enter the event message in the Message field. See Constructing a Rule on page 1008 for more information about using the Rule Editor to build rules.

Defining the Event Priority Requires: IPS or DC/MDC + IPS

By default, the priority of a rule derives from the event classification for the rule. However, you can override the classification priority for a rule by adding the priority keyword to the rule. To specify a priority using the Rule Editor, select priority from the Detection Options list, and select high, medium, or low from the drop-down list. For example, to assign a high priority for a rule that detects web application attacks, add the priority keyword to the rule and select high as the priority. See Constructing a Rule on page 1008 for more information about using the Rule Editor to build rules.

Defining the Event Classification Requires: IPS or DC/MDC + IPS

For each rule, you can specify an attack classification that appears in the packet display of the event. The following lists the predefined classifications:

Version 4.7

•

A Client was Using an Unusual Port

•

A Network Trojan was Detected

•

A Suspicious Filename was Detected

•

A System Call was Detected

•

A Suspicious String was Detected

•

A TCP Connection was Detected

•

Access to a Potentially Vulnerable Web Application

•


•

Attempt to Login By Default Username and Password

•


•

Attempted Denial of Service

•

Attempted Information Leak

•

Attempt to Login By Default Username and Password

•



958


•

Decode of an RPC Query

•

Denial of Service

•

Detection of a Denial Of Service Attack

•

Detection of a Network Scan

•

Detection of a Non-Standard Protocol or Event

•

Executable Code was Detected

•

Generic ICMP Event

•

Generic Protocol Command Decode

•

Information Leak

•

Large Scale Information Leak

•

Misc Activity

•

Misc Attack

•

Not Suspicious Traffic

•

Pornography was Detected

•

Potential Corporate Privacy Violation

•

Potentially Bad Traffic

•


•


•

Unknown Traffic

•


•

Web Application Attack

Chapter 23

To specify a classification in the Rule Editor, select a classification from the Classification list. See Writing New Rules on page 1008 for more information on the Rule Editor.

Adding Custom Classifications Requires: IPS or DC/MDC + IPS

Version 4.7

If you want more customized content for the packet display description of the events generated by a rule you define, create a custom classification.


959


Chapter 23

To add classifications to the Classification list: Access: Rules or Admin

1.


2. Click Create Rule. The Create New Rule page appears.

Version 4.7


960


Chapter 23

3. Under the Classification drop-down list, click Edit Classifications. A pop-up window appears.

4. Type the name of the classification in the Classification Name field. You can use up to 255 alphanumeric characters, but the page is difficult to read if you use more than 40 characters. 5. Type a description of the classification in the Classification Description field. You can use up to 255 alphanumeric characters and spaces. 6. Select a priority from the Priority list. You can select high, medium, or low. 7.

Click Add. The new classification is added to the list and becomes available for use in the Rule Editor.

8. Click Done.

Version 4.7


961


Chapter 23

Defining the Event Reference Requires: IPS or DC/MDC + IPS

You can use the reference keyword to add references to external web sites and additional information about the event. Adding a reference provides analysts with an immediately available resource to help them identify why the packet triggered a rule. The External Attack Identification Systems table lists some of the external systems that can provide data on known exploits and attacks.

External Attack Identification Systems System

URL Prefix

Example ID

Bugtraq

http://www.securityfocus.com/bid/

8550

CVE

http://cve.mitre.org/cgibin/cvename.cgi?name=

CAN-2003-0702

Arachnids

http://www.whitehats.com/info/IDS

563

McAfee

http://vil.nai.com/vil/content/v_

100561.htm

url

http://

www.example.com?exploit=14

To specify a reference using the Rule Editor, select reference from the Detection Options list, and enter a value in the corresponding field as follows: id_system,id

where id_system is the system being used as a prefix, and id is the Bugtraq ID, CVE number, Arachnids ID, or URL (without http://). For example, to specify the authentication bypass vulnerability on Microsoft Commerce Server 2002 servers documented in Bugtraq ID 17134, enter the following in the reference field: bugtraq,17134

See Constructing a Rule on page 1008 for more information about using the Rule Editor to build rules.

Searching for Content Matches Requires: IPS or DC/MDC + IPS

Use the content keyword to specify content that you want to detect in a packet. The rules engine searches the packet payload or stream for that string. For example, if you enter /bin/sh as the value for the content keyword, the rules engine searches the packet payload for the string /bin/sh. Match content using either an ASCII string, hexadecimal content (binary byte code), or a combination of both. Surround hexadecimal content with pipe characters (|) in the keyword value. For example, you can mix hexadecimal

Version 4.7


962


Chapter 23

content and ASCII content using something that looks like |90C8 C0FF FFFF|/bin/sh. You can specify multiple content matches in a single rule. To do this, use additional instances of the content keyword. For each content match, you can indicate that content matches must be found in the packet payload or stream for the rule to trigger. You should almost always follow a content keyword by modifiers that indicate where the content should be searched for, whether the search is case-sensitive, and other options. See Constraining Content Matches for more information about modifiers to the content keyword. IMPORTANT! All content matches must be true for the rule to trigger an event, that is, each content match has an AND relationship with the others. To enter content to be matched: Access: Rules or Admin

1.

In the content field, type the content you want to search for (for example, |90C8 C0FF FFFF|/bin/sh). If you want to specify that the rule search for any content that is not the specified content, check the Not box. WARNING! You could invalidate your intrusion policy if you create a rule that includes only one content keyword and that keyword has the Not option selected. For more information, see Not on page 965.

2. Optionally, add additional keywords that modify the content keyword or add constraints for the keyword. For more information on other keywords, see Understanding Keywords and Arguments in Rules on page 956. For more information on constraining the content keyword, see Constraining Content Matches on page 964. 3. Continue with creating or editing the rule. See Writing New Rules on page 1008 or Modifying Existing Rules on page 1011 for more information. TIP! For an example of content keywords used in rules, see the examples in Rule-Writing Examples and Tips on page 1018. If you are using an inline detection engine, you can set up rules that match malicious content and then replace it with your own text string of equal length. See Understanding Replace Rules on page 1044 for more information.

Version 4.7


963


Chapter 23

Constraining Content Matches Requires: IPS or DC/MDC + IPS

You can constrain the location and case-sensitivity of content searches with parameters that modify the content keyword. Configure options that modify the content keyword to specify the content for which you want to search.

For more information, see the following sections. •

Case Insensitive on page 964

•

URI Only on page 964

•

Raw Data on page 965

•

Not on page 965

•

Distance on page 966

•

Within on page 967

•

Offset on page 967

•

Depth on page 967

Case Insensitive Requires: IPS or DC/MDC + IPS

You can instruct the rules engine to ignore case when searching for content matches in ASCII strings. To make your search case-insensitive, check Case Insensitive when specifying a content search. To specify Case Insensitive when doing a content search:


1.

Select Case Insensitive for the content keyword you are adding.

2. Continue with creating or editing the rule. See Constraining Content Matches, Searching for Content Matches on page 962, Writing New Rules on page 1008 or Modifying Existing Rules on page 1011 for more information.

URI Only Requires: IPS or DC/MDC + IPS

You can select URI Only to instruct the rules engine to search the packet for content matches only within URI data decoded by the HTTP Inspect preprocessor. The URI Only option applies only to TCP traffic. IMPORTANT! A pipelined HTTP request packet contains multiple URIs. When URI Only is selected and the rules engine detects a pipelined HTTP request packet, the rules engine searches all URIs in the packet for a content match.

Version 4.7


964


Chapter 23

To specify URI Only when doing a content search of TCP traffic: Access: Rules or Admin

1.

Select URI Only for the content keyword you are adding.

2. Continue with creating or editing the rule. See Constraining Content Matches, Searching for Content Matches on page 962, Writing New Rules on page 1008, or Modifying Existing Rules on page 1011 for more information.

Raw Data Requires: IPS or DC/MDC + IPS

The raw data option instructs the rules engine to analyze the original packet payload before analyzing the normalized payload data (data decoded by a Sourcefire 3D System preprocessor) and does not use an argument value. You can use this keyword when analyzing telnet traffic to check the telnet negotiation options in the payload prior to normalization. To analyze raw data:


1.

Select the Raw Data check box for the content keyword you are adding.


Not Requires: IPS or DC/MDC + IPS

Select the Not option to search for content that does not match the specified content. If you create a rule that includes a content keyword with the Not option selected, you must also include in the rule at least one other content keyword without the Not option selected. WARNING! Do not create a rule that includes only one content keyword if that keyword has the Not option selected. You could invalidate your intrusion policy. For more information, see Creating Intrusion Policies on page 747. For example, SMTP rule 1:2541:7 includes three content keywords, one of which has the Not option selected. A custom rule based on this rule would be invalid if

Version 4.7


965


Chapter 23

you removed all of the content keywords except the one with the Not option selected. Adding such a rule to your intrusion policy could invalidate the policy.

To search for content that does not match the specified content: Access: Rules or Admin

1.

Select the Not check box for the content keyword you are adding.

2. Include in the rule at least one other content keyword that does not have the Not option selected. 3. Continue with creating or editing the rule. See Constraining Content Matches, Searching for Content Matches on page 962, Writing New Rules on page 1008, or Modifying Existing Rules on page 1011 for more information.

Distance Requires: IPS or DC/MDC + IPS

You can instruct the rules engine to identify subsequent content matches that occur a specified number of bytes after the previous successful content match. The distance counter starts at byte 0, so calculate the distance value by subtracting 1 from the number of bytes you want to move forward from the last successful content match. For example, if you specify a Distance value of 4, the rules engine starts searching for identical content matches five bytes after the previous content match. For a detailed example of a rule that uses the distance keyword, see Finding the Procedure Number Using Distance and Within on page 1039. To specify a distance for a content match:


1.

Type the distance value in the Distance field for the content keyword you are adding.


Version 4.7


966


Chapter 23

Within Requires: IPS or DC/MDC + IPS

The Within option indicates that, to trigger the rule, the next content match must occur within the specified number of bytes after the end of the last successful content match. For example, if you specify a Within value of 8, the next content match must occur within the next eight bytes of the packet payload or it does not meet the criteria that triggers the rule. To specify a within value in the user interface:


1.

Type the within value in the Within field for the content keyword you are adding.

2. Continue with creating or editing the rule. See Constraining Content Matches, Searching for Content Matches on page 962, Writing New Rules on page 1008 or Modifying Existing Rules on page 1011 for more information. For a detailed example of a rule that uses the within option, see Finding the Procedure Number Using Distance and Within on page 1039.

Offset Requires: IPS or DC/MDC + IPS

Use the offset keyword to specify where the rules engine should start searching for content within a packet payload, measured in bytes (note that all packet payloads start at byte 0). Because the offset counter starts at byte 0, calculate the offset value by subtracting 1 from the number of bytes you want to move forward from the beginning of the packet payload. For example, if you added a content match with an offset value of 7, the rules engine starts searching for the content at the eighth byte in the packet payload (or byte 7). Using an offset promotes more efficient searches by constraining the portion of packet payload that is searched and is useful in instances where you know that the matching content will not appear in the first part of the packet. Conversely, you should be sure not to set the value for offset too stringently, because the rules engine will not inspect the bytes that appear before the specified offset value. For an example of offset used in a rule, see Matching Content Patterns in Packet Payloads on page 1027. To specify an offset for a content match:


1.

Type the offset value in the Offset field for the content keyword you are adding.


Depth Requires: IPS or DC/MDC + IPS

Version 4.7

You can specify the maximum content search depth, in bytes, from the beginning of the offset value, or, if no offset is configured, from the beginning of the packet payload.


967


Chapter 23

For example, in a rule with a content value of cgi-bin/phf, and offset value of 3, and a depth value of 22, the rule starts searching for a match to the cgibin/phf string at byte 3, and stops after processing 22 bytes (byte 25) in packets that meet the parameters specified by the rule header. For a detailed example of how to use the depth keyword, see Matching Content Patterns in Packet Payloads on page 1027. To specify a depth for a content match: Access: Rules or Admin

1.

Type the depth value in the Depth field for the content keyword you are adding.


Using Byte_Jump and Byte_Test Requires: IPS or DC/MDC + IPS

You can use byte_jump and byte_test to calculate where in a packet the rules engine should begin testing for a data match, and which bytes it should evaluate. See the following sections for more information. •

byte_jump on page 968

•

byte_test on page 971

byte_jump Requires: IPS or DC/MDC + IPS

The byte_jump keyword calculates the number of bytes defined in a specified byte segment, and then skips that number of bytes within the packet, either forward from the end of the specified byte segment, or from the beginning of the packet payload, depending on the options you specify. This is useful in packets where a specific segment of bytes describe the number of bytes included in variable data within the packet. h

Version 4.7

To use byte_jump, select it in the drop-down list and click Add Option. Byte_Jump appears beneath the last keyword you selected.


968


Chapter 23

The Required byte_jump Arguments table describes the arguments required by the byte_jump keyword. Required byte_jump Arguments Argument

Description

Bytes

The number of bytes to calculate from the packet.

Offset

The number of bytes into the payload to start processing. The offset counter starts at byte 0, so calculate the offset value by subtracting 1 from the number of bytes you want to jump forward from the beginning of the packet payload or the last successful content match.

The Additional Optional byte_jump Arguments table describes options you can use to define how the system interprets the values you specified for the required arguments. Additional Optional byte_jump Arguments Argument

Description

Relative

Makes the offset relative to the last pattern found in the last successful content match.

Align

Rounds the number of converted bytes up to the next 32bit boundary.

Multiplier

Indicates the value by which the rules engine should multiply the byte_jump value obtained from the packet to get the final byte_jump value. That is, instead of skipping the number of bytes defined in a specified byte segment, the rules engine skips that number of bytes multiplied by an integer you specify with the Multiplier argument.

From Beginning

Version 4.7

Indicates that the rules engine should skip the specified number of bytes in the payload starting from the beginning of the packet payload, rather than from the end of the byte segment that specifies the number of bytes to skip.


969


Chapter 23

If you want to define how the byte_jump keyword calculates the bytes, you can choose from the arguments described in the Endianness-Related Arguments table (if neither argument is specified, network byte order is used). Endianness-Related Arguments Argument

Description

Big Endian

Processes data in big endian byte order, which is the default network byte order.

Little Endian

Processes data in little endian byte order.

Define how the system views string data in a packet by using one of the arguments in the Number Type-Related Arguments table. Number Type-Related Arguments Argument

Description

Hexadecimal String

Represents converted string data in hexadecimal format.

Decimal String

Represents converted string data in decimal format.

Octal String

Represents converted string data in octal format.

For example, if the values you set for byte_jump are as follows: •

Bytes = 4

•

Offset = 12

•

Relative enabled

•

Align enabled

the rules engine calculates the number described in the four bytes that appear 13 bytes after the last successful content match, and skips ahead that number of bytes in the packet. For instance, if the four calculated bytes in a specific packet were 00 00 00 1F, the rules engine would convert this to 31. Because align is specified (which instructs the engine to move to the next 32-bit boundary), the rules engine skips ahead 32 bytes in the packet. Alternately, if the values you set for byte_jump are as follows:

Version 4.7

•

Bytes = 4

•

Offset = 12

•

From Beginning enabled

•

Multiplier = 2


970


Chapter 23

the rules engine calculates the number described in the four bytes that appear 13 bytes after the beginning of the packet. Then, the engine multiplies that number by two to obtain the total number of bytes to skip. For instance, if the four calculated bytes in a specific packet were 00 00 00 1F, the rules engine would convert this to 31, then multiply it by two to get 62. Because From Beginning is enabled, the rules engine skips the first 63 bytes in the packet. See Using byte_jump to Skip Authentication Bytes on page 1040 for a detailed example of a rule that uses the byte_jump keyword.

byte_test Requires: IPS or DC/MDC + IPS

The byte_test keyword calculates the number of bytes in a specified byte segment and compares them, according to the operator and value you specify. h

To use byte_test, select it in the drop-down list on the New Rule page, and click Add Option. A byte_test section appears beneath the last keyword you selected.

The byte_test Arguments table describes the required arguments for the

byte_test keyword.

byte_test Arguments Argument

Description

Bytes

The number of bytes to calculate from the packet.

Operator and Value

Compares the specified value to , =, !, &, ^, !>, ! 128

•

Offset = 8

•

Relative enabled


972


Chapter 23

the rules engine calculates the number described in the four bytes that appear 9 bytes away from (relative to) the last successful content match, and, if the calculated number is larger than 128 bytes, the rule is triggered. See Using byte_test to Calculate Data Size on page 1042 for a detailed example of a rule that uses the byte_test keyword.

Searching for Content Using PCRE Requires: IPS or DC/MDC + IPS

The pcre keyword allows you to use Perl-compatible regular expressions (PCRE) to inspect packet payloads for specified content. You can use PCRE to avoid writing multiple rules to match slight variations of the same content. Regular expressions are useful when searching for content that could be displayed in a variety of ways. The content may have different attributes that you want to account for in your attempt to locate it within a packet’s payload. Note that the regular expression syntax used in intrusion rules is a subset of the full regular expression library and varies in some ways from the syntax used in commands in the full library. When adding a pcre keyword using the Rule Editor, enter the full value in the following format: !/pcre/ ismxAEGRUB

where:

Version 4.7

•

! is an optional negation (use this if you want to match patterns that do not match the regular expression).

•

/pcre/ is a Perl-compatible regular expression.

•

ismxAEGRUB is any combination of modifier options.


973


Chapter 23

Also note that you must escape the characters listed in the following table for the rules engine to interpret them correctly when you use them in a PCRE to search for specific content in a packet payload. Escaped PCRE Characters You must escape...

with a backslash...

or Hex code...

# (hash mark)

\#

\x23

; (semicolon)

\;

\x3B

| (vertical bar)

\|

\x7C

: (colon)

\:

\x3A

TIP! Optionally, you can surround your Perl-compatible regular expression with quote characters, for example, pcre_expression or “pcre_expression“.The option of using quotes accommodates experienced users accustomed to previous versions when quotes were required instead of optional. The Rule Editor does not display quotation marks when you display a rule after saving it. You can also use m?regex?, where ? is a delimiter other than /. You may want to use this in situations where you need to match a forward slash within a regular expression and do not want to escape it with a backslash. For example, you might use m?regex? ismxAEGRUB where regex is your Perl-compatible regular expression and ismxAEGRUB is any combination of modifier options. See PerlCompatible Regular Expression Basics on page 975 for more information about regular expression syntax. The following sections provide more information about building valid values for the pcre keyword:

Version 4.7

•

Perl-Compatible Regular Expression Basics on page 975 describes the common syntax used in Perl-compatible regular expressions.

•

PCRE Modifier Options on page 977 describes the options you can use to modify your regular expression.

•

Example PCRE Keyword Values on page 979 gives example usage of the pcre keyword in rules.


974


Chapter 23

Perl-Compatible Regular Expression Basics Requires: IPS or DC/MDC + IPS

The pcre keyword accepts standard Perl-compatible regular expression (PCRE) syntax. The following sections describe that syntax. TIP! While this section describes the basic syntax you may use for PCRE, you may want to consult an online reference or book dedicated to Perl and PCRE for more advanced information.

Metacharacters Requires: IPS or DC/MDC + IPS

Metacharacters are literal characters that have special meaning within regular expressions. When you use them within a regular expression, you must “escape” them by preceding them with a backslash. The PCRE Metacharacters table describes the metacharacters you can use with PCRE and gives examples of each.

PCRE Metacharacters Metacharacter

Description

Example

.

Matches any character except newlines. If s is used as a modifying option, it also includes newline characters.

on.

*

Matches zero or more occurrences of a character or expression.

abc* matches abc, abcc, abccc, abccccc, and so on.

?

Matches zero or one occurrence of a character or expression.

abc? matches abc.

+

Matches one or more occurrences of a character or expression.

()

Groups expressions.

(abc)+ matches abc, abcabc, abcabcabc and so on.

{}

Specifies a limit for the number of matches for a character or expression. If you want to set a lower and upper limit, separate the lower limit and upper limit with a comma.

a{4,6} matches aaaa, aaaaa, or aaaaaa.

Allows you to define character classes, and matches any character or combination of characters described in the set.

[abc123] matches a or b or c, and so

[]

Version 4.7

abc. matches abcd, abc1, abc#, and so

abc+ matches abc, abcc, abccc, and so

on.

(ab){2} matches abab.

on.


975


Chapter 23

PCRE Metacharacters (Continued) Metacharacter

Description

Example

^

Matches content at the beginning of a string. Also used for negation, if used within a character class.

în matches the “in” in info, but not in bin. [â] matches anything that does not contain a.

$

Matches content at the end of a string.

ce$ matches the “ce” in announce, but not cent.

|

Indicates an OR expression.

(MAILTO|HELP) matches MAILTO or HELP.

\

Allows you to use metacharacters as actual characters and is also used to specify a predefined character class.

\. matches a period, \* matches an asterisk, \\ matches a backslash and so on. \d matches the numeric characters, \w matches alphanumeric characters,

and so on. See Character Classes on page 976 for more information about using character classes in PCRE.

Character Classes Requires: IPS or DC/MDC + IPS

Character classes include alphabetic characters, numeric characters, alphanumeric characters, and whitespace characters. While you can create your own character classes within brackets (see Metacharacters on page 975), you can use the predefined classes as shortcuts for different types of character types. When used without additional qualifiers, a character class matches a single digit or character. The PCRE Character Classes table describes and provides examples of the predefined character classes accepted by PCRE. PCRE Character Classes

Version 4.7

Character Class

Description

Character Class Definition

\d

Matches a numeric character (“digit”).

[0-9]

\D

Matches anything that is not an numeric character.

[^0-9]

\w

Matches an alphanumeric character (“word”).

[a-zA-Z0-9_]

\W

Matches anything that is not an alphanumeric character.

[â-zA-Z0-9_]


976


Chapter 23

PCRE Character Classes (Continued) Character Class

Description

Character Class Definition

\s

Matches whitespace characters, including spaces, carriage returns, tabs, newlines, and form feeds.

[ \r\t\n\f]

\S

Matches anything that is not a whitespace character.

[^ \r\t\n\f]

PCRE Modifier Options Requires: IPS or DC/MDC + IPS

You can use modifying options after you specify regular expression syntax in the pcre keyword’s value. These modifiers perform Perl, PCRE, and Snort-specific processing functions. Modifiers always appear at the end of the PCRE value, and appear in the following format: /pcre/ismxAEGRUB

where ismxAEGRUB can include any of the modifying options that appear in the following tables. TIP! Optionally, you can surround the regular expression and any modifying options with quotes, for example, “/pcre/ismxAEGRUB”. The option of using quotes accommodates experienced users accustomed to previous versions when quotes were required instead of optional. The Rule Editor does not display quotation marks when you display a rule after saving it. The Perl-Related Post Regular Expression Options table describes options you can use to perform Perl processing functions. Perl-Related Post Regular Expression Options

Version 4.7

Option

Description

i

Makes the regular expression case-insensitive.

s

The dot character (.) describes all characters except the newline or \n character. You can use "s" as an option to override this and have the dot character match all characters, including the newline character.


977


Chapter 23

Perl-Related Post Regular Expression Options (Continued) Option

Description

m

By default, a string is treated as a single line of characters, and ^ and $ match the beginning and ending of a specific string. When you use "m" as an option, ^ and $ match content immediately before or after any newline character in the buffer, as well as at the beginning or end of the buffer.

x

Ignores whitespace data characters that may appear within the pattern, except when escaped (preceded by a backslash) or included inside a character class.

The PCRE-Related Post Regular Expression Options table describes the PCRE modifiers you can use after the regular expression. PCRE-Related Post Regular Expression Options

Version 4.7

Option

Description

A

The pattern must match at the beginning of the string (same as using ^ in a regular expression).

E

Sets $ to match only at the end of the subject string. (Without E, $ also matches immediately before the final character if it is a newline, but not before any other newline characters).

G

By default, * + and ? are “greedy,” which means that if two or more matches are found, they will choose the longest match. Use the G character to change this so that these characters always choose the first match unless followed by a question mark character (?). For example, *? +? and ?? would be greedy in a construct using the G modifier, and any incidences of *, +, or ? without the additional question mark will not be greedy.


978


Chapter 23

The Snort-Specific Post Regular Expression Modifiers table describes the Snortspecific modifiers that you can use after the regular expression. Snort-Specific Post Regular Expression Modifiers Option

Description

R

Searches for matching content relative to the end of the last match found by the rules engine.

U

Searches for the content within URI data decoded by the HTTP Inspect preprocessor.

B

Searches for the content within data before it is decoded by a preprocessor (this option is similar to the rawbytes keyword).

IMPORTANT! A pipelined HTTP request packet contains multiple URIs. A PCRE expression that includes the U option causes the rules engine to search for a content match only in the first URI in a pipelined HTTP request packet. To search all URIs in the packet, use the content keyword with URI Only selected, either with or without an accompanying PCRE expression that uses the U option. (For additional information, see URI Only on page 964.)

IMPORTANT! Do not use the R and U options together. This could cause performance problems.

Example PCRE Keyword Values Requires: IPS or DC/MDC + IPS

The following examples show values that you could enter for pcre, with descriptions of what each example would match. •

/feedback[(\d{0,1})]?\.cgi/U

This example searches packet payload for feedback, followed by zero or one numeric character, followed by .cgi, and located only in URI data. This example would match: • feedback.cgi • feedback1.cgi • feedback2.cgi • feedback3.cgi This example would not match: • feedbacka.cgi • feedback11.cgi

Version 4.7


979


• • •

Chapter 23

feedback21.cgi feedbackzb.cgi

/êz(\w{3,5})\.cgi/iU

This example searches packet payload for ez at the beginning of a string, followed by a word of 3 to 5 letters, followed by .cgi. The search is caseinsensitive and only searches URI data. This example would match: • EZBoard.cgi • ezman.cgi • ezadmin.cgi • EZAdmin.cgi This example would not match: • ezez.cgi • fez.cgi • abcezboard.cgi • ezboardman.cgi •

/mail(file|seek)\.cgi/U

This example searches packet payload for mail, followed by either file or seek, in URI data. This example would match: • mailfile.cgi • mailseek.cgi This example would not match: • MailFile.cgi • mailfilefile.cgi •

m?http\\x3a\x2f\x2f.*(\n|\t)+?U

This example searches packet payload for URI content for a tab or newline character in an HTTP request, after any number of characters. This example uses m?regex? to avoid using http\:\/\/ in the expression. Note that the colon is preceded by a backslash. This example would match: • http://www.example.com?scriptvar=x&othervar=\n\..\.. • http://www.example.com?scriptvar=\t This example would not match: • ftp://ftp.example.com?scriptvar=&othervar=\n\..\.. • http://www.example.com?scriptvar=|/bin/sh -i|

Version 4.7


980


•

Chapter 23

m?http\\x3a\x2f\x2f.*=\|.*\|+?sU

This example searches packet payload for a URL with any number of characters, including newlines, followed by an equal sign, and pipe characters that contain any number of characters or white space. This example uses m?regex? to avoid using http\:\/\/ in the expression. This example would match: • http://www.example.com?value=|/bin/sh/ -i| • http://www.example.com?input=|cat /etc/passwd| This example would not match: • ftp://ftp.example.com?value=|/bin/sh/ -i| • http://www.example.com?value=x&input?|cat /etc/passwd| •

/[0-9a-f]{2}\:[0-9a-f]{2}\:[0-9a-f]{2}\:[0-9a-f]{2}\:[0-9af]{2}\:[0-9a-f]{2}/i

This example searches packet payload for any MAC address. Note that it escapes the colon characters with backslashes.

Adding Metadata to a Rule Requires: IPS or DC/MDC + IPS

You can use the metadata keyword to add descriptive information to a rule, using either the format: key value

where key and value provide a combined description separated by a space. Optionally, you can also use the format: key=value

You can use the information you add to organize or identify rules in ways that suit your needs, and to search for rules. For example, you could identify rules by author and date, using a category and sub-category as follows: author SnortGuru_20050406

You can use multiple metadata keywords in a rule, you can separate multiple key value statements with commas in a single metadata keyword, or both. The following example combines multiple statements in a single keyword: author SnortGuru_20050406, revised_by SnortUser1_20050707, revised_by SnortUser2_20061003, revised_by SnortUser1_20070123

Note the following character restrictions:

Version 4.7

•

You cannot use a semi-colon (;) or colon (:) in a key value statement.

•

You can use a comma only after a key value statement to separate it from a subsequent key value statement.

•

You cannot use an equal to (=) character or a space character except as separators between key and value.


981


Chapter 23

All other characters are permitted.

Avoiding Reserved Metadata Requires: IPS or DC/MDC + IPS

You must not use the following words for key in a key value statement in a metadata keyword; these are reserved for use by the Sourcefire Vulnerability Research Team (VRT): application engine os rule-type rule-flushing service soid

Searching for Rules with Metadata Requires: IPS or DC/MDC + IPS

You can conveniently search for rules that use the metadata keyword and for specific metadata key value statements. When searching for rules that use the metadata keyword, select the metadata keyword on the rules Search page and, optionally, type any portion of the key value statement next to the keyword. For example, you would: •

type author to display all rules where you have used author for key.

•

type author snortguru to display all rules where you have used author for key and SnortGuru for value.

•

type author s to display all rules where you have used author for key and any terms such as SnortGuru or SnortUser1 or SnortUser2 for value.

TIP! When you search for both key and value, use the same connecting operator (equal to (=) or a space character) in searches that is used in the key value statement in the rule; searches return different results depending on whether you follow key with equal to (=) or a space character. For more information on searching for intrusion rules, see Searching for Rules on page 1014.

Inspecting IP Header Values Requires: IPS or DC/MDC + IPS

Version 4.7

You can use keywords to identify possible attacks or security policy violations in the IP headers of packets. See the following sections for more information: •

Inspecting Fragments and Reserved Bits on page 983

•

Inspecting the IP Header Identification Value on page 983

•

Identifying Specified IP Options on page 984


982


•

Identifying Specified IP Protocol Numbers on page 984

•

Inspecting a Packet’s Type of Service on page 985

•

Inspecting a Packet’s Time-To-Live Value on page 985

Chapter 23

Inspecting Fragments and Reserved Bits Requires: IPS or DC/MDC + IPS

The fragbits keyword inspects the fragment and reserved bits in the IP header. You can check each packet for the Reserved Bit, the More Fragments bit, and the Don't Fragment bit in any combination. Fragbits Argument Values Argument

Description

R

Reserved bit

M

More Fragments bit

D

Don’t Fragment bit

To further refine a rule using the fragbits keyword, you can specify any operator described in the Fragbit Operators table after the argument value in the rule. Fragbit Operators Operator

Description

plus sign (+)

The packet must match on all specified bits.

asterisk (*)

The packet can match on any of the specified bits.

exclamation point (!)

The packet meets the criteria if none of the specified bits are set.

For example, to generate an event against packets that have the Reserved Bit set (and possibly any other bits), use R+ as the fragbits value.

Inspecting the IP Header Identification Value Requires: IPS or DC/MDC + IPS

Version 4.7

The id keyword tests the IP header fragment identification field against the value you specify in the keyword’s argument. Some denial-of-service tools and scanners set this field to a specific number that is easy to detect. For example, in


983


Chapter 23

SID 630, which detects a Synscan portscan, the id value is set to 39426, the static value used as the ID number in packets transmitted by the scanner. IMPORTANT!

ID argument values must be numeric.

Identifying Specified IP Options Requires: IPS or DC/MDC + IPS

The IPopts keyword allows you to search packets for specified IP header options. The IPoption Arguments table lists the available argument values. IPoption Arguments Argument

Description

rr

record route

eol

end of list

nop

no operation

ts

time stamp

sec

IP security option

lsrr

loose source routing

ssrr

strict source routing

satid

stream identifier

Analysts most frequently watch for strict and loose source routing because these options may be an indication of a spoofed source IP address.

Identifying Specified IP Protocol Numbers Requires: IPS or DC/MDC + IPS

Version 4.7

The ip_proto keyword allows you to identify packets with the IP protocol specified as the keyword’s value. You can specify the IP protocols as a number, 0 through 255. You can find the complete list of protocol numbers at http://www.iana.org/assignments/protocol-numbers. You can combine these numbers with the following operators: , or !. For example, to inspect traffic with any protocol that is not ICMP, use !1 as a value to the ip_proto keyword. You can also use the ip_proto keyword multiple times in a single rule; note, however, that the rules engine interprets multiple instances of the keyword as


984


Chapter 23

having a Boolean AND relationship. For example, if you create a rule containing ip_proto:!3; ip_proto:!6, the rule ignores traffic using the GGP protocol AND the TCP protocol.

Inspecting a Packet’s Type of Service Requires: IPS or DC/MDC + IPS

Some networks use the type of service (ToS) value to set precedence for packets traveling on that network. The tos keyword allows you to test the packet’s IP header ToS value against the value you specify as the keyword’s argument. Rules using the tos keyword will trigger on packets whose ToS is set to the specified value and that meet the rest of the criteria set forth in the rule. IMPORTANT!

Argument values for tos must be numeric.

IMPORTANT! The ToS field has been deprecated in the IP header protocol and replaced with the Differentiated Services Code Point (DSCP) field.

Inspecting a Packet’s Time-To-Live Value Requires: IPS or DC/MDC + IPS

Version 4.7

A packet’s time-to-live (ttl) value indicates how many hops it can make before it is dropped. You can use the ttl keyword to test the packet’s IP header ttl value against the value, or range of values, you specify as the keyword’s argument. It may be helpful to set the ttl keyword parameter to a low value such as 0 or 1, as low time-to-live values are sometimes indicative of a traceroute or intrusion evasion attempt. (Note, though, that the appropriate value for this keyword depends on your sensor placement and network topology.) Use syntax as follows: •

Use an integer from 0 to 255 to set a specific value for the TTL value.

•

Use a hyphen (-) to specify a range of TTL values (for example, 0-2 specifies all values between 0 and 2).

•

Use the greater than (>) sign to specify TTL values greater than a specific value (for example, >3 specifies all values greater than 3).

•

Use the greater than and equal to signs (>=) to specify TTL values greater than or equal to a specific value (for example, >=3 specifies all values greater than or equal to 3).

•

Use the less than (, 200 would trigger when traffic from the client is greater than 200 bytes OR traffic from the server is greater than 200 bytes.

The stream_size Keyword Argument Operators table describes the operators you can use with the stream_size keyword: stream_size Keyword Argument Operators Operator

Description

=

equal to

!=

not equal to

>

greater than

=

greater than or equal to

=, 5001216 as the argument for the stream_size keyword to detect a TCP stream traveling from a client to a server and greater than or equal to 5001216 bytes.

Extracting SSL Information from a Session Requires: IPS or DC/MDC + IPS

Version 4.7

You can use SSL rule keywords to invoke the Secure Sockets Layer (SSL) preprocessor and extract information about SSL version and session state from packets in an encrypted session.


993


Chapter 23

When a client and server communicate to establish an encrypted session using SSL or Transport Layer Security (TLS), they exchange handshake messages. Although the data transmitted in the session is encrypted, the handshake messages are not. The SSL preprocessor extracts state and version information from specific handshake fields. Two fields within the handshake indicate the version of SSL or TLS used to encrypt the session and the stage of the handshake. IMPORTANT! The ssl_state and ssl_version keywords can only invoke the SSL preprocessor on sensors where the SSL preprocessor is enabled in the policy applied to the sensor. Because the SSL preprocessor interface only appears on Defense Centers or 3D Sensors running Sourcefire 3D System Version 4.7 or higher, you cannot write rules using these keywords on appliances running lower versions. For more information, see the following sections: •

ssl_state on page 994

•

ssl_version on page 995

ssl_state Requires: IPS or DC/MDC + IPS

The ssl_state keyword can be used to match against state information for an encrypted session. When a rule uses the ssl_state keyword, the rules engine invokes the SSL preprocessor to check traffic for SSL state information. For example, to detect an attacker’s attempt to cause a buffer overflow on a server by sending a ClientHello message with an overly long challenge length and too much data, you could use the ssl_state keyword with client_hello as an argument then check for abnormally large packets. Use a comma-separated list to specify multiple arguments for the SSL state. When you list multiple arguments, IPS evaluates them using the OR operator. For example, if you specify client_hello and server_hello as arguments, IPS evaluates the rule against traffic that has a client_hello OR a server_hello. The ssl_state keyword takes the following identifiers as arguments: ssl_state Arguments

Version 4.7

Argument

Purpose

client_hello

Matches against a handshake message with ClientHello as the message type, where the client requests an encrypted session.

server_hello

Matches against a handshake message with ServerHello as the message type, where the server responds to the client’s request for an encrypted session.


994


Chapter 23

ssl_state Arguments (Continued)

Argument

Purpose

client_keyx

Matches against a handshake message with ClientKeyExchange as the message type, where the client transmits a key to the server to confirm receipt of a key from the server.

server_keyx

Matches against a handshake message with ServerKeyExchange as the message type, where the client transmits a key to the server to confirm receipt of a key from the server.

unknown

Matches against any handshake message type

ssl_version Requires: IPS or DC/MDC + IPS

The ssl_version keyword can be used to match against version information for an encrypted session. When a rule uses the ssl_version keyword, the rules engine invokes the SSL preprocessor to check traffic for SSL version information. For example, if you know there is a buffer overflow vulnerability in SSL version 2, you could use the ssl_version keyword with the sslv2 argument to identify traffic using that version of SSL. Use a comma-separated list to specify multiple arguments for the SSL version. When you list multiple arguments, IPS evaluates them using the OR operator. For example, if you wanted to identify any encrypted traffic that was not using SSLv2, you could add ssl_version:ssl_v3,tls1.0,tls1.1,tls1.2 to a rule. The rule would evaluate any traffic using SSL Version 3, TLS Version 1.0, TLS Version 1.1, or TLS Version 1.2. The ssl_version keyword takes the following SSL/TLS version identifiers as arguments: ssl_version Arguments

Version 4.7

Argument

Purpose

sslv2

Matches against traffic encoded using Secure Sockets Layer (SSL) Version 2.

sslv3

Matches against traffic encoded using Secure Sockets Layer (SSL) Version 3.

tls1.0

Matches against traffic encoded using Transport Layer Security (TLS) Version 1.0.


995


Chapter 23

ssl_version Arguments (Continued)

Argument

Purpose

tls1.1


tls1.2


Inspecting Application Layer Protocol Values Requires: IPS or DC/MDC + IPS

Although preprocessors perform most of the normalization and inspection of application layer protocol values, you can continue to inspect application layer values using the keywords described in the following sections: •

RPC on page 996

•

ASN.1 on page 997

•

urilen on page 998

RPC Requires: IPS or DC/MDC + IPS

The rpc keyword identifies RPC services in TCP or UDP packets. This allows you to detect attempts to identify the RPC programs on a host. Intruders can use an RPC portmapper to determine if any of the RPC services running on your network can be exploited. They can also attempt to access other ports running RPC without using portmapper. The rpc Keyword Arguments table lists the arguments that the rpc keyword accepts. rpc Keyword Arguments Argument

Description

application

The RPC application number

procedure

The RPC procedure invoked

version

The RPC version

To specify the arguments for the rpc keyword, use the following syntax: application,procedure,version

where application is the RPC application number, procedure is the RPC procedure number, and version is the RPC version number. You must specify all arguments for the rpc keyword – if you are not able to specify one of the arguments, replace it with an asterisk (*).

Version 4.7


996


Chapter 23

For example, to search for RPC portmapper (which is the RPC application indicated by the number 100000), with any procedure or version, use 100000,*,* as the arguments. As another example, if you were to use this keyword to detect the exploit described in Exploring a Complex Rule: Snort ID 1965 on page 1031, you would use the following as the arguments for rpc: 10083,7,2

where 10083 is the RPC program number for ToolTalk, 7 is the procedure to search for, and 2 is the RPC version.

ASN.1 Requires: IPS or DC/MDC + IPS

The asn1 keyword allows you to decode a packet or a portion of a packet, looking for various malicious encodings. The asn.1 Keyword Arguments table describes the arguments for the asn1 keyword. asn.1 Keyword Arguments Argument

Description

Bitstring Overflow

Detects invalid, remotely exploitable bitstring encodings.

Double Overflow

Detects a double ASCII encoding that is larger than a standard buffer. This is known to be an exploitable function in Microsoft Windows, but it is unknown at this time which services may be exploitable.

Oversize Length

Detects ASN.1 type lengths greater than the supplied argument. For example, if you set the Oversize Length to 500, any ASN.1 type greater than 500 triggers the rule.

Absolute Offset

Sets an absolute offset from the beginning of the packet payload. (Remember that the offset counter starts at byte 0.) For example, if you want to decode SNMP packets, set Absolute Offset to 0. Absolute Offset may be positive or negative.

Relative Offset

This is the relative offset from the last successful content match or byte_test/byte_jump. To decode an ASN.1 sequence right after the content "foo", set Relative Offset to 0, and do not set an Absolute Offset. Relative Offset may be positive or negative. (Remember that the offset counter starts at 0.)

For example, there is a known vulnerability in the Microsoft ASN.1 Library that creates a buffer overflow, allowing an attacker to exploit the condition with a specially crafted authentication packet. When the system decodes the asn.1 data,

Version 4.7


997


Chapter 23

exploit code in the packet could execute on the host with system-level privileges or could cause a DoS condition. The following rule uses the asn1 keyword to detect attempts to exploit this vulnerability: alert tcp $EXTERNAL_NET any -> $HOME_NET 445 (flow:to_server, established; content:”|FF|SMB|73|”; nocase; offset:4; depth:5; asn1:bitstring_overflow,double_overflow,oversize_length 100,relative_offset 54;)

The above rule generates an event against TCP traffic traveling from any IP address defined in the $EXTERNAL_NET variable, from any port, to any IP address defined in the $HOME_NET variable using port 445. In addition, it only executes the rule on established TCP connections to servers. The rule then tests for specific content in specific locations. Finally, the rule uses the asn1 keyword to detect bitstring encodings and double ASCII encodings and to identify asn.1 type lengths over 100 bytes in length starting 55 bytes from the end of the last successful content match. (Remember that the offset counter starts at byte 0.)

urilen Requires: IPS or DC/MDC + IPS

You can use the urilen keyword in conjunction with the HTTP Inspect preprocessor to inspect HTTP traffic for URIs of a specific length, less than a maximum length, greater than a minimum length, or within a specified range. After the HTTP Inspect preprocessor normalizes and inspects the packet, the rules engine evaluates the packet against the rule and determines whether the URI matches the length condition specified by the urilen keyword. You can use this keyword to detect exploits that attempt to take advantage of URI length vulnerabilities, for example, by creating a buffer overflow that allows the attacker to cause a DoS condition or execute code on the host with system-level privileges. Note the following when using the urilen keyword in a rule: •

in practice, you always use the urilen keyword in combination with the flow:established keyword and one or more other keywords

•

a TCP stream preprocessor must be enabled. See Understanding TransportLayer Preprocessors on page 873 for more information.

•

the HTTP Inspect preprocessor must be enabled. See Decoding HTTP Traffic on page 891 for more information.

•

the rule protocol is always TCP. See Specifying Protocols on page 953 for more information.

•

target ports are always HTTP ports. See Specifying Source and Destination Ports on page 954 and Understanding Existing Variables on page 779 for more information.

You specify the URI length using a decimal number of bytes, less than (). For example:

Version 4.7


998


Chapter 23

•

specify 5 to detect a URI 5 bytes long.

•

specify < 5 (separated by one space character) to detect a URI less than 5 bytes long.

•

specify > 5 (separated by one space character) to detect a URI greater than 5 bytes long.

•

specify 3 5 (with one space character before and after ) to detect a URI between 3 and 5 bytes long.

For example, there is a known vulnerability in Novell’s server monitoring and diagnostics utility iMonitor version 2.4, which comes with eDirectory version 8.8. A packet containing an excessively long URI creates a buffer overflow, allowing an attacker to exploit the condition with a specially crafted packet that could execute on the host with system-level privileges or could cause a DoS condition. The following rule uses the urilen keyword to detect attempts to exploit this vulnerability: alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"EXPLOIT eDirectory 8.8 Long URI iMonitor buffer overflow attempt";flow:to_server,established; urilen:> 8192; uricontent:"/nds/"; nocase; classtype:attempted-admin; sid:x; rev:1;)

The above rule generates an event against TCP traffic traveling from any IP address defined in the $EXTERNAL_NET variable, from any port, to any IP address defined in the $HOME_NET variable using the ports defined in the $HTTP_PORTS variable. In addition, packets are evaluated against the rule only on established TCP connections to servers. The rule uses the urilen keyword to detect any URI over 8192 bytes in length. Finally, the rule searches the URI for the specific case-insensitive content /nds/.

Inspecting Packet Characteristics Requires: IPS or DC/MDC + IPS

Version 4.7

You can write rules that only generate events against packets with specific packet characteristics. The Sourcefire 3D System provides the following keywords to evaluate packet characteristics: •

dsize on page 1000

•

isdataat on page 1000

•

sameip on page 1000

•

fragoffset on page 1000

•

cvs on page 1001


999


Chapter 23

dsize Requires: IPS or DC/MDC + IPS

The dsize keyword tests the packet payload size. With it, you can use the greater than and less than operators (< and >) to specify a range of values. You can use the following syntax to specify ranges: >number_of_bytes 400 as the dtype value. To indicate a packet size of less than 500 bytes, use

greater than

not greater than (less than or equal to)

!
any any (msg:"IMAP login"; content:"OK LOGIN"; flowbits:set,logged_in; flowbits:noalert;)

Note that flowbits:set sets a state of logged_in, while flowbits:noalert suppresses the alert because you are likely to see many innocuous login sessions on an IMAP server. The next rule fragment looks for an LIST string, but does not generate an event unless the logged_in state has been set as a result of some previous packet in the session: alert tcp any any -> any 143 (msg:"IMAP LIST"; content:"LIST"; flowbits:isset,logged_in;)

In this case, if a previous packet has caused a rule containing the first fragment to trigger, then a rule containing the second fragment triggers and generates an event.

Constructing a Rule Requires: IPS or DC/MDC + IPS

Just as you can create your own custom standard text rules, you can also modify existing standard text rules provided by Sourcefire as long as you save your changes as a new rule. Note that for shared object rules provided by Sourcefire, you are limited to modifying aspects such as the source and destination ports and IP addresses. You cannot modify the rule keywords and arguments in a shared object rule. See the following sections for more information: •

Writing New Rules on page 1008

•

Modifying Existing Rules on page 1011

•

Adding Comments to Rules on page 1013

•

Deleting Custom Rules on page 1013

Writing New Rules Requires: IPS or DC/MDC + IPS

Version 4.7

You can create your own standard text rules. In a custom standard text rule, you set the rule header settings and the rule keywords and arguments. Optionally, you can use the rule header settings to focus the rule to only match traffic using a specific protocol and traveling to or from specific IP addresses or ports.


1008

Understanding and Writing Intrusion Rules Constructing a Rule

Chapter 23

After you create a new rule, you can find it again quickly using the rule number, which has the format GID:SID:Rev. The rule number for all standard text rules starts with 1. The second part of the rule number, the Snort ID (SID) number, indicates whether the rule is a local rule or a rule provided by Sourcefire. When you create a new rule, the system assigns the rule the next available Snort ID number for a local rule and saves the rule in the Local Rules category. Snort ID numbers for local rules start at 1,000,000 (although intrusion rules created on the secondary Defense Center in a high availability pair begin with the number 1,000,000,000) and the SID for each new local rule is incremented by one. The last part of the rule number is the revision number. For a new rule, the revision number is one. Each time you modify a custom rule the revision number increments by one. IMPORTANT! The system assigns a new SID to any custom rule in an intrusion policy that you import. For more information, see Importing Objects on page 1252. See also, Exporting a Single Intrusion Policy on page 1249. To write a custom standard text rule using the Rule Editor: Access: Rules or Admin

1.


2. Click Create Rule. The Create page appears.

3. In the Message field, enter the message you want displayed with the event. For details on event messages, see Defining the Event Message on page 957. TIP! You must specify a rule message. Also, the message cannot consist of white space only, one or more quotation marks only, one or more apostrophes only, or any combination of just white space, quotation marks, or apostrophes.

Version 4.7


1009


Chapter 23

4. From the Classification list, select a classification to describe the type of event. For details on available classifications, see Defining the Event Classification on page 958. 5. From the Action list, select the type of rule you would like to create. You can use one of the following: •

Select alert to create a rule that generates an event when traffic triggers the rule.

•

Select pass to create a rule that ignores traffic that triggers the rule.

6. From the Protocol list, select the traffic protocol (tcp, udp, icmp, or ip) of packets you want the rule to inspect. For more information about selecting a protocol type, see Specifying Protocols on page 953. 7.

In the Source IPs field, enter the originating IP address or address range for traffic that should trigger the rule. In the Destination IPs field, enter the destination IP address or address range for traffic that should trigger the rule. For more detailed information about the IP address syntax that the Rule Editor accepts, see Defining IP Addresses in Variables and Rules on page 774.

8. In the Source Port field, enter the originating port numbers for traffic that should trigger the rule. In the Destination Port field, enter the receiving port numbers for traffic that should trigger the rule. For more detailed information about the port syntax that the Rule Editor accepts, see Defining Ports in Variables and Rules on page 777. 9. From the Direction list, select the operator that indicates which direction of traffic you want to trigger the rule. You can use one of the following: •

Directional to match traffic that moves from the source IP address to the destination IP address

•

Bidirectional to match traffic that moves in either direction

10. From the Detection Options list, select the keyword that you want to use. 11. Click Add Option. 12. Enter any arguments that you want to specify for the keyword you added. For more information about rule keywords and how to use them, see Understanding Keywords and Arguments in Rules on page 956. When adding keywords and arguments, you can also perform the following: •

To reorder keywords after you add them, click the up or down arrow next to the keyword you want to move.

•

To delete a keyword, click the X next to that keyword.

Repeat steps 10 through 12 for each keyword option you want to add.

Version 4.7


1010


Chapter 23

13. Click Save As New to save the rule. The system assigns the rule the next available Snort ID (SID) number in the rule number sequence for local rules and saves it in the Local rule category. The system does not begin evaluating traffic against new or changed rules until you enable them within the appropriate intrusion policy, and then apply the policy. See Applying an Intrusion Policy on page 764 for more information.

Modifying Existing Rules Requires: IPS or DC/MDC + IPS

You can modify custom standard text rules, or you can create a new revision of a rule and make changes to that. You can also modify a standard text rule provided by Sourcefire by making changes to the rule then saving it as a new rule. Creating a rule or modifying a Sourcefire standard text rule copies the new rule or revision to Local rule category and assigns a new Snort ID (SID) to the new rule. To modify a rule:


1.


2. Expand the rule category that contains the rule you want to edit.

Version 4.7


1011


Chapter 23

3. Click Edit next to the rule you want to edit. The Rule Editor opens, displaying the rule you selected.

Note that if you select a shared object rule, the Rule Editor displays only the rule header information. A shared object rule can be identified on the Rule page by a listing that begins with the number 3 (the GID), for example, 3:1000004. 4. Make any modifications to the rule (see Writing New Rules on page 1008 for more information about rule options) and click Save As New. The rule is saved to the Local rule category. TIP! If you want to use the local modification of the rule instead of the system rule, deactivate the system rule by using the procedures at Enabling and Disabling Intrusion Rules on page 794 and activate the local rule. 5. Activate the intrusion policy as described in Applying an Intrusion Policy on page 764 to apply your changes.

Version 4.7


1012


Chapter 23

Adding Comments to Rules Requires: IPS or DC/MDC + IPS

You can add comments to any intrusion rule. This allows you to provide additional context and information about the rule and the exploit or policy violation it identifies. To add a comment to a rule:


1.

Locate the rule you want to annotate. You have two options: •

To locate a rule by browsing rule categories, select Policy & Response > IPS > Rules. Navigate through the folders to the rule you want and click Edit next to the rule.

•

To locate a rule by searching for it, select Policy & Response > IPS > Rules. Click Search. Enter the search criteria (most simply, the SID) for the rule you want and click Search. Click the rule returned by the search as appropriate.

The Rule Editor appears. 2. Click Rule Comment. The Rule Comment page appears.

3. Enter your comment in the text box and click Save. The comment is saved in the comment text box. TIP! You can also add and view rule comments in an intrusion event’s packet view. For more information, see Viewing Event Information on page 676.

Deleting Custom Rules Requires: IPS or DC/MDC + IPS

Version 4.7

You can delete custom rules that are not currently enabled in an intrusion policy. You cannot delete either standard text rules or shared object rules rules provided by Sourcefire. See Writing New Rules on page 1008 for information on creating


1013

Understanding and Writing Intrusion Rules Searching for Rules

Chapter 23

custom rules. See Enabling and Disabling Intrusion Rules on page 794 for information on setting rule states. The system stores deleted rules in the Deleted category, and you can use a deleted rule as the basis for a new rule. See Modifying Existing Rules on page 1011 for information on editing rules. The Rule State page does not display the Deleted category, so you cannot enable deleted custom rules. To delete a custom rule: Access: Rules or Admin

1.


2. Navigate through the folders to the Local rule category and click it. Note that custom standard text rules have a generator ID (GID) or 1 (for example, 1:1000012) and custom shared object rules have a GID of 3 (for example, 3:1000005). The Local rule category expands, displaying any custom rules. The following graphic shows two example custom rules in the Local rule category.

TIP! IPS also stores shared object rules that you save with modified header information in the Local rule category and lists them with a GID of 3. You can delete your modified version of a shared object rule, but you cannot delete the original shared object rule. 3. Click Delete next to the rule you want to delete. The rule is deleted from the Local rule category and moved to the Deleted category.

Searching for Rules Requires: IPS or DC/MDC + IPS

Version 4.7

The Sourcefire 3D System provides over 4000 standard text rules, and the Sourcefire Vulnerability Research Team continues to add rules as new vulnerabilities and exploits are discovered. You can easily search for specific rules so that you can activate, deactivate, or edit them


1014


Chapter 23

The Rule Search Criteria table describes the available search options: Rule Search Criteria

Version 4.7

Option

Description

Signature ID

To search for a single rule based on Snort ID (also called the Signature ID), enter a Snort ID number. To search for multiple rules, enter a comma-separated list of Snort ID numbers. This field has an 80-character limit.

Generator ID

To search for standard text rules, select 1. To search for shared object rules, select 3.

Message

To search for a rule with a specific message, enter a single word from the rule message in the Message field. For example, to search for DNS exploits, you would enter DNS, or to search for buffer overflow exploits, enter overflow.

Protocol

To search rules that evaluate traffic of a specific protocol, select the protocol. If you do not select a protocol, search results contain rules for all protocols.

Source Port

To search for rules that inspect packets originating from a specified port, enter a source port number or a port-related variable.

Destination Port

To search for rules that inspect packets destined for a specific port, enter a destination port number or a port-related variable.

Source IP

To search for rules that inspect packets originating from a specified IP address, enter a source IP address or an IP address-related variable.

Destination IP

To search for rules that inspect packets destined for a specified IP address, enter a destination IP address or an IP address-related variable.

Keyword

To search for specific keywords, you can use the keyword search options. You select a keyword and a keyword value for which to search. You can also precede the keyword value with an exclamation point (!) to match any value other than the specified value.

Category

To search for rules in a specific category, select the category from the Category list.


1015


Chapter 23

Rule Search Criteria (Continued) Option

Description

Classification

To search for rules that have a specific classification, select the classification name from the Classification list.

Rule State

To search for rules within a specific policy and a specific rule state, select the policy from the first Rule State list, and choose a state (Enabled or Disabled) from the second list. For inline policies, you can also choose Drop to search for Drop rules.

To search for specific rules: Access: Rules or Admin

1.


2. Click Search on the toolbar. The Search page appears.

3. Add search criteria using any of the fields described in the Rule Search Criteria table on page 1015. IMPORTANT! rules.

Version 4.7

You must specify at least one search criterion to search for


1016


Chapter 23

4. Perform the following steps to search for rules that contain specific keywords: •

From the drop-down list in the Keyword section, select the keyword for which to search. For a list of each available keyword, see Understanding Keywords and Arguments in Rules on page 956.

•

In the Keyword field, enter the arguments for which you want to search.

5. Click Search. The page reloads, showing a list of the rules that match your search criteria. 6. To view or edit a rule (or a copy of the rule, if it is a system rule), click the hyperlinked rule message. See Modifying Existing Rules on page 1011 for detailed information about editing rules.

Version 4.7


1017

Chapter 23

Rule-Writing Examples and Tips

The IPS component of the Sourcefire 3D System provides an extensive rule set that detects a wide variety of intrusions, attacks, and suspicious traffic. However, when tuning the existing rule set for your network environment, you may want to create custom intrusion rules that relate specifically to your particular network and security policies. The following sections provide more information about writing custom standard text rules, including best practices, tutorials, and tips that you should consider: •

Understanding the Rule Creation Process on page 1019 describes the basic steps you should follow when writing a rule for the Sourcefire 3D System.

•

Creating a Simple Rule: Sending Yahoo IM Messages on page 1020 provides a step-by-step tutorial of basic rule creation.

•

Exploring a Complex Rule: Snort ID 1965 on page 1031 provides a description of a more complex, existing Snort rule.

•

Understanding Replace Rules on page 1044 explains how to use replace rules to replace content in a packet.

•

Rule Writing and Tuning Recommendations on page 1051 provides a list of tips to remember when configuring and writing rules within your environment.

WARNING! Make sure you use a controlled network environment to test any intrusion rules that you write before you use the rules in a production environment. Poorly written intrusion rules can seriously affect the performance of your Sourcefire 3D System.

Version 4.7


1018

Rule-Writing Examples and Tips Understanding the Rule Creation Process

Chapter 24

IMPORTANT! The rules discussed here are not all-inclusive. There are many additional options and arguments available in the Snort rules language. See Understanding and Writing Intrusion Rules on page 948 for a comprehensive list of available rule detection options and values. Note that custom standard text rules have a generator ID of 1. Custom rules are automatically placed in the Local rule category.

Understanding the Rule Creation Process Requires: IPS or DC/MDC + IPS

The basic rule writing process can be distilled to a list of important steps: •

identify problem

•

capture traffic

•

inspect traffic

•

identify common characteristics

•

write rule

•

test rule

The following diagram shows the steps in the rule writing process.

To ensure that you write a meaningful rule: Access: Rules or Admin

1.

Clearly identify the problem that requires a new intrusion rule.

2. Capture traffic that illustrates the problem. You can capture traffic using a tool such as Snort, WinDump with WinPcap on Windows systems, or tcpdump on Linux systems. For more information about using packet capture software, refer to the documentation that accompanies the packet capture tool you use.

Version 4.7


1019

Rule-Writing Examples and Tips Creating a Simple Rule: Sending Yahoo IM Messages

Chapter 24

3. Inspect the traffic you capture, paying attention to any constants in the network protocol. What protocol does the traffic use? Does it use specific ports? Does it always originate from or target a specific network? 4. Identify characteristics that specifically define the traffic that the rule should generate an event against. What kinds of unique identifiers distinctly identify the traffic in question? Does the payload content contain identifying strings? If so, do they always appear in the same places? 5. Based on your analysis, write a rule. 6. Implement your rule and test it to ensure that it triggers on the suspicious traffic.

Creating a Simple Rule: Sending Yahoo IM Messages Requires: IPS or DC/MDC + IPS

This example describes how to create an intrusion rule that generates an event when a user on your local network sends a message using Yahoo Messenger. You might use a rule like this if sending messages using an instant messaging application violates your corporate policy. This example rule is based on, and identical to, Snort ID (SID) 3691. However, for illustrative purposes the example rule is presented as if you were creating it. You can create and save the example rule, in which case you will have a custom rule that duplicates SID 3691. There is no harm in duplicating a rule so long as you do not enable both rules, which would result in duplicate alerts. You could also save and then delete the duplicate rule. For the specific procedure for creating and saving custom rules, see Writing New Rules on page 1008. For information on deleting custom rules, see Deleting Custom Rules on page 1013. The actual rule SID 3691 appears in the system as follows: alert tcp $HOME_NET any -> $EXTERNAL_NET 5050 (msg:"CHAT Yahoo Messenger Message"; flow:established; content:"YMSG"; depth:4; content:"|00 06|"; depth:2; offset:10; classtype:policy-violation; sid:3691; rev:1; )

You can view the rule in its Sourcefire 3D System format by searching for the rule with a SID of 3691. For more information about searching for rules using the web interface, see Searching for Rules on page 1014.

Version 4.7


1020


Chapter 24

The following sections provide a step-by-step example of planning and creating the rule: •

Planning the Rule on page 1021 describes how to analyze applicable protocol traffic.

•

Defining the Rule Header on page 1022 describes how to determine rule header values for the sample rule.

•

Defining Detection Options (Keywords) on page 1026 describes how to determine rule detection options for the sample rule.

Planning the Rule Requires: IPS or DC/MDC + IPS

Before building the example rule, you would capture packets that are exchanged when Yahoo messages are sent. TIP! You can capture traffic using a tool such as Snort, WinDump with WinPcap on Windows systems, or tcpdump on Linux systems. For more information about using packet capture software, refer to the documentation that accompanies the packet capture tool you use. Then, gather some information about the traffic in question: •

Are specific ports always/often/never involved?

•

Are specific server ranges always/often/never involved?

•

Which direction of traffic do you want to search? Do you want to search for inbound messages, outbound messages, or both?

•

Should the rule be run on ICMP, UDP, or TCP traffic only, or on all IP traffic including the ICMP, IGMP, UDP, and TCP protocols, and many more?

•

Which payload content pattern or patterns uniquely identify the Yahoo Messenger protocol?

•

Which payload content pattern or patterns uniquely identify a message in the Yahoo Messenger protocol?

•

Are there any legitimate uses of messages (or anything that “looks” like this) that should be excluded from the rule?

Using the types of information listed above, you can write effective rules that are less prone to false positives. The following sections provide a step-by-step example of rule creation: IMPORTANT! Because proprietary network protocols such as the Yahoo Messenger protocol are subject to change, the information provided in this section should be used as a learning exercise only, and is not guaranteed to be accurate for all versions of the protocol.

Version 4.7


1021


Chapter 24

Defining the Rule Header Requires: IPS or DC/MDC + IPS

The rule header contains basic information about the rule, including the rule type, source and destination IP address, source and destination ports, and the traffic direction used for inspection. See the following sections for more information: •

Describing the Event on page 1022 describes how to specify a name for the rule.

•

Defining Traffic Flow on page 1026 describes how to enter rule classification and reference information.

•

Defining the Rule Action on page 1023 describes how to determine the basic action of the rule.

•

Defining the Traffic Protocol on page 1023 describes how to determine which network traffic protocol is used for the rule.

•

Defining the Traffic Direction on page 1024 describes how to inspect directional or bidirectional traffic.

•

Defining Source and Destination IP Addresses and Ports on page 1024 describes how to determine source and destination IP addresses and ports.

Describing the Event Requires: IPS or DC/MDC + IPS

The rule message provides basic information about what occurred to trigger the rule. This message appears as the summary when viewing events with the web interface. Select Policy & Response > IPS > Rules, and click Create Rule to open the Rule Editor. Because the sample rule triggers on instances of Yahoo Messenger messages, type Yahoo Messenger Message in the Message field. The text that appears in the Message field corresponds to the value used in the msg keyword in a traditional Snort rule. Continue with Classifying and Providing References.

Classifying and Providing References Requires: IPS or DC/MDC + IPS

When creating a rule, you describe the vulnerability by classifying the rule and, optionally, by specifying external references to an associated vulnerability. If you do not include a priority keyword in the rule, the classification dictates priority level. External references add additional context to the rule. The classification, along with the priority and reference keywords, help analysts quickly understand the importance of an event. The example message rule addresses a security policy violation rather than a specific vulnerability. However, if it included a specific vulnerability, you could define reference information using the procedures described in Defining the Event Reference on page 962.

Version 4.7


1022


Chapter 24

While this message rule does not have a reference, it does have a classification type (classtype) that maps to a priority level in the system. IMPORTANT! A list of available classification types and priorities is included in Defining the Event Classification on page 958. Using instant messaging software to send and receive messages does not necessarily constitute an intrusion event, but it can indicate a violation of corporate policy. For the sample rule, select Potential Corporate Policy Violation from the Classification list. TIP! To override the default priority (which is based on the classification) for an event, use the priority keyword to assign a manual priority to the rule. Continue with Defining the Rule Action.

Defining the Rule Action Requires: IPS or DC/MDC + IPS

When creating a rule, you must define the type of rule you want to create. You can choose: •

alert to generate an event against traffic that triggers the rule

•

pass to ignore traffic that triggers the rule

Because this rule should generate an event when messages are sent using Yahoo Messenger, select alert from the Action list. TIP! In an inline intrusion policy, rules with the rule state set to drop generate an intrusion event against the packet that triggered the rule. Also, if you apply a drop rule to a passive intrusion policy, the rule acts as an alert rule. For more information on drop rules, see Using the Drop Rule State on page 798 Continue with Defining the Traffic Protocol.

Defining the Traffic Protocol Requires: IPS or DC/MDC + IPS

After defining the rule type, you must define the network traffic protocol that the rule inspects. You can specify tcp, udp, icmp, or ip. Yahoo Messenger uses both TCP and UDP methods of data transmission. However, it uses UDP only for video and voice data transmission, and user messages will typically occur only in TCP traffic. Given this knowledge, choose tcp from the Protocol list. Continue with Defining the Traffic Direction.

Version 4.7


1023


Chapter 24

Defining the Traffic Direction Requires: IPS or DC/MDC + IPS

You must specify whether to inspect traffic in a single direction from the source IP address and ports to the destination IP address and ports, or in both directions. You should limit traffic inspection to a single direction whenever possible to minimize the impact on performance. When you need to inspect traffic in both directions, it usually is most efficient to write a separate rule for each direction. In the example rule, set Direction to Directional. Continue with Defining Source and Destination IP Addresses and Ports.

Defining Source and Destination IP Addresses and Ports Requires: IPS or DC/MDC + IPS

You must specify the source and destination IP addresses and ports from which to inspect traffic. The example rule inspects outbound traffic for messages, so you can use $HOME_NET as the source IP address. See Understanding Existing Variables on page 779 for more information about the $HOME_NET variable. To specify the destination IP address, you could do either of the following: •

specify the exact Yahoo servers used for messaging traffic

•

specify anything external ($EXTERNAL_NET).

You will notice in your traffic analysis that the destination IP address for outbound messages is typically the address of the destination Yahoo server, not the address of the destination user, even for messages sent to local users. You could do the research necessary to determine and specify all known Yahoo messaging server IP addresses to minimize processing. However, if Yahoo adds servers the rule may miss some traffic. Therefore, use $EXTERNAL_NET as the destination IP address to capture any traffic bound for an IP address outside of the home network. TIP! The sample rule uses $EXTERNAL_NET. However, you could create a new variable called, for example, $YAHOO_SERVERS on the Sourcefire 3D System Variables page using known Yahoo Messaging server IP addresses (see Creating New Variables on page 784 for more information about creating variables). After establishing source and destination IP address values, you must decide whether to restrict the rule by port. Viewing captured packets shows that Yahoo Messenger typically uses port 5050 as the source port for traffic from Yahoo messaging servers and as the destination port for traffic to Yahoo servers. Yahoo messaging also typically uses a port number above 1023 for the user source or destination port. Although you could create a rule that checks traffic from only these ports, many IM applications can be used on alternative ports and, in fact, scan for open ports if the default ports are unavailable.

Version 4.7


1024


Chapter 24

Use the following port configuration for this particular rule: •

Use any as the value for Source Port so you do not restrict the rule to specific user ports

•

Use 5050 as the value for Destination Port so you do restrict the rule to the specific port used by the server for messages sent to the server

IMPORTANT! In large networks or networks with high-capacity bandwidth, Sourcefire recommends that you use specific source or destination ports to ensure faster processing. To summarize, the example rule uses the following values for the remaining header options. .

Header Options Option

Value

Source IPs

$HOME_NET

Source Port

any

Operator

Directional

Destination IPs

$EXTERNAL_NET

Destination Port

5050

The sample rule header now appears in the Rule Editor as follows:

Continue with Defining Detection Options (Keywords) on page 1026.

Version 4.7


1025


Chapter 24

Defining Detection Options (Keywords) Requires: IPS or DC/MDC + IPS

Rule keywords (or “detection options”) define how the rules engine inspects any packet that has the characteristics specified in the rule header. Detection options comprise the substance of the rule and allow you to define content-specific, protocol-specific, and state-specific pattern matching. See the following sections for more information: •

Defining Traffic Flow on page 1026 describes how to use the flow detection option to define the flow and state of traffic that is inspected by the rules engine.

•

Matching Content Patterns in Packet Payloads on page 1027 describes how to use the content detection option and its arguments to perform pattern matching.

Defining Traffic Flow Requires: IPS or DC/MDC + IPS

Because the rule generates an event on TCP traffic (see Defining the Traffic Protocol on page 1023), you should establish the type of TCP traffic flow that the rules engine inspects. In the example rule header, the configured options instruct the rules engine to inspect outbound traffic from $HOME_NET using any source port to $EXTERNAL_NET using destination port 5050. This does not, however, give the rule any state awareness. Use the flow detection option to specify the state of traffic that the rule inspects. IMPORTANT! For more detailed information about using the flow detection option in rules, see Applying Rules to a TCP Client or Server Flow on page 990. Because Yahoo Messenger messages are always part of an established TCP session, select flow, click Add Option, and select Established as the value for the flow detection option. Note that although the direction to inspect (outbound) is determined in the example rule by the combination of the Direction option, which is set to Directional, and the Destination IPs option, which is set to $EXTERNAL_NET, other rules might use additional flow arguments to further qualify the specific directional flow of traffic. TIP! For maximum performance, always include a flow keyword in a TCP rule.

Version 4.7


1026


Chapter 24

The flow detection option appears as follows in the Rule Editor:

Continue with Matching Content Patterns in Packet Payloads on page 1027.

Matching Content Patterns in Packet Payloads Requires: IPS or DC/MDC + IPS

After configuring the rule header and traffic flow, further customize the rule by using content-related detection options to perform payload content matching. TIP! To research the protocol associated with the rule you want to create, you can use the Sourcefire 3D System or tcpdump to capture and inspect packets. You can also consult http://www.snort.org/ for information about existing rules and rule writing. Often, the best place to start when conducting research is by searching the web. Inspect a few sample Yahoo IM transmissions to find any commonalities. The following sample packet payload from a Yahoo message shows a beginning byte number for each line on the left followed by the hexadecimal-formatted packet payload, and the ASCII text translation on the right. Byte Num

Hexadecimal

0x0000: 0x0010: 0x0020: 0x0030: 0x0040: 0x0050:

Version 4.7

59 74 80 C0 39 34

4D 5F 35 80 37 C0

53 AC C0 31 C0 80

47 BB 80 34 80 30

ASCII 00 31 6A C0 31 C0

0F C0 6F 80 C0 80

00 80 68 6D 80 32

00 6A 6E 65 36 30

00 6F 64 73 33 36

4B 68 6F 73 C0 C0

00 6E 65 61 80 80

06 64 73 67 3B 30

5A 6F 62 65 30 C0


55 65 6F 31 C0 80

AA 31 73 C0 80 00

56 C0 73 80 36

YMSG.....K..ZU.V t_..1..johndoe1. .5..johndoesboss ..14..message1.. 97..1..63..;0..6 4..0..206..0...

1027


Chapter 24

Note that the first four bytes in a Yahoo Messenger packet payload are always 59 4D 53 47 in hexadecimal, which is YMSG in ASCII text. The highlighted characters in the following excerpt from the sample packet illustrate this. 0x0000: 59 4D 53 47 00 0F 00 00 00 4B 00 06 5A 55 AA 56 0x0010: 74 5F AC BB 31 C0 80 6A 6F 68 6E 64 6F 65 31 C0

YMSG.....K..ZU.V t_..1..johndoe1.

These four bytes identify Yahoo Messenger traffic. So, to configure your example rule to identify Yahoo-specific traffic, you would add YMSG as the value for a content detection option so the rules engine will search for this content in the packet payload. You can also make the rule more efficient by adding Offset and Depth values to indicate exactly where the rules engine should look for the YMSG string. This eliminates unnecessary searching in a packet. However, for this content search you do not need to enter an offset value for

YMSG. Not specifying an offset instructs the rules engine to begin inspection at the

start of the packet data section.

The depth value indicates how many bytes from the current offset position the rules engine should search for the specified content. Because the system should match the first four bytes (YMSG), use a depth of 4. The content detection options should appear as follows in the Rule Editor:

The Yahoo Messenger YMSG content itself, however, is not enough information to create a concise rule. If the sample rule uses only these four bytes for content-matching, the Sourcefire 3D System will generate an event against each packet of Yahoo IM traffic that traverses the network. Even if a single user in the

Version 4.7


1028


Chapter 24

organization uses Yahoo Messenger, you will receive thousands of events due to the amount of network traffic generated by messaging software. Look again at the hexadecimal representation of the Yahoo Messenger packet payload when a message is sent: Byte Num

Hexadecimal

0x0000: 0x0010: 0x0020: 0x0030: 0x0040: 0x0050:

59 74 80 C0 39 34

4D 5F 35 80 37 C0

53 AC C0 31 C0 80

47 BB 80 34 80 30

ASCII 00 31 6A C0 31 C0

0F C0 6F 80 C0 80

00 80 68 6D 80 32

00 6A 6E 65 36 30

00 6F 64 73 33 36

4B 68 6F 73 C0 C0

00 6E 65 61 80 80

06 64 73 67 3B 30

5A 6F 62 65 30 C0

55 65 6F 31 C0 80

AA 31 73 C0 80 00

56 C0 73 80 36

YMSG.....K..ZU.V t_..1..johndoe1. .5..johndoesboss ..14..message1.. 97..1..63..;0..6 4..0..206..0...

Notice that the hexadecimal value 06, which is the non-printing ASCII ACK (acknowledge) character, always appears in the Yahoo Messenger packet when a user message is sent (or received), and does not appear in other Yahoo Messenger traffic. Therefore, the rule can use 06 as a content detection option to distinguish user message traffic from other Yahoo Messenger traffic. In addition, the byte 00, which is the non-printing ASCII NULL character, always appears immediately before 06, so you can use 00 06 as the content match. Including the NULL character in the search improves performance because the system matches longer (that is, more specific) patterns faster. TIP! To match a specific hexadecimal byte string, surround the bytes with pipe characters (|) For example, |59 4D 53 47|. Optionally, separate characters with a space. ASCII and hexadecimal-encoded text can be mixed. For example, if you have a content detection option that mixes both hexadecimal and ASCII content, where 90C8 C0FF FFFF is the hexadecimal data and /bin/sh is the ASCII data, you would use |90 C8 C0 FF FF FF|/bin/sh. Further investigation reveals that the hexadecimal values 00 06 always appear in the message packet as bytes eleven and twelve, respectively. Therefore, for this content option you should specify an offset of 10 as the number of bytes to skip before beginning to search for the specified values. Note that because you start counting with byte 0, the rules engine skips ten bytes (bytes 0 through 9) and begins the search with the eleventh byte (which is numbered byte 10 in the packet payload). The following diagram illustrates the byte count used for the second content keyword: 0x0000:

Version 4.7

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 59 4D 53 47 00 0F 00 00 00 4B 00 06 5A 55 AA 56


1029


Chapter 24

Because the system should match the first two bytes (00 06) from the current offset position, specify a depth of 2. IMPORTANT! Case sensitivity matters in content matches that use ASCII text. To disable case sensitivity, use the Case Insensitive option (in Snort, the nocase keyword). Note that disabling case sensitivity requires more processing; therefore, if the rule does not require case insensitivity, do not enable the Case Insensitive option. The sample rule does not require case insensitivity because the ASCII characters YMSG are uppercase by definition (that is, they represent the specific hexadecimal values 59 4D 53 47 for the uppercase string YMSG). The rule is now complete. It is not necessary to save the sample rule (to save it as a custom rule, click Save As New) because it is identical to SID 3691. When you do save a rule, rule ID and revision numbers are assigned automatically by the system. The system assigns the next rule ID available to the system (always above 1,000,000, because all numbers less than 1,000,000 are reserved for official Snort rules). The revision number is based on the number of times you edit the rule. If you do save the example rule, you will have a custom rule that duplicates SID 3691. There is no harm in this so long as you do not enable both rules, which would result in duplicate alerts. You could also delete the duplicate rule. For information on deleting custom rules, see Deleting Custom Rules on page 1013.

Version 4.7


1030

Rule-Writing Examples and Tips Exploring a Complex Rule: Snort ID 1965

Chapter 24

The completed rule appears as follows in the Rule Editor:

Note that the following saved example rule would appear identical to SID 3691 to the system except for the rule message, which was optional, the system-assigned SID, and possibly the revision number, which can vary: alert tcp $HOME_NET any -> $EXTERNAL_NET 5050 (flow:established; content:"YMSG"; depth:4; content:"|00 06|"; offset:10; depth:2; msg:"Yahoo Messenger Message"; classtype:policy-violation; sid:1000000; gid:1; rev:1; )

Exploring a Complex Rule: Snort ID 1965 Requires: IPS or DC/MDC + IPS

You should now have a basic understanding of the Sourcefire 3D System rule creation process. At some point, however, you may discover that you need to create a rule with more complex options in order to generate alerts for more complicated types of intrusions. This section, and the sections that follow, walk you step-by-step through the construction of Snort ID 1965, “RPC ToolTalk TCP Overflow Attempt” (SID 1965) to more thoroughly explain why and how specific options are used within rules. SID 1965 detects the use of a buffer overflow exploit against the ToolTalk object database server. ToolTalk is a Remote Procedure Call (RPC) service that allows

Version 4.7


1031


Chapter 24

ToolTalk-enabled applications to communicate with each other and interoperate. ToolTalk ships as a standard component in a number of UNIX-based operating systems, including Solaris, HP-UX, IBM AIX, and SGI IRIX. ToolTalk-enabled applications send RPC requests to the ToolTalk object database server, which forwards the request to the recipient application. ToolTalk runs with root privileges on most systems, and the exploit in question sends a specially crafted RPC request to the ToolTalk object database server. This causes a buffer overflow condition that can allow the attacker to overwrite information in the database with data included in the request. This can then allow the attacker to obtain root privileges on the compromised server. SID 1965 searches for traffic that matches the patterns exhibited by this exploit, and generates events when matches are found. The actual rule appears within the system as follows: alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"RPC tooltalk TCP overflow attempt"; flow:to_server,established; content:"|00 01 86 F3|"; depth:4; offset:16; content:"|00 00 00 07|"; within:4; distance:4; byte_jump:4,4,relative,align; byte_jump:4,4,relative,align; byte_test:4,>,128,0,relative; content:"|00 00 00 00|"; depth:4; offset:8; reference:bugtraq,122; reference:cve,CVE-1999-0003; classtype:misc-attack; sid:1965; rev:8;)

IMPORTANT!

This example describes 1965 revision 8.

You can view the rule in its Sourcefire 3D System format by searching for the rule with a SID of 1965. For more information about searching for rules using the web interface, see Searching for Rules on page 1014. See the following sections for more information about SID 1965: •

Header Options on page 1032

•

Detection Options on page 1034

Header Options Requires: IPS or DC/MDC + IPS

Version 4.7

This section describes the rule heaader for SID 1965.


1032


Chapter 24

The graphic below displays the rule header information for SID 1965 as it appears in the Rule Editor.

The Rule Header Options table describes each segment of the rule header, and explains why each option was used. Rule Header Options Header Option

Value

Description

Message

RPC tooltalk TCP overflow attempt

Indicates the name of the rule. This is the message you see when this rule triggers an event.

Classification

Misc-Attack

Indicates the classification type.

Action

alert

Generates an event when the rule is triggered.

Protocol

tcp

Evaluates TCP traffic.

Direction

Directional

Evaluates traffic that originates from the Source IP and port and targets the Destination IP and port.

Source IPs

$EXTERNAL_NET

Evaluates traffic that originates from an outside source.

Source Port

any

Evaluates traffic that originates from any port.

Destination IPs

$HOME_NET

Evaluates traffic that targets an IP address on the internal network, as defined in the $HOME_NET variable.

Destination Port

any

Evaluates traffic that targets any port.

Continue with Detection Options on page 1034.

Version 4.7


1033


Chapter 24

Detection Options Requires: IPS or DC/MDC + IPS

Version 4.7

This section describes the detection options for SID 1965. The rule detection options within SID 1965 comprise the most significant part of the rule. In the Rule Editor, they appear in the following format:


1034


Chapter 24

The following sections discuss each detection option used in SID 1965, and why and how each detection option is used. •

Defining Flow Options on page 1035

•

Investigating a Sample ToolTalk Exploit Packet on page 1036

•

Finding the ToolTalk Program Number on page 1038

•

Finding the Procedure Number Using Distance and Within on page 1039

•

Using byte_jump to Skip Authentication Bytes on page 1040

•

Using byte_jump to Skip Verification Bytes on page 1041

•

Using byte_test to Calculate Data Size on page 1042

•

Locating the RPC Call on page 1043

•

Specifying Classification and External References for SID 1965 on page 1044

Defining Flow Options Requires: IPS or DC/MDC + IPS

The flow detection option defines the type of traffic to inspect. Using the flow detection option to define the state of inspected traffic makes the rule more specific, so that it only alerts on traffic that flows from the client that initiates the session (that is, the potential attacker) to the server (that is, the potentially compromised target) that responds to the RPC request. Therefore, the to_server argument is used with flow. In addition to indicating traffic direction, you can use the flow detection option to define the state of inspected traffic. In the case of the ToolTalk exploit, the rule should only alert on an established session. If an RPC request is sent to a server that does not run the ToolTalk service, and thus does not respond to the request, the exploit is irrelevant. A rule that triggered on this would cause unnecessary false positives. In other words, the rule would generate an event, even though the system was not susceptible to the exploit. The traffic that triggers the rule would not exist outside of an established session. This is because the packet in question comprises the buffer overflow data that is actually transmitted to the ToolTalk service. Given the requirements to restrict the rule so that it inspects only traffic that is transmitted from client to server for an established session, the flow detection option is defined as Established and To Server.

Continue with Investigating a Sample ToolTalk Exploit Packet on page 1036.

Version 4.7


1035


Chapter 24

Investigating a Sample ToolTalk Exploit Packet Requires: IPS or DC/MDC + IPS

Before continuing to the content matching sections, you should review a sample packet generated by the ToolTalk buffer overflow exploit. The following diagram illustrates the first seven lines of the packet payload: 0x0000 : 0x0010 : 0x0020 : 0x0030 : 0x0040 : 0x0050 : 0x0060 :

00 00 00 6C 00 41 41

00 01 00 68 00 41 41

0F 86 00 6F 00 41 41

9C F3 20 73 00 41 41

36 00 37 74 00 41 41

51 00 5E 00 00 41 41

D5 00 D1 00 00 41 41

2B 01 6A 00 00 41 41

00 00 00 00 00 41 41

00 00 00 00 00 41 41

00 00 00 00 00 41 41

00 07 09 00 00 41 41

00 00 6C 00 00 41 41

00 00 6F 00 00 41 41

00 00 63 00 0F 41 41

02 01 61 00 FF 41 41

....6Q.+........ ................ ... 7^.j....loca lhost........... ................ AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA

Because this packet is an RPC request, there are a number of constants in the RPC protocol that SID 1965 uses as a basis for its construction. In the graphic that follows, each line of the packet payload has been separated, and each significant

Version 4.7


1036


Chapter 24

byte segment has been assigned a letter that corresponds to the information it includes. A 0x0000 :

D

F

G

H

00 01 86 F3 00 00 00 01 00 00 00 07 00 00 00 01

I 0x0020 :

C

00 00 0F 9C 36 51 D5 2B 00 00 00 00 00 00 00 02

E 0x0010 :

B

J

00 00 00 20 37 5E D1 6A 00 00 00 09 6C 6F 63 61

J, continued 0x0030 :

6C 68 6F 73 74 00 00 00 00 00 00 00 00 00 00 00

J, continued 0x0040 :

K

L

M

00 00 00 00 00 00 00 00 00 00 00 00 00 00 0F FF

N 0x0050 :

41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41

0x0060 :

41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41

r

A: Fragmentation data

H: Authorization type

B: RPC ID number

I: Authorization byte size

C: RPC call

J: Authorization information

D: RPC version

K: Verification type

E: RPC program number

L: Verification byte size

F: RPC response

M: Number of data bytes

G: RPC procedure number

N: Data

The segments that are matched or tested in this rule include:

Version 4.7

•

RPC version number (D), to identify RPC traffic

•

RPC procedure number (G), to identify the ToolTalk RPC procedure number

•

authorization byte size (I), to detect the number of authorization bytes to skip forward in the packet

•

verification byte size (L), to detect the number of verification bytes to skip forward in the packet

•

number of data bytes (M), to calculate if the data is large enough to indicate a possible buffer overflow attempt.

•

RPC call (C), to further identify RPC traffic


1037


Chapter 24

Continue with Finding the ToolTalk Program Number.

Finding the ToolTalk Program Number Requires: IPS or DC/MDC + IPS

In messages that use the RPC protocol, the RPC version number (segment D: RPC version) follows the RPC call segment. The rule skips the RPC version number in the packet payload and leaves the RPC call segment as a final confirmation of the RPC protocol, because the RPC program number (the four bytes that follow the RPC call segment and the RPC version number) is more likely to be unique. In the RPC protocol, program numbers identify each RPC service. For example, portmapper uses program number 100000 and rstatd uses program 100001. ToolTalk’s object database server (ttdbserverd) is identified by program number 100083. The program number starts at byte 16, and, in hexadecimal, is represented by 00 01 86 F3 (segment E: RPC program number). 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060

: : : : : : :

00 00 00 6C 00 41 41

00 01 00 68 00 41 41

0F 86 00 6F 00 41 41

9C F3 20 73 00 41 41

36 00 37 74 00 41 41

51 00 5E 00 00 41 41

D5 00 D1 00 00 41 41

2B 01 6A 00 00 41 41

00 00 00 00 00 41 41

00 00 00 00 00 41 41

00 00 00 00 00 41 41

00 07 09 00 00 41 41

00 00 6C 00 00 41 41

00 00 6F 00 00 41 41

00 00 63 00 0F 41 41

02 01 61 00 FF 41 41


TIP! If you convert bytes 16 through 19 in the sample packet from hexadecimal to decimal, you will find that the hexadecimal value of 00 01 86 F3 (186F3) converts to 100083 in decimal; 100083 is the RPC program number that corresponds to ToolTalk. Because the rule searches the packet based on specified detection options, it must skip from the beginning of the packet to the RPC program number (byte 16) to make the match. To accomplish this, this rule uses an offset at byte 16 (which is where the program number starts) and a depth of 4 (which is the number of bytes that comprise the RPC program number section), to skip over the RPC version number:

Continue with Finding the Procedure Number Using Distance and Within on page 1039.

Version 4.7


1038


Chapter 24

Finding the Procedure Number Using Distance and Within Requires: IPS or DC/MDC + IPS

After the ToolTalk program number appears in the packet, the next four-byte segment (beginning with byte 20, segment F: RPC response) indicates the response from the RPC server. The value here, in a typical packet generated by the exploit, should be one (00 00 00 01). The RPC response byte segment is not useful for pattern matching because the RPC request content match made at byte eight (00 00 00 00, C: RPC call) confirms that the message is an RPC request later in the rule. The 24th byte in the RPC protocol (segment G: RPC procedure number), however, identifies the operation that the ToolTalk server should perform. The ToolTalk buffer overflow exploit uses ToolTalk procedure seven (00 00 00 07), which corresponds with the _TT_ISERASE_() function in the ToolTalk object database server. This function implements an RPC procedure that accepts a long ASCII string as an argument, and then passes the argument to other functions, which in turn pass the string to other functions that eventually write the data to the ToolTalk database. If the ASCII string is suitably long, it causes a buffer overflow condition, overwriting data in the ToolTalk database with information included in the string. This allows the attacker to obtain root access to the compromised computer. The packet display that follows shows each of the patterns the rule has matched so far, in addition to the RPC procedure segment. 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060

: : : : : : :

00 00 00 6C 00 41 41

00 01 00 68 00 41 41

0F 86 00 6F 00 41 41

9C F3 20 73 00 41 41

36 00 37 74 00 41 41

51 00 5E 00 00 41 41

D5 00 D1 00 00 41 41

2B 01 6A 00 00 41 41

00 00 00 00 00 41 41

00 00 00 00 00 41 41

00 00 00 00 00 41 41

00 07 09 00 00 41 41

00 00 6C 00 00 41 41

00 00 6F 00 00 41 41

00 00 63 00 0F 41 41

02 01 61 00 FF 41 41


Because the ToolTalk procedure appears four bytes after the RPC program number (the last match) and right after the RPC reply section, the rule uses the distance option to skip four bytes past the RPC program number (over the RPC reply bytes) and match the procedure, 00 00 00 07. Because the match always occurs within four bytes, the rule uses the within option to match within four bytes. The content match is then specified as follows:

Continue with Using byte_jump to Skip Authentication Bytes on page 1040.

Version 4.7


1039


Chapter 24

Using byte_jump to Skip Authentication Bytes Requires: IPS or DC/MDC + IPS

After the procedure number appears in the packet, the next byte segment specifies the type of authentication. The ToolTalk overflow exploit uses UNIX authentication, which is signified by a byte segment that equals one (00 00 00 01, or segment H: Authorization type). The authentication type does not assist in identifying the exploit, so it does not need to be used as a content match and is skipped in the rule. The byte segment that appears after the authorization type byte segment indicates the number of bytes included in the authorization data segments that follow (segments I: Authorization byte size and J: Authorization information). Because authorization data can vary in length, the byte segment that defines the number of bytes included in authorization data is very useful. Using the byte_jump detection option, the rule can tell the system to calculate the number of bytes defined in the segment, and then skip forward that number of bytes within the packet in order to move to the next possible match. When you use the byte_jump detection option, you would specify the following arguments, in order, in a traditional Snort rule: byte_jump: Number of bytes to convert, offset, relative, big, little, string, hex, dec, oct, align, from_beginning, multiplier

The Sourcefire 3D System Rule Editor, however, simplifies the configuration of byte_jump by providing selectable options. The authorization byte size segment contains four bytes, so for the first byte_jump argument (number of bytes to convert), the rule specifies four. The authorization byte size segment is located four bytes after the last pattern match (segment G: RPC procedure number). Therefore, the rule sets an offset of 4, and modifies it with relative. The relative argument establishes that the bytes occur four bytes after the last pattern match. This is required because the number of bytes that occur before this string may vary; setting a static offset from the beginning of the packet payload may fail to detect an attempted exploit. The rule also uses the align argument to stipulate that, no matter what the calculated value, the next pattern match begins on a 32-bit boundary (that is, at the beginning or end of a four-byte segment). For example, if you use align as an argument, and the calculated value of the byte size segment was 29, it stops skipping bytes at the 32nd byte instead of the 29th byte. This is a useful option when skipping bytes of a variable size, because there is no way to know whether the variable value itself will always end on a 32-bit boundary, but you do know that each significant value in the RPC protocol is located on a 32-bit boundary. Based on the reasons described above, the rule uses the following options to create a jump:

Version 4.7


1040


Chapter 24

For example, in the sample packet, if you convert the hexadecimal value of the authentication information bytes (00 00 00 20), you find that it equals 32. If you used byte_jump, the rule would calculate 00 00 00 20 hexadecimal as 32 decimal, and would then skip over 32 bytes. In the packet display that follows, the calculated byte segment is highlighted, the skipped bytes appear in italics, and the byte where the system would await a directive for the next match is highlighted: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060

: : : :

00 00 0F 9C 00 01 86 F3 00 00 00 20

36 00

37 74

6C 68 6F 73 : 00 00 00 00

00 41 41

: 41 41 41 41 : 41 41 41 41

51 D5 2B 00 00 00 00 00 00 01 00 00 00 07

5E D1 6A 00 00 00 09 00 00 00 00 00 00 00

00 00 00 00 00 00 00 41 41 41 41 41 41 41 41 41 41 41 41 41 41

00 00 00 02 ....6Q.+........ 00 00 00 01 ................ 6C 6F 63 61 ... 7^.j....loca 00 00 00 00 lhost........... 00 00 0F FF ................ 41 41 41 41 AAAAAAAAAAAAAAAA 41 41 41 41 AAAAAAAAAAAAAAAA

Continue with Using byte_jump to Skip Verification Bytes on page 1041.

Using byte_jump to Skip Verification Bytes Requires: IPS or DC/MDC + IPS

After skipping authentication bytes, the next byte segment indicates the verification type (segment K: Verification type). Like the authentication type byte segment, these bytes are not required for a content match, and do not have to be inspected. The byte segment that appears after this (segment L: Verification byte size), however, is significant in that it indicates the number of verification data bytes that follow it. In the sample packet, the verification byte size value is 0, but this number may vary depending on the verification data included in the packet. Since these defining bytes appear four bytes after the last byte jump, the rule uses another byte jump to move to the bytes, calculate their value, and jump any number of verification bytes indicated by the calculation:

In the sample packet displayed below, the bytes used for byte_jump’s calculation are highlighted and in italics. 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060

Version 4.7

: : : : : : :

00 00 00 6C 00 41 41

00 01 00 68 00 41 41

0F 86 00 6F 00 41 41

9C F3 20 73 00 41 41

36 00 37 74 00 41 41

51 00 5E 00 00 41 41

D5 00 D1 00 00 41 41

2B 01 6A 00 00 41 41

00 00 00 00

00 00 00 00

00 00 00 00

00 07 09 00

00 00 00 00

41 41 41 41 41 41 41 41


00 00 6C 00 00 41 41

00 00 6F 00 00 41 41

00 00 63 00 0F 41 41

02 01 61 00 FF 41 41


1041


Chapter 24

Because the calculated bytes in the sample packet are equal to zero, no bytes are skipped, and the system awaits the next match at the beginning of the next byte segment, 00 00 0F FF. Continue with Using byte_test to Calculate Data Size on page 1042.

Using byte_test to Calculate Data Size Requires: IPS or DC/MDC + IPS

After skipping the verification bytes (if they exist), the rule searches for the next content match at the beginning of the next byte segment. This byte segment (segment M: Number of data bytes) describes the number of bytes of data that is sent to the ToolTalk database and is followed by the data itself. SID 1965 uses the byte_test detection option to calculate the number of bytes indicated in this byte segment to determine if the data is larger than a specific number of bytes, which may indicate a buffer overflow attempt. When using the byte_test detection option, you would use the following arguments, in order, in a traditional Snort rule: byte_test: Number of bytes to convert, operator, value, offset, relative, big, little, string, hex, dec, oct

The Sourcefire 3D System Rule Editor, however, simplifies the configuration of byte_test by providing selectable options. IMPORTANT!

In this rule, Big Endian, Little Endian, Hexadecimal String, Decimal String, and Octal String are not used. For more information about these arguments, see Constraining Content Matches on page 964.

Because the rule checks for a buffer overflow condition, the rule must calculate the four-byte segment and then generate an event if the number of calculated bytes is suspiciously high. In this case, any value larger than 128 bytes can constitute suspicious data because calls to the ToolTalk object database are typically not that large. Because this byte segment should appear directly after the last byte jump (segment L: Verification byte size), the rule uses zero as the offset value, relative to the last match. Therefore, the byte_test options are as follows, where four bytes are tested zero bytes after the last pattern match, and if that number is greater than 128, the rule generates an alert.

Version 4.7


1042


Chapter 24

In the sample packet, the hexadecimal value of 00 00 0F FF (FFF) is converted to a decimal value of 4095 bytes, which is much larger than the rule’s specified value of 128, and indicative of an attack. 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060

: : : : : : :

00 00 00 6C 00 41 41

00 01 00 68 00 41 41

0F 86 00 6F 00 41 41

9C F3 20 73 00 41 41

36 00 37 74 00 41 41

51 00 5E 00 00 41 41

D5 00 D1 00 00 41 41

2B 01 6A 00 00 41 41

00 00 00 00 00 41 41

00 00 00 00 00 41 41

00 00 00 00 00 41 41

00 07 09 00 00 41 41

00 00 6C 00 00 41 41

00 00 6F 00 00 41 41

00 00 63 00 0F 41 41

02 01 61 00 FF 41 41


Continue with Locating the RPC Call on page 1043.

Locating the RPC Call Requires: IPS or DC/MDC + IPS

After the flow detection option appears in SID 1965, content matches appear. Content matches are used to match payload content. Because the suspicious traffic is always going to be an RPC call, all traffic follows the conventions of the RPC protocol. The third four-byte segment (segment C: RPC call) indicates the RPC call. In the RPC protocol, 0 signifies an RPC request, and 1 signifies an RPC reply. Because the rule should trigger on an RPC request, we want to find packets where these four bytes are set to 0. 0 1 2 3 4 5 6 7 8 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060

: : : : : : :

00 00 00 6C 00 41 41

00 01 00 68 00 41 41

0F 86 00 6F 00 41 41

9C F3 20 73 00 41 41

36 00 37 74 00 41 41

51 00 5E 00 00 41 41

D5 00 D1 00 00 41 41

2B 01 6A 00 00 41 41

00 00 00 00 00 41 41

00 00 00 00 00 41 41

00 00 00 00 00 41 41

00 07 09 00 00 41 41

00 00 6C 00 00 41 41

00 00 6F 00 00 41 41

00 00 63 00 0F 41 41

02 01 61 00 FF 41 41


The rule should search for this string at the eighth byte of a packet payload and should match four bytes. Therefore, the rule specifies the content to match, and then specifies the location using an offset of eight with a depth of four:

Note that in revision 6 and later of rule 1965, the RPC call was moved to the end of the rule. This is because the rules engine begins comparing traffic against rules using the first content match listed. Because most RPC rules use the RPC call for verification, any RPC traffic will be compared against all rules that use the RPC call as the first content match. This matches a large number of rules. It then compares the packet to the second content match, ruling out other rules, then compares the third, and so on. By moving the ubiquitous RPC call to the end of the rule, the rules engine instead compares incoming traffic against the second content match, which is more likely to be unique. In the case of the Tooltalk rule,

Version 4.7


1043

Rule-Writing Examples and Tips Understanding Replace Rules

Chapter 24

this content match is the ToolTalk program number, which is more likely to be unique than the RPC call. This approach quickly matches traffic to a much smaller group of rules and speeds performance significantly. Continue with Specifying Classification and External References for SID 1965 on page 1044.

Specifying Classification and External References for SID 1965 Requires: IPS or DC/MDC + IPS

After content matching detection options are specified in the rule, the rule includes reference information. The table that follows displays each detection option, its corresponding value in rule 1965, and a description of the value. Detection Options for Rule 1965 Detection Option

Value

Description

reference

cve,CVE-1999-0003

Indicates that the rule references MITRE’s Current Vulnerabilities and Exposures database, entry CVE-19990003.

reference

bugtraq,122

Indicates that the rule references Security Focus’ Bugtraq vulnerability database, entry 122.

The following graphic shows the reference detection options.

Understanding Replace Rules Requires: IPS or DC/MDC + IPS

When using an inline detection engine, you can take advantage of rules that use the replace keyword. To use the replace keyword, construct a custom standard text rule that uses the content keyword to look for a specific string. Then use the replace keyword to replace the string with exactly the same number of characters. Only the first instance of the content found by the rule is replaced. The following two examples show how replace rules can be helpful: •

Version 4.7

If you detect an incoming packet that contains an exploit, you can replace the malicious string with a harmless one. Sometimes this technique is more successful than simply dropping the offending packet. In some attack scenarios, the attacker simply re-sends the dropped packet until it bypasses


1044


Chapter 24

your network defenses or floods your network. By substituting one string for another rather than dropping the packet, you may trick the attacker into believing that the attack was launched against a target that was not vulnerable. See Example: Replacing a Malicious String on page 1045 for more information. •

If you are concerned about reconnaissance attacks that try to learn whether you are running a vulnerable version of, for example, a web server, then you can detect the outgoing packet and replace the banner with your own text. See Example: Replacing a Web Server Banner on page 1048 for more information.

IMPORTANT! Make sure that you set the rule state to Enable in the inline intrusion policy where you want to use the replace rule. As part of the string replacement process, IPS automatically updates the packet checksum so that the destination host can receive the packet without error.

Example: Replacing a Malicious String Requires: IPS or DC/MDC + IPS

In this example, use the Rule Editor to create a rule that detects an attempt to execute code on the target host. The rule replaces the malicious code (/bin/sh) with a harmless string that has, as required, exactly the same number of characters (/foo/sh). Note that this example is just an illustration and is not recommended for implementation; this example would generate too much alert traffic on a busy network. To replace a malicious string:


1.

Select Policy & Response > IPS > Detection & Prevention > Rules.

2. Click Create Rule. The Create page appears. 3. In the rule header fields, add the following:

Version 4.7

•

Message: Replace /bin/sh

•

Classification: Executable code was detected

•

Action: alert

•

Protocol: ip

•

Direction: Directional

•

Source IPs: any

•

Source Port: any

•

Destination IPs: any

•

Destination Port: any


1045


Chapter 24

4. From the list of detection options, select content and click Add Option. The content options appear.

5. In the text field, type /bin/sh and select the Case Insensitive option. 6. From the list of detection options, select replace and click Add Option. The replace options appear.

Version 4.7


1046


7.

Chapter 24

In the text field, type the replacement text, enclosing the text in quotation marks and making sure the string is the same length; for example, "/foo/sh". IMPORTANT! If you do not include the quotation marks, they are added to the rule automatically so that the rule is syntactically correct. If you want to include a leading or trailing quotation mark as part of the replacement text, you must use a backslash to escape it. For example, "\"replacement text plus quotations marks\"". The completed rule should look like this:

8. Click Save As New. The new rule is saved to the Local rule category. See Applying an Intrusion Policy on page 764 for more information about enabling the rule in the current intrusion policy. IMPORTANT! Make sure that you set the rule state for this rule to Enable in the inline intrusion policy where you want to use it.

Version 4.7


1047


Chapter 24

Example: Replacing a Web Server Banner Requires: IPS or DC/MDC + IPS

Often, as a prelude to an attack, an attacker tries to determine which vendor and version of a service are running on your network, which in turn helps the attacker understand which vulnerabilities the host may have. One key piece of data that an attacker can use is the banner text that services provide.You can use the replace keyword to create a rule that obfuscates the banner and makes the host more difficult to attack. This rule takes advantage of three variables you can set up in the intrusion policy: $HTTP_SERVERS, $HTTP_PORTS, and $EXTERNAL_NET. You need to define the first two variables as the IP addresses of the web servers you want to protect and the ports that those web servers use. $EXTERNAL_NET represents the IP addresses outside your network. For more information, see Defining IP Addresses and Ports for Your Network on page 773. Note that this example is just an illustration and is not recommended for implementation; this rule would generate too much alert traffic on a busy network with multiple web servers. To replace a web server banner:


1.

Select Policy & Response > IPS > Detection & Prevention > Rules.

2. Click Create Rule. The Create page appears. 3. In the rule header fields, add the following: •

Message: Obfuscate Web Server Banner

•

Classification: Attempted Information Leak

•

Action: alert

•

Protocol: tcp

•

Direction: Directional

•

Source IPs: $HTTP_SERVERS

•

Source Port: $HTTP_PORTS

•

Destination IPs: $EXTERNAL_NET

•

Destination Port: any

4. From the list of detection options, select flow and click Add Option. The flow options appear.

5. Because you want to limit this rule to examining traffic that flows from the web servers as part of an established TCP session, from the flow options, select Established and From Server.

Version 4.7


1048


Chapter 24

6. From the list of detection options, select content and click Add Option. The content options appear.

7.

For this example, assume that your web server is Apache and the banner reads, in part, Apache/2.0.45. Therefore, in the text field, type Apache/2.0.45.

8. From the list of detection options, select replace and click Add Option. The replace options appear.

Version 4.7


1049


Chapter 24

9. In the text field, type the text that you want to replace the banner, enclosing the text in quotation marks and making sure the string is the same length; for example, "web.server.00". IMPORTANT! If you do not include the quotation marks, they are added to the rule automatically so that the rule is syntactically correct. If you want to include a leading or trailing quotation mark as part of the replacement text, you must use a backslash to escape it. For example, "\"replacement text plus quotations marks\"". The rule should look like this:

10. Click Save As New. The new rule is saved to the Local rule category. See Applying an Intrusion Policy on page 764 for more information about enabling the rule in the current intrusion policy. IMPORTANT! Make sure you set the rule state for this rule to Enable in the IPS intrusion policy where you want to use it.

Version 4.7


1050

Rule-Writing Examples and Tips Rule Writing and Tuning Recommendations

Chapter 24

Rule Writing and Tuning Recommendations Requires: IPS or DC/MDC + IPS

This section includes tips to help you effectively write and use rules in your environment without compromising the performance of your system. 1. Disable rules that are not relevant in your environment. The Sourcefire 3D System includes thousands of standard text rules. These rules offer you a comprehensive set of options from which to choose before requiring you to write your own rules. The sensor evaluates network traffic against all rules whose rule state is set to Enable or Drop. Many of these rules may not be relevant to your network environment. To optimize the performance of your system, you should disable all rules that are not relevant to your environment. This allows the system to evaluate only pertinent rules and decreases the number of false positives and alerts that do not convey meaningful data. For example, if you are monitoring a network that contains no IIS servers, deactivate IIS-specific rules. 2. When writing rules that affect large blocks of your network, write each rule to reflect the largest portion of your network possible rather than writing more rules that address smaller sections of your network. The sensor decides whether to evaluate a packet against an active rule based on protocol, specified destination IP addresses, and port numbers. If you create several rules that each test for the same criteria, changing only the destination IP address, the system must evaluate each packet against each rule’s protocol, then each rule’s specified destination IP address to determine whether the packet should be evaluated against the rule’s options. This slows performance unnecessarily. Instead, write a single rule and specify the destination IP address range that encompasses all of the destination IP addresses for which you want to test. 3. When writing new rules, be as restrictive as possible with specified port. When possible, restrict the destination port as narrowly as possible. If a packet is not intended for the specified destination port, the system does not need to evaluate it further. For example, if you know the FTP server listens on port 21, use port 21 as the destination port for FTP-related rules. The system can determine whether to continue evaluating each packet against the detection options and arguments based on the destination port. 4. Before writing a new rule, conduct ample research. You should understand the problem for which you are writing the rule, and understand the protocol of the traffic that will trigger the rule. Conduct adequate research before you begin writing your rule (you may find that the rule you want to write has already been written), and take the time to thoroughly examine the traffic that you want to detect for identifying characteristics. You should then be able to write a rule that contains information that specifically describes the suspicious traffic that you want to generate an event against. If you use unique information for pattern-matching, you are less likely to trigger a large number of false positives (or false negatives).

Version 4.7


1051

Rule-Writing Examples and Tips Rule Writing and Tuning Recommendations

Chapter 24

5. Use modifiers in content matching rules to narrow the extent of the content evaluation to that which offers relevant data. The Snort rules language offers detection options that modify content searches. Using these where applicable can limit meaningless, processor-intensive string matching. For example, the options depth and offset limit the bytes where content string matching occurs. Often, the content you want to locate occurs in a specific area of the packet payload. The offset option allows you to optimize processing by allowing you to specify that the system only search for content in the area of the packet payload that you specify. The depth option instructs the pattern match function to stop searching for a content match after the possible search region for a given set of content has been searched. When possible, use rule options that restrict pattern-matching (such as flow, offset, depth, byte_test, byte_jump, distance, and within). If you provide the exact location for the rules engine to locate matching content, system performance increases because the rules engine does not have to inspect the entire packet. 6. When using content matches, specify unique patterns early in the rule, and place ubiquitous matches last. Because the rules engine compares packets against the content matches in rules by order of appearance in the rule, if you place the less common matches at the beginning of the rule, and the more common matches at the end of the rule, rules engine performance is significantly enhanced. For example, in an RPC rule, you almost always detect on the RPC call as well as a procedure number or other identifying characteristic. If the RPC call is described in the first match, all RPC call network traffic is compared against the rule. If a less common content match, such as a procedure number, is used as the first content match, a much smaller subset of RPC traffic will be compared against the rule, and unnecessary load on the rules engine is avoided. 7. Write comprehensive rules where possible. Write rules that eliminate the redundant evaluation of packets with the same specified protocol, IP addresses, and ports. Because the system evaluates against protocol, IP addresses, and ports first, group detection options together in a single rule where possible. For example, if you have three programs that are vulnerable on port 80 of your Web server: •

cgi-bin/myCompanyBlue

•

cgi-bin/myCompanyRed

•

cgi-bin/myCompanyYellow

You could write a single TCP rule that alerts on the string cgi-bin/myCompany within traffic that is sent to the specific IP of the Web server on port 80. The simplest way of writing a rule is often the most effective – avoid adding complexity to the rule if it is not required.

Version 4.7


1052

Chapter 24

Using Real-time User Awareness

Sourcefire Real-time User Awareness, also called RUA, allows your organization to correlate threat, endpoint, and network intelligence with user identity information. By linking network behavior, traffic, and events directly to individual users, RUA can help you to identify the source of policy breaches, attacks, or network vulnerabilities, as well as mitigate risk, block users or user activity, and take action to protect others from disruption. These capabilities also significantly improve audit controls and enhance regulatory compliance. All RUA deployments require a Defense Center that has an RUA feature license installed. If your organization uses LDAP, you can use the user information on your LDAP server to populate the Defense Center’s database of user identity information. In addition, you have three choices in how you collect user login information: •

You can configure 3D Sensors to observe your organization’s network traffic and communicate LDAP, POP3, IMAP, SMTP, and AOL Instant Messenger (AIM) user logins to the sensors’ managing Defense Center.

•

If your organization uses Active Directory LDAP servers, you can install Sourcefire RUA Agents on them. The agents communicate LDAP user logins to the Defense Center.

•

You can use both 3D Sensors and RUA Agents.

The following sections explain more about RUA, how to choose an implementation and set up RUA, and how to view, interpret, and use the data that RUA collects.

Version 4.7

•

Understanding RUA on page 1054

•

Configuring RUA on page 1074


1053

Using Real-time User Awareness Understanding RUA

•

Working with RUA Users on page 1084

•

Working with RUA Events on page 1095

Chapter 25

Understanding RUA Requires: DC + RUA

RUA, when paired with IPS or RNA (or both), allows you to correlate network activity with user identity information. By linking network behavior, traffic, and events directly to individual users, RUA can help you to identify the source of policy breaches, attacks, or network vulnerabilities. In other words, RUA can tell you the “who” behind the “what.” For example, you could determine: •

who owns the host targeted by an intrusion event that has a red (vulnerable) impact flag

•

who initiated an internal attack or portscan

•

who is attempting unauthorized access of a server that has high host criticality

•

who is consuming an unreasonable amount of bandwidth

•

who has not applied critical operating system updates

•

who is using instant messaging software or peer-to-peer file-sharing applications in violation of company IT policy

Armed with this information, you can take a targeted approach to mitigate risk, block users or user activity, and take action to protect others from disruption. For more information, see the following sections: •

How Does RUA Work? on page 1054

•

How Do I Choose an RUA Implementation? on page 1063

•

What Information Does RUA Provide? on page 1067

•

How Can You Use RUA? on page 1068

•

What are the Limitations of Sourcefire RUA? on page 1073

How Does RUA Work? Requires: DC + RUA

Version 4.7

An RUA deployment includes: •

a Defense Center that you can use to configure RUA and view and analyze the data that RUA collects

•

either 3D Sensors with RUA or Sourcefire RUA Agents (or both) that detect user logins

•

optionally, LDAP servers that you can use to populate the Defense Center’s user database


1054


Chapter 25

The following diagram illustrates a typical RUA deployment.

The following sections describe the role that each component plays in your RUA deployment: •

Understanding LDAP Servers and RUA on page 1055

•

Understanding Sourcefire RUA Agents on page 1058

•

Understanding 3D Sensors with RUA on page 1059

•

Understanding the Defense Center and RUA on page 1060

Understanding LDAP Servers and RUA Requires: DC + RUA

Version 4.7

If your organization uses LDAP, you can configure the Defense Center to connect to an LDAP Server that you designate as the “primary” LDAP server. RUA supports connections to LDAP servers running Microsoft Active Directory on Windows Server 2003, Sun Directory Services 5.2 P4 on Windows 2003 and XP,


1055


Chapter 25

or OpenLDAP on Linux. You must have TCP/IP access from the Defense Center to the LDAP server. IMPORTANT! If you are using Microsoft Active Directory to implement LDAP and you have more than 1000 LDAP users, you must change the default query size on the Active Directory server to reflect the number of users in your organization. Otherwise, the Defense Center will only be able to obtain user information for 1000 users. To create the Defense Center-LDAP server connection, you must create and configure an authentication object, which contains your settings for connecting to and retrieving user data from the LDAP server. Note that you do not need to enable the object in a system policy to use the object for RUA. The Defense Center uses the information on the LDAP server to create a local user identity database. The Defense Center stores the following information and metadata about each user: •

LDAP username

•

first and last names

•

email address

•

department

•

telephone number

Note that RUA does not correlate LDAP metadata with existing user records. For example, if RUA adds a user to the Defense Center database because a 3D Sensor with RUA detected a POP3 login, and then the Defense Center connects to your LDAP server and discovers the same user, there will be two user records in the Defense Center database for that user even though they have the same email address. However, if RUA adds the user to the database via the Defense Center-LDAP server connection before the POP3 login is detected, RUA recognizes the identical email addresses and does not create duplicate user records. You must make sure that the LDAP server uses the default LDAP field names shown in the the Field Names for Mapping LDAP Fields to RUA Fields table on page 1057. For example, if you are using an Active Directory server, RUA maps the givenname metadata for a particular user on the LDAP server to the first name of that user in the Defense Center database. If you rename one of the

Version 4.7


1056


Chapter 25

fields, the Defense Center cannot populate its user database with the information in that field. Field Names for Mapping LDAP Fields to RUA Fields LDAP Server Field Name

Defense Center Field Name

Servers Where Field Exists by Default

samaccountname

Username

• Microsoft Active Directory on Windows Server 2003

uid

Username

• Sun Directory Services 5.2 P4 on Windows 2003 and XP • OpenLDAP on Linux

givenname

First Name

• Microsoft Active Directory on Windows Server 2003 • Sun Directory Services 5.2 P4 on Windows 2003 and XP • OpenLDAP on Linux

sn

Last Name

• Microsoft Active Directory on Windows Server 2003 • Sun Directory Services 5.2 P4 on Windows 2003 and XP • OpenLDAP on Linux

mail

• Sun Directory Services 5.2 P4 on Windows 2003 and XP

E-mail

• OpenLDAP on Linux department

Department

• Sun Directory Services 5.2 P4 on Windows 2003 and XP

distinguishedname

Department

• Microsoft Active Directory on Windows Server 2003

telephonenumber

Phone

• OpenLDAP on Linux

If there is no field on a particular LDAP server type, and you want that metadata, you must create the field on the server. For example, only OpenLDAP has a phone number field by default. If you are using an Active Directory server and want your user database on the Defense Center to include phone numbers, you must create a field called telephonenumber on the Active Directory server. This allows the Defense Center to pull the metadata from that field. The Defense Center and the LDAP server synchronize every hour, at which time the Defense Center adds any new users and metadata to its user database. Note that is if you remove an LDAP user from your server, the Defense Center does

Version 4.7


1057


Chapter 25

not remove that user from its local database. You must manually purge the user from the Defense Center database. TIP! Make sure your RUA feature license allows you to add all your LDAP users to the Defense Center database. Otherwise, every time the Defense Center synchronizes with the LDAP server, RUA will generate multiple User Identity Dropped events as it attempts to add users to the database and fails. For more information, see Understanding the Defense Center and RUA on page 1060. For information on configuring the Defense Center-LDAP Server connection, see Connecting to an LDAP Server on page 1075.

Understanding Sourcefire RUA Agents Requires: DC + RUA

If your organization uses Microsoft Active Directory to implement LDAP, you can install Sourcefire RUA Agents on your Active Directory servers. RUA Agents monitor users as they log into the network or when they authenticate against Active Directory credentials for any other reason (for example, your organization may use services or applications that rely on Active Directory for centralized authentication). IMPORTANT! If your organization does not use Active Directory, you must configure 3D Sensors with RUA to obtain user login data. For more information, see Understanding 3D Sensors with RUA on page 1059. The RUA Agent is less than 1MB in file size and runs as a background Microsoft .NET Framework service, typically using less than 5% of CPU resources, depending on the processing power of the Active Directory server and the frequency and quantity of authentications. The agent uses approximately 15MB of RAM. If the Microsoft .NET Framework version 2.0 is not installed on your Active Directory servers, the RUA Agent setup will guide you through the .NET Framework installation process. You should install RUA Agents on all your Active Directory servers to get complete coverage of your network. After you install RUA Agents on your Active Directory servers, you must configure your Defense Center to communicate with the agents. Then, when a login or other authentication occurs, an RUA Agent sends the following information to the Defense Center: •

the user’s LDAP username

•

the time of the login or other authentication

•

the IP address of the user’s host

When the Defense Center receives the information, it logs it to the RUA events database as a User Login event. The Defense Center also correlates the information with the user identity data in its user database, and logs the

Version 4.7


1058


Chapter 25

information to the RUA history database so that you can view a history of the user’s logins over time. For information on installing and configuring RUA Agents, see Configuring an RUA Agent on an Active Directory Server on page 1080.

Understanding 3D Sensors with RUA Requires: DC + RUA

You can use the RUA component on 3D Sensors instead of—or in addition to— the Sourcefire RUA Agents on your Active Directory servers. Setting up 3D Sensors with RUA is a two-step process. First, you must decide which sensors you are going to use. In general, you will want to monitor your internal network with RUA, although depending on your organization and network infrastructure, you may also want to monitor your DMZ. If you are adding RUA to an existing deployment, consider the placement of your current 3D Sensors. Do they provide you with complete coverage of the networks you want to monitor with RUA? Do you have enough free resources on these sensors to add one or more RUA detection engines? If not, you may need to deploy additional sensors. The number of RUA detection engines you can create is limited by the 3D Sensor model and by how many other detection engines of different types you have already created. If you are setting up the Sourcefire 3D System for the first time, you must address the same issues. That is, make sure you deploy 3D Sensors so that you have complete coverage of the networks you want to monitor, and deploy sensors that can run RUA as well as the other components of the Sourcefire 3D System you want to use (RNA and IPS). For detailed information on where and how to deploy 3D Sensors with RUA, refer to the Sourcefire 3D Sensor Installation Guide. After you decide which sensors you are going to use in your RUA deployment, you must create RUA detection engines on those sensors. RUA detection engines passively observe your organization’s network traffic and detect user logins using a variety of protocols: LDAP, POP3, IMAP, SMTP, and AIM. When a login occurs, the 3D Sensor sends the following information to the Defense Center:

Version 4.7

•

the username identified in the login event

•

the time of the login

•

either the IP address of the user’s host (for LDAP and AIM logins) or the IP address of the mail server (for POP3, IMAP, and SMTP logins)

•

the user’s email address (for POP3, IMAP, and SMTP logins)

•

the name of the detection engine that detected the login, as well as the name of the sensor it resides on


1059


Chapter 25

The Defense Center logs the information in the RUA events database as a User Login event, as well as in the RUA history database, which stores records of individual user logins. IMPORTANT! If you want to detect LDAP authentications with your 3D Sensors with RUA, make sure that your LDAP server uses the Kerberos authentication protocol. 3D Sensors with RUA cannot detect non-Kerberos encrypted LDAP user authentications. The Defense Center also attempts to correlate the information with its user database. For example, if a 3D Sensor with RUA detects a POP3 login for a user with the same email address as a user that already exists in the database, the POP3 login will be associated with that user. If there is no data in the login event that the Defense Center can correlate with its user database, the Defense Center creates a new user record. AIM logins, for example, will always create new user records. IMPORTANT! SMTP logins are not logged unless there is already a user with a matching email address in the database. For information on configuring 3D Sensors with RUA, see Setting up 3D Sensors with RUA on page 1083.

Understanding the Defense Center and RUA Requires: DC + RUA

You must use a Defense Center to configure RUA; you cannot configure it on a standalone 3D Sensor. Although 3D Sensors with RUA can detect user logins and collect user identity data, the sensors send that data to their managing Defense Center where you can view and analyze it. You must also use the Defense Center to view user identity data and RUA events. Note, however, that you can use the Master Defense Center to view user identity data correlated with intrusion, compliance, and white list events. This section explains some important things to keep in mind when you are using the Defense Center to configure RUA. Install an RUA feature license on the Defense Center. For you to view user identity data and RUA events, your Defense Center must have a RUA feature license. In a high-availability environment, both Defense

Version 4.7


1060


Chapter 25

Centers must have RUA licenses. If one Defense Center does not have a RUA license, you will not be able to use it to view user identity data or RUA events. IMPORTANT! An RUA Agent can only connect to one Defense Center at a time. In an high-availability environment, if the primary Defense Center fails, you must make sure that your RUA Agents can communicate with the secondary Defense Center. For more information, see Configuring an RUA Agent on an Active Directory Server on page 1080. RUA feature licenses specify the number of users you can monitor with RUA. After you reach your licensed limit, RUA stops adding new users to the Defense Center database. If you plan to populate the Defense Center user database with user identity data from an LDAP server, make sure you purchase a license that will allow you to add all your LDAP users to your Defense Center database. Otherwise, every time the Defense Center synchronizes with the LDAP server, RUA will generate multiple User Identity Dropped events as it attempts to add users to the database and fails. If your licensed limit drops to a number that is below the number of users in the Defense Center database (for example, if you install a new, smaller RUA license), the Defense Center automatically purges the database until it reaches the limit; oldest records are purged first. Keep in mind that 3D Sensors with RUA can detect multiple types of user logins (LDAP, POP3, IMAP, SMTP, and AIM). Also, RUA does not correlate LDAP metadata with existing user records. For example, if RUA adds a user to the Defense Center database because it detected a POP3 login, and then the Defense Center connects to your LDAP server and discovers the same user, there will be two user records in the Defense Center database for that user even though they have the same email address. However, if RUA adds the user to the database via the Defense Center-LDAP server connection before the POP3 login is detected, RUA recognizes the identical email addresses and does not create duplicate user records. Also note that AIM logins will always create duplicate user records because they are not associated with any of the user metadata that RUA obtains from the LDAP server, nor are they associated with any of the information contained in the LDAP, POP3, IMAP, or SMTP logins that your 3D Sensors detect. Therefore, if you are using 3D Sensors with RUA in your deployment, you may want to purchase an RUA license that allows you to monitor more than the actual number of users in your organization.

Version 4.7


1061


Chapter 25

After you reach your licensed limit, to detect additional users, you have three options: •

You can purchase and install a larger RUA license.

•

You can manually delete old or inactive users from the Defense Center database. For more information, see Viewing RUA Users on page 1086.

•

You can purge all users from the Defense Center database and start over. For more information, see Purging the RNA and RUA Databases on page 1232.

For information on setting up RUA licensing, see Licensing RUA on page 1074. Set realistic database limits. RUA stores data on the Defense Center in three places: in the users database, the RUA events database, and the RUA history database. You should make sure that you configure the Defense Center to store an adequate amount of data for your analysis. User identity data is stored in the Defense Center users database, with one record for each unique user. As explained above, your RUA feature license determines the number of users you can store in the database. This database is populated in two ways: •

When you create a connection between the Defense Center and an LDAP server, the Defense Center uses that connection to populate its user database with the user identity information and user metadata stored on the LDAP server.

•

When a user login occurs, whether it was detected by an RUA Agent on an Active Directory server or by a 3D Sensor with RUA, the Defense Center uses information in the login event to create an record in the user database (if there is not already a record of that user).

For more information on RUA users, see Working with RUA Users on page 1084. RUA events, which track not only user logins, but also additions and deletions of users from the Defense Center database, are stored in the RUA event database, which by default stores 10 million events. For more information on RUA events, see Working with RUA Events on page 1095. Individual user logins are stored in the RUA history database. This data is used to generate host histories, which track the users that have logged into an individual host over a period of time, and user histories, which track the hosts that an individual user has logged into over a similar period of time. By default, the RUA history database stores 10 million user logins. For more information on host histories and user histories, see Working with User History in the Host Profile on page 181 and Understanding User Details and Host History on page 1091. For information on changing the number of events you can store in the RUA events and RUA history database, see Configuring Database Event Limits on page 1197.

Version 4.7


1062


Chapter 25

Configure a connection with an LDAP server. If your organization uses LDAP, you can set up a connection between the Defense Center and an LDAP Server. The Defense Center uses the information on the LDAP server to create a local user identity database. For more information, see Understanding LDAP Servers and RUA on page 1055 and Connecting to an LDAP Server on page 1075. Configure connections with Sourcefire RUA Agents. If your organization uses Active Directory, you can set up connections between the Defense Center and the Sourcefire RUA Agents you can install on your Active Directory servers. RUA Agents send LDAP login information to the Defense Center. For more information, see Understanding Sourcefire RUA Agents on page 1058 and Configuring an RUA Agent on an Active Directory Server on page 1080. Configure connections with 3D Sensors with RUA. You can set up 3D Sensors with RUA to collect LDAP, POP3, IMAP, SMTP, and AIM user login information and send it to the Defense Center. For more information, see Understanding 3D Sensors with RUA on page 1059 and Setting up 3D Sensors with RUA on page 1083.

How Do I Choose an RUA Implementation? Requires: DC + RUA

As explained in detail in Understanding RUA on page 1054, an RUA deployment includes: •

a Defense Center that you can use to configure RUA and view and analyze the data that RUA collects

•

Either 3D Sensors with RUA or Sourcefire RUA Agents (or both) that detect user logins

•

Optionally, LDAP servers that you can use to populate the Defense Center’s user database

The main decision you must make when choosing an RUA implementation is whether you want to use RUA Agents or 3D Sensors with RUA (or both) to collect user login data. You must also decide whether or not you want to use an LDAP server to populate the Defense Center’s user database. For information on the advantages and disadvantages of these choices, see the following sections:

Version 4.7

•

Using LDAP Servers on page 1064

•

Using the Sourcefire RUA Agent on page 1064

•

Using 3D Sensors with RUA on page 1065

•

Using Both the Sourcefire RUA Agent and 3D Sensors with RUA on page 1066


1063


Chapter 25

Using LDAP Servers Requires: DC + RUA

If your organization uses LDAP, Sourcefire strongly recommends that you create a connection between the Defense Center and an LDAP Server that you designate as the “primary” LDAP server, so you can populate the Defense Center’s user database with information about your LDAP users. This provides you with a comprehensive user database, complete with any user metadata stored on the LDAP server. RUA supports connections to LDAP servers running Microsoft Active Directory on Windows Server 2003, Sun Directory Services 5.2 P4 on Windows 2003 and XP, or OpenLDAP on Linux. You must have TCP/IP access from the Defense Center to the LDAP server. IMPORTANT! If you are using Microsoft Active Directory to implement LDAP and you have more than 1000 LDAP users, you must change the default query size on the Active Directory server to reflect the number of users in your organization. Otherwise, the Defense Center will only be able to obtain user information for 1000 users. Note that you will have to work closely with your LDAP administrators to obtain the configuration information you need to set up the Defense Center-LDAP Server connection. For more information on using LDAP servers in your RUA deployment, see Understanding LDAP Servers and RUA on page 1055.

Using the Sourcefire RUA Agent Requires: DC + RUA

If you use Microsoft Active Directory LDAP servers, Sourcefire strongly recommends that you install Sourcefire RUA Agents on all of your Active Directory servers to collect user login data and send that data to the Defense Center. There are two advantages to using RUA Agents: •

If installed on all your Active Directory servers, RUA Agents provide comprehensive coverage of LDAP logins across your entire organization, and you will not have to rely on or deploy additional 3D Sensors with RUA to cover your network segments.

•

You can dedicate the hardware resources of your 3D Sensors to running IPS and RNA.

In general, you should not be concerned about running the RUA Agent on your Active Directory servers. The RUA Agent is less than 1MB in file size and runs as a background Microsoft .NET Framework service, typically using less than 5% of CPU resources, depending on the processing power of the Active Directory server and the frequency and quantity of authentications. The agent uses

Version 4.7


1064


Chapter 25

approximately 15MB of RAM. However, there are a few potential reasons for not using RUA Agents: •

Your organization may have a policy against installing third-party software on your mission-critical Active Directory servers.

•

Your organization may require certification testing of the RUA Agent, which can be a lengthy process. If you want to benefit from RUA right away, you can implement it using 3D Sensors with RUA and then later replace (or supplement) them with RUA Agents.

•

RUA Agents only detect LDAP logins. If you want to detect POP3, IMAP, SMTP, and AIM logins, you must use 3D Sensors with RUA.

Note that you will have to work closely with your Active Directory administrators to install the RUA Agents and obtain the configuration information you need to set up Defense Center-RUA Agent connections. TIP! There are advantages to using both RUA Agents and 3D Sensors with RUA in the same deployment. For more information, see Using Both the Sourcefire RUA Agent and 3D Sensors with RUA on page 1066. For more information on RUA Agents, see Understanding Sourcefire RUA Agents on page 1058.

Using 3D Sensors with RUA Requires: DC+ RUA

If your organization does not use Microsoft Active Directory LDAP servers and thus you cannot use Sourcefire RUA Agents, you must use 3D Sensors with RUA to collect user login information. In addition, because RUA Agents only detect LDAP logins, if you want to detect POP3, IMAP, SMTP, and AIM logins, you must use 3D Sensors with RUA. If you use 3D Sensors with RUA, there are several questions you must answer: •

Can you achieve complete network coverage with your existing 3D Sensors?

•

Do your 3D Sensors have enough available resources to devote to RUA?

•

If your organization uses LDAP, do your LDAP servers use the Kerberos authentication protocol? 3D Sensors with RUA cannot detect non-Kerberos encrypted LDAP user authentications.

If you cannot answer “yes” to these questions, you may need to purchase additional 3D Sensors or revisit your network encryption. Also note that RUA does not correlate LDAP metadata (obtained via the Defense Center-LDAP server connection, if you have configured one) with existing user records that were created by user logins detected by 3D Sensors with RUA. For example, if RUA adds a user to the Defense Center database because it detected a POP3 login, and then the Defense Center connects to your LDAP server and discovers the same user, there will be two user records in the Defense Center

Version 4.7


1065


Chapter 25

database for that user even though they have the same email address. However, if RUA adds the user to the database via the Defense Center-LDAP server connection before the POP3 login is detected, RUA recognizes the identical email addresses and does not create duplicate user records. In addition, AIM logins always create duplicate user records because they are not associated with any of the user metadata that RUA obtains from the LDAP server, nor are they associated with any of the information contained in the LDAP, POP3, IMAP, and SMTP logins that your 3D Sensors detect. Therefore, if you are using 3D Sensors with RUA in your deployment, you may want to purchase an RUA license that allows you to monitor more than the actual number of users in your organization. TIP! There are advantages to using both RUA Agents and 3D Sensors with RUA in the same deployment. For more information, see the next section, Using Both the Sourcefire RUA Agent and 3D Sensors with RUA. For more information on 3D Sensors with RUA, see Understanding 3D Sensors with RUA on page 1059.

Using Both the Sourcefire RUA Agent and 3D Sensors with RUA Requires: DC+ RUA

If your organization uses Microsoft Active Directory LDAP servers and you are using use Sourcefire RUA Agents to collect LDAP user login information, but you also want to detect POP3, IMAP, SMTP, and AIM logins, you must use 3D Sensors with RUA in addition to your RUA Agents. There are no compatibility issues with the use of both methods. The issues that you must consider when deciding to implement both methods are the same as if you were deciding to implement either method by itself. Note that even though both RUA Agents and 3D Sensors with RUA detect LDAP logins, you will not see duplicate login events on the Defense Center—the Defense Center records the first time that a user logs into a specific host and disregards subsequent logins. If another user logs into that host, however, the Defense Center will record the new login. Then, if the original user logs in again, his or her new login is recorded. For specific information about using either component, see Using the Sourcefire RUA Agent on page 1064 and Using 3D Sensors with RUA on page 1065.

Version 4.7


1066


Chapter 25

What Information Does RUA Provide? Requires: DC + RUA

RUA analyzes the data it collects and provides you with the information described in the following sections: •

RUA Users on page 1067

•

RUA Events on page 1067

•

Host Histories and User Histories on page 1067

RUA Users Requires: DC + RUA

The Defense Center maintains a database of RUA users on your network. The database is populated in two ways: •

When you create a connection between the Defense Center and an LDAP server, the Defense Center uses that connection to populate its user database with the user identity information and user metadata stored on the LDAP server.

•

When either an RUA Agent on an Active Directory server or a 3D Sensor with RUA detects an LDAP, POP3, IMAP, or AIM user login for a user who is not already in the database, the RUA user is added.

The number of users the Defense Center can store in its database depends on your RUA feature license. For more information, see Working with RUA Users on page 1084.

RUA Events Requires: DC + RUA

RUA events are triggered by user logins, additions and deletions of RUA users from the Defense Center database, and failures of RUA to add a user to the database (because you have reached your licensed limit). The events generated by RUA can alert you to the user activity on your network and provide you with the information you need to respond appropriately. Whenever possible the Sourcefire 3D System correlates RUA events with other types of events. For example, intrusion events can tell you the users who were logged into the source and destination hosts at the time of the event. RUA provides a predefined workflow that you can use to analyze the events that are generated for your network. You can use this predefined workflow, or you can create custom workflows that display only the information that matches your specific needs. For more information, see Working with RUA Events on page 1095.

Host Histories and User Histories Requires: DC+ RUA

Version 4.7

RUA uses its record of individual user logins to generate host histories, which track the hosts that a user has logged into. The host history provides a graphic representation of the last twenty-four hours of the user’s activity. For more information, see Understanding User Details and Host History on page 1091.


1067


Chapter 25

RUA also uses its record of individual user logins to generate user histories, which track the users that have logged into an individual host. The user history provides a graphic representation of the last twenty-four hours of the logins on the host. For more information, see Working with User History in the Host Profile on page 181.

How Can You Use RUA? Requires: DC + RUA

You can use RUA not only to view a complete record of your users and their activity your network, but you can also take advantage of the Sourcefire 3D System’s correlation of RUA events with other types of events. For example, intrusion events can tell you the users who were logged into the source and destination hosts at the time of the event. This can tell you who owns the host that was targeted by an attack, or who initiated an internal attack or portscan. You can also use RUA events in compliance rules. Based on the type of RUA event generated as well as other criteria that you specify, you can build compliance rules that, when used in a compliance policy, launch remediations and syslog, SNMP, and email alert responses when network traffic meets your criteria. The following sections provide examples of how you can use RUA to correlate threat, endpoint, and network intelligence with user identity information: •

Example: Identifying the Owner of an Attacked Host on page 1068

•

Example: Unauthorized Access of High-Criticality Host on page 1069

•

Example: Identifying Excessive Bandwidth Users on page 1070

•

Example: Identifying Instant Messenger Users on page 1071

Example: Identifying the Owner of an Attacked Host Requires: DC + IPS + RNA + RUA

Impact flags are indicators of the correlation between intrusion data, RNA network discovery events, and vulnerability information. A red impact flag means that a host is vulnerable to an attack represented by an intrusion event. You can use RUA to determine who was logged into the attacked host at the time of the attack. With this knowledge, you may be able to lessen the time it takes to mitigate the effects of the attack. To identify the owners of attacked hosts:


1.

Search for intrusion events with red impact flags. For more information, see Searching for Intrusion Events on page 689.

2. View the search results in a workflow that contains a table view of intrusion events. All of the predefined intrusion event workflows contain a table view of events; after you select a workflow click Table View of Events in the top left corner of the event view.

Version 4.7


1068


Chapter 25

3. Evaluate the events. The Destination User column tells you who was logged into each host at the time of each attack.

Example: Unauthorized Access of High-Criticality Host Requires: DC + IPS + RNA + RUA

Your organization’s critical servers need extra protection and monitoring. You can use the Sourcefire 3D System to track and notify you of unauthorized access attempts to your critical servers from internal users. When you receive a notification, you can use RUA to determine who attempted the access. To identify unauthorized users accessing critical servers:


1.

Use RNA to assign a high host criticality to your critical servers. For more information, see Setting Host Attributes for Specific Hosts on page 247.

2. Create a compliance rule that triggers on intrusion events with classifications that suggest unauthorized access or other suspicious activity.

These classifications can include: •


•


•


•


•


•


•

Attempt to Login By a Default Username and Password

For information on creating compliance rules, see Creating Rules for Compliance Policies on page 394. For a list of classifications, see Defining the Event Classification on page 958.

Version 4.7


1069


Chapter 25

3. Add a host profile qualification that constrains the comp[liance rule so it only triggers if the target host has a high host criticality.

For information on adding a host profile qualification to a compliance rule, see Adding a Host Profile Qualification on page 411. 4. Save the compliance rule. 5. Create and activate an alert. For more information, see Creating Alerts on page 460 6. Create a compliance policy. Add the rule you just created to the policy, and assign the alert you created as a response to that rule.

For more information on creating compliance policies, see Creating Compliance Policies on page 439. 7.

Save and activate the compliance policy. When an internal user attempts unauthorized access or other suspicious activity targeted at one of your critical hosts, you are notified via the alert you created.

8. Use the information in the alert to search compliance events for the event that concerns you. For more information, see Searching for Compliance Events on page 452. 9. View the search results in a workflow that contains a table view of compliance events. The predefined compliance workflow contains a table view of events. 10. Evaluate the event. The Source User column tells you who initiated the attack.

Example: Identifying Excessive Bandwidth Users Requires: DC + RNA + RUA

Version 4.7

Your organization may prohibit excessive bandwidth use. You can use the Sourcefire 3D System to view which hosts use the most bandwidth, and then examine the host profiles of those hosts to determine who is logged into those hosts.


1070


Chapter 25

To identify excessive bandwidth users: Access: Data or Admin

1.

View a flow graph of the Top Ten Initiators by Traffic, which is graph of your 10 most active hosts on your monitored network, based on the total number of kilobytes transmitted by the hosts. For more information, see Viewing Flow Data on page 299.

2. On the graph that appears, click any of the bars associated with a host that is using excessive bandwidth, then select View Host Profile. The host profile for that host appears in a new window. The User History section of the host profile tells you which users have logged into that host in the last 24 hours.

Example: Identifying Instant Messenger Users Requires: DC + RNA+ RUA

Use of instant messaging software may be a violation of your company policy. You can use the Sourcefire 3D System to track and notify you of unauthorized use of this software. When you receive a notification, you can use RUA to determine who is logged into the host running the instant messaging client application. Note that this example outlines how to use RNA to detect instant messaging client use, then associate that use with RUA users. RNA can detect the use of multiple instant messaging clients, including AIM, Microsoft MSN Messenger, Yahoo! Messenger, and Skype. RUA, on the other hand, specifically detects AIM logins and records the usernames and IP adresses of AIM users. To see all the AIM users on your network, search for RUA users discovered by the AIM authorization protocol. For more information, see Searching for RUA Users on page 1092. To identify users of instant messaging software:


1.

Create a compliance rule that triggers when RNA detects instant messaging activity.

For information on creating compliance rules, see Creating Rules for Compliance Policies on page 394. 2. Save the compliance rule. 3. Create and activate an alert. For more information, see Creating Alerts on page 460

Version 4.7


1071


Chapter 25

4. Create a compliance policy. Add the rule you just created to the policy, and assign the alert you created as a response to that rule.

For more information on creating compliance policies, see Creating Compliance Policies on page 439. 5. Save and activate the compliance policy. When RNA detects the use of an instant messaging client application on one of the hosts on your network, you are notified via the alert you created. 6. Use the information in the alert to search compliance events for the event that concerns you. For more information, see Searching for Compliance Events on page 452. 7.

View the search results in a workflow that contains a table view of compliance events. The predefined compliance event workflow contains a table view of events.

8. Evaluate the event. The Source User column tells you who was logged into the host at the time that RNA detected the instant messaging application. TIP! You can detect peer-to-peer activity in a similar way. For your convenience, the Defense Center ships with predefined compliance rules and a compliance policy that detect peer-to-peer activity. If you edit the compliance policy to assign alerts to its rules and then activate the policy, you can investigate any resulting compliance events in the same way that you would investigate events that detail instant messenger use.

Version 4.7


1072


Chapter 25

What are the Limitations of Sourcefire RUA? Requires: DC + RUA

The limitations of Sourcefire RUA are described in the Sourcefire RUA Limitations table. Sourcefire RUA Limitations Limitation

Description

non-Kerberos LDAP authentication

3D Sensors with RUA cannot detect non-Kerberos encrypted LDAP user authentications (for example, SSL). The Sourcefire RUA Agent, on the other hand, has no such limitation.

non-Active Directory LDAP servers

The Sourcefire RUA Agent is only supported on Active Directory. It is not supported on other types of LDAP servers, such as Sun Directory Services or OpenLDAP.

logoff detection

RUA detects user logins only. It does not detect logoffs.

multiple logins to the same host by different users

RUA assumes that only one user is logged into any given host at a time, and that the current user of a host is the user who logged in last.

multiple logins to the same host by the same user

The Defense Center records the first time that a user logs into a specific host and disregards subsequent logins. If an individual user is the only person who logs into a specific host, the only login that the Defense Center records is the original login. If another user logs into that host, however, the Defense Center will record the new login. Then, if the original user logs in again, his or her new login is recorded.

Version 4.7

double-byte characters

RUA does not detect usernames with double-byte characters (Chinese and Japanese).

disabled/deleted LDAP user accounts

Note that if you remove or disable an LDAP user on your LDAP server, the Defense Center does not remove that user from its local database, and that user continues to count against your licensed limit. You must manually purge the user from the Defense Center database (see RUA Users Table Functions on page 1086).

AOL Instant Messenger (AIM) login detection

3D Sensors with RUA can detect AIM logins using the OSCAR protocol only. While most AIM clients use OSCAR, some use TOC2.


1073

Using Real-time User Awareness Configuring RUA

Chapter 25

Configuring RUA Requires: DC + RUA

Before you can correlate your network traffic with user identity data, you must license and configure RUA. The steps you take to configure RUA depends on how you plan to implement RUA data collection. For more information on deciding how to implement RUA, see How Do I Choose an RUA Implementation? on page 1063. To configure RUA:

Access: Admin

1.

Make sure your Defense Center has an RUA feature license installed. You cannot view RUA user identity data or RUA events without a license. For more information, see Licensing RUA on page 1074.

2. Does your organization use LDAP? •

If yes, configure a connection between the Defense Center and one of your LDAP servers. The Defense Center uses the information on the LDAP server to create a local user identity database. For more information, see Connecting to an LDAP Server on page 1075

•


3. Does your organization use Active Directory LDAP servers? •

If yes, configure Sourcefire RUA Agents on your Active Directory servers to send LDAP login information to the Defense Center. For more information, see Configuring an RUA Agent on an Active Directory Server on page 1080.

•

If no (or if you choose not to install RUA Agents on your Active Directory servers), continue with the next step.

4. Optionally, set up 3D Sensors with RUA to collect LDAP, POP3, IMAP, SMTP, and AIM login information. Note that you must configure 3D Sensors with RUA to collect user login information if: •

Your organization does not use Active Directory LDAP servers.

•

Your organization uses Active Directory LDAP servers, but you did not configure an RUA Agent.

•

You want to obtain POP3, IMAP, SMTP, and AIM login information.

For more information, see Setting up 3D Sensors with RUA on page 1083.

Licensing RUA Requires: DC + RUA

For you to view user identity data and RUA events, your Defense Center must have an RUA feature license. For more information, see Understanding the Defense Center and RUA on page 1060. If your organization has purchased an RUA feature license but you do not have the license file, you can request it from the Defense Center web interface. Before

Version 4.7


1074


Chapter 25

beginning, you should have the 12-digit feature license serial number provided when you purchased RUA. To add an RUA feature license: Access: Admin

1.


2. Click License. The License page appears. 3. Click Add New License. The Add Feature License page appears. 4. Do you already have the license file? •

If yes, skip to step 6.

•

If no, click Get License.

The Licensing Center web site appears. IMPORTANT! If your web browser cannot access the Internet, you must switch to a host that can access it. Copy the license key at the bottom of the page and browse to https://www.keyserver.nokia.sourcefire.com/. 5. Follow the on-screen instructions for a feature license to obtain your license file, which will be sent to you in an email. 6. Copy the license file from the email you received, paste it into the License field, and click Submit License. If the license is valid, the RUA license is installed on the Defense Center. 7.

Does your organization use LDAP? •

If yes, continue with the next section, Connecting to an LDAP Server.

•

If no, skip to Setting up 3D Sensors with RUA on page 1083

Connecting to an LDAP Server Requires: DC + RUA

Version 4.7

Optionally, you can configure a connection between your Defense Center and one of your LDAP servers that you designate as your “primary” LDAP server. The Defense Center uses the information on the LDAP server to create a local user identity database, with an entry for each LDAP user. The Defense Center


1075


Chapter 25

synchronizes with the LDAP server and updates the local database every hour. Make sure your LDAP server uses the default LDAP field names. For more information, see Understanding LDAP Servers and RUA on page 1055. IMPORTANT! If you are using Microsoft Active Directory to implement LDAP and you have more than 1000 LDAP users, you must change the default query size on the Active Directory server to reflect the number of users in your organization. Otherwise, the Defense Center will only be able to obtain user information for 1000 users. To create the Defense Center-LDAP server connection, you must create and configure an authentication object, which contains your settings for connecting to and retrieving user data from the LDAP server. You use the same method to configure an authentication object as you would if you were setting up external authentication for user accounts on your Sourcefire appliances. Note, however, that RUA does not require all of the information that you must provide when configuring external authentication, nor does it support all of the functionality of an external authentication object. For example, RUA does not support encryption. In addition, you do not need to configure attribute mapping, group controlled access roles, shell access, or additional test parameters. The procedures in this section indicate which settings you can safely ignore. After you create the authentication object, you must add the connection to your RUA configuration. However, note that you do not need to enable the authentication object in your system policy or reapply the system policy. Work with your LDAP administrators to obtain the configuration information you need to set up the Defense Center-LDAP Server connection. For more information, see the following sections: •

Creating an Authentication Object for RUA Data Collection on page 1076

•

Identifying the LDAP Server on page 1077

•

Configuring the Authentication Method on page 1077

•

Adding the LDAP Connection to your RUA Configuration on page 1079

TIP! For general information on authentication objects, see Creating Authentication Objects on page 1266. For sample configurations showing how you might use different configuration options for connections to different LDAP server types, see Authentication Object Examples on page 1275.

Creating an Authentication Object for RUA Data Collection Requires: DC + RUA

Version 4.7

Use the following procedure to begin creating an authentication object for RUA data collection.


1076


Chapter 25

To create an authentication object for RUA data collection: Access: Admin

1.

Select Operations > Configuration > Login Authentication. The Login Authentication configuration page appears.

2. Click Create Authentication Object. The Create Authentication Object page appears. 3. Continue with the next section, Identifying the LDAP Server.

Identifying the LDAP Server Requires: DC + RUA

As part of configuring the authentication object, you must specify the LDAP server’s IP address and the port that the Defense Center and the LDAP server will use to communicate.

To identify the LDAP server: Access: Admin

1.

On the Create Authentication Object page, select LDAP from the Authentication Method drop-down list.

2. Type a name and (optional) description for the LDAP server in the Name and Description fields. 3. Type the IP address or host name for the LDAP server in the Server Host Name/IP Address field. 4. Leave the Server Port field as the default value. LDAP uses port 389; RUA does not support encrypted connections. 5. Leave the Server IP Address Backup field blank, and the Server Port Backup and Server Timeout fields as their defaults. RUA does not use a backup LDAP server. 6. Continue with the next section, Configuring the Authentication Method.

Configuring the Authentication Method Requires: DC + RUA

Version 4.7

You must configure the authentication object to specify where on the LDAP server the Defense Center should look for user identity information. You can specify the namespace, or directory tree, where the Defense Center should look by providing a base distinguished name, or base DN. Typically, a base DN has a


1077


Chapter 25

basic structure that indicates the company domain and operational unit. For example, the Security organization of the Example company might have a base DN of ou=security,dc=example,dc=com. You must also supply credentials for a user that can access the information you want to retrieve on the LDAP server. Note that the distinguished name for the user you specify must be unique to the directory information tree for the directory server.

To configure the authentication method: Access: Admin

1.

On the Create Authentication Object page, under Authentication Method Specific Parameters, select None as the encryption mode. RUA does not support encryption.

2. Leave the SSL Certificate Upload Path field blank. Because RUA does not support encryption, you cannot use a certificate to authenticate. 3. Type the base distinguished name for the LDAP directory you want to access in the Base DN field. For example, the Security organization of the Example company might have a base DN of ou=security,dc=example,dc=com. 4. Leave the Base Filter field blank. Do not filter the user identity information on the LDAP server when you are populating the Defense Center’s database. 5. In the User Name and Password fields, type the distinguished name and password for the user whose credentials you want to use to access the LDAP server fields. For example, the user name could be

[email protected].

6. Re-type the password in the Confirm Password field.

Version 4.7


1078


7.

Chapter 25

Leave the User Name Template field blank. You do not need to specify any required user name formatting, because the user information you are obtaining will not be used to log in to Sourcefire appliances.

8. Skip the sections that configure attribute mapping, group controlled access roles, shell access, and additional test parameters. 9. Click Save. The Login Authentication page appears again. You can safely ignore the shell access filter warning that also appears; you will not be using this authentication object in a system policy. 10. Continue with Adding the LDAP Connection to your RUA Configuration.

Adding the LDAP Connection to your RUA Configuration Requires: DC + RUA

The final step in configuring the Defense Center-LDAP Server connection is to add the authorization object to your RUA configuration. Note that you do not need to enable the authentication object in your system policy or reapply the system policy. To add the LDAP connection to your RUA configuration:

Access: Admin

1.

Select Operations > Configuration > RUA. The RUA configuration page appears.

2. Click Add LDAP Connection. The Add LDAP Connection pop-up window appears.

3. From the Authentication Object drop-down list, select the authentication object you just created and click Add. The LDAP connection is added. The Defense Center begins to synchronize its user database with the LDAP server. 4. Make sure that you have configured the connection correctly by selecting Analysis & Reporting > RUA > Users. Your LDAP users should appear in the RUA users event view. For more information on using the event view, see Working with RUA Users on page 1084.

Version 4.7


1079


Chapter 25

5. To get RUA events, you must configure at least one RUA Agent or a 3D Sensor with RUA. You have two options. •

If you are using Active Directory and want to configure RUA Agents on your Active Directory servers, continue with Configuring an RUA Agent on an Active Directory Server.

•

If you are not using Active Directory, or do not want to configure RUA Agents, skip to Setting up 3D Sensors with RUA on page 1083.

Note that you can use both RUA Agents and 3D Sensors with RUA. For more information, see How Do I Choose an RUA Implementation? on page 1063.

Configuring an RUA Agent on an Active Directory Server Requires: DC+ RUA

If your organization uses Microsoft Active Directory to implement LDAP, you can install Sourcefire RUA Agents on your Active Directory servers. RUA Agents monitor users as they log into the network or when they authenticate against Active Directory credentials for any other reason (for example, your organization may use services or applications that rely on Active Directory for centralized authentication). RUA Agents run as a background Microsoft .NET Framework services on your Active Directory server. If the Microsoft .NET Framework version 2.0 is not installed on your Active Directory servers, the RUA Agent setup will guide you through the .NET Framework installation process. You should install RUA Agents on all your Active Directory servers to get complete coverage of your network. For more information, see Understanding Sourcefire RUA Agents on page 1058. To collect LDAP user login information using RUA Agents, you must configure the Defense Center to connect to the Active Directory servers where the RUA Agents will reside. Then, you can install and configure the agents. For more information, see •

Configuring the Defense Center to Connect to RUA Agents on page 1080

•

Installing an RUA Agent on an Active Directory Server on page 1081

Configuring the Defense Center to Connect to RUA Agents Requires: DC + RUA

The first step in collecting LDAP user login information using Sourcefire RUA Agents is to configure the Defense Center to connect to the RUA Agents you plan to install on your Active Directory servers. To configure the Defense Center to connect to an RUA Agent:

Access: Admin

1.

Select Operations > Configuration > RUA. The RUA configuration page appears.

Version 4.7


1080


Chapter 25

2. Click Add Sourcefire RUA Agent. The Add Sourcefire RUA Agent pop-up window appears.

3. Type a descriptive name for the Agent in the Name field. 4. Type the IP address or host name of the Active Directory server where the RUA Agent will reside in the Hostname or IP Address field. 5. Click Add Sourcefire RUA Agent. The Defense Center is configured to connect to the RUA Agent on the Active Directory server. TIP! To delete the Defense Center-RUA Agent connection, click Delete next to the connection you want to delete. 6. Repeat steps 2 through 5 to add connections to RUA Agents on additional Active Directory servers. 7.

Continue with the next section, Installing an RUA Agent on an Active Directory Server.

Installing an RUA Agent on an Active Directory Server Requires: DC + RUA

After you configure the Defense Center to connect to your Active Directory servers, you must install and configure the Sourcefire RUA Agents. You should install RUA Agents on all your Active Directory servers to get complete coverage of your network. Note that RUA Agents require that Microsoft .NET Framework version 2.0, which is available from Microsoft as the .NET Framework Version 2.0 Redistributable Package (dotnetfx.exe), be installed on the Active Directory server. If it is not already installed, the RUA Agent setup will prompt you to download and install it. To install an RUA Agent on an Active Directory server:

Access: Any

1.

Download the RUA Agent setup file (SourcefireRUAAgentSetup.zip) from the Nokia Support Site. IMPORTANT! Download the setup file directly from the Support Site and do not transfer it by email. If you transfer the setup file by email, it may become corrupted.

Version 4.7


1081


Chapter 25

2. Copy the setup file to the Active Directory server where you want to install the RUA Agent. 3. Unzip the setup file and open the Windows Installer file (SourcefireRUAAgentSetup.msi) that appears. If Microsoft .NET Framework version 2.0 is not installed on your Active Directory server, you are prompted to download and install it. After you download and install the framework, open the RUA Agent installer file again. The RUA Agent setup wizard appears. 4. Follow the prompts in the setup wizard to install the RUA Agent and to read the release notes. 5. On the Active Directory server, select Start > All Programs > Accessories > Administrative Tools> Services. The service manager appears. 6. In the services list, right-click Sourcefire RUA Agent and select Stop. The RUA Agent stops. 7.

On the Active Directory server, select Start > All Programs > Sourcefire RUA Agent > Agent Settings. The Sourcefire RUA Agent Settings window appears.

8. Type the IP address or host name of your Defense Center in the Sourcefire Defense Center Hostname (or IP Address) field. 9. Optionally, modify the number of seconds in the Server Timeout (in seconds) field. 10. Click OK to save your settings. 11. In the service manager, in the services list, right-click Sourcefire RUA Agent and select Properties. The Sourcefire RUA Agent Properties window appears. 12. Ensure that the RUA Agent starts automatically when the Active Directory server boots by selecting Automatic from the Startup type drop-down list on the General tab. 13. Click OK. The Sourcefire RUA Agent Properties window closes.

Version 4.7


1082


Chapter 25

14. In the service manager, in the services list, right-click Sourcefire RUA Agent and select Start. The RUA Agent starts as a service on the Active Directory server and begins reporting logins to the server to your Defense Center. 15. Repeat steps 1 through 14 to install RUA Agents on additional Active Directory servers. 16. Do you want to configure 3D Sensors with RUA to supplement the LDAP logins detected by the RUA Agent with data gathered from POP3, IMAP, SMTP, and AIM logins? •

If yes, continue with the next section, Setting up 3D Sensors with RUA.

•

If no, you are finished configuring RUA. If you have installed an RUA feature license on your Defense Center, you can begin viewing and analyzing RUA data. You do not need to manage RUA with a policy.

Setting up 3D Sensors with RUA Requires:

If you choose to use the RUA component on 3D Sensors instead of (or in addition to) the Sourcefire RUA Agent on your Active Directory server, you must first decide which sensors you are going to use. Then, you must create RUA detection engines on those sensors. For more information, see Understanding 3D Sensors with RUA on page 1059. You can create an RUA detection engine on any 3D Sensor if you have an available interface set and detection resource; an RUA detection engine uses one detection resource. You can create as many RUA detection engines on one 3D Sensor as you need to monitor the interface sets that you have configured. In general, however, you should only create multiple RUA detection engines if you need to monitor multiple interface sets. Keep in mind that you can monitor the same interface set with multiple detection engines. For example, if you have a passive interface set that includes all of the interfaces on the 3D Sensor, you can monitor that set with IPS, RNA, and RUA. For general information on detection engines and interface sets, see Using Detection Engines and Interface Sets on page 102. Note that the number of RUA detection engines you can create on a 3D Sensor is limited by the sensor model and by how many other detection engines of different types you have already created.To create an RUA detection engine:

Access: Admin

1.

On the Defense Center, select Operations > Configuration > Detection Engines > Detection Engines. The Detection Engines page appears.

Version 4.7


1083

Using Real-time User Awareness Working with RUA Users

Chapter 25

2. Click Create Detection Engine. The Create Detection Engine page appears.

3. In the Name and Description fields, enter a name and description for the new detection engine. You can use alphanumeric characters, punctuation, and spaces. 4. From the Type drop-down list, specify that you want to create a RUA detection engine. 5. Optionally, add the detection engine to an existing detection engine group. See Using Detection Engine Groups on page 109 for information on creating and modifying detection engine groups. 6. Select the interface set that you want to assign to this detection engine. You can monitor any available interface set. See Using Interface Sets on page 114 for more information about creating and modifying interface sets. 7.

Specify that you want to use one detection resource for this detection engine. RUA detection engines only use one detection resource.

8. Click Save. The detection engine is created. 9. Repeat steps 2 through 8 to create additional RUA detection engines on additional 3D Sensors. You are finished configuring RUA. If you have installed an RUA feature license on your Defense Center, you can begin viewing and analyzing RUA data. You do not need to manage RUA with a policy.

Working with RUA Users Requires: DC+RUA

Version 4.7

If you have installed an RUA feature license, the Defense Center maintains a database of users on your network.


1084


Chapter 25

First, when you create a connection between the Defense Center and an LDAP server, the Defense Center uses that connection to populate its user database with the user identity information and user metadata stored on the LDAP server. The Defense Center stores the following information and metadata about each user: •

LDAP username

•

first and last names

•

email address

•

department

•

telephone number

Second, when either an RUA Agent on an Active Directory server or a 3D Sensor with RUA detects an LDAP, POP3, IMAP, or AIM user login for a user who is not already in the database, the RUA user is added. IMPORTANT! Although RUA detects SMTP logins, the Defense Center does not record them unless there is already a user with a matching email address in the database; RUA users are not added to the database based on SMTP logins. The type of login determines what information is stored about the new user, as described in the RUA Login Types and User Data Stored table. RUA Login Types and User Data Stored Login Type LDAP AIM

User Data Stored • username • current IP address • login type (aim or ldap)

POP3 IMAP

• username • current IP address • email address • login type (pop3 or imap)

The number of users the Defense Center can store in its database depends on your RUA license. For more information, see Licensing RUA on page 1074. Note that RUA does not correlate LDAP metadata with existing user records. For example, if RUA adds a user to the Defense Center database because it detected a POP3 login, and then the Defense Center connects to your LDAP server and discovers the same user, there will be two user records in the Defense Center database for that user even though they have the same email address. However, if RUA adds the user to the database via the Defense Center-LDAP server

Version 4.7


1085


Chapter 25

connection before the POP3 login is detected, RUA recognizes the identical email addresses and does not create duplicate user records. Also note that AIM logins will always create duplicate user records because they are not associated with any of the user metadata that RUA obtains from the LDAP server. You can search, view, and delete users from the database; you can also purge all RUA users from the database. For more information, see the following sections: •

Viewing RUA Users on page 1086

•

Understanding the RUA Users Table on page 1088

•

Understanding User Details and Host History on page 1091

•

Searching for RUA Users on page 1092

Viewing RUA Users Requires: DC+RUA

You can view a table of RUA users, and then manipulate the event view depending on the information you are looking for. The page you see when you access RUA users differs depending on the workflow you use. You can use the predefined workflow, which includes the table view of users as well as a table view of users with an additional column that indicates the IP address of the host that the user is currently logged into. You can also create a custom workflow that displays only the information that matches your specific needs. For information on creating a custom workflow, see Creating Custom Workflows on page 1179. The RUA Users Table Functions table below describes some of the specific actions you can perform on an RUA users workflow page. RUA Users Table Functions

Version 4.7

To...

You can...


find more information in Understanding the RUA Users Table on page 1088.






click the user icon ( )that appears next to the user identity. For more information, see Understanding User Details and Host History on page 1091.


1086


Chapter 25

RUA Users Table Functions (Continued) To...

You can...

sort user data






delete RUA users from the system

use one of the following methods: • To delete some RUA users, select the check boxes next to the users you want to delete, then click Delete. • To delete all RUA users in the current constrained view, click Delete All, then confirm you want to delete all the users. RUA users remain deleted until they are detected again, either via a login event or via the Defense Center’s synchronization with the LDAP server. See Purging the RNA and RUA Databases on page 1232 for information on deleting all RUA users from the database.

Version 4.7








1087


Chapter 25

RUA Users Table Functions (Continued) To...

You can...





search for RUA users

click Search. For more information, see Searching for RUA Users on page 1092.

To view RUA users: Access: Data or Admin

h

Select Analysis & Reporting > RUA > Users. The first page of the default RUA users workflow appears. If you created a custom RUA users workflow and did not specify a default, you must first select one. For information on specifying a default workflow, see Setting Event Preferences on page 35. If no users appear, you may need to adjust the time range. See Setting Event Time Constraints on page 1169 for more information. TIP! If you are using a custom workflow that does not include the table view of users, click Workflows. On the Select Workflow page, click Users.

Understanding the RUA Users Table Requires: DC+ RUA

Version 4.7

When RUA discovers a user, either via a Defense Center-LDAP server connection, or via a user login, it collects data about that user and stores it in the Defense Center database.That data includes at minimum the username, and depending on the discovery method can also include the user’s email address and other metadata.


1088


Chapter 25

The fields in the RUA users table are described in the RUA Users Fields table. RUA Users Fields Field

Description

User

Depending on how the user was discovered, the user is one of: • the first name, last name, and username of the user (for users discovered via the Defense Center-LDAP server connection) • the username only (for users discovered by user logins)

Username

The username of the RUA user, collected either from the LDAP server or a user login.

Current IP

For RUA users added to the database by user logins, the IP address of the host that the RUA user is logged into. Note that this field is blank if: • another user logs into the host (RUA associates the last user that logged in with the host) • the RUA user was added to the database via the Defense Center-LDAP server connection, and in addition is not associated with any user logins

Version 4.7

First Name

The user’s first name, as obtained from the Defense Center -LDAP server connection. If the user was added to the database via a user login, or if there is no first name associated with the user on the LDAP server, this field is blank.

Last Name

The user’s last name, as obtained from the Defense Center -LDAP server connection. If the user was added to the database via a user login, or if there is no last name associated with the user on the LDAP server, this field is blank.

E-Mail

The user’s email address, as obtained from either the Defense Center -LDAP server connection, or from an user login that contains email address information (POP3 and IMAP logins). If the user was added to the database via a user login that does not contain email address information (AIM and LDAP logins), or if there is no email address associated with the user on the LDAP server, this field is blank.


1089


Chapter 25

RUA Users Fields (Continued) Field

Description

Department

The user’s department,as obtained from the Defense Center -LDAP server connection. If there is no department explicitly associated with the user on the LDAP server, the department is listed as whatever default group the server assigns. For example, on Active Directory, this is Users (ad). If the user was added to the database via a user login, this field is blank.

Phone

The user’s telephone number, as obtained from the Defense Center -LDAP server connection. If the user was added to the database via a user login, or if there is no telephone number associated with the user on the LDAP server, this field is blank.

Auth Protocol

The protocol used to detect the RUA user. For example, for users added to the database via the Defense Center-LDAP server connection, the protocol is ldap. As another example, for users added when RUA detects a POP3 login, the protocol is pop3. Note that this field does not appear in either table view in the default RUA users workflow, nor in a table view that you add to a custom workflow based on RUA users. To see this field in an event view, you must create a custom workflow, add a drill-down page, and designate Auth Protocol as one of the fields on that page. However, you can use Auth Protocol as a search constraint.

Count

Version 4.7



1090


Chapter 25

Understanding User Details and Host History Requires: DC + RUA

From any event view that associates user identity data with other kinds of events, as well as from a table view of RUA users, you can display the User Identify pop-up window to learn more about a specific user.

The user identity data you see is the same as you would see in the table view of users; for more information, see the RUA Users Fields table on page 1089. The host history provides a graphic representation of the last twenty-four hours of the user’s activity. A list of IP addresses of the hosts that the user logged into approximates login and logout times with bar graphs. A typical user might log on to multiple hosts in the course of a day. For example, periodic automated logins to a mail server would display as multiple short sessions, while longer logins (such as during working hours) display longer sessions. The data used to generate the host history is stored in the RUA history database, which by default stores 10 million user login events. If you do not see any data in the host history for a particular user, either that user is inactive, or you may need to increase the database limit. For more information, see Configuring Database Event Limits on page 1197. To view RUA user details and host history: Access: Data or Admin

h

In any event view that lists RUA users, click the user icon ( next to a user identity.

)that appears

A pop-up window appears, displaying details about and a login history for that user.

Version 4.7


1091


Chapter 25

Searching for RUA Users Requires: DC + RUA

You can search for specific RUA users. You may want to create searches customized for your network environment, then save them to re-use later. The search criteria you can use are described in the RUA Users Search Criteria table. RUA Users Search Criteria Field


User

Enter all or part of the user identity you want to search for. Depending on how the user was discovered, the user is one of: • the first name, last name, and username of the user (for users discovered via the Defense Center-LDAP server connection) • the username only (for users discovered by RUA events)

Version 4.7

Username

Enter the full username of the user you want to search for. This search field is case-insensitive. You can use an asterisk (*) as a wildcard character in this field.

First Name

Enter the full first name of the user you want to search for. This search field is case-insensitive. You can use an asterisk (*) as a wildcard character in this field.

Last Name

Enter the full last name of the user you want to search for. This search field is case-insensitive. You can use an asterisk (*) as a wildcard character in this field.

E-Mail

Enter the full email address of the user you want to search for. This search field is case-insensitive. You can use an asterisk (*) as a wildcard character in this field.

Department

Enter the full department name of the user you want to search for. This search field is case-insensitive. You can use an asterisk (*) as a wildcard character in this field.


1092


Chapter 25

RUA Users Search Criteria (Continued) Field


Phone

Enter the telephone number of the user you want to search for. Note that you must enter the telephone number exactly as it is stored on the LDAP server and thus in the Defense Center database. For example, if you search for 800-555-1212 and the number is stored as (800) 555-1212, you will not get any results. You can, however, use an asterisk (*) as a wildcard character in this field. For example, you could search for *800*555*1212.

Auth Protocol

Enter the protocol used to detect the user you want to search for. Valid search criteria are ldap, pop3, imap, smtp, and aim. Note that although using this search criteria correctly constrain searches for RUA users, the Auth Protocol column does not appear in either table view in the default RUA users workflow, nor in a table view that you add to a custom workflow based on RUA users. To see this field in an event view, you must create a custom workflow, add a drill-down page, and designate Auth Protocol as one of the fields on that page.

For more information on searching, including how to load and delete saved searches, see Searching for Events on page 1124.

Version 4.7


1093


Chapter 25

To search for RUA users: Access: Data or Admin

1.

Select Analysis & Reporting > Searches > Users. The RUA Users search page appears.

TIP! To search the database for a different kind of event, select it from the Table list. 2. Optionally, if you want to save the search, enter a name for the search in the Name field. If you do not enter a name, one is created automatically when you save the search. 3. Enter your search criteria in the appropriate fields, as described in the RUA Users Search Criteria table on page 1092. If you enter multiple criteria, the search returns only the records that match all the criteria. 4. If you want to save the search so that other users can access it, clear the Save As Private check box. Otherwise, leave the check box selected to save the search as private. TIP! If you want to save a search as a restriction for restricted data users, you must save it as a private search.

Version 4.7


1094

Using Real-time User Awareness Working with RUA Events

Chapter 25


Click Search to start the search. Your search results appear in the default RUA users workflow, constrained by the current time range. If you created a custom RUA users workflow and did not specify a preferred workflow, you must select one. For information on specifying a preferred workflow, see Setting Event Preferences on page 35.

•


•


Working with RUA Events Requires: DC + RUA

If you have installed an RUA feature license on your Defense Center, RUA generates events that communicate the details of user activity on your network. There are four types of RUA events, as described in the RUA Event Types table. RUA Event Types Event Name

Description

New User Identity

This event is generated when RUA detects a user login for a user that is not in the database. RUA also generates a New User Identity event for each new user when it populates the database using the Defense Center-LDAP server connection.

User Login

This event is generated when either: • an RUA Agent that you installed on an Active Directory server detects an LDAP login • an RUA detection engine on a 3D Sensor detects an LDAP, POP3, IMAP, SMTP, or AIM login Note that SMTP logins are not recorded unless there is already a user with a matching email address in the database.

Version 4.7


1095


Chapter 25

RUA Event Types (Continued) Event Name

Description

Delete User Identity

This event is generated when you manually delete a user from the Defense Center database.

User Identity Dropped: User Limit Reached

This event is generated when RUA detects a user that is not in the database, but cannot add the user because you have reached the maximum number of users in the database as determined by your RUA feature license. Note that if your license limit is lower than the number of users on your LDAP server, every time the Defense Center synchronizes its database with the LDAP server, RUA will log multiple User Identity Dropped events.

When an RUA event is generated, it is logged to the database. You can view, search, and delete RUA events; you can also purge all RUA events from the database. Whenever possible the Sourcefire 3D System correlates RUA events with other types of events. For example, intrusion events can tell you the users who were logged into the source and destination hosts at the time of the event. This can tell you who owns the host that was targeted by an attack, or who initiated an internal attack or portscan. You can also use RUA events in compliance rules. Based on the type of RUA event generated as well as other criteria that you specify, you can build compliance rules that, when used in a compliance policy, launch remediations and syslog, SNMP, and email alert responses when network traffic meets your criteria. For more information on how you can use RUA events, see How Can You Use RUA? on page 1068. For more information, see the following sections: •

Viewing RUA Events on page 1096

•

Understanding the RUA Events Table on page 1099

•

Searching for RUA Events on page 1100

Viewing RUA Events Requires: DC + RUA

You can view a table of RUA events, and then manipulate the event view depending on the information you are looking for. The page you see when you access RUA events differs depending on the workflow you use. You can use the predefined workflow, which includes the table view of RUA events. You can also create a custom workflow that displays only the information that matches your specific needs. For information on creating a custom workflow, see Creating Custom Workflows on page 1179.

Version 4.7


1096


Chapter 25

The RUA Events Table Functions table below describes some of the specific actions you can perform on an RUA users workflow page. RUA Events Table Functions To...

You can...


find more information in Understanding the RUA Events Table on page 1099.






click the user icon ( )that appears next to the user identity. For more information, see Understanding User Details and Host History on page 1091.

sort user data






Version 4.7


1097


Chapter 25

RUA Events Table Functions (Continued) To...

You can...

delete RUA events from the system

use one of the following methods: • To delete some RUA events, select the check boxes next to the users you want to delete, then click Delete. • To delete all RUA events in the current constrained view, click Delete All, then confirm you want to delete all the users. See Purging the RNA and RUA Databases on page 1232 for information on deleting all RUA events from the database.

Version 4.7











search for RUA events

click Search. For more information, see Searching for RUA Events on page 1100.


1098


Chapter 25

To view RUA events: Access: Data or Admin

h

Select Analysis & Reporting > RUA > RUA Events. The first page of the default RUA events workflow appears. If you created a custom RUA events workflow and did not specify a default, you must first select one. For information on specifying a default workflow, see Setting Event Preferences on page 35. If no events appear, you may need to adjust the time range. See Setting Event Time Constraints on page 1169 for more information. TIP! If you are using a custom workflow that does not include the table view of users, click Workflows. On the Select Workflow page, click RUA Events.

Understanding the RUA Events Table Requires: DC + RUA

When RUA generates an event, it is logged to the database. The fields in the RUA users table are described in the RUA Events Fields table. RUA Events Fields

Version 4.7

Field

Description

Time

The time that RUA generated the event.

Event

The event type. For more information, see the RUA Event Types table on page 1095.

User

The user associated with the RUA event. At a minumum, this field contains a username. If there is LDAP metadata on the user, this field can also contain the first name and last name of the user.

IP Address

For User Login events, the IP address of the host that the user logged into. For other types of RUA events, this field is blank.

Description

For Delete User Identity and User Identity Dropped events, the username of the user who was deleted from the database or failed to be added to the database. For other types of RUA events, this field is blank.


1099


Chapter 25

RUA Events Fields (Continued) Field

Description

Detection Engine

For events generated by an RUA detection engine on a 3D Sensor, the name of the detection engine and the sensor it resides on. For other types of RUA events, Local Detection Engine.

Count


Searching for RUA Events Requires: DC+RUA

You can search for specific RUA users. You may want to create searches customized for your network environment, then save them to re-use later. The search criteria you can use are described in the RUA Events Search Criteria table. RUA Events Search Criteria Field


Event

Enter all or part of the event type you want to search for. For more information, see the RUA Event Types table on page 1095.

IP Address

Specify the IP address of the host for which you want to see User Login events. See Specifying IP Addresses in Searches on page 1130 for detailed information about how to enter IP addresses.

User

Enter all or part of the user identity you want to search for. Depending on how the user was discovered, the user is one of: • the first name, last name, and username of the user (for users discovered via the Defense Center-LDAP server connection) • the username only (for users discovered by RUA events)

Version 4.7


1100


Chapter 25

RUA Events Search Criteria (Continued) Field


Description

Enter the username of a user who was deleted from the database or failed to be added to the database.

Detection Engine

Enter one of: • the name of the RUA detection engine that generated the event or the name of the sensor where that detection engine resides, to search for events generated by that detection engine or by any one of the RUA detection engines on a 3D Sensor • Local Detection Engine, to search for all other types of RUA events See Specifying Detection Engine/Appliance Names on page 1133 for detailed information about how to enter detection engine names.

For more information on searching, including how to load and delete saved searches, see Searching for Events on page 1124. To search for RUA events: Access: Data or Admin

1.

Select Analysis & Reporting > Searches > Events. The RUA Events search page appears.


Version 4.7


1101


Chapter 25

2. Optionally, if you want to save the search, enter a name for the search in the Name field. If you do not enter a name, one is created automatically when you save the search. 3. Enter your search criteria in the appropriate fields, as described in the RUA Events Search Criteria table on page 1100. If you enter multiple criteria, the search returns only the records that match all the criteria. 4. If you want to save the search so that other users can access it, clear the Save As Private check box. Otherwise, leave the check box selected to save the search as private. TIP! If you want to save a search as a restriction for restricted data users, you must save it as a private search. 5. You have the following options: •

Click Search to start the search. Your search results appear in the default RUA events workflow, constrained by the current time range. If you created a custom RUA events workflow and did not specify a preferred workflow, you must select one. For information on specifying a preferred workflow, see Setting Event Preferences on page 35.

Version 4.7

•


•



1102

Chapter 25

Building and Generating Reports

The Sourcefire 3D System provides a flexible reporting system that you can use to generate a variety of event reports. Event reports include data that is similar to the information that you see on the event view pages for each type of event. The Report Types table describes the reports you can create and the components required for producing them. For example, the RNA Events report appears under the RNA platform on the Report Designer page. You must have an RNA host license on the Defense Center managing your 3D Sensor, and you must configure the RNA component for that sensor to collect RNA events. Similarly, the Intrusion Events report appears under the IPS platform and requires the IPS component on a 3D Sensor. You can run the report on the 3D Sensor or on the Defense Center that manages the sensor. Report Types

Version 4.7

Report

Platform

Requires

Intrusion Events with Destination Criticality

IPS or RNA

DC + RNA + IPS

Intrusion Events with Source Criticality

IPS or RNA

DC + RNA + IPS

Intrusion Events

IPS

DC + IPS

SEU Import Log

IPS

DC + IPS

Host Attributes

RNA

DC + RNA


1103

Building and Generating Reports

Chapter 26

Report Types (Continued) Report

Platform

Requires

RNA Hosts

RNA

DC + RNA

Scan Results

RNA

DC + RNA

RNA Client Applications

RNA

DC + RNA

RNA Events

RNA

DC + RNA

RNA Services

RNA

DC + RNA

Vulnerabilities

RNA

DC + RNA

Hosts with Services

RNA

DC + RNA

Flow Data

RNA

DC + RNA

RUA Events

RUA

DC + RUA

Users

RUA

DC + RUA

White List Violations

Compliance

DC + RNA

Compliance Events

Compliance

DC + RNA

White List Events

Compliance

DC + RNA

Remediation Status

Compliance

DC + RNA

Health Events

Health Monitoring

DC

Audit Log Events

Audit Log

Any

See the following sections for information about creating and producing reports.

Version 4.7

•

Creating Reports from Event Views on page 1105 explains how to generate a report for the data that appears on one of the event views.

•

Managing Generated Reports on page 1107 explains the options for viewing, downloading, and deleting previously generated reports.

•

Understanding Report Profiles on page 1109 explains how to create and save report profiles. You can use these profiles for scheduled reports or to make sure that you use the same parameters each time you run a report.


1104

Building and Generating Reports Creating Reports from Event Views

Chapter 26

•

Running Remote Reports on page 1120 explains how to generate reports on managed sensors and view the results on the Defense Center.

•

Understanding Summary Reports on page 1121 describes the kind of information included in each of the summary reports.

•

Adding Logos to the System on page 1122 explains how to add your own corporate logos for use in reports.

Creating Reports from Event Views Requires: DC/MDC or 3D Sensor

You can generate reports on any subset of events in an event view. You can also specify how you want the report formatted: PDF, HTML, or as comma-separated values (CSV). To generate a report for a specific set of events:


1.

Populate an event view with the events you want to include in the report. You can do this several ways: •

Use an event search to define the type of events you want to view. For details on using the event search, see Searching for Events on page 1124.

•

Drill down through a workflow until you have the proper events in your event view. For details on using workflows and constraining events within a workflow, see Understanding and Using Workflows on page 1147.

TIP! In addition to generating reports in an event view, as described in this section, you can also create a report profile and then either use it to generate a report or save it to use later. For more information, see Understanding Report Profiles on page 1109.

Version 4.7


1105

Building and Generating Reports Creating Reports from Event Views

Chapter 26

2. Click Report Designer in the toolbar. The Report Designer page appears. The settings on the page reflect the parameters that you selected for the search or through the drill-down pages. The following graphic shows the Defense Center version of the page.

TIP! If you need to go back to the drill-down page where you opened the Report Designer, click Return to Calling Page at the bottom of the Report Designer page. 3. Change any of the parameters as necessary to meet your needs. For details on the parameters for a report, see Building a Report Profile on page 1112. 4. Select the check boxes next to the output options you want in the report: PDF, HTML, or CSV.

Version 4.7


1106

Building and Generating Reports Managing Generated Reports

Chapter 26

5. Click Generate Report. 6. Click OK to confirm that you want to save the current parameters as a report profile. The report profile is saved and the report generates in the output formats you selected. To view the report, you have two options:

7.

•

Click Reports in the toolbar and click View next to the report name.

•

Select Analysis & Reporting > Reporting and click View next to the report name.

In either case, the report appears.

Managing Generated Reports Requires: DC/MDC or 3D Sensor

You can view, download, or delete reports that you previously generated. For more information, see the following topics: •

Viewing Generated Reports on page 1107

•

Downloading Generated Reports on page 1108

•

Deleting Generated Reports on page 1108

Viewing Generated Reports Requires: DC/MDC or 3D Sensor

Version 4.7

The Reporting page lists the previously generated reports. Each report is listed with the report name as defined in the report profile plus the date and time the report was generated. Each report also has one of the following file extensions appended to the report name: •

.csv for comma-separated value reports

•

.pdf for PDF reports

•

.zip for HTML reports


1107

Building and Generating Reports Managing Generated Reports

Chapter 26

To view generated reports: Access: Data or Admin

1.

Select Analysis & Reporting > Reporting. The Reporting page appears.

2. Click View next to the report you want to view. The report opens. TIP! You can also click Download to save the report locally. For more information, see Downloading Generated Reports on page 1108.

Downloading Generated Reports Requires: DC/MDC or 3D Sensor Access: Data or Admin

You can download a copy of a generated report. To download a generated report: 1.


2. Click Download next to the report you want to download.

Deleting Generated Reports Requires: DC/MDC or 3D Sensor Access: Data or Admin

Use the following procedure to delete a generated report. To delete a generated report: 1.


2. Click Delete next to the report you want to delete. The report is deleted.

Version 4.7


1108

Building and Generating Reports Understanding Report Profiles

Chapter 26

Understanding Report Profiles Requires: DC/MDC or 3D Sensor

A report profile is a template that governs the structure of a report and the kinds of information it contains. You can create and save your own custom report profiles, or use the predefined report profiles as a template for an event report. You can modify and use a custom report profile or a predefined report profile in the same way. See the following sections for more information: •

Understanding the Predefined Report Profiles on page 1109

•

Building a Report Profile on page 1112

•

Using a Report Profile on page 1116

•

Deleting Report Profiles on page 1119

Understanding the Predefined Report Profiles Requires: DC/MDC or 3D Sensor

A predefined report profile provide you with predefined settings for event reports. As with custom report profiles that you create (see Building a Report Profile on page 1112), you can use a predefined report profile as a template for an event report. You can modify field settings as appropriate, save the report with the new values, and run the report manually or automatically. You can use the Blocked Events report profile on the Defense Center or on a 3D Sensor with IPS to generate a report on blocked intrusion events for all detection engines for the past twenty-four hours. Default Settings for the Blocked Events Report Profile Field

Setting

Platform

IPS

Report Type

Intrusion Events

Detection Engine

All

Search Query

Blocked Events

Workflow

Impact and Priority (on the Defense Center) Destination Port (on the 3D Sensor)

Version 4.7

Use Relative Time

Enabled, Previous 1 day(s)

Add Summary Report

Quick


1109


Chapter 26

Default Settings for the Blocked Events Report Profile (Continued) Field

Setting

Impact Based Event Summary (on the Defense Center)

Enabled

Drill Down of Source and Destination IPs (on the Defense Center)

Enabled

Drill Down of Destination Port (on the 3D Sensor)

Enabled

Drill Down of Events (on the 3D Sensor)

Enabled

Table View of Events

Disabled

Packets (limit 50 pages)

Disabled

The High Priority Events report profile provides information on intrusion events as well as the host criticality of hosts involved in the intrusion events for the past twenty-four hours. This report profile is available only on a Defense Center that manages 3D Sensors with RNA and IPS. Default Settings for the High Priority Events Report Profile

Version 4.7

Field

Setting

Platform

IPS

Report Type


Detection Engine

All

Search Query

High Priority Events

Workflow

Events by Impact, Priority, and Host Criticality

Use Relative Time

Enabled, Previous 1 day(s)

Add Summary Report

Quick

Impact to Criticality Summary

Enabled

Source Destination Drill Down

Enabled


1110


Chapter 26

Default Settings for the High Priority Events Report Profile (Continued) Field

Setting


Enabled


Disabled

The Host Audit report profile provides operating system details for the past week on systems less than two network hops away from 3D Sensors with RNA. This report profile is available only on the Defense Center that manages 3D Sensors with RNA. Default Settings for the Host Audit Report Profile

Version 4.7

Field

Setting

Platform

RNA

Report Type

RNA Hosts

Detection Engine

All

Search Query

Local Systems

Workflow

Operating System Summary

Use Relative Time

Enabled, 1 week(s)

Add Summary Report

summary

Summary of OS Names

Enabled

Summary of OS Versions

Enabled

OS Details with IP, NetBIOS, Criticality

Enabled

Table View of Events

Disabled


Disabled


1111


Chapter 26

Building a Report Profile Requires: DC/MDC or 3D Sensor

You can use the report designer to create and save custom report profiles. You can then manually run these reports or schedule them to run automatically (for information about scheduling tasks, see Scheduling Tasks on page 1299). You can define a variety of attributes for any report you want to run, including adding a company logo, defining the set of events that appear in the report, and selecting the amount of detail contained in the report. Additionally, you can output the report as an HTML file, a PDF file, or a comma-separated values (CSV) file. To define a report profile:


Version 4.7

1.



1112


Chapter 26

2. Click Create Report. The Report Designer page appears. The following graphic shows the Defense Center version of the page.

TIP! You can also reach the Report Designer page by clicking the Report Designer toolbar button on any event view. 3. In the Report Name field, type a name for the report using 1 - 80 alphanumeric characters, periods, dashes, and spaces. 4. From the Platform drop-down list, select the platform for which you want to create a report. You can choose from:

Version 4.7

•

IPS (with an IPS license)

•

RNA (on a Defense Center with an RNA host license)


1113


Chapter 26

•

RUA (on a Defense Center with an RUA host license)

•

Compliance (on a Defense Center with an RNA host license)

•

Health Monitoring (on a Defense Center)

•

Audit Log

5. From the Report Type drop-down list, select the type of report you want to create. 6. Optionally, if the report type you selected includes the Detection Engine option, select a specific Detection Engine on which to report. 7.

Requires: DC Optionally, if you are reporting on health events, select a specific sensor or sensor group from the Sensor drop-down list.

8. From the Search Query drop-down list, either use the Use Current Query option (which retains any query parameters you specified on the search page or event page) or select one of the existing search queries. Note that if you did not previously specify a search query, the Use Current Query option places no constraints on the events. 9. From the Workflows list, select the workflow you want to use to build the report. For information on workflows, see Understanding and Using Workflows on page 1147. The Report Sections area is populated based on the workflow you selected. Select the check box for each report section you want to include in the report. Reports can include up to 10,000 records for each report section you select. 10. Specify the time range for the report. The default time range matches the time range displayed on the event views.

Version 4.7

•

You can change the start and end times by clicking either time and using the Date/Time pop-up window to select a new time range.

•

You can select the Use Relative Time check box and select one of the relative time options: minute, hour, day, week, month, or year. For example, to include events from the past two hours, type 2 and select hour(s) from the list.


1114


Chapter 26

11. If a summary is available for the report type you selected, specify whether you want to include it as part of your report. •

To include a summary with intrusion event-based reports, select quick or detailed. For a full description of the information provided in Quick and Detailed summaries, see Understanding Summary Reports on page 1121.

•

On a Defense Center with an RNA host license, to include a summary with an RNA-based report, select summary. For a full description of the information provided in the RNA summary, see Understanding Summary Reports on page 1121.

•

To exclude the summary, select none, which is the default.

12. If you want to include an image in the report, type the path to the image in the Include Image File text box, or navigate to a JPEG, PNG, or TIFF file. 13. Select the check boxes next to the sections of the workflow you want to include in the report. The options in this section depend on the workflow you selected in step 9. TIP! Note that if you select a table view of events, the report is limited to 10,000 records as noted in step 9, regardless of the number of events. 14. Select the check boxes next to one or more output options for your report: PDF, HTML, or CSV. 15. Optionally, for PDF and HTML reports, select a logo from the list of image files that were previously added to the system. See Adding Logos to the System on page 1122 for information about how to make more logos available to the report designer. 16. Optionally, for PDF and HTML reports, type a description in the Description field. You can use alphanumeric characters and spaces. The description appears in the report header. 17. Optionally, for PDF reports, type the text you want to include as the footer in the Custom Footer field. You can use 1 - 80 alphanumeric characters and spaces.

Version 4.7


1115


Chapter 26

18. Optionally, you can specify that reports are automatically emailed after they are generated. To email a report, type one or more email addresses in a comma-separated list in the Email to field. IMPORTANT! You must make sure that the mail host is identified: Click Not available. You must set up your mail relay host. The System Policy page appears. Click Edit in the row for the system policy you want to modify. Click Email Notification. Type the name of your mail server in the Mail Relay Host field and click Save. Click Apply in the row for the system policy you changed and apply it to the appliance. The report is emailed from host_name@domain_name, where host_name is the host name of the appliance and domain_name is the name of the domain where you deployed the appliance. 19. You have the following options: •

To save the report profile, click Save Report. When prompted, follow the instructions for your browser to save the report profile. The report profile is saved with the name you specified in the Report Name field.

•

To generate the report and save the report profile, click Generate Report. When prompted, follow the instructions for your browser to generate the report and save the report profile.

•

To see a PDF preview of your report, click Preview Report. When prompted, follow the instructions for your browser to display a PDF version of the report in the browser window.

•

On a Defense Center, to generate the report remotely, select the sensor where you want to run the report and click Run Remote Report. When prompted, follow the instructions for your browser to generate the report and save the report profile.

IMPORTANT! The PDF, HTML, and CSV selections for Output Options apply to generated reports, not to report previews. When you click Preview Report, you see a PDF version of the report.

Using a Report Profile Requires: DC/MDC or 3D Sensor

You can use report profiles to generate reports that contain the information that is important to you and your evaluation of the events generated for your network. If you want to generate a report for a specific set of events or a specific time period, populate the event view with the events you want to see in your report

Version 4.7


1116


Chapter 26

before opening the report designer. For details on using the event view, see the following sections: •

Viewing RNA Network Discovery and Host Input Events on page 225

•

Viewing Hosts on page 232

•

Viewing Services on page 251

•

Viewing Client Applications on page 262

•


•

Working with Intrusion Events on page 651

To generate a report using a report profile: Access: Data or Admin

1.


2. Click Report Profiles in the toolbar. The Report Profiles page appears.

Version 4.7


1117


Chapter 26

3. Click the name of the report profile you want to use. The Report Designer page loads the parameters defined for that selected report. The following graphic shows the Defense Center version of the page.

4. If necessary, change the time range to include the events you want in your report. 5. Click Generate Report. The system generates the report.

Version 4.7


1118


Chapter 26

6. Click Reports in the toolbar to display the Reporting page. The Reporting page appears.

The Reporting page displays a list of the previously generated reports:

7.

•

The Status column indicates the report name and the number of events requested.

•

The Time Requested column indicates when the report was requested.

•

The Time Completed column indicates when the report was completed.

•

The User column indicates which user requested the report.

•

The Info column indicates the status of the report.

Click View next to the report you generated. The report appears in the browser window. TIP! You can also download reports by clicking Download next to the report name. For more information, see Downloading Generated Reports on page 1108.

Deleting Report Profiles Requires: DC/MDC or 3D Sensor Access: Data or Admin

Use the following procedure to delete a report profile. To delete a report profile: 1.


2. Click Report Profiles. The Report Profiles page appears. 3. Click Delete next to the profile that you want to delete. The report profile is deleted from the list.

Version 4.7


1119

Building and Generating Reports Running Remote Reports

Chapter 26

Running Remote Reports Requires: DC + 3D Sensor

If you use a Defense Center to manage your sensors, you have the option of running reports remotely from the Defense Center using the data on the sensors. For example, if you use your Defense Center to manage a 3D Sensor with IPS, and you store IPS data on the sensor in addition to sending it automatically to the Defense Center, you can run the report on the data that is resident on the sensor. There are several limitations that you need to keep in mind: •

If you do not store data on the sensor, then the remote report will be empty.

•

If your report uses a logo or image file, it must exist on both the Defense Center and the managed sensor where you run the report.

•

You cannot run incident reports remotely on managed 3D Sensors with IPS.

IMPORTANT!

You cannot run remote reports on Sourcefire Sensors on Nokia.

To run a remote report: Access: Data or Admin

1.


2. Click Create Report. The Report Designer page appears. 3. Create the report that you want to run on the managed sensor. See Creating Reports from Event Views on page 1105 for details. 4. At the bottom of the page, select the sensor where you want to run the report and click Run Remote Report. A prompt appears asking you to confirm that you want to run the report remotely. 5. Click OK. The report is run on the sensor that you selected. 6. In the toolbar, click Reports. The Reporting page appears, listing the report you just generated on the managed sensor. Note that remote- is prepended to the name of the report. 7.

You can view or download the remote report as you would with any other locally generated report. TIP! You can also use report profiles as the basis for remote reports by creating a profile as described in Building a Report Profile on page 1112. When you run the report, make sure you select the name of the sensor and click Run Report Remotely.

Version 4.7


1120

Building and Generating Reports Understanding Summary Reports

Chapter 26

Understanding Summary Reports Requires: DC/MDC or 3D Sensor

Depending on the components you are licensed to use in your Sourcefire 3D System deployment, you can include summary reports for intrusion events and RNA events. You can append these summary reports to the beginning of any report by selecting the appropriate radio button in the report profile. Intrusion event reports require the IPS component. If your deployment includes IPS, you can include either a Quick Summary or a Detail Summary report in your report profile definition. Quick Summary reports contain the following: •

a pie chart showing the percentage of events in each event type (which maps to the rule category for the rule that generated the event)

•

the ten most active and ten least active events

•

a graph showing the number of events over time

•

pie charts showing the percentage of events by protocol (for example, TCP, UDP, or ICMP) and event classification (which maps to the value for the classtype keyword in the rule that generated the event)

•

tables listing the 50 most active and least active events

•

tables listing the 50 most active source and destination ports

•

tables listing the 25 most active source and destination IP addresses and IP address combinations.

Detailed Summary Reports contain the following:

Version 4.7

•

a pie chart showing the percentage of events in each event type (which maps to the rule category for the rule that generated the event)

•

the ten most active and ten least active events

•

a graph showing the number of events over time

•

pie charts showing the percentage of events by protocol (for example, TCP, UDP, or ICMP) and event classification (which maps to the value for the classtype keyword in the rule that generated the event)

•

tables listing the 50 most and least active events

•

tables listing the 50 most active source and destination ports

•

tables listing the most active events for each of the 25 most active destination ports

•

tables listing the 25 most active source and destination IP addresses as well as the 25 most active source and destination IP combinations


1121

Building and Generating Reports Adding Logos to the System

Chapter 26

•

tables listing the most active events for each of the 25 most active destination IP addresses

•

tables listing the most active events for the 25 most active source/destination IP address combinations

IMPORTANT! On the Defense Center, the report includes summary information for all the managed 3D Sensors with IPS that you include in the report. RNA-related event reports require the RNA component. If your deployment includes 3D Sensors with RNA and a Defense Center that manages the sensors, you can add the RNA Summary to RNA event, host, client application, service, and flow data reports. The RNA Summary includes: •

RNA event statistics including total number of events, events in the last day and hour, total services, total hosts, total routers, total bridges, and host limit usage

•

a list of events divided by event type with counts for the last hour and total number within the report range

•

pie charts showing the percentage of events by protocol (for example, TCP, UDP, or ICMP), service, and operating system

Adding Logos to the System Requires: DC/MDC or 3D Sensor

You can add custom logos for use in your PDF and HTML reports. IMPORTANT! If a remote report uses a logo or image file, it must exist on both the Defense Center and the managed sensor where you run the report. To make logos available for use:


1.


2. Click Report Profiles in the toolbar. The Report Profiles page appears. 3. Next to the report profile you want to use, click Edit. The Report Designer page appears, populated with the parameters defined for that selected report.

Version 4.7


1122

Building and Generating Reports Adding Logos to the System

Chapter 26

4. In the Report Options section, click Edit/Add Logos. The Logos pop-up window appears.


To use a logo that you have already loaded, select a file from the drop down list of logos saved on the appliance.

•

To use a new logo, click Browse to browse to the logo you want to use.

You can use JPEG, PNG, and TIFF files as logos, but only JPEG and PNG graphics are supported in most browsers. 6. In the Title Text and Sub-Title Text fields, type text you want to appear with the logo as a report title and subtitle:

7.

•

Titles may contain up to 64 characters, and subtitles may contain up to 128 characters.

•

To include the model of the appliance where the report was generated, type %model.

•

To include the version number of the appliance where the report was generated, type %version.

Click Save. The logo is saved and becomes available in the report designer.

8. Click Done to close the pop-up window and return to the Report Designer page.

Version 4.7


1123

Chapter 26

Searching for Events

Sourcefire 3D Sensors and Defense Centers generate information that is stored as events in database tables. Events contain multiple fields that describe the activity that caused the appliance to generate the event. The Sourcefire 3D System provides predefined searches that serve as examples and can provide quick access to important information about your network. You can modify fields within the predefined searches for your network environment, then save the searches to re-use later. You can also create your own search criteria. TIP! On the Defense Center, you can search both predefined and custom tables for specific events or other data. The search criteria you can use depends on the type of search, but the mechanics are the same. See the following sections for more information on how to perform a search and on the correct syntax to use in search fields.

Version 4.7

•

Performing and Saving Searches on page 1125

•

Using Wildcards and Symbols in Searches on page 1129

•

Specifying Time Constraints in Searches on page 1130

•

Specifying IP Addresses in Searches on page 1130

•

Specifying Ports in Searches on page 1132

•

Specifying Detection Engine/Appliance Names on page 1133


1124

Searching for Events Performing and Saving Searches

Chapter 27

Performing and Saving Searches Requires: IPS or DC/MDC

You can create and save searches for any of the different event types. When you create a search you give it a name and specify whether the search will be available to you alone or to all users on the appliance. For more information, see the following sections: •

Performing a Search on page 1125 explains how to perform a search and, optionally, save it.

•

Loading a Saved Search on page 1128 explains how to load a previouslysaved search.

•

Deleting a Saved Search on page 1129 explains how to delete a previouslysaved search.

IMPORTANT! To search a custom table on the Defense Center, you follow a slightly different procedure. For more information, see Searching Custom Tables on page 1144.

Performing a Search Requires: IPS or DC/MDC

Version 4.7

For some event types, the Sourcefire 3D System provides predefined searches that serve as examples and can provide quick access to important information about your network. You can modify fields within the predefined searches for your network environment, then save the searches to re-use later. You can also create your own search criteria. For more information, see Loading a Saved Search on page 1128.


1125


Chapter 27

To perform a search: Access: Data or Admin

1.

Select Analysis & Reporting > Searches, then select the type of event or data you want to search for. The Search page appears. The following graphic shows the search page for the audit log.

TIP! To search the database for a different kind of event or data, select it from the Table list. 2. Optionally, if you want to save the search, enter a name for it in the Name field. If you do not enter a name, a name is created automatically when you save the search.

Version 4.7


1126


Chapter 27

3. Enter your search criteria in the appropriate fields. If you enter multiple criteria, the search returns only the records that match all the criteria. See the sections listed in the following table for detailed information on the search criteria you can use.

Version 4.7

Under these conditions...

For search criteria for...

See...

Requires: IPS or DC/MDC + IPS

Intrusion Events

Searching for Intrusion Events on page 689

Requires: DC + RNA

RNA Events


Requires: DC + RNA

Hosts

Searching for Hosts on page 239

Requires: DC + RNA

Host Attributes

Searching for Host Attributes on page 248

Requires: DC + RNA

Services


Requires: DC + RNA

Client Applications

Searching for Client Applications on page 265

Requires: DC + RNA

Flow Data


Requires: DC + RNA

Vulnerabilities


Requires: DC/MDC + RNA

Compliance Events


Requires: DC/MDC + RNA

White List Events


Requires: DC + RNA



Requires: DC + RNA

Remediation Status Events


Requires: IPS or DC/MDC + IPS

SEU Import Log

Searching the SEU Import Log on page 842

Requires: IPS or DC/MDC

Audit Log Events

Searching Audit Records on page 1426


1127


Chapter 27

Under these conditions...

For search criteria for...

See...

Requires: DC/MDC

Health Events

Searching for Health Events on page 1410

Requires: DC + RNA

Scan Results

Searching for Scan Results on page 627

Requires: DC + RUA

Users


Requires: DC + RUA

RUA Events


4. If you want to save the search so that other users can access it, clear the Save As Private check box. Otherwise, leave the check box selected to save the search as private. TIP! If you want to save a search as a restriction for restricted data users, you must save it as a private search. 5. You have the following options: •

Click Search to start the search. Your search results appear in your preferred workflow. If multiple workflows exist and you did not specify a preferred workflow, you must select one. For more information on how to specify a preferred workflow, see Setting Event Preferences on page 35.

•


•

Click Save As New Search to save the search criteria. The search is saved (and associated with your user account if you selected Save As Private), so that you can run it at a later time.

Loading a Saved Search Requires: IPS or DC/MDC

Version 4.7

If you previously saved a search, you can load it, make any necessary modifications, and then start the search.


1128

Searching for Events Using Wildcards and Symbols in Searches

Chapter 27

To load a saved search: Access: Data or Admin

1.


From any page on a workflow, click Search.

•

Select Analysis & Reporting > Searches, then select the type of events you want to search for.

The Search page appears. 2. From the list of saved searches on the left of the page, select the search you want to load and click Load. Data from the saved search populates the search constraints fields. 3. Optionally, change the search constraints. 4. Click Search. The appliance displays the events that match your search constraints.

Deleting a Saved Search Requires: IPS or DC/MDC

If you have saved searches, you can delete them from the Search page.


1.

To delete a saved search: You have two options: •

From any page on a workflow, click Search.

•

Select Analysis & Reporting > Searches, then select the type of events you want to search for.

The Search page appears. 2. From the list of saved searches, select the search you want to delete and click Delete. The search is deleted.

Using Wildcards and Symbols in Searches Requires: IPS or DC/MDC

Many text fields on search pages allow you to use an asterisk (*) to match characters in a string. For example, specifying net* matches network, netware, netscape, and so on. If you want to search for non-alphanumeric characters (including the asterisk character), enclose the search string in quotation marks. For example, to search for the string: Find an asterisk (*)

enter: “Find an asterisk (*)”

Version 4.7


1129

Searching for Events Specifying Time Constraints in Searches

Chapter 27

Note that in text fields that allow a wildcard, you must use the wildcard if you want to match a partial string. For example, if you are searching the audit log for all audit records that involve page views (that is, the message is Page View), searching for Page returns no results. Instead, specify Page*.

Specifying Time Constraints in Searches Requires: IPS or DC/MDC

You can use a number of formats for specifying time search constraints. You can enter a time you want to match, and optionally, a less than () operator to match times before or after the time you enter. The formats accepted by search criteria fields that take a time value are shown in the Time Specification in Search Fields table. Time Specification in Search Fields Time Formats

Example

today [at HH:MMam|pm]

today

today at 12:45pm YYYY-MM-DD HH:MM:SS

2006-03-22 14:22:59

You can precede a time value with one of the following operators/keyword. Time Specification Operators Operator

Example

Explanation

> today at 2:45pm

Returns events with a timestamp later than today at 2:45pm.

Specifying IP Addresses in Searches Requires: IPS or DC/MDC

Version 4.7

When specifying IP addresses in searches, you can enter an individual IP address, a list of IP addresses, or a range of IP addresses for the search value. IP address ranges can be defined with a starting and ending address or with CIDR (Classless


1130

Searching for Events Specifying IP Addresses in Searches

Chapter 27

Inter-Domain Routing) notation. You can also use negation. The following table contains examples of valid ways to enter an IP address. Acceptable IP Address Syntax Example

Description

192.168.1.1

Specifies only the 192.168.1.1 IP address.

192.168.1.1,192.168.1.2

Specifies both 192.168.1.1 and 192.168.1.2. Do not add a space before or after the comma.

192.168.1.0/24

Specifies any IP in the 192.168.1.x range with a subnet mask of 255.255.255.0.

192.168.1.1-192.168.1.5

Specifies any IP between 192.168.1.1 and 192.168.1.5. Do not add a space before or after the hyphen.

!192.168.1.10

Specifies all IPs except 192.168.1.10.

local

Requires: DC/MDC + RNA Specifies all IPs in the networks you are monitoring with RNA.

remote

Requires: DC/MDC + RNA Specifies all IPs that are not in the networks you are monitoring with RNA.

Specifying Subnets with CIDR Notation Requires: IPS or DC/MDC

CIDR notation uses a network IP address combined with a value that signifies a subnet mask to define network and host bits in an IP address range. For example, if you want to define the network described by 192.168.1.x with a subnet mask of 255.255.255.0, you would use 192.168.1.0/24, where 24 signifies the number of bits in the subnet mask. The following table displays a list of CIDR bit mask values for Class B and C networks, with the corresponding subnet mask. CIDR Notation Syntax

Version 4.7

Mask Bits

Subnet Mask

Number of IPs

/14

255.252.0.0

262,144

/15

255.254.0.0

131,072

/16

255.255.0.0

65,536

/17

255.255.128.0

32,768


1131

Searching for Events Specifying Ports in Searches

Chapter 27

CIDR Notation Syntax (Continued) Mask Bits

Subnet Mask

Number of IPs

/18

255.255.192.0

16,384

/19

255.255.224.0

8192

/20

255.255.240.0

4096

/21

255.255.248.0

2048

/22

255.255.252.0

1024

/23

255.255.254.0

512

/24

255.255.255.0

256

/25

255.255.255.128

128

/26

255.255.255.192

64

/27

255.255.255.224

32

/28

255.255.255.240

16

/29

255.255.255.248

8

/30

255.255.255.252

4

/31

255.255.255.254

2

Specifying Ports in Searches Requires: IPS or DC/MDC

Version 4.7

The Sourcefire 3D System accepts specific syntax for port numbers in searches. You can enter: •

a single port number

•

a comma-separated list of port numbers

•

two port numbers separated by a dash to represent a range of port numbers


1132

Searching for Events Specifying Detection Engine/Appliance Names

Chapter 27

•

a port number followed by a protocol abbreviation, separated by a forward slash (only when searching for intrusion events)

•

a port number or range of port numbers preceded by an exclamation mark to indicate a negation of the specified ports

IMPORTANT!

Do not use spaces when specifying port numbers or ranges.

The Port Syntax table contains examples of valid ways to enter ports as search constraints. Port Syntax Example

Description

21

Returns all events on port 21, including TCP and UDP events.

!23

Returns all events except those on port 23.

25/tcp

Requires: IPS or DC/MDC + IPS Returns all TCP-related intrusion events on port 25.

21/tcp,25/tc p

Requires: IPS or DC/MDC + IPS Returns all TCP-related intrusion events on ports 21 and 25

21-25

Returns all events on ports 21 through 25.

Specifying Detection Engine/Appliance Names Requires: IPS or DC/MDC

Your Sourcefire 3D System uses a specific syntax for detection engines, group names, and appliance names in an event search. If you enter a string in the Detection Engine field, the search is conducted in the following order for: •

an event detected by a detection engine with that name

•

an event detected by a detection engine that belongs to a detection engine group with that name

•

Requires: DC an event detected by a 3D Sensor with that name

•

Requires: DC an event detected by a 3D Sensor that belongs to a sensor group with that name

That is, if there is a detection engine whose name matches the string you entered, the search does not use detection engine groups, sensors, or sensor groups with that name as a search criterion. Note that the context for detection engine group searches is local. For example, assume that you create two detection engine groups on a 3D Sensor and name them apple and orange. Next you create two detection engine groups on the

Version 4.7


1133


Chapter 27

sensor’s managing Defense Center and name them horse and lion. If you conduct a search based on detection engine groups on the Defense Center, it will not return any results for a search that includes apple or orange. A search on the Defense Center will only return results for a search that uses horse or lion (assuming there are valid results that can be returned). WARNING! On a 3D Sensor with IPS, if you search using a term that does not match any detection engines, you retrieve all events on the sensor. This occurs because a standalone sensor does not have a sensor name, and the search engine defaults to returning all events in case the supplied search term was intended as a sensor name. If you need to refine your search further, use the following syntax: DE_name:DE_group

For example: Default*:DE_GROUP_1

Requires: DC You can use the detection engine name, the sensor name and sensor group: DE_name:DE_group/sensor_name:sensor_group

For example: Default*:DE_GROUP_1/Sensor13:NOC4_Sensors

This syntax allows you to search for events detected by a detection engine whose name starts with Default, that is in the detection engine group DE_GROUP_1, which is on the sensor Sensor13 which is in the sensor group NOC4_Sensors. Keep in mind that you do not have to use all the parameters. For example: *:DE GROUP 1/*

searches for events detected by any detection engine in the detection engine group DE_GROUP_1. As another example: Primary:*/*:NOC4_Sensors

searches for events detected by detection engines named called Primary that exist on sensors in the NOC4_Sensors group. Requires: MDC You can use the detection engine name, the sensor name, the Defense Center (or appliance) name and the Defense Center (or appliance) group name: DE_name:DE_group/sensor_name:sensor_group/app_name:app_grou p

For example: Default*:DE_GROUP_1/Sensor13:NOC4_Sensors/DC_Alpha:NOC_DCs

Version 4.7


1134


Chapter 27

This syntax allows you to search for events detected by a detection engine whose name starts with Default, that is in the detection engine group DE_GROUP_1, which is on the sensor Sensor13 which is in the sensor group NOC4_Sensors connected to Defense Center Alpha in the Defense Center group NOC_DCs. Keep in mind that you do not have to use all the parameters. For example: Active:*/*:NOC_DCs

searches for events detected by detection engines named called Active that exist on sensors connected to Defense Centers in the NOC_DCs group.

Version 4.7


1135

Chapter 27

Using Custom Tables

As 3D Sensors with RNA collect information about your network and send the information to the Defense Center that manages them, the Defense Center stores the information in a series of database tables. When you use a workflow to view the resulting information, the Defense Center pulls the data from one of these tables. For example, the columns on each page of the Network Services by Count workflow are taken from the fields in the RNA Services table. If you determine that your analysis of the activity on your network would be enhanced by combining fields from different tables, you can create a custom table. For example, you could combine the host criticality information from the predefined Host Attributes table with the fields from the predefined RNA Flow Data table and then examine flow data in a new context. IMPORTANT! You must use a Defense Center with an RNA host license to work with custom tables. You cannot view custom tables on a Master Defense Center. Note that you can create custom workflows for either predefined or custom tables. For more information on creating custom workflows, see Creating Custom Workflows on page 1179. The following sections describe how to create and use your own custom tables.

Version 4.7

•

Understanding Custom Tables on page 1137

•

Creating a Custom Table on page 1140

•

Modifying a Custom Table on page 1142

•

Deleting a Custom Table on page 1143


1136

Using Custom Tables Understanding Custom Tables

Chapter 28

•

Viewing a Workflow Based on a Custom Table on page 1143

•

Searching Custom Tables on page 1144

Understanding Custom Tables Requires: DC + RNA

Custom tables contain fields from two or more of the predefined tables. The Sourcefire 3D System is delivered with a number of Sourcefire-defined custom tables, but you can create additional custom tables that contain only the information that matches your specific needs. For example, the Sourcefire 3D System is delivered with Sourcefire-defined custom tables that correlate intrusion event data with RNA host data so that, if your Defense Center is managing sensors with both RNA and IPS, you can search for events that impact critical systems and view the results of that search in one workflow. The Sourcefire-defined Custom Tables table describes the custom tables provided with the system. Sourcefire-defined Custom Tables Table

Description

Requires: DC + IPS + RNA Intrusion Events with Destination Criticality

Includes fields from the Intrusion Events table and the RNA Hosts table, providing you with information on the intrusion events generated by IPS, as well as the host criticality of the destination host involved in each intrusion event. TIP! Use this table to search for intrusion events involving destination hosts with high host criticality.

Requires: DC + IPS + RNA Intrusion Events with Source Criticality

Includes fields from the Intrusion Events table and the RNA Hosts table, providing you with information on the intrusion events generated by IPS, as well as the host criticality of the source host involved in each intrusion event. TIP! Use this table to search for intrusion events involving source hosts with high host criticality.

Hosts with Services

Includes fields from the RNA Hosts and RNA Services tables, providing you with information about the detected services running on your network, as well as basic operating system information about the hosts running those services.

Understanding Possible Table Combinations Requires: DC + RNA

Version 4.7

When creating a custom table, you can combine fields from predefined tables that have related data. The Custom Table Combinations table lists the predefined


1137


Chapter 28

tables you can combine to create a new custom table. Keep in mind that you can create a custom table that combines fields from more than two predefined custom tables. Custom Table Combinations You can combine fields from... Compliance Events

With fields from... • Host Attributes • RNA Hosts

Requires: DC + IPS + RNA Intrusion Events

• Host Attributes • RNA Hosts • RNA Services

Flow Summary Data


Host Attributes

• Compliance Events • Requires: DC + IPS + RNA Intrusion Events • Flow Summary Data • RNA Client Applications • RNA Events • Flow Data • RNA Hosts • RNA Services • White List Events

RNA Client Applications

• Host Attributes • RNA Hosts

RNA Events


Flow Data


Version 4.7


1138


Chapter 28

Custom Table Combinations (Continued) You can combine fields from... RNA Hosts

With fields from... • Compliance Events • Requires: DC + IPS + RNA Intrusion Events • Flow Summary Data • Host Attributes • RNA Client Applications • RNA Events • Flow Data • RNA Services • White List Events

RNA Services

• Requires: DC + IPS + RNA Intrusion Events • Host Attributes • RNA Flow Data • RNA Hosts

White List Events


Sometimes a field in one table maps to more than one field in another table. For example, the predefined Intrusion Events with Destination Criticality custom table combines fields from the Intrusion Events table and the RNA Hosts table. Each event in the Intrusion Events table has two IP addresses associated with it—a source IP address and a destination IP address. However, the “events” in the RNA Hosts table each represent a single host with a single IP address. Therefore, when you create a custom table based on the Intrusion Events table and the RNA Hosts table, you must choose whether the data you are displaying from the RNA Hosts table applies to the host with the source IP address or the destination IP address in the Intrusion Events table. When you create a new custom table, a default workflow that displays all the columns in the table is automatically created. Also, just as with predefined tables, you can search custom tables for data that you want to use in your network analysis. You can also generate reports based on custom tables, as you can with predefined tables. For more information on creating custom tables, see:

Version 4.7

•

Creating a Custom Table on page 1140

•

Modifying a Custom Table on page 1142

•

Deleting a Custom Table on page 1143


1139

Using Custom Tables Creating a Custom Table

Chapter 28

•

Viewing a Workflow Based on a Custom Table on page 1143

•

Searching Custom Tables on page 1144

Creating a Custom Table Requires: DC + RNA

To create a custom table, decide which predefined tables delivered with the Sourcefire 3D System contain the fields you want to include in your custom table. You can then choose which fields you want to include and, if necessary, configure field mappings for any common fields. For example, consider a custom table that combines fields from the Compliance Events table and the RNA Hosts table. You can use this custom table to get detailed information about the hosts involved in violations to any of your compliance policies. Note that you need to decide whether to display data from the RNA Hosts table that matches the source IP address or the destination IP address in the Compliance Events table.

111

If you view the table view of events for this custom table, it displays compliance events, one per row. The following information is included:

Version 4.7

•

The date and time the event was generated

•

the name of the compliance policy that was violated

•

name of the rule that triggered the violation

•

the IP address of the source, or initiating, host involved in the compliance event

•

the source host’s NetBIOS name


1140

Using Custom Tables Creating a Custom Table

Chapter 28

•

the operating system and version the source host is running

•

the source host criticality

TIP! You could create a similar custom table that displays the same information for destination, or responding, hosts. To build the custom table in the previous example: Access: Data or Admin

1.

Select Analysis & Reporting > Custom Tables. The Custom Tables page appears.

2. Click Create Custom Table. The Create Custom Table page appears.

3. In the Name field, type a name for the custom table, such as Compliance Events with Host Information (Src IP). 4. From the Tables drop-down list, select Compliance Events. The fields in the Compliance Events table appear in the Fields list. 5. Under Fields, select Time and click Add to add the date and time a compliance event was generated.

Version 4.7


1141

Using Custom Tables Modifying a Custom Table

Chapter 28

6. Repeat step 5 to add the Policy and Rule fields. TIP! You can use Ctrl or Shift while clicking to select multiple fields. You can also click and drag to select multiple adjacent values. However, if you want to specify the order the fields appear in the table view of events associated with the table, add the fields one at a time. 7.

From the Tables drop-down list, select RNA Hosts. The fields in the Hosts table appear in the Fields list. For more information on these fields, see the Host Fields table on page 234.

8. Add the IP Address, NetBIOS Name, OS Name, OS Version, and Host Criticality fields to the custom table. 9. Under Common Fields, next to Compliance Events, select Source IP. Your custom table is configured to display the host information you chose in step 8 for the source, or initiating, hosts involved in compliance events. TIP! You could create a custom table that displays detailed host information for the destination, or responding, hosts involved in a compliance event by following this procedure but selecting Destination IP instead of Source IP. 10. Click Save. The custom table is saved.

Modifying a Custom Table Requires: DC + RNA

You can add or delete fields in a custom table as your needs change. To modify a custom table:


1.


2. Click Edit next to the table you want to edit. The Create Custom Table page appears. See Creating a Custom Table on page 1140 for information on the various configurations you can change. 3. Optionally, remove fields from the table by clicking Delete next to the fields you want to remove. 4. Make other changes as needed and click Save. Your custom table is updated.

Version 4.7


1142

Using Custom Tables Deleting a Custom Table

Chapter 28

Deleting a Custom Table Requires: DC + RNA

You can delete a custom table that you no longer need. To delete a custom table:


1.


2. Click Delete next to the custom table you want to delete. The table is deleted.

Viewing a Workflow Based on a Custom Table Requires: DC + RNA

When you create a custom table, RNA automatically creates a default workflow for it. The first page of this workflow displays a table view of events. If your Defense Center is managing a 3D Sensor with IPS and you include intrusion events in your custom table, the second page of the workflow is the packet view. Otherwise, the second page of the workflow is a hosts page. You can also create your own custom workflows based on your custom table. TIP! If you create a custom workflow based on a custom table, you can specify it as the default workflow for that table. For more information, see Setting Event Preferences on page 35. You can use the same techniques to view events in your custom table that you use for event views based on predefined tables. See Using Workflow Pages on page 1165 for more information. To view a workflow based on a custom table:


1.

Select Analysis & Reports > Custom Tables. The Custom Tables page appears.

2. Click View next to the custom table upon which the workflow you want to see is based. The first page of the default workflow for the custom table appears. If you created a custom workflow for the custom table and did not specify a default, you must first select one. For information on specifying a default workflow, see Setting Event Preferences on page 35.

Version 4.7


1143

Using Custom Tables Searching Custom Tables

Chapter 28

Searching Custom Tables Requires: DC + RNA

You can create and save searches for a custom table. When you create a search you give it a name and specify whether the search is available to you alone or to all users. To perform a search on a custom table:


1.

Select Analysis & Reports > Custom Tables. The Custom Tables page appears.

2. Click View next to the custom table you want to search. The first page of the default workflow for the custom table appears. If you created a custom workflow for the custom table and did not specify a default, you must first select one. For information on specifying a default workflow, see Setting Event Preferences on page 35. 3. On the toolbar, click Search. The custom table’s search page appears. The following graphic shows the search page for the Hosts with Services predefined custom table.

TIP! To search the database for a different kind of event or data, select it from the Table list. 4. Optionally, if you want to save the search, enter a name for it in the Name field. If you do not enter a name, one is automatically created when you save the search.

Version 4.7


1144


Chapter 28

5. Enter your search criteria in the appropriate fields. If you enter multiple criteria, the search returns only the records that match all the criteria. The search criteria you can use are the same as the criteria for the predefined tables you used to build your custom table. See the sections listed in the following table for detailed information on the search criteria you can use.

Version 4.7

For search criteria for....

See...

Audit Events


Client Applications

Searching for Client Applications on page 265

Compliance Events


Flow Data


Hosts

Searching for Hosts on page 239

Host Attributes

Searching for Host Attributes on page 248

Hosts with Services

Searching for Hosts on page 239 and Searching for Services on page 256

Intrusion Events

Searching for Intrusion Events on page 689


Searching for Intrusion Events on page 689 and Searching for Hosts on page 239

Intrusion Events with Source Criticality

Searching for Intrusion Events on page 689 and Searching for Hosts on page 239

Remediation Status Events


RNA Events


RUA Events


SEU Import Log

Searching the SEU Import Log on page 842

Services


Users



1145


Chapter 28

For search criteria for....

See...

Vulnerabilities


White List Events




6. If you want to save the search so that other users can access it, clear the Save As Private check box. Otherwise, leave the check box selected to save the search as private. TIP! If you want to save a search as a restriction for restricted data users, you must save it as a private search. 7.

You have the following options: •

Click Search to start the search. Your search results appear in your preferred workflow. If multiple workflows exist and you did not specify a preferred workflow, you must select one. For more information on how to specify a preferred workflow, see Setting Event Preferences on page 35.

Version 4.7

•


•



1146

Chapter 28

Understanding and Using Workflows

A workflow is a series of pages displaying sensor data that analysts use to evaluate events generated on a sensor. The Sourcefire 3D System provides three categories of workflows: •

Predefined workflows, which are installed on the system that you cannot modify or delete.

•

Saved custom workflows, which are predefined custom workflows installed on the Defense Center that you can modify or delete.

•

Custom workflows, which are workflows you create and customize for your specific needs that you can also modify or delete.

For example, when you are analyzing intrusion events, you can choose between predefined workflows for intrusion events. There are also predefined workflows for each type of analysis that you can perform for RNA data: event-based, hostbased, flow-based, and service-based. In addition, you can view simple workflows listing RNA vulnerabilities and RNA host attributes. You cannot modify or delete predefined workflows. However, if the predefined workflows do not meet your needs, you can create your own custom workflows using the Custom Workflows feature. Saved custom workflows are also included on the Defense Center; you can modify these workflows if needed or use them as examples for creating your own new custom workflows.

Version 4.7


1147

Understanding and Using Workflows Components of a Workflow

Chapter 29

See the following sections for more information about using predefined and custom workflows: •

Components of a Workflow on page 1148

•

Using Workflows on page 1161

•

Using Custom Workflows on page 1179

TIP! You can also use custom workflows as the basis for reports. See Building and Generating Reports on page 1103 for more information.

Components of a Workflow Requires: Any

Workflows can include several types of pages, as described in the following sections.

Table Views Table views include a column for each of the fields in the database on which your workflow is based. For example, the table view of RNA events (Defense Center only) includes the Time, Event, IP Address, User, MAC Address, Port, Description, Confidence, and Detection Engine columns. By contrast, the table view of intrusion events (Master Defense Center, Defense Center, or 3D Sensor with IPS only) includes the Time, Priority, Impact Flag, Inline Result, Detection Engine, Protocol, Source IP, Destination IP, Source User, Destination User, Source Port/ICMP Type, Destination Port/ICMP Code, Generator, and Message columns.

Drill-Down Pages Drill-down pages contain a subset of columns that are available in the database. For example, a drill-down page for RNA events might include only the IP Address, MAC Address, and Time columns. A drill-down page for intrusion events, on the other hand, might include only the Priority, Impact Flag, Inline Result, and Message columns. Generally, drill-down pages are intermediate pages that you use to narrow your investigation to a few events before moving to a table view page.

Graphs Requires: DC+ RNA

Workflows based on flow data can include graph pages, also called flow graphs. For example, a flow graph might display a line graph that shows the number of flows detected by RNA over time. Generally, flow graphs are, like drill-down

Version 4.7


1148


Chapter 29

pages, intermediate pages that you use to narrow your investigation. For more information, see Understanding Flow Data Graphs on page 283.

Final Pages The final page of a workflow depends on the type of event on which the workflow is based: •

Requires: DC + RNA The host view is the final page for workflows based on RNA events. For more information, see Using Host Profiles on page 172.

•

Requires: DC + RNA The vulnerability detail view is the final page for workflows based on vulnerabilities. For more information, see Viewing Vulnerability Details on page 197.

•

Requires: IPS or DC/MDC + IPS The packet view is the final page for workflows based on intrusion events. For more information, see Using the Packet View on page 673.

Workflows based on other kinds of events (for example, audit log events) do not have final pages. See the following sections for more information on workflows: •

Comparing Predefined and Custom Workflows on page 1149

•

Comparing Workflows for Predefined and Custom Tables on page 1150

•

Predefined Intrusion Event Workflows on page 1150

•

Predefined RNA Workflows on page 1154

•

Predefined Compliance and White List Workflows on page 1156

•

Predefined Flow Data Workflows on page 1156

•

Predefined RUA Workflows on page 1158

•

Additional Predefined Workflows on page 1159

•

Saved Custom Workflows on page 1159

Comparing Predefined and Custom Workflows Requires: IPS or DC/MDC

Your Sourcefire 3D System is delivered with a set of predefined workflows (described in the sections that follow) that you can use to analyze the events and other data it collects. Custom workflows are workflows that you create to meet the unique needs of your organization. When you create a custom workflow, you choose the kind of event (or database table) on which the workflow is based. On the Defense Center, you can base a custom workflow on a custom table. You can also choose the pages a custom workflow contains; custom workflows can contain drill-down, table view, and host or packet view pages. The Defense Center is delivered with several saved custom workflows, which are based on the saved custom tables that are also delivered with the Defense

Version 4.7


1149


Chapter 29

Center. The differences between workflows based on predefined and custom tables is described in the next section, Comparing Workflows for Predefined and Custom Tables. Note that you cannot create or view custom workflows on a 3D Sensor that does not have an IPS license.

Comparing Workflows for Predefined and Custom Tables Requires: DC + RNA

You can use the custom tables feature to create tables that use the data from two or more types of events. This is useful because you can, for example, create tables and workflows that correlate intrusion event data with RNA data to allow simple searches for events that affect critical systems. See Using Custom Tables on page 1136 for information about creating custom tables. Each custom table has, by default, a workflow that you can use to view the events associated with the table. The features in the workflow differ depending on which type of table you use. For example, custom table workflows based on the intrusion event table always end with the packet view. However, custom table workflows based on RNA events end with the host view. Unlike workflows based on the predefined event tables, workflows based on custom tables do not have links to other types of workflows.

Predefined Intrusion Event Workflows Requires: IPS or DC/MDC + IPS

Version 4.7

The Predefined Intrusion Event Workflows table describes the predefined intrusion event workflows included with the Sourcefire 3D System. For


1150


Chapter 29

information on accessing these workflows, see Viewing Intrusion Events on page 658 and Viewing Reviewed Intrusion Events on page 661 :

Predefined Intrusion Event Workflows Workflow Name

Description

Destination Port

Because destination ports are usually tied to a service, this workflow can help you detect services that are experiencing an uncommonly high volume of alerts. The Destination Port column can also help you identify services that should not be present on your network. This workflow begins with a page showing the destination ports associated with the intrusion events, followed by a page showing the event types that were generated. You can then see a tabular view of event information, called the table view of events, followed by a packet view that shows the decoded contents of the packets associated with each event.

Event Specific

This workflow provides two useful features. Events with that occur frequently may indicate: • false positives • a worm • a badly misconfigured network Events that occur infrequently are most likely evidence of a targeted attack and warrant special attention. This workflow begins with a page showing the event types that were generated. You can then view a page with two tables, one listing the source IP addresses associated with the events, the other showing the destination IP addresses associated with the events. The last pages in the workflow are the table view of events and the packet view.

Events to Destinations

This workflow provides a high level view of which hosts are being attacked and the nature of the attack. This workflow begins with a page of paired event types and destination IP addresses that you can use to investigate what types of events are directed towards specific IP addresses. The last pages in the workflow are the table view of events and the packet view.

IP-Specific

This workflow shows which hosts are generating the most alerts. Hosts with the greatest number of events are either public-facing and receiving wormtype traffic (indicating a good place to look for tuning) or require further investigation to determine the cause of the alerts. Hosts with the lowest counts also warrant investigation as they could be the subject of a targeted attack. Low counts may also indicate that a host might not belong on the network. This workflow begins with a page showing two tables, one each for the source and destination IP addresses that are associated with the events. The next page shows the event types that were generated. The last pages in the workflow are the table view of events and the packet view.

Version 4.7


1151


Chapter 29

Predefined Intrusion Event Workflows (Continued) Workflow Name

Description

Impact and Priority

Requires: DC/MDC + IPS + RNA This workflow lets you find high-impact recurring events quickly. The reported impact flag level is shown with the number of times the event has occurred. Using this information, you can identify the high-impact events that recur most often, which might be an indicator of a widespread attack on your network. This workflow begins with a page showing the impact level, priority, and count associated with each event. Next, a drill-down page appears with the source and destination IP addresses for each event. Events on the second page are sorted by count. The last pages in the workflow are the table view of events and the packet view.

Impact and Source

Requires: DC/MDC + IPS + RNA This workflow can help you identify the source of an attack in progress. The reported impact flag level is shown with the associated source IP address for the event. If, for example, events with a level 1 impact flag are coming from the same source IP repeatedly, they may indicate an attacker who has identified vulnerable systems and is targeting them. This workflow begins with a page showing the impact level, source IP address, priority, and count associated with each event. Within each event level, events are sorted by count, then priority. Next, a drill-down page appears with the source and destination IP addresses for each event. Events on the second page are sorted by count. The last pages in the workflow are the table view of events and the packet view.

Version 4.7


1152


Chapter 29

Predefined Intrusion Event Workflows (Continued) Workflow Name

Description

Impact to Destination

Requires: DC/MDC + IPS + RNA You can use this workflow to identify events repeatedly occurring on vulnerable computers, so you can address the vulnerabilities on those systems and stop any attacks in progress. This workflow begins with a page showing the impact level, inline result (whether the packet was dropped), destination IP address, priority, and count associated with each event. Within each event level, events are sorted by count, then priority. Next, a drill-down page appears with the source and destination IP addresses for each event. Events on the second page are sorted by count. The last pages in the workflow are the table view of events and the packet view.

Source Port

This workflow indicates which services are generating the most alerts. You can use this information to identify areas that require tuning, and to decide which services require attention. This workflow begins with a page showing the source ports associated with the intrusion events, followed by a page showing the types of events that were generated. The last pages in the workflow are the table view of events and the packet view.

Source and Destination

This workflow identifies hosts sharing high levels of alerts. Pairs at the top of the list could be false positives, and may identify areas that require tuning. You can check pairs at the bottom of the list for targeted attacks, for users accessing resources they should not be accessing, or for hosts that do not belong on the network. This workflow begins with a page showing the source and destination IP addresses for each event, followed by a page showing the types of events that were generated. The last pages in the workflow are the table view of events and the packet view.

Version 4.7


1153


Chapter 29

Predefined RNA Workflows Requires: DC + RNA

There is a predefined workflow for each type of data collected by RNA. For information on accessing these workflows, see Understanding RNA Event Workflows on page 217. Predefined RNA Workflows

Version 4.7

Workflow Name

Description

Client Applications

This workflow contains a table view of client applications, followed by the host view. See Viewing Client Applications on page 262 for more information.

Client Application Summaries

You can use this workflow to analyze the client applications on your network in more detail. This workflow contains a series of pages that begin with a list of the client applications and application products on your network and a count of the number of hosts running each application. You can then view the number of hosts running each version of that application. The next page lets you identify which applications have been accessed most frequently on specific hosts. The workflow then provides a table view of client applications, followed by the host view. See Viewing Client Applications on page 262 for more information.

Events

This workflow contains a table view of RNA events followed by the host view. See Viewing RNA Network Discovery and Host Input Events on page 225 for more information.

Flow Data

Your Sourcefire 3D System includes several predefined flow data workflows. See Predefined Flow Data Workflows on page 1156 for more information.

Host Attributes

This workflow contains a table view of host attributes and their assigned values for each detected host followed by the host view. See Viewing Host Attributes on page 244 for more information.

Hosts

This workflow contains a table view of hosts followed by the host view. See Viewing Hosts on page 232 for more information.


1154


Chapter 29

Predefined RNA Workflows (Continued)

Version 4.7

Workflow Name

Description

Network Services by Count

You can use this workflow to analyze the most frequently used services on your network. This workflow contains a series of pages that show services with a count of hosts where each service occurs, then add the vendor and version of each service. The workflow then concludes with a table view listing the services per host, followed by the host view. See Viewing Services on page 251 for more information.

Network Services by Hit

You can use this workflow to analyze the most active services on your network. This workflow contains a series of pages that show services with a count of how often each service is accessed, then add the vendor and version information for each service. The workflow finishes with a page containing a table view listing the services per host, followed by the host view. See Viewing Services on page 251 for more information.

Operating System Summary

You can use this workflow to analyze the operating systems in use on your network. This workflow provides a series of pages that start with a list of the operating systems and operating system vendors on your network, then view the number of hosts running each version of that operating system. The next page lists hosts by criticality, IP address, and NetBIOS name, with their associated operating systems and operating system vendors. The workflow finishes with a table view of hosts, followed by the host view. See Viewing Hosts on page 232 for more information.

Services

This workflow contains a table view of services followed by the host view. See Viewing Services on page 251 for more information.

Vulnerabilities

This workflow contains a table view of vulnerabilities showing all the vulnerabilities in the database, followed by a table view of only those active vulnerabilities that apply to the detected hosts on your network.The workflow ends in a vulnerability detail view, which contains a detailed description for every vulnerability that meets your constraints. See Viewing Vulnerabilities on page 267 for more information.


1155


Chapter 29

Predefined Compliance and White List Workflows Requires: DC + RNA

There is a predefined workflow for each type of compliance data, including compliance and white list events, white list violations, and remediation status events. Predefined Compliance Workflows Workflow Name

Description

Compliance Events

This workflow, which is also available on the Master Defense Center, contains a table view of compliance events. See Working with Compliance Events on page 447 for more information.

White List Events

This workflow, which is also available on the Master Defense Center, contains a table view of white list events. See Working with White List Events on page 378 for more information.

Host Violation Count

This workflow provides a series of pages that list all the hosts that violate at least one white list. The first page sorts the hosts based on the number of violations per host, with the hosts with the most number of violations at the top of the list. If a host violates more than one white list, there is a separate row for each violated white list. The workflow also contains a table view of white list violations that lists all violations with the most recently detected violation at the top of the list. Each row in the table contains a single detected violation. See Working with White List Violations on page 385 for more information.


This workflow includes a table view of white list violations that lists all violations with the most recently detected violation at the top of the list. Each row in the table contains a single detected violation. See Working with White List Violations on page 385 for more information.

Remediation Status

This workflow contains a table view of remediation status, which includes the name of the policy that was violated and the name and status of the remediation that was applied. See Working with Remediation Status Events on page 524 for more information.

Predefined Flow Data Workflows Requires: DC + RNA

Version 4.7

The Predefined Flow Data Workflows table describes the predefined flow data workflows included on the Defense Center. All the flow data workflows, with the exception of RNA Flows, include a table view of flow summary data and a table


1156


Chapter 29

view of flow data. For information on accessing flow data workflows, see Viewing Flow Data on page 299. Predefined Flow Data Workflows

Version 4.7

Workflow Name

Description

Flow Summaries

This workflow contains a table view of flow summary data and the table view of flow data events.

Flows by Detection Engine

This workflow contains a graph of the 10 most active detection engines on the monitored network segment based on the number of flows detected by each engine.

Flows by Initiator

This workflow contains a graph of the 10 most active hosts on the monitored network segment based on the number of flows where the host initiated the flow transaction.

Flows by Port

This workflow contains a graph of the 10 most active ports on the monitored network segment based on the number of detected flows.

Flows by Responder

This workflow contains a graph of the 10 most active hosts on the monitored network segment based on the number of flows where the host was the responder in the flow transaction.

Flows by Service

This workflow contains a graph of the 10 most active services on the monitored network segment based on the number of detected flows.

Flows over Time

This workflow contains a graph of the total number of flows on the monitored network segment over time.

RNA Flows

This workflow contains only the table view of flow data events.

Traffic by Detection Engine

This workflow contains a graph of the 10 most active detection engines on the monitored network segment based on the total number of kilobytes in the flows detected by each engine.

Traffic by Initiator

This workflow contains a graph of the 10 most active hosts on the monitored network segment based on the total number of kilobytes transmitted by the host.

Traffic by Port

This workflow contains a graph of the 10 most active ports on the monitored network segment based on the number of kilobytes transmitted.


1157


Chapter 29

Predefined Flow Data Workflows (Continued) Workflow Name

Description

Traffic by Responder

This workflow contains a graph of the 10 most active hosts on the monitored network segment based on the total number of kilobytes received by the host.

Traffic by Service

This workflow contains a graph of the 10 most active services on the monitored network segment based on the number of kilobytes transmitted.

Traffic over Time

This workflow contains a graph of the total kilobytes transmitted on the monitored network segment over time.

Unique Initiators by Responder

This workflow contains a graph of the 10 most active responding hosts on the monitored network segment, based on the number of unique initiators that contacted each host.

Unique Responders by Initiator

This workflow contains a graph of the 10 most active initiating hosts on the monitored network segment, based on the number of unique responders that the hosts contacted.

Predefined RUA Workflows Requires: DC + RUA

The Predefined RUA Workflows table describes the predefined RUAworkflows included on the Defense Center. Predefined RUA Workflows

Version 4.7

Workflow Name

Description

Users

This workflow provides a list of user information collected from RUA events or from the LDAP server connection. For details about the users workflow refer to Viewing RUA Users on page 1086

RUA Events

This workflow provides a list of Real-time User Awareness events. For details about the RUA events refer to Viewing RUA Events on page 1096.


1158


Chapter 29

Additional Predefined Workflows Requires: Any

The Sourcefire 3D System is delivered with some additional workflows, including those for system events such as audit events and health events, as well as workflows that list results from SEU imports and active scans. Additional Predefined Workflows Workflow Name

Description

Audit Log

This workflow contains a table view of the audit log listing audit events. See Viewing Audit Records on page 1424 for more information.

Requires: DC/MDC Health Events

This workflow displays events triggered by the health monitoring policy. See Working with the Health Events Table View on page 1407 for more information.

Requires: IPS or DC/MDC + IPS SEU Import Log

This workflow contains a table view listing information about both successful and failed SEU imports. For more information, see Viewing the SEU Import Log on page 838.

Requires: DC + RNA Scan Results

The workflow contains a table view listing each completed scan. For more information, see Working with Active Scan Results on page 625.

Saved Custom Workflows Requires: DC + RNA

Version 4.7

In addition to predefined workflows, which cannot be modified, your Defense Center includes several saved custom workflows. Each of these workflows are


1159


Chapter 29

based on a custom table and can be modified. For information on accessing these workflows, see Viewing a Workflow Based on a Custom Table on page 1143. Saved Custom Workflows

Version 4.7

Workflow Name

Description

Requires: DC + IPS + RNA Events by Impact, Priority, and Host Criticality

You can use this workflow to quickly pick out and focus in on hosts that are important to your network, currently vulnerable, and possibly currently under attack.

Requires: DC + IPS + RNA Events with Destination, Impact, and Host Criticality

You can use this workflow to find the most recent attacks on hosts that are important to your network and currently vulnerable.

Hosts with Services Default Workflow

You can use this workflow to quickly view the basic information in the Hosts with Services custom table.

Requires: DC + IPS + RNA Intrusion Events with Destination Criticality Default Workflow

You can use this workflow to quickly view the basic information in the Intrusion Events with Destination Criticality custom table.

By default, this workflow starts with a summary of events sorted by impact flag level, then by host criticality, and then by the number of occurrences of the event. You can use the second page of the workflow to drill down and view the source and destination addresses where specific events occur. The workflow concludes with a table view of Intrusion Events with Destination Criticality, then the packet view. This workflow is based on the Intrusion Events with Destination Criticality custom table. For more information, see Understanding Custom Tables on page 1137.

By default, this workflow starts with a list of the most recent events, sorted by impact level. The next page of the workflow provides a table view of Intrusion Events with Destination Criticality, followed by the packet view. This workflow is based on the Intrusion Events with Destination Criticality custom table. For more information, see Understanding Custom Tables on page 1137.

By default, this workflow begins with a table view of hosts with services, followed by the host view. This workflow is based on the Hosts with Services custom table. For more information, see Understanding Custom Tables on page 1137.

By default, this workflow starts with a table view of Intrusion Events with Destination Criticality, followed by the packet view. This workflow is based on the Intrusion Events with Destination Criticality custom table. For more information, see Understanding Custom Tables on page 1137.


1160

Understanding and Using Workflows Using Workflows

Chapter 29

Saved Custom Workflows (Continued) Workflow Name

Description

Requires: DC + IPS + RNA Intrusion Events with Source Criticality Default Workflow

You can use this workflow to quickly view the basic information in the Intrusion Events with Source Criticality custom table.

Service and Host Details

You can use this workflow to determine what services are most frequently used on your network and which hosts are running those services.

By default, this workflow begins with a table view of hosts with services, followed by the host view. This workflow is based on the Intrusion Events with Source Criticality custom table. For more information, see Understanding Custom Tables on page 1137.

By default, this workflow begins with a summary of services with the frequency of access for each service. The next page lists services by operating system vendor and version. The workflow concludes with a table view of hosts with services, followed by the host view. This workflow is based on the Hosts with Services custom table. For more information, see Understanding Custom Tables on page 1137.

Using Workflows Requires: Any

Version 4.7

The drill-down and table view pages in workflows allow you to quickly narrow your view of the data so you can zero in on events that are significant to your analysis. Although the data in each type of workflow is different, all workflows share a common set of features. The following sections describe these features and explain how to use them. •

Selecting Workflows on page 1162 describes the workflow selection page and how to select a workflow to use.

•

Understanding the Workflow Toolbar on page 1165 describes the toolbar options available in workflows.

•

Using Workflow Pages on page 1165 describes the features that appear on all workflow pages and explains how to use them.

•

Setting Event Time Constraints on page 1169 describes how to set the time range for event-based workflows. The workflow includes events generated in the specified time range.

•

Constraining Events on page 1170 describes features that are used in workflows to constrain, or narrow, the view of data in workflows and to advance through workflow pages.

•

Using Compound Constraints on page 1173 explains how compound constraints can be used and provides examples.


1161


Chapter 29

•

Sorting Workflow Pages and Changing Their Layout on page 1174 describes features for sorting the data displayed in workflows, and for removing and restoring table columns to view.

•

Selecting Rows on a Workflow Page on page 1174 describes how to select data rows in the displayed table that you want to analyze or on which you want to perform some other action.

•

Navigating to Other Pages in the Workflow on page 1175 describes how to open other workflows using the constraints, including any selected events, from the current workflow.

•

Navigating between Workflows on page 1175 describes the links that appear above the column headings of a workflow page on the Defense Center and explains how you can use them to apply the current constraints to a different workflow.

•

Searching for Events on page 1124 provides information about the feature used to search event data.

•

Using Bookmarks on page 1177 describes how to create, manage, and use bookmarks.

Selecting Workflows Requires: Any

The Sourcefire 3D System provides predefined workflows are also provided for the types of data listed in the table that follows.

Features Using Workflows Feature

Menu Path

Option

Requires: IPS or DC/MDC + IPS Intrusion events

Analysis & Reporting > IPS

Events Reviewed Events Clipboard

Requires: DC + RNA RNA-related events(including flow data)

Analysis & Reporting > RNA

Events Hosts Host Attributes Services Client Applications Flow Data Vulnerabilities

Requires: DC + RUA RUA-related events

Version 4.7

Analysis & Reporting > RUA

Users RUA Events


1162


Chapter 29

Features Using Workflows (Continued) Feature

Menu Path

Option

Requires: DC + RNA Compliance events

Analysis & Reporting > Compliance

Compliance Events (also available on the Master Defense Center) White List Events (also available on the Master Defense Center) White List Violations

Requires: DC + RNA Remediation status events

Policy & Response > Responses > Remediations

Status

Requires: Any Audit events

Operations > Monitoring

Audit

Requires: MDC/DC Health monitoring events

Operations > Monitoring > Health

Health Events

Requires: IPS or MDC/DC + IPS SEU Import Log

Policy & Response > IPS

SEU

Requires: DC + RNA Scan Results

Operations > Tools

Scan Results

If there is only one workflow available, then the events appear on the first page of the workflow without any intervening page. If you have selected a default workflow through the event preference options (see Setting Event Preferences on page 35 for more information), then the first page of the workflow you selected as a preference appears. However, if there are multiple workflows (either predefined or custom) available for a feature, and you have not selected a default workflow for that feature, then the Select Workflow page appears when you select the associated menu option. Note that if you are managing a 3D Sensor with a Defense Center and you elected to store data only on the Defense Center and not on the sensor, you will not be able to view data in workflows using the sensor’s web interface, with the exception of the audit log.

Version 4.7


1163


Chapter 29

Also note that workflow access depends on your user role, as follows: •

Admin users can access any workflow, and are the only users who can access the audit log.

•

Data users can access intrusion event, RNA-related, compliance-related, and RUA-related workflows.

•

Rules users can access the remediation status workflow and the SEU import log.

•

Maintenance users can access health events.

•

Anyone can access scan results.

To select a workflow from a workflow list: Access: Any

1.

Select the appropriate menu path and option as described in the Features Using Workflows table. The Select Workflow page appears. For example, the following options appear by default when you attempt to view intrusion events.

2. Click the name of the workflow that you want to use from the list. The first page of the workflow appears.

Version 4.7


1164


Chapter 29

Understanding the Workflow Toolbar Requires: Any

Each page in a workflow includes a toolbar that offers quick access to related features. The Workflow Toolbar Links table describes each of the links on the toolbar.

Workflow Toolbar Links Feature

Page

Description

Bookmark This

Report Designer Workflows View Bookmarks Search

Bookmarks the current page so you can return to it later. Bookmarking captures the constraints in effect on the page you are viewing so you can return to the same data (assuming the data still exists) at a later time. See Using Bookmarks on page 1177 for information about creating bookmarks. Opens the report designer with the currently constrained workflow as the selection criteria. See Creating Reports from Event Views on page 1105 for information about creating reports. Displays the Select Workflow page where you can select a different workflow using the same constraints (if applicable). Displays a list of saved bookmarks from which you can select. See Using Bookmarks on page 1177 for information about creating and managing bookmarks. Displays a Search page where you can perform advanced searches on data in the workflow. See Searching for Events on page 1124 for information about searching workflows.

Using Workflow Pages Requires: Any

Version 4.7

The actions you can perform on a workflow page depend on the type of page. Table view pages and drill-down pages contain many features you can use to constraint the set of events you want to view or to navigate the workflow. For more information on the features available on each type of page, see the following sections: •

Using Common Table View or Drill-down Page Functionality on page 1166

•

Using Table View Pages on page 1167

•

Using Drill-down Pages on page 1168

•

Using the Host View, Packet View, or Vulnerability Detail Pages on page 1168


1165


Chapter 29

Using Common Table View or Drill-down Page Functionality Requires: Any

Table view and drill-down workflow pages provide a set of icons and other features in the table header and table rows that you can use to perform actions on the displayed data. The features are described in the Table View and Drill-down Page Features table. The Defense Center version of a sample page is shown below.

Table View and Drill-down Page Features Feature

Description Click this icon to display the corresponding row in the next page of the workflow. Click the host profile icon, which appears in IP address columns, to display the host profile for the host. The host profile appears in a pop-up window. For more information, see Using Host Profiles on page 172.

Check boxes

Version 4.7

Select the check box in two or more rows on a page to indicate which rows you want to affect, then click one of the buttons at the bottom of the page (for example, the View button). You can also select the check box at the top of the row to select all the rows on the page.


1166


Chapter 29

Table View and Drill-down Page Features (Continued) Feature

Description

Search Constraints

Lists the values constraining the data view. Click the Expand arrow to display the active constraints and disabled columns list or the Collapse arrow to hide the list from view. By default, this list is collapsed, which is useful when the list of constraints is long and takes up too much of the screen. To remove a single constraint, click it. To remove a compound constraint, click Compound Constraints. Click Edit Search or Save Search to open a search page prepopulated with the current single constraints. See Constraining Events on page 1170 for more information. IMPORTANT! Compound constraints are constraints created based on rows with multiple non-count values. You cannot perform a search or save a search on a compound constraint.

Time Range

The date range located in the upper right corner of the page sets a time range for events to include in the workflow. See Setting Event Time Constraints on page 1169 for more information.

Workflow Page Links

Workflow page links appear in the upper left corner of predefined workflow table view and drill-down pages (except the Table View of Vulnerabilities). Click a workflow page link to display that page using any active constraints.

Using Table View Pages Requires: Any

Version 4.7

Table views include a column for each of the fields in the database. Note that table view pages do not have a count column until you disable one of the existing columns, at which point a count column is added. When you click on a value in a table view page, you constrain by that value and the page refreshes with the column for that value disabled. When you create a custom workflow, you add a table view to it by clicking Add Table View.


1167


Chapter 29

Table view pages provide some additional features not available on drill-down, host view, packet view, or vulnerability detail pages. The Additional Table View Page Features table provides more information on those features. Additional Table View Page Features Feature

Description Click this icon to remove the associated column from a table view page and add the count column to the page. The column name appears in the Disabled Columns list at the top of the page.

Disabled Columns List

After you remove columns from a page, the column name appears in the Disabled Columns list located above the table. You can expand the list of disabled columns and then click a disabled column to restore the column to the view. The Disabled Columns list is hidden by default; click the Search Constraints Expand arrow to expand it. See Sorting Workflow Pages and Changing Their Layout on page 1174 for more information.

Using Drill-down Pages Requires: Any

Drill-down pages contain a subset of columns that are available in the database. Note that drill-down pages for predefined workflows always have a count column. Drill-down pages allow you to narrow the scope of events you are viewing and move forward in the workflow. If you click on a value in a drill-down page, for example, you constrain by that value and move to the next page in the workflow, focusing in on events matching your selected values. Clicking a value in a drilldown page does not disable the column where the value is, even if the page you advance to is a table view. When you create a custom workflow, you add a drilldown page to it by clicking Add Page. For more information on using features on drill-down pages to constrain the set of events as you go through a workflow, see Using Common Table View or Drilldown Page Functionality on page 1166.

Using the Host View, Packet View, or Vulnerability Detail Pages Requires: IPS or DC/MDC

Version 4.7

The final page in an RNA event, host, host attributes, services, client applications, or flow data workflow is the host view. The final page in a vulnerability workflow is the vulnerability detail page. An intrusion event workflow always ends with the packet view. On the final page of a workflow, you can expand detail sections to view specific information about each object in the set you focused on over the course of the workflow. Although the web interface does not list the constraints on the final page of a workflow, previously set constraints are retained and applied to the set of data.


1168


Chapter 29

Setting Event Time Constraints Requires: Any

You can constrain the information that appears in some workflows by setting the time range. Each event has a time stamp that indicates when the event occurred. When you first log into the web interface, the time range is set to the past hour. For example, if you log in at 11:30AM you will see events that occurred between 10:30AM and 11:30AM. Some workflows, such as those based on RNA hosts, host attributes, services, client applications, or vulnerabilities, do not constrain their views by time range. Other workflows that are more time-dependent include a time range line at the top of the page, as shown in the following graphic.

The time range you configure persists throughout your current session, for any workflows where time ranges apply. When you reset the time range for one workflow, you change that setting for all workflows you view until you modify the time range again or log out of the web interface. If you log out of the web interface, wait for a few minutes, and then log back in again, the default time range resets based on the time of your second login. In addition, even if you set the event view to automatically refresh, the time range remains static and does not increment. To set the time constraint used to display events: Access: Any

1.

On a workflow affected by the time, click the time range link. A pop-up window appears.

Version 4.7


1169


Chapter 29

2. Set the time constraint for the workflow in one of the following ways: •

Specify the start date and time on the Start Date calendar, and then set the end date and time on the End Date calendar.

•

Click one of the time ranges in the Defaults list. By default, the web interface displays events generated in the last hour.

IMPORTANT! The Sourcefire 3D System uses a 24-hour clock based on the time you specified in your time zone preferences. See Setting Your Default Time Zone on page 37 for information about configuring a time zone. 3. Click Apply Changes. The window closes and the event view page displays events from the new time range. IMPORTANT! Selecting a default time range does not change the time range—you must click Apply Changes after setting the range to change it.

Constraining Events Requires: Any

The information that you see on a workflow page is determined by the constraints that you impose. For example, when you initially open an event workflow, the information is constrained to events that were generated in the previous hour. For more information, see Setting Event Time Constraints on page 1169. To advance to the next page in the workflow and constrain the data you are viewing by specific values, select the rows with those values on the page and click View. To advance to the next page in the workflow retaining the current constraints and carrying forward all events, select View All. IMPORTANT! If you select a row with multiple non-count values and click View, you create a compound constraint. For more information on compound constraints, see Using Compound Constraints on page 1173. There is a third method for constraining data in a workflow. To constrain the page to the rows with values that you selected and also add the selected value to the list of constraints at the top of the page, click a value within a row on the page.

Version 4.7


1170


Chapter 29

For example, if you click 10.14.12.29 in the Source IP column on a page with the following events:

Then the constrained page includes only the events with that IP address:

You can also use searches to constrain the information in a workflow. The search criteria you enter on the search page are listed as the constraints at the top of the page with the resulting events constrained accordingly. On the Defense Center, the current constraints are also applied when navigating to other workflows, unless they are compound constraints (see Navigating between Workflows on page 1175).

Version 4.7


1171


Chapter 29

The Search Constraint Functions table describes each of the actions you can perform when applying a constraint. Search Constraint Functions To...

Click...

constrain the view to events that match a single value

the value in the table. Note that because all of the remaining events share that value, in a table view page the column where you clicked is removed and appears in the Disabled Columns list. When you remove the first column from a page, the count column is added. If you remove a column on a table view page, the column remains disabled until you enable it again. For example, with RNA, if you are viewing a list of services and want to constrain the list to only web services, click http in the Service column. With IPS, if you are viewing intrusion events and want to constrain the list to only events where the destination port is 80, click 80 (http)/tcp in the DST Port/ICMP Code column.

constrain the view to events that match multiple values

the check box for events with those values and click View.

remove a constraint

the name of the constraint in the Search Constraints box.

edit constraints using the search page

Edit Search in the Search Constraints box.

save constraints as a saved search

Save Search in the Search Constraints box and give the query a name.

Note that a compound constraint is added if the row contains multiple non-count values. For more information on compound constraints, see Using Compound Constraints on page 1173.

Use this feature when you want to constrain against multiple values in a single column. For example, if you want to view the events related to two IP addresses, click Edit Search, then modify the appropriate IP address field on the Search page to include both addresses, and then click Search.

Note that you cannot save queries containing compound constraints. For more information on compound constraints, see Using Compound Constraints on page 1173.

Version 4.7


1172


Chapter 29

Search Constraint Functions (Continued) To...

Click...

Requires: DC + RNA use the same constraints with another event view

the link at the top of the table that corresponds to the event view. See Navigating between Workflows on page 1175 for more information.

toggle the display of constraints

Click the expand icon. This is useful when the list of constraints is large and takes up most of the screen.

Note that you do not retain compound constraints when you switch to another workflow. For more information on compound constraints, see Using Compound Constraints on page 1173.

Using Compound Constraints Requires: Any

Compound constraints are based on all non-count values for a specific event. When you select a row with multiple non-count values, you set a compound constraint that only retrieves events matching all the non-count values in that row on that page. For example, if you select a row that has a source IP address of 10.10.31.17 and a destination IP address of 10.10.31.15 and a row that has a source IP address of 172.10.10.17 and a destination IP address of 172.10.10.15, you retrieve all of the following: •

Events that have a source IP address of 10.10.31.17 AND a destination IP address of 10.10.31.15 OR

•

Events that have a source IP address of 172.10.31.17 AND a destination IP address of 172.10.31.15

When you combine compound constraints with simple constraints, the simple constraints are distributed across each set of compound constraints. If, for example, you added a simple constraint for a protocol value of tcp to the compound constraints listed above, you retrieve all of the following: •

Events that have a source IP address of 10.10.31.17 AND a destination IP address of 10.10.31.15 AND a protocol of tcp OR

•

Events that have a source IP address of 172.10.31.17 AND a destination IP address of 172.10.31.15 AND a protocol of tcp

You cannot perform a search or save a search on a compound constraint. You also cannot retain compound constraints when you use the event view links or the Workflows toolbar button to switch to another workflow. If you bookmark an event view with compound constraints applied, the constraints are not saved with the bookmark. To clear all compound constraints, click Compound Constraints.

Version 4.7


1173


Chapter 29

Sorting Workflow Pages and Changing Their Layout Requires: Any

When viewing data in a workflow, you can sort the data based on any available column and remove and restore columns to view. You can sort data in ascending or descending order by column. TIP! If you create a custom workflow, you can fully customize the arrangement of columns on the pages and predefine the page sort order. See Creating Custom Workflows on page 1179 for more information. Sorting and Layout Functions To...

Click...

sort a column

the column title. Click the column title again to reverse the sort order.

remove a column from a table view

the in the column heading that you want to remove. When you disable a column, it is disabled for the duration of your session (unless you add it back later). Note that when you disable the first column, the count column is added.

add a disabled column back to the view

the column name under Disabled Columns.

Selecting Rows on a Workflow Page Requires: Any

There are several different ways to select and then act on the rows on workflow pages.

•

To select all rows on the page, select the check box at the top of the page. You can then click any of the buttons at the bottom of the page (View, Delete, and so on) to perform that action on all of the events on that page.

•

To select a single row, select the check box next to the individual row. You can then click any of the buttons at the bottom of the page to perform that action on only the events associated with that row.

Version 4.7


1174


•

Chapter 29

To select a single row and view its associated events on the next page of the workflow, click the arrow icon (

IMPORTANT!

).

You cannot select rows from multiple pages at once.

Navigating to Other Pages in the Workflow Requires: Any

The set of links that appear at the bottom of all workflows help you navigate the workflow pages.

The Navigating Pages table describes how to use these links. Navigating Pages To...

Click...

view the previous page

Previous

view the next page

Next

view a different page

the page number

jump to the next set of 10 pages

>

jump to the previous set of 10 pages

|

jump to the first page

|
Bookmarks. The Bookmarks page appears. The Defense Center version of the page is displayed below.

2. Next to the bookmark you want to use, click View. The page you bookmarked appears. IMPORTANT! If the events that originally appeared in a bookmark are deleted (either directly by an event analyst or by automatic database clean-up), the bookmark no longer displays the original set of events.

Deleting Bookmarks Requires: Any

Use the following procedure to delete bookmarks. Note that deleting a bookmark does not affect the events retrieved by that bookmark. To delete a bookmark:

Access: Any

1.

From any event view, click View Bookmarks, or select Analysis & Reporting > Bookmarks. The Bookmarks page appears.

2. Click Delete next to the bookmark you want to remove. The bookmark is deleted.

Version 4.7


1178

Understanding and Using Workflows Using Custom Workflows

Chapter 29

Using Custom Workflows Requires: IPS or DC/MDC

If the predefined and Sourcefire-provided custom workflows do not meet your needs, you can create custom workflows. Note that you cannot create or view custom workflows on a 3D Sensor that does not have an IPS license. For more information, see: •

Creating Custom Workflows on page 1179 for a procedure to create custom workflows

•

Creating Custom Flow Data Workflows on page 1181 for a procedure to create a custom workflow based on flow data

•

Viewing Custom Workflows on page 1184 for procedures for viewing custom workflows based on event and custom tables

•

Editing Custom Workflows on page 1185 for a procedure for editing custom workflows

•

Deleting Custom Workflows on page 1185 for a procedure for deleting custom workflows

Creating Custom Workflows Requires: IPS or DC/MDC

When you create a custom workflow, you: •

select a table to be the source of the workflow

•

provide a workflow name

•

add drill-down pages and table view pages to the workflow

For each drill-down page in the workflow, you can: •

provide a name that appears at the top of the page in the web interface

•

include up to five columns per page

•

specify a default sort order, ascending or descending

You can add table view pages in any position in the sequence of workflow pages. They do not have any editable properties, such as a page name, or sort order, or user-definable column positions. On a Defense Center with RNA, workflows based on the predefined RNA event tables always have a host profile as the final page of the workflow. On a Defense Center or 3D Sensor with IPS, custom workflows based on intrusion event tables always have a packet page as the final page of the workflow. These final pages are added by default when you create the workflow. IMPORTANT! The procedure for creating a custom workflow based on flow data is slightly different. For more information, see the next section, Creating Custom Flow Data Workflows.

Version 4.7


1179


Chapter 29

To create a custom workflow: Access: Data or Admin

1.

Select Analysis & Reporting > Custom Workflows. The Custom Workflows page appears. The Defense Center version of the page is displayed below.

2. Type a name for the workflow in the Workflow Name field. You can use up to 60 alphanumeric characters and spaces in the name. 3. Optionally, type a description for the workflow in the Workflow Description field. You can use up to 80 alphanumeric characters and spaces. 4. Select the table you want to include from the Table Type drop-down list and click Start Creating Workflow. The Edit Custom Workflow page appears.

Version 4.7


1180


Chapter 29

5. Optionally, click Add Page to add one or more drill-down pages to the workflow. A drill-down page section appears.

Begin by typing a name for the page in the Page Name field, using up to 80 alphanumeric characters, but no spaces. Under Column 1, select a sort priority and a table column. This column will appear in the leftmost column of the page. For example, to create a page showing the destination ports that are targeted, and to sort the page by count, select 2 from the Sort Priority drop-down list and DST Port/ICMP Code from the Field drop-down list. Continue selecting fields to include and setting their sort priority until all the fields to appear on the page have been specified. You can specify up to five fields per page. IMPORTANT! On a Defense Center with RNA, if you selected Vulnerabilities as the Table Type in step 4, then add IP Address as a table column, the IP Address column does not appear when you are viewing vulnerabilities using your custom workflow, unless you use the search feature to constrain the workflow to view a specific IP address or range of addresses. For more information on searching for vulnerabilities, see Searching for Vulnerabilities on page 272. 6. Optionally, click Add Table View to add a table view page to the workflow. IMPORTANT! You must add at least one drill-down page or a table view of events to a custom workflow. 7.

Click Save. The new workflow is saved and added to the list of custom workflows.

Creating Custom Flow Data Workflows Requires: DC + RNA

Version 4.7

Custom workflows based on flow data are like other custom workflows, except you can include flow data graph pages as well as drill-down pages and table view pages. You can include as many of each type of page in the workflow as you want, in any order. Each flow data graph page contains a single graph, which can


1181


Chapter 29

be a line graph, bar graph, or pie chart. On line and bar graphs, you may include more than one dataset. For more information on flow data, including flow summaries, flow graphs, and datasets, see Understanding Flow Data on page 279. To create a custom workflow based on flow data: Access: Data or Admin

1.

Select Analysis & Reporting > Custom Workflow. The Custom Workflows page appears.

2. Type a name for the workflow in the Workflow Name field. You can use up to 60 alphanumeric characters and spaces in the name. 3. Optionally, type a description for the workflow in the Workflow Description field. You can use up to 80 alphanumeric characters and spaces. 4. From the Table Type drop-down list, select Flow Data and click Start Creating Workflow. The Edit Custom Workflow page appears.

Version 4.7


1182


Chapter 29

5. Optionally, add one or more drill-down pages to the workflow. •

To add a drill-down page that contains data on individual flows, click Add Page.

•

To add a drill-down page that contains flow summary data, click Add Summary Page.

In either case, a drill-down page section appears.

Begin by typing a name for the page in the Page Name field using up to 80 alphanumeric characters, but no spaces. Under Column 1, select a sort priority and a table column. This column will appear in the leftmost column of the page. Continue selecting fields to include and setting their sort priority until all the fields to appear on the page have been specified. You can specify up to five fields per page. For example, to create a page showing the amount of traffic transmitted over your monitored network and to sort the page by the responders that transmitted the most traffic, select 1 from the Sort Priority drop-down list and Responder Bytes from the Field drop-down list. 6. Optionally, click Add Graph to add one or more graph pages to the workflow. A graph section appears.

Begin by typing a name for the page in the Page Name field using up to 80 alphanumeric characters, but no spaces. Then, select the type of graph you want to include on the page: line graph, bar graph, or pie chart. Then, specify what kind of data you want to graph by selecting the x- and yaxes of the graph. On a pie chart, the x-axis represents the independent variable and the y-axis represents the dependent variable. Finally, select the datasets you want to include on the graph. Note that pie charts can only include one data set.

Version 4.7


1183


Chapter 29

Optionally, add a table view to the workflow.

7.

•

To add a table view of individual flows, click Add Table View.

•

To add a table view of flow summaries, click Add Summary Table View.

8. Click Save. The new workflow is saved and added to the list of custom workflows.

Viewing Custom Workflows Requires: IPS or DC/MDC

The method you use to view a workflow depends on whether the workflow is based on one of the predefined event tables or on a custom table. If your custom workflow is based on a predefined event table, use the options in the Analysis & Reporting menu to access the workflow. For example, to access a custom workflow based on the RNA Hosts table on a Defense Center with RNA, select Analysis & Reporting > RNA > Hosts. If, on the other hand, you are using a Defense Center and your custom workflow is based on a custom table, you must access it from the Custom Tables page. For more information, see: •

Viewing Custom Workflows for Predefined Tables on page 1184

•

Viewing Custom Workflows for Custom Tables on page 1185

TIP! If you want to set a custom workflow as your default workflow and bypass the Select Workflow page, use the Event Preference page to set the default workflow. See Setting Event Preferences on page 35 for more information.

Viewing Custom Workflows for Predefined Tables Requires: IPS or DC/MDC

Use the following procedure to view a custom workflow that is not based on a custom table. Keep in mind that workflow access depends on your platform and user role, as described in Selecting Workflows on page 1162. To view a custom workflow based on a predefined table:

Access: Any

h

Select an option from the Analysis & Reporting or other menu corresponding to the table used in your custom workflow. See the Features Using Workflows table on page 1162 for a list of the menu options that depend on workflows. The page that appears next depends on the number of workflows available for that table: •

Version 4.7

If there is only one workflow for the table, the first page of the workflow appears.


1184


•

Chapter 29

If there are multiple workflows for the table and if you have not selected a default workflow, the Select Workflow page appears with a list of the available workflows, including custom workflows. Click the name of the custom workflow you want to use. The first page of the workflow appears.

Viewing Custom Workflows for Custom Tables Requires: DC + RNA

Use the following procedure to view a custom workflow that is based on a custom table. To view a custom workflow based on a custom table:


1.

Select Analysis & Reporting > Custom Tables. The Custom Tables page appears, listing the available custom tables.

2. Click View next to the custom table you want to view. If you have created more than one custom workflow for the custom table, the Select Workflow page appears, listing the workflows based on the table. 3. Click the name of the custom workflow you want to view. The first page of the workflow appears.

Editing Custom Workflows Requires: IPS or DC/MDC

If your event evaluation process changes, you can edit custom workflows to meet your new needs. Note that you cannot edit any of the predefined workflows. To edit a custom workflow:


1.

Select Analysis & Reporting > Custom Workflows. The Custom Workflows page appears, listing the existing custom workflows.

2. Click Edit next to the name of the workflow that you want to edit. The Edit Workflow page appears. 3. Make any changes that you want to the workflow and click Save. The changes you made to the workflow are saved.

Deleting Custom Workflows Requires: IPS or DC/MDC

The following procedure explains how to delete a custom workflow that you no longer need. To delete a custom workflow:


Version 4.7

1.

Select Analysis & Reporting > Custom Workflows. The Custom Workflows page appears, listing the available custom workflows.


1185


Chapter 29

2. Click Delete next to the name of the workflow that you want to delete. The workflow is deleted.

Version 4.7


1186

Chapter 29

Managing the System

As a user with Admin access, you can perform the following system management tasks: •

Version 4.7

Set up a system policy that controls some of the important settings on the Defense Center or 3D Sensor. See Using System Policies on page 1189 for more information. The following sections explain how to configure specific aspects of a system policy: •

To configure specific access policies for your appliance, see Configuring the Access List for Your Appliance on page 1193.

•

To authenticate user credentials against an LDAP directory server, see Configuring Authentication Profiles on page 1194.

•

To configure the maximum number of events allowed in the database, see Configuring Database Event Limits on page 1197.

•

To enable DNS resolution of IP addresses in event views for your appliance, see Configuring DNS Cache Properties on page 1200.

•

To configure a mail relay host for use by email alerting functions and an email address for database purge notifications, see Configuring a Mail Relay Host and Notification Address on page 1201 for more information.

•

To change the language displayed on the web interface, see Specifying a Different Language on page 1202.

•

To add custom login banners that appear when you log into the appliance, see Adding a Custom Login Banner on page 1203.

•

Requires: DC + RNA To configure the kinds of RNA data stored in the database, and therefore the data that other parts of the Sourcefire 3D System can use, see Configuring RNA Settings on page 1204.


1187

Managing the System

Chapter 30

• •

Version 4.7

To synchronize time on the appliance either manually or using an NTP server, see Synchronizing Time on page 1208.

Configuring the System Settings on page 1211 explains how to configure aspects of the system that are not controlled by the system policy. The following sections explain how to configure specific system settings: •

To view information about the appliance and to change the appliance name, see Viewing and Modifying the Appliance Information on page 1213.

•

To view your current license, see Verifying Your License on page 1216.

•

To add and manage feature licenses, see Managing Feature Licenses on page 1217.

•

To configure network settings, see Configuring Network Settings on page 1220.

•

To shut down or reboot the appliance, see Shutting Down and Restarting the System on page 1222.

•

To set up the management virtual network and port that the Defense Center uses to communicate in high availability mode with another Defense Center, see Configuring the Communication Channel on page 1223.

•

To set up management with a Defense Center, see Configuring Remote Access to the Defense Center on page 1226.

•

If the system policy in effect allows you to set the time manually, see Setting the Time Manually on page 1229 for information about changing the time on the appliance.

•

Requires: DC To suppress health events from selected appliances, see Blacklisting Health Modules on page 1230.

•

Requires: DC + RNA To specify the NetFlow devices you want to use to collect flow data, see Specifying NetFlow Devices on page 1231.

•

Purge the RNA and RUA databases on the Defense Center. See Purging the RNA and RUA Databases on page 1232 for more information.

•

Install updates on your Defense Center or managed sensors. See Updating System Software on page 1233 for more information.

•

Install VDB updates on your Defense Center or managed sensors. See Installing the VDB Update on page 1237 for more information.

•

Back up and restore your system. See Using Backup and Restore on page 1239 for more information.

•

Restore your Defense Center to the software version and factory default settings it originally shipped with. See Restoring the Defense Center to Factory Defaults on page 1247 for more information.

•

Import and export policies from one appliance to another. See Importing and Exporting Objects on page 1248.


1188

Managing the System Using System Policies

Chapter 30

•

Requires: DC Configure Sourcefire Event Streamer to stream events to external Event Streamer clients. See Managing Event Streamer Clients on page 1256 for more information.

•

View the status of tasks including manual and scheduled policy applications, software update pushes, and software update installations. See Viewing the Status of Long-Running Tasks on page 1259.

Using System Policies Requires: Any

A system policy allows you to manage the following on your Defense Center: •

access configuration

•

authentication profiles (Defense Center only)

•

database limits

•

DNS cache settings

•

the mail relay host and a notification address for database prune messages

•

language selection (English or Japanese)

•

login banner

•

the kinds and amount of RNA data stored in the database (Defense Center only)

•

time synchronization settings

You can use a system policy to control the aspects of your Defense Center that are likely to be similar for other Sourcefire 3D System appliances in your deployment. For example, your organization’s security policies may require that your appliances have a “No Unauthorized Use” message when a user logs in. With system policies, you can set the login banner once in a system policy on a Defense Center and then apply the policy to all the sensors that it manages. Contrast a system policy, which controls aspects of an appliance that are likely to be similar across a deployment, with system settings, which are likely to be specific to a single appliance. See Configuring the System Settings on page 1211 for more information. IMPORTANT! sensors.

You cannot apply system policies to Nokia-based software


Version 4.7

•

Creating a System Policy on page 1190

•

Editing a System Policy on page 1191

•

Applying a System Policy on page 1192

•

Deleting System Policies on page 1192


1189


Chapter 30

•

Exporting Objects on page 1248

•

Importing Objects on page 1252

Creating a System Policy Requires: Any

When you create a system policy, you assign it a name and a description. Next, you configure the various aspects of the policy, each of which is described in its own section. To create a system policy:

Access: Admin

1.

Select Operations > System Policy. The System Policy page appears.

2. Click Create Policy. The Create page appears.

3. From the drop-down list, select an existing policy to use as a template for your new system policy. 4. Type a name and description (up to 40 alphanumeric characters and spaces each) for your new policy. 5. Click Save. Your system policy is saved and the Access List page appears. For information about configuring each aspect of the system policy, see one of the following sections:

Version 4.7

•

Configuring the Access List for Your Appliance on page 1193

•

Configuring Authentication Profiles on page 1194

•

Configuring Database Event Limits on page 1197

•

Configuring DNS Cache Properties on page 1200

•

Configuring a Mail Relay Host and Notification Address on page 1201

•

Specifying a Different Language on page 1202

•

Adding a Custom Login Banner on page 1203


1190


Chapter 30

•


•

Synchronizing Time on page 1208

•

Serving Time from the Defense Center on page 1210

Editing a System Policy Requires: Any

You can edit a system policy that is currently in use, but remember to re-apply the policy as explained in Applying a System Policy on page 1192. To edit an existing system policy:

Access: Admin

1.

Select Operations > System Policy. The System Policy page appears, including a list of the existing system policies.

2. Click Edit next to the system policy that you want to edit. Access List, the first section of the system policy, appears. For information about configuring each aspect of the system policy, see one of the following sections: •

Configuring the Access List for Your Appliance on page 1193

•

Configuring Authentication Profiles on page 1194

•

Configuring Database Event Limits on page 1197

•

Configuring DNS Cache Properties on page 1200

•

Configuring a Mail Relay Host and Notification Address on page 1201

•

Specifying a Different Language on page 1202

•

Adding a Custom Login Banner on page 1203

•


•

Synchronizing Time on page 1208

•

Serving Time from the Defense Center on page 1210

IMPORTANT! If you are editing the current system policy, make sure you apply the updated policy when you are finished. See Applying a System Policy on page 1192.

Version 4.7


1191


Chapter 30

Applying a System Policy Requires: Any

After you create or edit a system policy, your settings do not take effect until you apply it. IMPORTANT! sensors.

You cannot apply system policies to Nokia-based software

To apply a system policy: Access: Admin

1.


2. Click Apply next to the system policy that you want to apply. On the Defense Center, the system policy is applied.

Deleting System Policies Requires: Any

You can delete a system policy even if it is in use. If the policy is still in use, it is used until a new policy is applied. Default system policies cannot be deleted. To delete a system policy:

Access: Admin

1.


2. Click Delete next to the system policy that you want to delete. The policy is deleted.

Version 4.7


1192

Managing the System Configuring the Access List for Your Appliance

Chapter 30

Configuring the Access List for Your Appliance Requires: Any

The Access List page allows you to control which computers can access your appliance on specific ports. By default, port 443 (Secure Sockets Layer, or SSL), which is used to access the web interface and port 22 (Secure Shell, or SSH), which is used to access the command line, are enabled for any IP address. WARNING! By default, access to the appliance is not restricted. To operate the appliance in a more secure environment, consider adding access to the appliance for specific IP addresses and then deleting the default any option. The access list is part of the system policy. You can specify the access list either by creating a new system policy or by editing an existing policy. In either case, the access list does not take effect until you apply the system policy. To configure the access list:

Access: Admin

1.



To modify the access list in an existing system policy, click Edit next to the system policy.

•

To configure the access list as part of a new system policy, click Create Policy. Provide a name and description for the system policy as described in Creating a System Policy on page 1190, and click Save.

In either case, the Access List page appears.

3. To delete one of the current settings, click Delete. WARNING! If you delete access for the IP address that you are currently using to connect to the appliance interface (and if there is no entry for “IP=any port=443”), you will lose access to the system when you apply the policy. The setting is removed.

Version 4.7


1193

Managing the System Configuring Authentication Profiles

Chapter 30

4. To add access for one or more IP addresses, click Add. The Add IP Address page appears.

5. In the IP Address field, use the following syntax depending on the IP addresses you want to add: •


•

an IP address range using CIDR notation (for example, 192.168.1.1/24)

•

any, to designate any IP address

6. Select SSL, SSH, or both to specify which ports you want to enable for these IP addresses, then click Add. The Access List page appears again, reflecting the changes you made. TIP! You can click Add to add access for additional IP addresses or click Delete to remove access from other IP addresses. 7.

Click Save Policy and Exit. The system policy is updated. Your changes do not take effect until you apply the system policy. See Applying a System Policy on page 1192 for more information.

Configuring Authentication Profiles Requires: DC/MDC

Normally, when a user logs into a Sourcefire 3D System Defense Center or managed sensor, the appliance verifies the user credentials by comparing them to a user account stored in the Defense Center or managed sensor’s local database. However, if you create an authentication object referencing an external authentication server, you can apply the system policy to let users logging into the Defense Center or managed sensor authenticate to that server rather than using the local database. When you apply a policy with authentication enabled to an appliance, the appliance verifies the user credentials against LDAP users on the LDAP server. In addition, if a user has internal authentication enabled and the user credentials are not found in the internal database, the appliance then checks the external server for a set of matching credentials. If a user has the same username on multiple systems, all passwords across all servers work. Note, however, that if authentication fails on the available LDAP servers, the appliance does not revert to checking the local database.

Version 4.7


1194


Chapter 30

When you enable authentication, you can set the default user role for any user whose account is externally authenticated. For example, if you set up an authentication profile that retrieves only users in the Network Security group in your company, you may set the default role to Data Access so users can access collected event data without any additional user configuration on your part. However, if your authentication profile retrieves records for other personnel in addition to the security group, you would probably want to set the role to No Access. For more information on available user roles, see Understanding User Privileges on page 1264. When you create an authentication object on your Defense Center, you can set a filter search attribute to specify the set of users who can successfully authenticate against the LDAP server. See Configuring Attribute Mapping on page 1270 for more information. If the role is set to No Access, users can connect to the appliance but cannot log in. After a user attempts to log in, their account is listed on the User Management page, where you can modify the account settings to grant additional permissions. For more information on modifying a user account, see Modifying User Privileges and Options on page 1287. For a complete procedure for logging in initially as an externally authenticated user, see Logging into the Appliance to Set Up an Account on page 32. If you configure the system policy to use one user role and apply the policy, then later modify the policy to use another default user role and re-apply, any user accounts created before the modification retain the first user role until you modify or delete and recreate them. The Authentication Profiles page only displays in the system policy on a Defense Center. You can enable authentication in a system policy on your Defense Center and then push that policy to managed sensors. Once you apply the policy to a sensor, eligible LDAP users can log into the sensor. However, the system policy on the sensor does not display authentication profile settings, so you cannot manage them on the sensor itself. To make changes to the authentication profile settings, you have to modify the policy on the Defense Center and then push it to the sensor again. To disable authentication on a managed sensor, you can either disable it in a system policy on the Defense Center and push that to the sensor or apply a local system policy (which cannot contain authentication profile settings) on the sensor. Note that authentication for the Nokia Network Voyager interface is managed through Voyager. Note that you can only enable external authentication on Defense Centers. If a user with internal authentication attempts to log in, the appliance first checks if that user is in the local user database. If the user exists, the appliance then checks the username and password against the local database. If a match is found, the user logs in successfully. If the login fails, however, and LDAP is enabled, the appliance checks the user against each LDAP server in the authentication order shown in the system policy. If the username and password match results from an LDAP server, the appliance changes the user to an LDAP user with the default privileges for LDAP users.

Version 4.7


1195


Chapter 30

If an LDAP user attempts to log in, the appliance checks the username and password against the LDAP database. If a match is found, the user logs in successfully. If the login fails, the user login attempt is rejected. LDAP users cannot authenticate against the user list in the local database. If the user is a new LDAP user, a LDAP user account is created in the local database the default LDAP privileges. To enable authentication of users on external servers: Access: Admin

1.

On the Defense Center, select Operations > System Policy. The System Policy page appears.


To modify the authentication profile settings in an existing system policy, click Edit next to the system policy.

•

To configure the authentication profile settings as part of a new system policy, click Create Policy. Provide a name and description for the system policy as described in Creating a System Policy on page 1190, and click Save.

In either case, the Access List page appears. 3. Click Authentication Profiles. The Authentication Profiles page appears.

4. From the Status drop-down list, select Enabled. 5. From the Default User Role drop-down list, select a user role to define the default permissions you want to grant to users authenticated externally. 6. If you want to use the external server to authenticate shell access accounts as well, select Enabled from the Shell Authentication drop-down list. 7.

To enable use of an authentication object, click Enable next to the object. IMPORTANT! You must enable at least one authentication object to enable external authentication.

Version 4.7


1196

Managing the System Configuring Database Event Limits

Chapter 30

8. Optionally, use the up and down arrows to change the order in which authentication servers are accessed when an authentication request occurs. Remember that shell access users can only authenticate against the server whose authentication object is highest in the profile order. 9. Click Save Policy and Exit. The system policy is updated. Your changes do not take effect until you apply the system policy. See Applying a System Policy on page 1192 for more information.

Configuring Database Event Limits Requires: Any

You can use the Database page to specify the maximum number of events you want to store on an appliance. To improve performance, you should try to tailor the database event limit to the number of events you regularly work with. In most cases, the minimum number of records you can store in any database is one record (or, in the case of the compliance violation history database, one day’s history). However, for some databases, you can choose not to store any events. These databases include those that store RNA and RUA events, as well as flow events, flow summaries, and health events. The Database Event Limits table below describes the maximum number of records you can store in the databases on your appliance. Note that if you apply a system policy to an appliance that does not support the maximum limit you specify (for example, if you specify 100 million intrusion events and apply that policy to a 3D Sensor), the maximum limit for the appliance is silently enforced. IMPORTANT! Database event limits apply only to the Defense Center and the Master Defense Center. Events are not stored on Nokia sensors.

Database Event Limits The...

Is the database that stores...

And can store up to...

Intrusion Event Database (Defense Center or Master Defense Center)

intrusion events on a Defense Center or on a Master Defense Center (which is always a DC3000)

10 million events on the DC1000 100 million events on the DC3000

RNA Event Database

RNA network discovery events on a Defense Center

10 million events

RNA Flow Database

RNA flows on a Defense Center


Version 4.7


1197


Chapter 30

Database Event Limits (Continued) The...

Is the database that stores...

And can store up to...

RNA Flow Summary Database

RNA flow summaries (aggregated RNA flows) on a Defense Center


Compliance & White List Event Database

compliance events and white list events on a Defense Center or Master Defense Center

1 million events

Health Event Database

health events on a Defense Center or Master Defense Center

1 million events

Audit Event Database

audit records

100,000 records

Remediation Status Event Database

remediation status events on a Defense Center

10 million events

White List Violation History Database

the white list violation history of the hosts on your network, on a Defense Center

a 30-day history of violations

RUA Event Database

RUA events on a Defense Center

10 million events

RUA History Database

RUA storage of user logins on a Defense Center

10 million user login records

SEU Import Log Database

SEU import log records

1 million records

Note that if the number of events in the intrusion event database exceeds the maximum, the oldest events and packet files are pruned until the database is back within limits. In addition, if the /var disk partition reaches 85% of its capacity, unified files are deleted from the system, beginning with the oldest files. See Configuring a Mail Relay Host and Notification Address on page 1201 for information about generating automated email notifications when events are automatically pruned. For information on manually pruning the RNA and RUA databases, see Purging the RNA and RUA Databases on page 1232. To configure the maximum number of records in the database: Access: Admin

1.


Version 4.7


1198


Chapter 30

2. Click Edit next to the system policy that you want to modify. The Access List page appears. 3. Click Database. The Database page appears. The following graphic shows the Database page on the Defense Center.

Version 4.7


1199

Managing the System Configuring DNS Cache Properties

Chapter 30

4. For each of the databases, enter the number of records you want to store. For information on how many records each database can maintain, see the Database Event Limits table on page 1197. 5. Click Save Policy and Exit. The system policy is updated. Your changes do not take effect until you apply the system policy. See Applying a System Policy on page 1192 for more information.

Configuring DNS Cache Properties Requires: Any

If you have a DNS server configured on the Network page, you can configure the appliance to resolve IP addresses automatically on the event view pages. As an administrator, you can also configure basic properties for DNS caching performed by the appliance. Configuring DNS caching allows you to identify IP addresses you previously resolved without performing additional lookups. This can reduce the amount of traffic on your network and speed the display of event pages when IP address resolution is enabled. To configure the DNS cache properties:

Access: Admin

1.



To modify the DNS cache settings in an existing system policy, click Edit next to the system policy.

•

To configure the DNS cache settings as part of a new system policy, click Create Policy. Provide a name and description for the system policy as described in Creating a System Policy on page 1190, and click Save.

In either case, the Access List page appears. 3. Click DNS Cache. The DNS Cache page appears.

Version 4.7


1200

Managing the System Configuring a Mail Relay Host and Notification Address

Chapter 30

4. Next to DNS Resolution Caching, select Enabled to enable caching or Disabled to disable it. IMPORTANT! DNS resolution caching is a system-wide setting that allows the caching of previously resolved DNS lookups. To configure IP address resolution on a per-user-account basis, users must also select Event View Settings from the User Preferences menu, enable Resolve IP Addresses, and then click Save. For information about configuring DNS servers, see Configuring Network Settings on page 1220. For information about configuring event preferences, see Setting Event Preferences on page 35. 5. In the DNS Cache Timeout field, enter the number of minutes a DNS entry remains cached in memory before it is removed for inactivity. The default setting is 300 minutes (five hours). 6. Click Save Policy and Exit. The system policy is updated. Your changes do not take effect until you apply the system policy. See Applying a System Policy on page 1192 for more information. WARNING! Although DNS caching is enabled for the appliance, IP address resolution is not enabled on a per-user basis unless it is configured on the Events page accessed from the User Preferences menu.

Configuring a Mail Relay Host and Notification Address Requires: Any

If you plan to: •

email event-based reports

•

email status reports for scheduled tasks

•

use email for RNA event, impact flag, and compliance event alerting (Defense Center only - requires RNA)

•

use email for intrusion event alerting (Defense Center only - requires IPS)

•

use email for health event alerting (Defense Center only)

you must configure a mail host. In addition, you can configure an email address that will receive notifications when intrusion events and audit logs are pruned from the database. To configure a mail relay host: Access: Admin

1.


Version 4.7


1201

Managing the System Specifying a Different Language

Chapter 30


To modify the email settings in an existing system policy, click Edit next to the system policy.

•

To configure the email settings as part of a new system policy, click Create Policy. Provide a name and description for the system policy as described in Creating a System Policy on page 1190, and click Save.

In either case, the Access List page appears. 3. Click Email Notification. The Configure Email Notification page appears.

4. In the Mail Relay Host field, type the hostname or IP address of the mail server you want to use. IMPORTANT!

The mail host you enter must allow access from the appliance.

5. Optionally, in the Purge Notification Address field, enter the email address you want to receive notifications when intrusion events and audit logs are pruned from the appliance’s database. 6. Click Save Policy and Exit. The system policy is updated. Your changes do not take effect until you apply the system policy. See Applying a System Policy on page 1192 for more information.

Specifying a Different Language Requires: Any

You can use the Language page to specify a different language for the web interface. WARNING! The language you select here is used for the web interface for every user who logs into the appliance. To select a different language for the user interface:

Access: Admin

1.


Version 4.7


1202

Managing the System Adding a Custom Login Banner

Chapter 30


To modify the language settings in an existing system policy, click Edit next to the system policy.

•

To configure the language settings as part of a new system policy, click Create Policy. Provide a name and description for the system policy as described in Creating a System Policy on page 1190, and click Save.

In either case, the Access List page appears. 3. Click Language. The Language page appears.

4. Select the language you want to use. 5. Click Save Policy and Exit. The system policy is updated. Your changes do not take effect until you apply the system policy. See Applying a System Policy on page 1192 for more information.

Adding a Custom Login Banner Requires: Any

You can create a custom login banner that appears when users log into the appliance using SSH and on the login page of the web interface. Banners can contain any printable characters except the less-than symbol (). Custom login banners are part of the system policy. You can specify the login banner either by creating a new system policy or by editing an existing policy. In either case, the login banner is not used until you apply the system policy. To add a custom banner:

Access: Admin

1.


Version 4.7


1203

Managing the System Configuring RNA Settings

Chapter 30


To modify the login banner in an existing system policy, click Edit next to the system policy.

•

To configure the login banner as part of a new system policy, click Create Policy. Provide a name and description for the system policy as described in Creating a System Policy on page 1190, and click Save.

In either case, the Access List page appears. 3. Click Login Banner. The Login Banner page appears.

4. In the Custom Login Banner field, enter the login banner that you want to use with this system policy. 5. Click Save Policy and Exit. The system policy is updated. Your changes do not take effect until you apply the system policy. See Applying a System Policy on page 1192 for more information.

Configuring RNA Settings Requires: DC/ MDC + RNA

Version 4.7

The RNA settings control the kinds of RNA data stored in the database, and therefore determines the data that other parts of the Sourcefire 3D System can


1204


Chapter 30

use. The RNA settings, described in the RNA Settings table, also control how long data is retained in the network map. RNA Settings Field

Description

Host Timeout

The amount of time that passes, in seconds, before RNA drops a host from the network map due to inactivity. The default setting is 604,800 seconds (7 days). IMPORTANT! To avoid premature timeout of hosts, make sure that the host timeout value is longer than the update interval in the RNA detection policy. For more information, see Creating an RNA Detection Policy on page 138.

Service Timeout

The amount of time that passes, in seconds, before RNA drops a service from the network map due to inactivity. The default setting is 604,800 seconds (7 days). IMPORTANT! To avoid premature timeout of services, make sure that the service timeout value is longer than the update interval in the RNA detection policy. For more information, see Creating an RNA Detection Policy on page 138.

Client Application Timeout

The amount of time that passes, in seconds, before RNA drops a client application from the network map due to inactivity. The default setting is 604,800 seconds (7 days). IMPORTANT! Make sure that the client application timeout value is longer than the update interval in the RNA detection policy. For more information, see Creating an RNA Detection Policy on page 138.

Drop New Hosts When Host Limit Reached

Enable this check box if you want new hosts rather than old hosts dropped when the Defense Center reaches its host limit and the network map is full. This option is especially valuable if you want to prevent spoofed hosts from taking the place of valid hosts in the network map.

Combine Flows for Out-Of-Network Responders

Enable this check box if you want to treat flow summary data from IP addresses that are not in your list of monitored networks (as defined by your RNA detection policy) as coming from a single host. The Defense Center combines flow summaries involving a host on your monitored network and one or more hosts not on your monitored network if the flow summaries use the same port, protocol, service, and if they were detected by the same detection engine (for flows detected by 3D Sensor) or were exported by the same NetFlow device and were processed by the same detection engine. Event views, graphs, and reports use “external” to indicate the hosts outside your monitored network, instead of an individual IP address. This can reduce the amount of space required to store flow summary data, and can also speed up the rendering of flow data graphs.

Version 4.7


1205


Chapter 30

RNA Settings (Continued) Field

Description

Drop Duplicate RNA Flow Events

Enable this check box if you want the Defense Center to drop duplicate flow events generated by 3D Sensors with RNA. Duplicate flow events can be created if you use two RNA detection policies, each of which is monitoring a separate network segment using separate detection engines. In that scenario, each detection engine generates a flow event when RNA detects that a connection is terminated between a monitored host on one of the networks and a monitored host on the other network. On the other hand, if you use one policy to monitor both networks, only the reporting detection engine for the flow initiator generates a flow event. Duplicate flow events can also be created if you overlap network segment coverage with your RNA detection engines in your RNA detection policy. Note that best practices are to use only one detection policy and to not overlap network segment coverage; not following best practices can degrade performance as the Defense Center attempts to resolve the conflicts, and can also use excessive bandwidth.

Drop Duplicate NetFlow Events

Enable this check box if you want the Defense Center to drop duplicate flow events that are based on NetFlow data. Duplicate NetFlow events can be created, for example, if two NetFlow devices export information about the same session. Just as with RNA flow events, best practices are to avoid creating duplicate NetFlow events, For more information, see Drop Duplicate RNA Flow Events.

Version 4.7


1206


Chapter 30

RNA Settings (Continued) Field

Description

Vulnerabilities to use for Impact Assessment Requires: IPS

Select the checkboxes in this section to configure how the Sourcefire 3D System performs impact flag correlation with intrusion events. • Select the Use RNA Vulnerability Mappings check box if you want to use RNA vulnerability information to perform impact flag correlation. • Select the Use Nessus Vulnerability Mappings check box if you are using the integrated Nessus scan capability and you want to use vulnerability lookups from Nessus to perform impact flag correlation. Note that you must perform a Nessus scan on your network for this option to be useful. For more information, see Understanding Nessus Scans on page 591. • Select the Third Party Vulnerability Mappings check box if you want to use third-party vulnerability references to perform impact flag correlation. For more information, see Mapping Third-Party Vulnerabilities on page 566. You can enable any or all of the checkboxes in this section; if IPS generates an intrusion event and the Sourcefire 3D System is able to use any of the methods you specified to determine that the host involved in the event is vulnerable to the attack or exploit, the intrusion event will be marked with the red (Vulnerable) impact flag. Note that if you clear all the checkboxes, intrusion events will never be marked with the red impact flag. For more information, see Using Impact Flags to Evaluate Events on page 686.

RNA Event Logging

Expand this section and use the check boxes to specify the types of RNA network discovery events that you want to log in the database. See Understanding RNA Network Discovery Event Types on page 219 for information about each event type

Host Input Event Logging

Expand this section and use the check boxes to specify the types of RNA host input events that you want to log in the database. See Understanding RNA Host Input Event Types on page 223 for information about each event type. To specify RNA settings:

Access: Admin

1.



To modify the RNA settings in an existing system policy, click Edit next to the system policy.

•

To configure the RNA settings as part of a new system policy, click Create Policy. Provide a name and description for the system policy as described in Creating a System Policy on page 1190, and click Save.


Version 4.7


1207

Managing the System Synchronizing Time

Chapter 30

3. Click RNA Settings. The RNA Settings page appears.

4. Specify the RNA settings that you want for your Defense Center. See the RNA Settings table on page 1205 for more information. 5. Optionally, specify the RNA network discovery events that you want to log by clicking the arrow next to RNA Event Logging. All the event types are enabled by default. See the RNA Network Discovery Event Types table on page 220 for more information. 6. Optionally, specify the RNA host input events that you want to log by clicking the arrow next to Host Input Event Logging. All the event types are enabled by default. See the RNA Host Input Event Types table on page 224 for more information. Click Save Policy and Exit.

7.

The system policy is updated. Your changes do not take effect until you apply the system policy. See Applying a System Policy on page 1192 for more information.

Synchronizing Time Requires: Any

Version 4.7

You can manage time on the appliance using the Time Synchronization page. You can choose to synchronize the time: •

manually

•

using one or more NTP servers (one of which can be a Defense Center)


1208


Chapter 30

Time settings are part of the system policy. You can specify the time settings either by creating a new system policy or by editing an existing policy. In either case, the time setting is not used until you apply the system policy. Note that time settings are displayed on most pages on the appliance in local time using the time zone you set on the Time Zone page (America/New York by default), but are stored on the appliance itself using UTC time. In addition, the current time appears in UTC at the top of the Time Synchronization page (local time is displayed in the Manual clock setting option, if enabled). IMPORTANT! You cannot manage time settings for the Sourcefire Sensor on Nokia through the Defense Center web interface. Use the Nokia Network Voyager instead. You can synchronize the appliance’s time with an external time server. If you specify a remote NTP server, your appliance must have network access to it. Connections to NTP servers do not use configured proxy settings. To use the Defense Center as an NTP server, see Serving Time from the Defense Center on page 1210. The procedure for synchronizing time differs slightly depending on whether you are using the web interface on a Defense Center or a 3D Sensor. Each procedure is explained separately below. To synchronize time on the Defense Center: Access: Admin

1.



To modify the time settings in an existing system policy, click Edit next to the system policy.

•

To configure the time settings as part of a new system policy, click Create Policy. Provide a name and description for the system policy as described in Creating a System Policy on page 1190, and click Save.


Version 4.7


1209


Chapter 30

3. Click Time Synchronization. The Time Synchronization page appears.

4. If you want to serve time from the Defense Center to your managed sensors, in the Serve time via NTP drop-down list, select Enabled. Note that if you set this option to Enabled and then apply the system policy to a sensor rather than a Defense Center, this value is ignored. Only Defense Centers can act as NTP servers. 5. You have two options for specifying how the time is synchronized on the appliance: •

To set the time manually, select Manually in the System Settings. See Setting the Time Manually on page 1229 for information about setting the time after you apply the system policy.

•

To receive time through NTP from a different server, select Via NTP Server from and, in the text box, type a comma-separated list of IP addresses for the NTP servers you want to use or, if DNS is enabled, type the fully qualified host and domain names.

6. Click Save Policy and Exit. The system policy is updated. Your changes do not take effect until you apply the system policy. See Applying a System Policy on page 1192 for more information. IMPORTANT! It may take a few minutes for the appliance to synchronize with the configured NTP servers.

Serving Time from the Defense Center Requires: DC/MDC

You can configure the Defense Center as a time server using NTP and then use it to synchronize time between the Defense Center and managed 3D Sensors. IMPORTANT! You cannot serve time from a Defense Center to a Sourcefire Sensor for Nokia.

Version 4.7


1210

Managing the System Configuring the System Settings

Chapter 30

To configure the Defense Center as an NTP server: Access: Admin

1.

On the Defense Center, select Operations > System Policy. The System Policy page appears.


To modify the NTP server settings in an existing system policy, click Edit next to the system policy.

•

To configure the NTP server settings as part of a new system policy, click Create Policy. Provide a name and description for the system policy as described in Creating a System Policy on page 1190, and click Save.

In either case, the Access List page appears. 3. Click Time Synchronization. The Time Synchronization page appears. 4. From the Serve Time via NTP drop-down list, select Enabled. 5. In the Set My Clock option for the sensors, select Via NTP from Defense Center. 6. Click Save Policy and Exit. The system policy is updated. Your changes do not take effect until you apply the system policy. See Applying a System Policy on page 1192 for more information.

Configuring the System Settings Requires: Any

Version 4.7

The system settings include a series of linked pages that you can use to view and modify settings on your appliance. Contrast the system settings, which are likely to be specific to a single appliance, with a system policy, which controls aspects of an appliance that are likely to be similar across a deployment. See Using System Policies on page 1189 for more information.


1211

Managing the System Configuring the System Settings

Chapter 30

The System Settings Options table describes the options you can configure in the system settings. System Settings Options Option

Description

Information

Allows you to view current information about the appliance. You can also change the appliance name. See Viewing and Modifying the Appliance Information on page 1213 for more information.

License

Provides you with options for managing your current licenses and for adding additional feature licenses on the platforms that support them. See Managing Licenses on page 1215 for more information.

Network

Enables you to change options such as the IP address, hostname, and proxy settings of the appliance that were initially set up as part of the installation. See Configuring Network Settings on page 1220 for more information.

Process

Provides options that you can use to: • shut down the appliance • reboot the appliance • restart the Sourcefire 3D System-related processes See Shutting Down and Restarting the System on page 1222 for more information.

Remote Management

On the 3D Sensor, enables you to establish communications with a Defense Center from the sensor. See Configuring Remote Access to the Defense Center on page 1226 for more information. On the Defense Center, enables you to specify values for the internal network and management port that the Defense Center uses to communicate with its managed sensors and high availability peer. See Configuring the Communication Channel on page 1223 for more information.

Time

Version 4.7

Displays the current time. If the time synchronization settings in the current system policy for the appliance is set to Manual, then you can use this page to change the time. See Setting the Time Manually on page 1229 for more information.


1212

Managing the System Viewing and Modifying the Appliance Information

Chapter 30

System Settings Options (Continued) Option

Description

Health Blacklist

On the Defense Center, allows you to temporarily disable health monitoring for a 3D Sensor to prevent the Defense Center from generating unnecessary health events. See Blacklisting Health Modules on page 1230 for more information.

NetFlow Devices

On the Defense Center, allows you to specify the NetFlow devices you want to use to collect flow data. See Specifying NetFlow Devices on page 1231 for more information.

To configure the system settings: Access: Admin

h

Select Operations > System Settings. The Information page appears, with a list on the left side of the page that you can use to access other system settings.

Viewing and Modifying the Appliance Information Requires: Any

The Information page provides you with information about the Defense Center or 3D Sensor. The information includes view-only information such as the product name and model number, the operating system and version, and the current appliance-level policies. The page also provides you with an option to change the name of the appliance. IMPORTANT! You cannot view sensor information for Nokia-based software sensors, other than the sensor name (used only in the web interface) and product model.

Version 4.7


1213

Managing the System Viewing and Modifying the Appliance Information

Chapter 30

The Appliance Information table describes each field. Appliance Information

Version 4.7

Field

Description

Name

A name you assign to the appliance. Note that this name is only used within the context of the Sourcefire 3D System. Although you can use the hostname as the name of the appliance, entering a different name in this field does not change the hostname.

Product Model

The model name for the appliance.

Software Version

The version of the software currently installed.

Store Events Only on Defense Center

Enable this check box to store event data on the Defense Center, but not the managed sensor. Clear this check box to store event data on both appliances.

Prohibit Packet Transfer to the Defense Center

Enable this check box to prevent the managed sensor from sending packet data with the events. Clear this check box to allow packet data to be stored on the DC with events.

Operating System

The operating system currently running on the appliance.


The version of the operating system currently running on the appliance.

IP Address

The IP address of the appliance.

Current Policies

The appliance-level policies currently applied to the appliance. If a policy has been updated since it was last applied, the name of the policy appears in italics.

Model Number

The model number for the appliance. This number can be important for troubleshooting.


1214

Managing the System Managing Licenses

Chapter 30

To modify the appliance information: Access: Admin

1.

Select Operations > System Settings. The Information page appears. The Defense Center version of the page is shown below.

For comparison, the 3D Sensor version of the page is shown below.

2. To change the appliance name, type a new name in the Name field. WARNING! The name must be alphanumeric characters and should not be composed of numeric characters only. 3. To save your changes, click Save. The page refreshes and your changes are saved.

Managing Licenses Requires: Any

Version 4.7

For Defense Centers, the Sourcefire 3D System requires that you apply a base license file to each appliance as part of the installation process. You can also add feature licenses such as RNA host licenses and Intrusion Agent licenses.


1215


Chapter 30

See the following for more information: •

Verifying Your License on page 1216

•

Managing Feature Licenses on page 1217

•

Adding Feature Licenses on page 1217

•

Viewing Feature Licenses on page 1217

Verifying Your License Requires: Any

During installation, the user who sets up the appliance adds the software license as part of the process. In most cases, you do not need to re-install the license. To verify the license file:

Access: Admin

1.


2. Click License. The License page appears. 3. Under Product Licenses, click View/Edit License. The Manage License page appears. 4. Click Verify License. •

If the license file is valid, a message appears under the License field. Do not proceed to step 5.

•

If the license file is invalid, continue with step 5 to obtain a license and install it.

5. Click Get License. The Licensing Center web site appears. IMPORTANT! If your web browser cannot access the Internet, you must switch to a host that can access it. Copy the license key at the bottom of the page and browse to https://www.keyserver.nokia.sourcefire.com/. 6. Follow the on-screen instructions for an appliance license to obtain your license file, which will be sent to you in an email.

Version 4.7


1216


Chapter 30

Copy the license file from the email, paste it into the License field, and click Submit License.

7.

If the license file is correct, the license is added to the appliance, and the features for the appliance are available in the web interface. IMPORTANT! If you purchased a feature license, click Add New License and add it using the Add Feature License page. For more information about feature licenses, see Managing Feature Licenses on page 1217.

Managing Feature Licenses Requires: DC

The Defense Center uses feature licenses to allow for additional features. Feature licenses include: •

NetFlow licenses, which specify the number of NetFlow devices you can use to gather flow data

•

RUA licenses, which allow you to use the RUA feature

•

RNA host licenses, which specify the number of hosts that you can monitor with RNA


Adding Feature Licenses on page 1217

•

Viewing Feature Licenses on page 1217

Adding Feature Licenses Requires: DC

Your Defense Center will not receive any events from your Sourcefire Sensor on Nokia until you add the appropriate feature licenses to the Defense Center. See Adding Feature Licenses for a Sourcefire Sensor on Nokia on page 54 for more information. IMPORTANT! Both Defense Centers in a high-availability pair must have NetFlow licenses for at least the number of NetFlow devices you are using. If one Defense Center does not have a NetFlow license, it will not receive data from your NetFlow devices.

Viewing Feature Licenses Requires: DC

The licenses page displays the base and feature licenses that you have added to the Defense Center. The first license that appears shows the Defense Center’s base product license. Base licenses show the license status, model code, node (MAC address), expiration date, and provides a link that allows you to view or edit the license. For

Version 4.7


1217


Chapter 30

more information about viewing and modifying base licenses, see Verifying Your License on page 1216. If you have feature or host licenses installed, they appear below the base license. The NetFlow License Columns table describes each column that appears in an NetFlow license. NetFlow License Columns Column

Description

Feature ID

Displays the ID number that corresponds with the feature being licensed.

Serial Number

Displays the feature serial number.

Status

Indicates whether the license is valid or not.

Model

Displays the appliance model number.

Allowed NetFlow Exporters

Lists the number of NetFlow devices that the license allows you to use.

Node

Displays the appliance’s MAC address.

Expires

Displays the date and time that the feature license expires.

Action

Allows you to delete the NetFlow license by clicking Delete.

The RNA Host License Columns table describes each column that appears in an RNA host license. RNA Host License Columns

Version 4.7

Column

Description

Feature ID


Serial Number


Status


Number of Hosts

Lists the number of monitored hosts added by the license.


1218


Chapter 30

RNA Host License Columns (Continued) Column

Description

Model


Node


Expires


Action

Allows you to delete the host license by clicking Delete.

The RNA Maximum Hosts Limits section of the feature license page summarizes the number of allowable detectable hosts. It displays the number of hosts added by feature licenses and the total hosts that can be monitored by the Defense Center. The RUA User License Columns table describes each column that appears in an RUA host license. RUA User License Columns Column

Description

Feature ID


Serial Number


Status


Model


Number of Users

Lists the number of monitored Users added by the license.

Node


Expires


Action

Allows you to delete the host license by clicking Delete.

The RUA Maximum User Limits section of the feature license page summarizes the number of allowable detectable users. It displays the number of users added by feature licenses and the total users that can be monitored by the Defense Center.

Version 4.7


1219

Managing the System Configuring Network Settings

Chapter 30

To view information about the license you added: Access: Admin

1.


2. Click License. The License page appears, showing the base license and any feature licenses you have added. To delete a feature license at any time: h

In the Action column for the feature license you want to delete, click Delete.

Configuring Network Settings Requires: Any

You can choose to use DHCP network settings or static network settings for your appliance. If you specify DHCP, the appliance automatically retrieves its network settings from a local DHCP server. If you specify Static, you must manually configure all network properties. IMPORTANT! You cannot manage network settings for the Sourcefire Sensor on Nokia through the Defense Center web interface. Use the Nokia Network Voyager instead. Static Network Configuration Settings Setting

Description

Management Interface and Netmask

The IP address and network mask for the management interface. In most installations, the management interface is connected to an internal, protected network. This is the IP address that Defense Centers and sensors communicate through. Also, this is the IP address for the appliance’s user interface.

Default Network Gateway

The IP address of the gateway device for your network.

Hostname

The DNS-resolvable name for the appliance. IMPORTANT! If you change the hostname, the new name is not reflected in the syslog until after you reboot the appliance.

Domain

Version 4.7

The fully qualified domain name where the appliance resides.


1220

Managing the System Configuring Network Settings

Chapter 30

Static Network Configuration Settings (Continued) Setting

Description

Primary DNS Server

The IP address of the DNS server for the network where the appliance resides.

Secondary DNS Server

A secondary DNS server’s IP address.

If the appliance is not directly connected to the Internet, you can configure a proxy server to be used when downloading updates and SEUs. By default, the appliance is configured to directly connect to the Internet. To configure network settings: Access: Admin

1.


2. Click Network. The Network page appears.

3. Specify how you want to configure network settings: •

Select Use DHCP to use DHCP network setting resolution.

•

Select Use Static to manually specify network settings.

4. If you selected Use Static, specify the network settings. See the Static Network Configuration Settings table on page 1220 for a full description of each field you can configure.

Version 4.7


1221

Managing the System Shutting Down and Restarting the System

Chapter 30

5. If you appliance is not directly connected to the Internet, you can identify a proxy server to be used when downloading updates and rules. By default, appliances are configured to directly connect to the Internet. To configure a proxy server, you have two options: •

If you have a direct connection from the appliance to the Internet, select Direct connection.

•

If your network uses a proxy, select Manual proxy configuration and enter the IP address or fully qualified domain name of your proxy server in the HTTP Proxy field and the port in the Port field.

6. Click Reconfigure. The network settings are changed.

Shutting Down and Restarting the System Requires: Any

You have several options for controlling the processes on your appliance. You can: •

shut down the appliance

•

restart the appliance

•

restart the processes on the appliance

•

restart the RNA and Snort processes (Snort runs on the 3D Sensor only if you are licensed to use IPS)

To shut down or restart your appliance: Access: Admin

1.


2. Click Process. The Appliance Process page appears. The Defense Center version of the page is shown below.

Version 4.7


1222

Managing the System Configuring the Communication Channel

Chapter 30

3. Specify the command you want to perform: For DC/MDC •

If you want to shut down the Defense Center, click Run Command next to Shutdown Defense Center.

•

If you want to reboot the system, click Run Command next to Reboot Defense Center.

•

If you want to restart the Defense Center, click Run Command next to Restart Defense Center Console. Note that restarting the Defense Center may cause deleted hosts to reappear.

For 3D Sensor •

If you want to shut down the 3D Sensor, click Run Command next to Shutdown Appliance.

•

If you want to reboot the system, click Run Command next to Reboot Appliance.

•

If you want to restart the Defense Center, click Run Command next to Restart Appliance Console.

•

If you want to restart the Snort and RNA processes, click Run Command next to Restart Detection Engines.

WARNING! If you shut down the appliance, the process shuts down the operating system on the appliance, but does not physically shut off power. To shut off power to the appliance, you must press the power button on the appliance.

Configuring the Communication Channel Requires: DC + 3D Sensor

The Defense Center uses a range of internal network IP addresses called the management virtual network to transmit third-party communications such as NTP to managed sensors and, in high availability deployments, to its Defense Center peer. The default address range is 172.16.0.0/16 and the subnet mask is fixed at 255.255.0.0 or /16. The default port for all communications between the Defense Center, its managed sensors, and if high availability is enabled, its high availability peer is 8305/tcp. For more information, refer to:

Version 4.7

•

Setting Up the Management Virtual Network on page 1224

•

Editing the Management Virtual Network on page 1225


1223


Chapter 30

Setting Up the Management Virtual Network Requires: DC + 3D Sensor

If the IP address range or the port conflicts with other communications on your network, you can specify different values. This is usually configured as part of the installation process, but you can change it later. WARNING! The IP address range you specify for the Management Virtual Network must not conflict with any other local network, including your management network. The user interface prevents you from entering the address range for the management network, but make sure you do not to enter a range that overlaps other local networks. Doing so may break communications between hosts on the local network.

IMPORTANT! Master Defense Centers do not currently use a Management Virtual Network. You can not edit the Management Virtual Network field of a Master Defense Center. The field is filled with 0.0.0.0/24 to indicate that the Management Virtual Network is disabled on a Master Defense Center.

IMPORTANT! You cannot manage sensor channel communication settings for the Sourcefire Sensor on Nokia through the Defense Center web interface. For more information on registering Sourcefire Sensors on Nokia, see Adding a Sourcefire Sensor on Nokia to the Defense Center on page 51. To configure the communications channel: Access: Admin

1.


2. Click Remote Management. The Remote Management page appears.

3. In the Management Port field, enter the port number that you want to use. WARNING! Changing the management port on the Defense Center requires that you also manually change the management port on every managed sensor.

Version 4.7


1224


Chapter 30

4. In the Management Virtual Network field, enter the IP address range that you want to use. TIP! The subnet mask is fixed at /16 (sixteen bits). 5. Click Save to save your changes for both the IP address range and the port number. The new values are saved.

Editing the Management Virtual Network Requires: DC + 3D Sensor

You can change the host IP or host name of the connected appliance. You can also regenerate the Virtual IP address, a feature that is especially useful after network reconfigurations or appliance updates. WARNING! If the Management Virtual Network is functioning properly, it should not be edited. Typically, this function is used only under the direction of Sourcefire Support.

IMPORTANT! Master Defense Centers do not currently use a Management Virtual Network. You can not edit the Management Virtual Network field of a Master Defense Center. The field is filled with 0.0.0.0/24 to indicate that the Management Virtual Network is disabled on a Master Defense Center. Past versions of Sourcefire 3D Systems used a default /24 (twenty-four bit) CIDR address space, which provided enough addresses for 127 appliances. The current version uses a default /16 (sixteen bit) CIDR address space, which provides for a much greater number of appliances. To edit the remote management virtual network: Access: Admin

1.


2. Click Remote Management. The Remote Management page appears.

Version 4.7


1225

Managing the System Configuring Remote Access to the Defense Center

Chapter 30

3. Click Edit next to the host whose Management Virtual Network you want to change. The Edit Remote Management page appears.

4. Edit the name or host ID in the Name or Host fields as required. 5. Optionally, click Regenerate VIP to regenerate the IP address used by the virtual network. TIP! The regenerate VIP option is useful after you reconfigure your network or change the Sourcefire 3D System to take advantage of a larger address space. 6. After appropriate management virtual network edits are made, click Save.

Configuring Remote Access to the Defense Center Requires: DC + 3D Sensor

You must begin the procedure for setting up the management relationship between a Defense Center and a sensor on the sensor. Three fields are provided for setting up communications between appliances: •

Management Host - for the hostname or IP address.

•


•


Valid combinations include: •


•

Registration ID and Registration Key used on the 3D Sensor with Management Host, Registration ID and Registration Key used on the Defense Center.

•

Management Host, Registration ID and Registration Key used on the Defense Center with Registration ID and Registration Key used on the 3D Sensor.

IMPORTANT! The Management Host field (hostname or IP address) must be used on at least one of the appliance.

WARNING! Sourcefire strongly recommends that you read Managing Sensors on page 44 before you add sensors to the Defense Center.

Version 4.7


1226


Chapter 30

To set up sensor management from the sensor: Access: Admin

1.

On the sensor’s web interface, select Operations > System Settings. The Information page appears.

2. Click Remote Management. The Remote Management page appears. 3. Click Add Manager. The Add Remote Management page appears.

4. In the Management Host field, type the IP address or the hostname of the Defense Center that you want to use to manage the sensor. WARNING! Make sure you use hostnames rather than IP addresses if your network uses DHCP to assign IP addresses. 5. Optionally, in the Registration ID field, type a unique alphanumeric registration ID that you want to use to identify the sensor. TIP! This is especially useful in a network environment that uses network address translation and more than one sensor could have the same IP address. 6. In the Registration Key field, type the one-time use registration key that you want to use to set up a communications channel between the sensor and the Defense Center. 7.

Click Save. After the sensor confirms communication with the Defense Center, the Pending Registration status appears.

8. Access the Defense Center web interface and select Operations > Sensors. The Sensors page appears.

Version 4.7


1227


Chapter 30

9. Click New Sensor. The Add New Sensor page appears.

10. Type the IP address or the hostname of the sensor you want to add in the IP Address field. WARNING! Make sure you use hostnames rather than IP addresses if your network uses DHCP to assign IP addresses. 11. Optionally, in the Registration ID field, type the same alphanumeric registration ID that you used in step 5. 12. In the Registration Key field, type the same one-time use registration key that you used in step 6. 13. You can store IPS data on both the Defense Center and the sensor by clearing the Store Events and Packets Only on the Defense Center check box. By default, IPS data is stored only on the Defense Center and not on the sensor. Note that RNA data is never stored on the sensor. 14. To add the sensor to a group, select the group from the Add to Group list. For more information about groups, see Managing Sensor Groups on page 56. 15. Click Add. The sensor is added to the Defense Center. It can take up to two minutes for the Defense Center to verify the sensor’s heartbeat and establish communication. IMPORTANT! In some high availability deployments where network address translation is used, you may need to use the Add Manager feature to add the secondary Defense Center. Contact Sourcefire Support for more information.

Version 4.7


1228

Managing the System Setting the Time Manually

Chapter 30

Setting the Time Manually Requires: Any

If the Time Synchronization setting in the currently applied system policy is set to Manual, then you can manually set the time for the appliance using the Time page in the system settings. If the appliance is synchronizing its time based on NTP, you cannot change the time manually. Instead, the NTP Status section on the Time page provides the following information: NTP Status Column

Description

NTP Server

The IP address and name of the configured NTP server.

Status

The status of the NTP server time synchronization. The following states may appear: • Being Used indicates that the appliance is synchronized with the NTP server. • Available indicates that the NTP server is available for use but time is not yet synchronized. • Not Available indicates that the NTP server is in your configuration but the NTP daemon is unable to use it. • Pending indicates that the NTP server is new or the NTP daemon was recently restarted. Over time, its value should change to Being Used, Available, or Not Available. • Unknown indicates that the status of the NTP server is unknown.

Offset

The number of milliseconds of difference between the time on the appliance and the configured NTP server. Negative values indicate that the appliance is behind the NTP server, and positive values indicate that it is ahead.

Last Update

The number of seconds that have elapsed since the time was last synchronized with the NTP server. The NTP daemon automatically adjusts the synchronization times based on a number of conditions. For example, if you see larger update times such as 300 seconds, that indicates that the time is relatively stable and the NTP daemon has determined that it does not need to use a lower update increment.

See Synchronizing Time on page 1208 for more information about the time settings in the system policy.

Version 4.7


1229

Managing the System Blacklisting Health Modules

Chapter 30

To manually configure the time: Access: Admin

1.


2. Click Time. The Time page appears.

3. From list boxes that appear, select the following: •

year

•

month

•

day

•

hour

•

minute

4. Click Apply. The time is updated. 5. If you want to change the time zone, click the time zone link located next to the date and time. A pop-up window appears. 6. Select your time zone and click Save and, after the time zone setting is saved, click Close to close the pop-up window. For more information about using the time zone page, see Setting Your Default Time Zone on page 37.

Blacklisting Health Modules Requires: DC/MDC

If you want to disable health events for all appliances with a particular health policy, you can blacklist the policy. If you need to disable the results of a group of appliances’ health monitoring, you can blacklist the group of appliances. Once the blacklist settings take effect, the appliances report a disabled status in the Health Monitor Summary. For information on blacklisting individual or groups of appliances refer to Blacklisting Health Policies or Appliances on page 1387. You can also blacklist individual health policy modules on appliances. You may want to do this to prevent events from the module from changing the status for the appliance to warning or critical. For example, if an appliance is temporarily disconnected from the management network, you can blacklist the Appliance Heartbeat module during that maintenance window. For information on

Version 4.7


1230

Managing the System Specifying NetFlow Devices

Chapter 30

blacklisting an individual policy modules, refer to Blacklisting a Health Policy Module on page 1389

Specifying NetFlow Devices Requires: DC + RNA

If you have enabled the NetFlow feature on your Cisco routers (also called NetFlow devices), you can use the flow data that these devices collect to supplement the flow data collected by 3D Sensors with RNA by specifying the devices and the networks they monitor in your RNA detection policy. Note that although the 3D Sensor with RNA is not a NetFlow collector itself, you can configure the sensor to view data that is sent to a NetFlow collector. Before you can begin using NetFlow data, you must use the system settings to specify the NetFlow devices you are going to use to collect the data. These NetFlow devices must use NetFlow version 5. IMPORTANT! Using NetFlow devices to collect flow data requires a feature license. For more information, see Managing Licenses on page 1215. To add NetFlow devices for flow data collection:

Access: Admin

1.


2. Click NetFlow Devices. The NetFlow Devices page appears.

3. Click Add Device to add a NetFlow device.

4. In the IP Address field, enter the IP address of the NetFlow device you want to use to collect flow data. 5. To add additional NetFlow devices, repeat steps 3 and 4. TIP! To remove a NetFlow device, click Delete next to the device you want to remove. Keep in mind that if you remove a NetFlow device from the system policy, you should also remove it from your RNA detection policy. For more information, see Editing an RNA Detection Policy on page 147.

Version 4.7


1231

Managing the System Purging the RNA and RUA Databases

Chapter 30

6. Click Save. The list of NetFlow devices is saved.

Purging the RNA and RUA Databases Requires: DC + RNA or DC + RUA

You can use the RNA/RUA Event Purge page to purge files from the RNA and RUA databases. Note that if you purge database items from the RNA or RUA database, the RNA or RUA process is restarted. WARNING! Purging a database removes the data you specify from the Defense Center. After the data is deleted, it cannot be recovered. To purge the RNA database:

Access: Admin

1.

Select Operations > Configuration > RNA/RUA Event Purge. The RNA/RUA Event Purge page appears.

2. Under RNA Database, perform any or all of the following: •

Select RNA Events to remove all network discovery events from the RNA database.

•

Select Hosts to remove all hosts from the RNA database.

•

Select Flow Stats to remove all flow data from the RNA database.

•

Select Flow Summary to remove all flow summary data from the RNA database.

3. Click Save & Restart RNA. The items are purged and RNA is restarted. To purge the RUA database: Access: Admin

1.

Select Operations > Configuration > RNA/RUA Event Purge. The RNA/RUA Event Purge page appears.

2. Under RUA database, perform any or all of the following:

Version 4.7

•

Select RUA Events to remove all RUA events from the RUA events database.

•

Select Users to remove all users from the RUA history database.


1232

Managing the System Updating System Software

Chapter 30

3. Click Save & Restart RUA. The items are purged and RUA is restarted.

Updating System Software Requires: Any

Software and vulnerability database updates for the Sourcefire 3D System are distributed electronically by Sourcefire. You can use the web interface to download and install updates. If you are using a Defense Center, you can also download and install updates on managed 3D Sensors. TIP! If SEUs are updated by Sourcefire, you must use the Import Rules feature to import them. See Importing SEUs and Rule Files on page 833 for information about performing this task. If your Sourcefire 3D System deployment includes two Defense Centers configured as a high availability pair, you must import and apply patches and updates on both of the Defense Centers. The second Defense Center does not receive software updates as part of the regular synchronization process. See the following sections for more information: •

Installing Software Updates on page 1233 describes how to install software updates on your appliance.

•

Uninstalling Software Updates on page 1235 describes how to uninstall software updates, should you need to remove them.

•

Updating Sensor Software from the Defense Center on page 1235 describes how to install software updates on managed 3D Sensors.

Installing Software Updates Requires: Any

Sourcefire releases different types of software updates: •

patches that include a limited range of fixes (and usually change the fourth digit in the version number; for example, 4.5.1.1)

•

feature updates that are more comprehensive than patches and generally include new features (and usually change the third digit in the version number; for example, 4.5.1)

•

major and minor version releases that include new features and functionality and may entail large-scale changes to the product (and usually change the first or second digit in version number; for example, 4.0 or 4.6)

•

vulnerability database updates, which affect the vulnerabilities reported by RNA

For the remainder of this section, the term update is used generically to mean either a software patch, a software update, or a vulnerability database update.

Version 4.7


1233


Chapter 30

Regardless of the type of update, you must first upload the update to the appliance before you can install it. Sourcefire provides two methods for uploading an update. The first method, which you can use if your appliance has direct access to the Internet, allows you to automatically access the Sourcefire Support site and upload any applicable updates. The second method, which you must use if your appliance does not have direct access to the Internet, requires that you manually log into the Support site and download the applicable updates to your local computer. You can then use the web interface to upload the updates from your local computer to the appliance. After you upload the update to the appliance, you must install the update. Note that installing an update upgrades the appliance without modifying its configuration; the policies and network settings on the appliance remain intact. To install an update: Access: Admin

1.

Select Operations > Update. The Patch Update Management page appears.

2. You can upload the update to the appliance in one of two ways: •

If your appliance has access to the Internet, click Update to check for the latest updates on the Support site.

•

If your appliance does not have access to the Internet, manually download the update and click Upload Update. Browse to the update and click Upload. Note that patches and vulnerability updates are hosted on the Sourcefire Support site (https://support.sourcefire.com/). Software upgrades are hosted on the Nokia Support site (http://support.nokia.com/).

The update is saved on the appliance and appears in the Updates section. This list shows the type of update, the version number, the date and time it was generated and, for software updates, indicates whether the system is rebooted after the update is installed. WARNING! Make sure you upload the files directly from the Support web site or by clicking Update. Do not transfer them by email, as they may become corrupted during transmission.

Version 4.7


1234


Chapter 30

3. Select the update that you want to apply and click Install. IMPORTANT! If you are installing an update that requires a system reboot, a message appears confirming that you want to restart the system. Click OK to continue with the upgrade or Cancel to cancel the update. The update begins, and the software is installed. You can verify that the update is complete by reloading the page and checking to see if the correct version appears in the title bar of the web browser and in the “Currently running software version” line on the Upload Update page. If the update is a patch and not a major upgrade to a new version, after the software is installed, an uninstaller update appears, allowing you to uninstall the update, if necessary.

Uninstalling Software Updates Requires: Any

If you have installed an update on the appliance, you can remove it if necessary. When any update is installed on the appliance, an additional uninstaller update appears in the Select an Update list and you can use it to remove the update. IMPORTANT! You can only uninstall an update if you installed a patch. Uninstalling from the web interface is not supported for major version upgrades. If you upgraded to a new version of the appliance and need to revert to an older version, contact your Support representative for more information. To uninstall an update:

Access: Admin

1.

Select Operations > Update.

2. Select the uninstaller update that matches the update you want to remove. 3. Click Install. The update is removed and the appliance reverts to its previous version.

Updating Sensor Software from the Defense Center Requires: DC + 3D Sensor

Version 4.7

In addition to updating Defense Center software, you can also download software updates for sensors and then install the updates on managed 3D Sensors. Installing software updates on managed sensors is a two-step process. First, upload the update software to the sensors from the Remote Update Push page. Next, install the software on the sensors from the Remote Update Install page.


1235


Chapter 30

To install software updates on managed sensors: Access: Admin

1.

Download the update that you want to install on managed sensors. You can download patches and vulnerability database updates from the Sourcefire Support web site (https://support.sourcefire.com/). You can download the more comprehensive software updates from the Nokia Support web site (http://support.nokia.com/). WARNING! Do not transfer any of these updates by email. If you transfer an update file by email, it may become corrupted.

2. Select Operations > Update. The Patch Update Management page appears. 3. Click Upload Update to browse to the update you previously downloaded from the Support site. The update is uploaded to the Defense Center. 4. Next to the update, click Push. The Push Update page appears. 5. Under Selected Update, select the sensors where you want to push the update. TIP! You can list the sensors by sensor group, or model. 6. From the Batch size for this push list, select the number of sensors where the Defense Center should copy software at a time. For example, if you have 20 managed sensors where you want to copy software, you can specify 5 as the batch size in order to push the updates to 5 sensors at a time, then push to the next 5 sensors. 7.

Click Push. The Defense Center begins pushing software updates to the sensors you specified. WARNING! Depending on the size of the update file, it may take some time to copy the update software to all sensors. Wait until the software push is complete before proceeding to the next step. You can check the status of a software push from the Task Status page (Operations > Monitoring > Task Status). For more information about the Task Status page, see Viewing the Status of Long-Running Tasks on page 1259.

Version 4.7


1236

Managing the System Installing the VDB Update

Chapter 30

8. On the Patch Update Management page, click Install next to the update you have pushed and now want to install. The Install Update page appears. 9. Under Selected Update, select the sensors where you want to install the update. TIP! You can sort the sensors by sensor group or model. 10. Click Install. The update is installed on the sensors you specified. You can check the status of a software install from the Task Status page (Operations > Monitoring > Task Status). For more information about the Task Status page, see Viewing the Status of Long-Running Tasks on page 1259 WARNING! If the Reboot column indicates that a restart is required, you must confirm that you want to install the update. The managed sensors are rebooted after the software update is complete.

Installing the VDB Update Requires: DC + RNA

You can install the Sourcefire Vulnerability Database (VDB) update on the Defense Center in the same way you update the system software. Note that you can schedule the push and installation of VDB updates. See Automating Vulnerability Database Updates on page 1310 for more information. WARNING! Depending on the number of hosts in your network map, the update of vulnerabilities mapping on your system may take a long time to complete. You may want to schedule the upgrade during low system usage times to minimize the impact of the system downtime. As a rule of thumb, divide the number of hosts on your network by 1000 to determine the approximate number of minutes for the upgrade.

Version 4.7


1237

Managing the System Installing the VDB Update

Chapter 30

To update the VDB: Access: Admin

1.

Select Operations > Update. The Patch Management Update page appears.

2. You can upload the update to the Defense Center in one of two ways: •

If your Defense Center has access to the Internet, click Update to check for the latest updates on the Support site.

•

If your Defense Center does not have access to the Internet, manually download the update and click Upload Update. Browse to the update and click Upload. Note that patches and vulnerability updates are hosted on the Sourcefire Support site (https://support.sourcefire.com/). Software upgrades are hosted on the Nokia Support site (http://support.nokia.com/).

WARNING! Download files directly from the Sourcefire Support Site and do not transfer them by email. If you transfer an update file by email, it may become corrupted. The update appears in the Updates list. 3. Next to the update you just uploaded, click Install. The Install Update page appears. 4. Under Selected Updates, select the Defense Center and click Install.

Version 4.7


1238

Managing the System Using Backup and Restore

Chapter 30

5. Confirm that you want to install the update. The VDB is updated. WARNING! You can monitor the update's progress in the task queue (Operations > Monitoring > Task Status). Do not use the web interface to perform tasks related to mapped vulnerabilities until the update has completed. If the task queue stops updating with current status, manually refresh your browser. If you encounter issues with the update, for example, if the task queue indicates that the update has failed or if a manual refresh of the task queue shows no progress, do not restart the update. Instead, please contact Sourcefire Support. 6. After the update finishes, select Operations > Help > About and confirm that the VDB build number matches the update you installed. Continue with updating the vulnerability database (VDB) on any sensors that the Defense Center manages.

7.

Using Backup and Restore Requires: IPS or DC/MDC

Backup and restoration is an essential part of any system maintenance plan. While each organization’s backup plan is highly individualized, Sourcefire 3D System provides a mechanism for archiving data so that the Defense Center or 3D Sensor can be restored in case of disaster. By default, system configuration files are saved in the backup file. You can also choose to back up the following, if applicable for the range of appliances in your deployment: •

the entire intrusion event database

•

the entire RNA event database

•

additional files that reside on the appliance

WARNING! If you applied any SEU updates, those updates are not backed up. You need to apply the latest SEU update after you restore.

TIP! The backup and restore feature on the Defense Center functions only with the files on the Defense Center itself. If you want to back up or restore Network Voyager configuration data on Nokia-based sensors, you must use the Network Voyager web interface. You can save backup files to the appliance or to your local computer.

Version 4.7


1239


Chapter 30

See the following sections for more information. •

See Creating Backup Files on page 1240 for information about backing up files from the appliance.

•

See Creating Backup Profiles on page 1243 for information about creating backup profiles that you can use later as templates for creating backups.

•

See Restoring the Appliance from a Backup File on page 1245 for information about how to restore a backup file to the appliance.

Creating Backup Files Requires: IPS or DC/MDC

You should periodically save a backup file that contains all of the configuration files required to restore the appliance, in addition to event and packet data. You may also want to back up the system when testing configuration changes so that you can revert to the saved configuration, if needed. You can choose to save the backup file on the appliance or to your local computer. The Defense Center and Master Defense Center version of the page is shown below.

Version 4.7


1240


Chapter 30

For comparison, the 3D Sensor version of the page is shown below.

To create a backup file: Access: Maintenance or Admin

1.

Select Operations > Tools > Backup/Restore. The Restoration Database page appears.

2. Click Backup on the toolbar. The System Backup page appears. 3. In the Name field, type a name for the backup file. You can use alphanumeric characters, punctuation, and spaces. 4. Requires: IPS or DC/MDC If you want to archive the entire event database, select Backup Events. 5. Requires: IPS If you want to archive individual intrusion event data files, select the files that you want to include from the Unified File List.

Version 4.7


1241


Chapter 30

6. Requires: IPS Ensure that the value of the compressed backup file in the Selected Sum field is less than the value in the Available Space field. TIP! The compressed value that appears in the Selected Sum field is a conservative estimate of the size of the compressed file. Often, the file will be smaller. 7.

If you want to include an additional file in the backup, type the full path and file name in the Additional Files field and click the plus sign (+). TIP! You can repeat this step to add additional files.

8. Optionally, to be notified when the backup is complete, select the Email when complete check box and type your email address in the accompanying text box. IMPORTANT! You must make sure that your mail relay host is configured as described in Configuring a Mail Relay Host and Notification Address on page 1201. 9. Optionally, to use secure copy (scp) to copy the backup archive to a different machine, select the Copy when complete check box and then type the following information in the accompanying text boxes: •

the hostname or IP address of the machine where you want to copy the backup

•

the path to the directory where you want to copy the backup

•

the user name that you want to use to log into the remote machine

•

the password for that user name

TIP! Sourcefire recommends that you periodically save backups to a remote location so that the appliance can be restored in case of system failure. You may also want to consider saving backup files to media that you can store in a remote location.

Version 4.7


1242


Chapter 30


To save the backup file to the appliance, click Start Backup. The backup file is saved in the /var/sf/backup directory on the appliance. When the backup process is complete, you can view the file on the Restoration Database page. For information about restoring a backup file, see Restoring the Appliance from a Backup File on page 1245.

•

To save this configuration as a backup profile that you can use later, click Save As New. You can modify or delete the backup profile by selecting Operations > Tools > Backup & Restore and then clicking Backup Profiles. See Creating Backup Profiles on page 1243 for more information.

Creating Backup Profiles Requires: IPS or DC/MDC

You can use the Backup Profiles page to create backup profiles that contain the settings that you want to use for different types of backups. You can later select one of these profiles when you are backing up the files on your appliance. TIP! When you create a backup file as described in Creating Backup Files on page 1240, a backup profile is automatically created. To create a backup profile:


1.


2. Click Backup Profiles on the toolbar. The Backup Profiles page appears with a list of existing backup profiles.

TIP! You can click Edit to modify an existing profile or click Delete to delete a profile from the list. 3. Click Create Profile. The System Backup page appears. 4. Type a name for the backup profile. You can use alphanumeric characters, punctuation, and spaces.

Version 4.7


1243


Chapter 30

5. Configure the backup profile according to your needs. See Creating Backup Files on page 1240 for more information about the options on this page. 6. Click Save As New to save the backup profile. The Backup Profiles page appears and includes your new profile in the list.

Performing a Remote Backup with the Defense Center Requires: DC/MDC

You can use the Defense Center to back up data on managed 3D Sensors. IMPORTANT! You cannot run remote backups on Sourcefire Sensors on Nokia. Use the Network Voyager interface to backup Voyager configuration data on Sourcefire Sensors on Nokia. To back up a managed sensor:


1.


2. Click Remote Backup on the toolbar. The Remote Backup page appears.

3. In the Sensors field, select the managed sensors that you want to back up. 4. To include event data in addition to configuration data, select the Include Events check box. 5. To save the backup file on the Defense Center, select the Retrieve to DC check box. TIP! To save each sensor’s backup file on the sensor itself, leave this check box unselected. 6. Click Start Backup. A success messages appears and the backup task is set up. When the backup is complete, you can view the backup file on the Restoration Database page.

Version 4.7


1244


Chapter 30

Restoring the Appliance from a Backup File Requires: IPS or DC/MDC

You can restore the appliance from backup files using the Restoration Database page. After you complete the restoration process, you must apply the latest SEU. The Restoration Database table describes each column in the Restoration Database section. Restoration Database Column

Description

Name

The backup file’s full name.

Size

The size of the backup file, in bytes.

Date Created

The date and time that the backup file was created.

View Manifest

Click View Manifest next to a backup file to view a list of the files included in the compressed backup file.

Apply

Click Apply next to a backup file to apply it to the appliance.

Download

Click Download next to a backup file to save it to your local computer.

Delete

Click Delete next to a backup file to delete it.

To restore the appliance from a backup file: Access: Maintenance or Admin

Version 4.7

1.



1245


Chapter 30

2. If the backup file does not exist on the appliance, under Upload Backups, click Browse, and navigate to the backup file. After you return to the Restoration Database page, click Upload Backup. The backup file is uploaded and appears in the Restoration Database list. 3. To view the contents of a backup file, click View Manifest next to the name of the backup file. The manifest appears listing the name of each file, its owner and permissions, and its file size and date. The Defense Center version of the page is truncated to show a sample of the files that are backed up.

4. On the toolbar, click Restoration Database to return to the Restoration Database page. 5. Click Apply next to the backup file that you want to restore. The Restore Screen page appears. WARNING! This procedure will overwrite all configuration files and, on the 3D Sensor, all event data. 6. If you want to restore configuration files, select the Replace check box next to Configuration Data. 7.

Version 4.7

Requires IPS If you want to restore intrusion event data, select the files that you want to include from the Unified File List box.


1246

Managing the System Restoring the Defense Center to Factory Defaults

Chapter 30

8. Click Restore to begin the restoration. TIP! To cancel the restoration, click Cancel. The appliance is restored using the backup file you specified. 9. Apply the latest SEU to re-apply SEU rule and software updates. 10. Re-apply any intrusion, RNA detection, health, and system policies to the restored system.

Restoring the Defense Center to Factory Defaults Requires: DC/MDC

Sourcefire provides a CD-ROM for restoring the Defense Center to its original factory settings. WARNING! Restoring your Defense Center with the CD-ROM results in the loss of all configuration and event data on the Defense Center. Consider backing up your Defense Center before you use the Restore CD-ROM. The process retains the license file and network settings, if possible, but you may need to re-enter the original license file after the process completes. To restore your Defense Center to its original factory settings: 1.

Connect a monitor and keyboard to the Defense Center.

2. Place the Restore CD in the CD tray of the Defense Center and, at the command line, type reboot and press Enter. After the Defense Center reboots, you are prompted to restore the system. 3. Confirm that you want to restore the Defense Center by typing yes and pressing Enter. 4. When you are prompted to delete your license file and network settings, type no and press Enter. 5. When you are prompted to confirm that you want to restore, type yes and press Enter. The system is restored. 6. When you are prompted, press Enter to continue. 7.

When you are prompted, press Enter to eject the CD and reboot the Defense Center. The Defense Center ejects the CD and reboots.

Version 4.7


1247

Managing the System Importing and Exporting Objects

Chapter 30

8. Connect to the Defense Center and, if the Add Feature License page appears, paste the original license file into the License field and click Submit License. For more information on initial configuration of your Defense Center, see the Defense Center Installation Guide. 9. Download and apply the latest software updates, VDB updates, and SEU from Sourcefire. For more information, see: •

Updating System Software on page 1233

•

Installing the VDB Update on page 1237

•

Importing SEUs and Rule Files on page 833

Importing and Exporting Objects Requires: Any

You can export several types of policies and other objects from one appliance and then import them on another appliance of the same type. Depending on whether you are using a Defense Center or a 3D Sensor, you can import and export the following objects: •

custom service detector groups (Defense Center only)

•

health policies (Defense Center only)

•

intrusion policies (Defense Center or 3D Sensor with IPS)

•

RNA detection policies (Defense Center only)

•

system policies (any appliance)


Exporting Objects on page 1248

•

Importing Objects on page 1252

Exporting Objects Requires: IPS or DC/MDC

You can export a single object, or you can export several objects at once. Object import and export is not intended as a backup tool, but can be used to simplify the process of adding new appliances to your Sourcefire 3D System. Revision information for an object is exported along with the object. If you attempt to import an object revision that already exists on an appliance, the import fails. In addition, when you export the object, system objects that the object depends on, such as authentication objects, are exported with it. For example, if you set up authentication to an LDAP server on your Defense Center, then export a Defense Center system policy with authentication enabled, the authentication object is exported as well.

Version 4.7


1248


Chapter 30

Note that you cannot export individual custom service detectors; you can only export them as a group. IMPORTANT! Depending on the number of objects you export and the number of objects those objects reference, the export process may take several minutes. For more information, see the following: •

Exporting a Single Health Policy on page 1249

•

Exporting a Single Intrusion Policy on page 1249

•

Exporting a Single RNA Detection Policy on page 1250

•

Exporting a Single System Policy on page 1250

•

Exporting Multiple Objects on page 1251

Exporting a Single Health Policy Requires: DC/ MDC

You can export a single health policy from the Health Policy page. To export a health policy:


1.

Select Operations > Monitoring > Health. The Health Monitor page appears.

2. Click Health Policy in the toolbar. The Health Policy page appears, listing the existing health policies. 3. Click Export next to the policy you want to export. A file download box appears. 4. Follow your web browser’s prompts to save the exported package to your computer.

Exporting a Single Intrusion Policy Requires: IPS or DC/MDC

You can export a single intrusion policy from the Detection & Prevention page. + Exporting a policy exports all settings for the policy. If you choose to enable a rule or set SNMP alerting for a rule, or if you turn on the SMTP preprocessor in a policy, those settings remain in place in the exported policy. When you export an intrusion policy, any custom rules, custom rule classifications, and custom variables are exported with the policy. When you import the policy on another appliance, the policy (and each custom rule enabled in it) automatically imports if that revision of that policy does not already exist on the destination appliance. If the imported object does conflict with an existing policy or rule, you decide whether to keep one policy revision in place of the other or to keep both.

Version 4.7


1249


Chapter 30

Note that you cannot use intrusion policy export and import to update rules created by Sourcefire’s Vulnerability Research Team (VRT). For more information on importing rule packs, see Importing SEUs and Rule Files on page 833. WARNING! You must apply the same version of the SEU to both the source appliance and the destination appliance prior to performing the export/import process. Otherwise, the import will fail. Sourcefire recommends that you download and apply the latest SEU version to both appliances. To export an intrusion policy: Access: Rules or Admin

1.

Select Policy & Response > IPS > Detection & Prevention. The Detection & Prevention page appears, including a list of existing intrusion policies.

2. Click Export next to the policy you want to export. A file download box appears. IMPORTANT! Depending on the number of rules referenced by the policy you are exporting, the export process may take a few minutes. 3. Follow your web browser’s prompts to save the exported package to your computer.

Exporting a Single RNA Detection Policy Requires: DC + RNA

You can export a single RNA detection policy from the Detection Policy page. To export an RNA detection policy:


1.

Select Policy & Response > RNA > Detection Policy. The Detection Policy page appears, including a list of existing detection policies.

2. Click Export next to the policy you want to export. A file download box appears. 3. Follow your web browser’s prompts to save the exported package to your computer.

Exporting a Single System Policy Requires: Any

Version 4.7

You can export a single system policy for import on another appliance. For example, if you have two 3D Sensors and do not manage them with a Defense Center or if you have a new Defense Center and an existing Defense Center, you might want to export the system policy from one and import it on the other.


1250


Chapter 30

System policies contain database settings that may not apply to a standalone sensor. When you export a system policy from a standalone sensor, any database limits that you did not configure revert to the default values for those options, so all options have values that can be used if the policy is applied to a Defense Center. In addition, system policies where external authentication is enabled include references to authentication objects. Those objects are exported with the system policy. To export a system policy: Access: Admin

1.


2. Click Export next to the system policy that you want to export. 3. Follow your web browser’s prompts to save the exported package to your computer.

Exporting Multiple Objects Requires: IPS or DC/MDC

You can export several different types of objects at once using the Import/Export feature. You export all selected objects into a single package. When you upload the package for import, you can then select which objects to import from the objects in the package that are supported on the destination appliance. IMPORTANT! Depending on the number of objects being exported and the number of objects those objects reference, the export process may take a few minutes.

Version 4.7


1251


Chapter 30

To export multiple objects: Access: Admin

1.

Select Operations > Tools > Import/Export. The Import/Export page appears, including a list of the objects on the appliance. The Defense Center version of the page is shown below.

2. Select the objects that you want to export and click Export. 3. Follow your web browser’s prompts to save the exported package to your computer.

Importing Objects Requires: IPS or DC/MDC

Version 4.7

Depending on what type of appliance you are using, you can import custom service detector groups, health policies, intrusion policies, RNA detection policies, and system policies. When you upload the package for import, you can select which objects to import from the objects included the package. Only objects that are supported on your appliance display on the import list. The appliance creates a mapping for each object when you export the object and, if appropriate, also creates a mapping for each object referenced by that object. When you import the object, those mappings are compared with existing objects to determine whether or not the new objects should be imported automatically. If a conflict appears during the import process, you can choose to keep the existing object, replace the existing object with a new object, keep the newest object, or import the object as a new object.


1252


Chapter 30

If you import an object and its associated objects and then later make a modification to the object on the destination system, then import the object again, you are prompted to select which version of the object to keep. Select this option...

To...

Keep existing

keep the existing version on the destination system and discard the version from the imported package

Replace existing

keep the version from the imported package and discard the existing object on the destination system

Keep existing if newer

keep the newest version and discard the other object

Import as new

create a new object, with a new UUID, on the destination system and keep the existing object. If you select this option, you can edit the name of the object on the Import Resolution page

When you import an intrusion policy, you import all custom rules and custom variables enabled in the policy as well. Rules created by Sourcefire are not imported because they already exist on your Defense Center or 3D Sensor with IPS. You must make sure that you apply the latest SEU to both the appliance where you export an object and the appliance where you import the object. You cannot import an object if it was created on an appliance that has a different SEU version than the appliance where you plan to import it. WARNING! If you import default policies or rules to an appliance, you cannot delete them.

Version 4.7


1253


Chapter 30

To import one or more objects: Access: Admin

1.

Export the objects that you want to import. For more information, see Exporting Objects on page 1248.

2. On the appliance where you want to import the objects, select Operations > Tools > Import/Export. The Import/Export page appears. The Defense Center version of the page is shown.

3. Click Upload Package. The Upload Package page appears.

4. You have two options:

Version 4.7

•

Type the path for the package you want to upload.

•

Click Browse to browse to locate the package.


1254


Chapter 30

5. Click Upload. The result of the upload depends on the contents of the package: •

If the object and rule versions in the package exactly match versions that already exist on your appliance, a message displays indicating that the versions already exist. The appliance has the most recent objects so you do not need to import them.

•

If you are importing intrusion policies and rules and there is a mismatch in SEU versions between your appliance and the appliance where the package was exported, a message displays, indicating that you cannot import. Apply the latest SEU version to both appliances, re-export the package, and attempt the import again.

•

If the package contains any object or rule versions that do not exist on your appliance, the Package Import page appears. Continue with the next step.

IMPORTANT! Depending on the size of the package and the number of referenced objects, the upload process may take a few minutes. 6. Select the objects that you want to import from the package and click Import. The import process occurs, with the following results:

7.

•

If the objects you import do not have previous revisions on your appliance, the import completes automatically and a success message appears. Skip to step 9.

•

If the objects you import do have previous revisions on your appliance, the Import Resolution page appears. Continue with step 7.

Expand each object and select the appropriate option: •

To keep the object on your appliance, select Keep existing.

•

To replace the object on your appliance with the imported object, select Replace existing.

•

To keep the newest object, select Keep existing if newer.

•

To save the imported object as a new object, select Import as new, and, optionally, edit the object name.

8. Click Import. The objects are imported.

Version 4.7


1255

Managing the System Managing Event Streamer Clients

Chapter 30

9. To use an imported object on your appliance, apply the policy or otherwise activate the object. For more information, see the following sections: •

Activating and Deactivating Service Detectors on page 556

•


•

Applying an Intrusion Policy on page 764

•

Applying a System Policy on page 1192

•

Applying Health Policies on page 1382

Managing Event Streamer Clients Requires: DC

If you are using the Sourcefire Event Streamer (Estreamer) service to stream events to an Event Streamer client (including RNA Visualizer), you can use the Defense Center web interface to configure which events are streamed to clients, to add clients to the system, and to generate authentication certificates for Event Streamer clients. The Event Streamer messaging protocol is described in detail in the Sourcefire Event Streamer Integration Guide, which is part of the Estreamer SDK. This book also provides detailed information about configuring an Estreamer client to communicate with the Event Streamer service. Contact your sales representative for more information about this publication. Note that all events matching the event types you select are archived to a file on the Defense Center. Later, if you select a different set of event types, the older archived events are not deleted. In fact, the archived events are available to any Estreamer client that connects successfully to the Defense Center and then requests events from the time period before you made your change on the Estreamer page. See the following sections for more information: •

Configuring Event Streamer Event Types on page 1256

•

Adding Authentication for Event Streamer Clients on page 1258

Configuring Event Streamer Event Types Requires: DC

Version 4.7

You can control which types of events Event Streamer forwards to its clients. Available event types include: •

RNA events

•

compliance events

•

impact flag alerts

•

intrusion events


1256


•

packets associated with intrusion events

•

RUA events

Chapter 30

IMPORTANT! If the Defense Center acting as your Event Streamer server is managed by a Master Defense Center, you configure events to be sent to the Master Defense Center from that Defense Center at the Master Defense Center. In doing so, you automatically enable streaming of those events for all Event Streamer clients communicating with that Defense Center, and you cannot disable transmission of those event types on the Defense Center. Options enabled at the Master Defense Center level are checked and grayed out in the Defense Center web interface. To configure the types of events transmitted by Event Streamer: Access: Admin

1.

Select Operations > Configuration > Estreamer. The Estreamer page appears.

2. In the Estreamer Event Configuration section, select the check boxes that represent the types of events you want Event Streamer to forward to requesting clients. You can select any or all of the following:

Version 4.7

•

RNA Events to transmit RNA events.

•

Compliance Events to transmit compliance events.

•

Intrusion Flag Alerts to transmit impact flag alerts generated by the Defense Center.

•

Intrusion Events to transmit intrusion events generated by managed 3D Sensors with IPS.

•

Intrusion Event Packet Data to transmit packets associated with intrusion events.

•

RUA Events to transmit RUA events.


1257


Chapter 30

3. Click Save. Your settings are saved and the events you selected will be forwarded to Event Streamer clients when they request them.

Adding Authentication for Event Streamer Clients Requires: DC

Before Event Streamer can send events to a client, you must add the client to the Defense Center on the Estreamer Client page and copy the resulting authentication certificate to the client. To add an Event Streamer client:

Access: Admin

1.

Select Operations > Configuration > Estreamer. The Estreamer page appears.

2. Click Create Client. The Create Client page appears.

3. In the Hostname field, enter the host name or IP address of the host running the Event Streamer client. IMPORTANT! If you use a host name, the Defense Center must be able to resolve the host to an IP address. If you have not configured DNS resolution, you should configure it first or use an IP address. See Configuring Network Settings on page 1220 for more information about configuring DNS settings. 4. Optionally, in the Password field, enter a password. 5. Click Save. The Estreamer Client page appears again. 6. Click the link in the Certificate Location column that corresponds to the client to download the certificate file. 7.

Version 4.7

Save the certificate file in the location required by your client.


1258

Managing the System Viewing the Status of Long-Running Tasks

Chapter 30

Viewing the Status of Long-Running Tasks Requires: Any

When you apply a policy, push updates, install software, and perform other longrunning jobs, the status of these jobs is reported on the Task Status page. This page provides information about complex jobs (such as applying intrusion policies from a Defense Center to a large number of managed sensors) and reports when they are complete. The page automatically refreshes every 10 seconds to update the status. You can see the status of jobs that you initiated. If you are using the admin account, you can see the status of every job regardless of who initiated it. To view the Task Status page:

Access: Rules, Maintenance or Admin

1.


If you manually launched the task, you can click the Queue link. A pop-up window appears, displaying task status.

•

If you scheduled a task or a different page from where you launched processes, select Operations > Monitoring > Task Status.

The Task Status page appears.

The Job Summary section displays the following information:

Version 4.7

•

Running jobs, which displays the number of jobs currently in progress

•

Waiting jobs, which displays the number of jobs that are waiting for an in-progress job to complete before running


1259

Managing the System Viewing the Status of Long-Running Tasks

Chapter 30

•

Completed jobs, which displays the number of jobs that completed, regardless of whether they succeeded

•

Retrying jobs, which displays the number of jobs that are automatically retrying (no all jobs are permitted to try again)

•

Failed jobs, which displays the number of jobs that did not complete successfully

The Jobs section provides information for each job. Jobs that are dependent on other jobs are nested and can be expanded by clicking the folder icon. 2. You can perform the following actions: •

To remove all completed jobs from the queue, click Remove Finished Jobs.

•

If a job repeatedly fails (for example, if you are applying a policy to a sensor that is unavailable), click Delete next to the name of the job. The current iteration of the job will continue, but after the job fails it will not try to restart. Note that if the job is running on a remote appliance (for example, an intrusion policy applied to a managed sensor from a Master Defense Center), you must delete the job on the Defense Center that manages the sensor.

Version 4.7


1260

Chapter 30

Managing Users

If your user account has Admin access, you can manage the user accounts that can access the web interface on your Defense Center or 3D Sensor. On the Defense Center, you can also set up user authentication via an external LDAP directory server, rather than through the internal database. For more information, see the following sections: •

Understanding Sourcefire User Authentication on page 1261

•

Managing LDAP Authentication Objects on page 1265

•

Managing User Accounts on page 1281

Understanding Sourcefire User Authentication Requires: DC/MDC or 3D Sensor

Version 4.7

When a user logs into the web interface, the appliance looks for a match for the user name and password in the local list of users. This process is called authentication. There are two kinds of authentication: internal and external. If the user’s account uses internal authentication, the authentication process checks the local database for this list. If the account uses external authentication, the process checks the local database to see if the user exists there and, if the user is


1261

Managing Users Understanding Sourcefire User Authentication

Chapter 31

not found locally, it queries an external server, such as an LDAP directory server, for a list of users.

For users with either internal or external authentication, you can control user permissions. Users with external authentication receive the permissions either for the group they belong to, or based on the default user access role you set in a system policy on the managing Defense Center, unless you change the user permissions manually. For more information, see the following sections:

Version 4.7


1262


•

Understanding Internal Authentication on page 1263

•

Understanding External Authentication on page 1263

•

Understanding User Privileges on page 1264

Chapter 31

Understanding Internal Authentication Requires: DC/MDC or 3D Sensor

By default, the Sourcefire 3D System uses internal authentication to check user credentials when a user logs in. Internal authentication occurs when the username and password are verified against records in the internal Sourcefire 3D System database. If you do not enable external authentication when you create a user, the user credentials are managed in the internal database. IMPORTANT! Note that an internally authenticated user is converted to external authentication if you enable LDAP authentication, the same username exists for the user on the LDAP server, and the user logs in using the password stored for that user on the LDAP server. Once an internally authenticated user converts to an externally authenticated user, you cannot revert to internal authentication for that user.

Understanding External Authentication Requires: DC

External authentication, also called LDAP authentication, occurs when the Defense Center or managed sensor retrieves user credentials from an external repository, such as an LDAP directory server. LDAP, or the Lightweight Directory Access Protocol, allows you to set up a directory on your network that organizes objects, such as user credentials, in a centralized location. Multiple applications can then access those credentials and the information used to describe them. If you ever need to change a user's credentials, you can change them in one place, rather than having to change them on the local appliances as well as on any other application that uses them. If you want to use external authentication, you must configure an authentication object for each LDAP directory server from which you want to request user information. The authentication object contains your settings for connecting to and retrieving user data from that server. You can then enable that object in a system policy on the managing Defense Center and apply the policy to an appliance to enable authentication. When any LDAP user logs in, the web interface checks each authentication server to see if that user is listed, in the order the servers are listed in the system policy. IMPORTANT! Currently, external authentication is only supported for LDAP directory servers running Microsoft Active Directory on Windows Server 2003, Sun Directory Services 5.2 P4 on Windows 2003 and XP, or OpenLDAP on Linux.

Version 4.7


1263


Chapter 31

You can push a system policy to a managed 3D Sensor to enable external authentication on that sensor, but you cannot control the authentication object from the sensor’s web interface. The only configuration of external authentication on the sensor occurs when you select the type of authentication for a new user. If you want to disable external authentication on a managed 3D Sensor, disable it in the system policy on the managing Defense Center and re-apply the policy to the sensor. If you apply a local system policy (created on the sensor) to the sensor itself, external authentication is also disabled. IMPORTANT! on Nokia.

External authentication is not supported on Sourcefire 3D Sensors

To configure LDAP authentication, you must first create an authentication object on the Defense Center that contains connection settings for the server. Once the object is created, you then enable external authentication in a system policy on the managing Defense Center and apply that policy to the appliance where you want external authentication to occur. When you create a user on the Defense Center, you can specify whether that user is internally or externally authenticated. When an externally authenticated user logs in for the first time, the user receives the default access settings for groups the user belongs to, or if groups are not configured, the default access setting you selected in the system policy. You can then modify those settings, if needed, unless the settings are granted through group membership. Because you manually create each internally authenticated user, you set the access settings when you create the user and you do not need to set default settings. TIP! You can use the Import/Export feature to export system policies. When you export a policy with LDAP authentication enabled, the LDAP authentication object is exported with the policy. You can then import the policy and object on another Defense Center. Do not import policies with authentication objects onto 3D Sensors.

Understanding User Privileges Requires: DC/MDC or 3D Sensor

The Sourcefire 3D System lets you allocate user privileges based on the user’s role. For example, an analyst typically needs access to event data to analyze the security of monitored networks, but might never require access to administrative functions for the Sourcefire 3D System itself. You can grant Data access privileges for the analysts and reserve Admin access rights for the network administrator managing the Sourcefire 3D System. In the system policy on the Defense Center, you set a default access role for all users who are externally authenticated. After an externally authenticated user logs in for the first time, you can add or remove access rights for that user on the User Management page. If you do not modify the user’s rights, the user has only

Version 4.7


1264

Managing Users Managing LDAP Authentication Objects

Chapter 31

the rights granted by default. Because you create internally authenticated users manually, you set the access rights when you create them. If you configured management of access rights through LDAP groups, the access rights for users are based on their membership in LDAP groups. They receive the default access rights for the group that they belong to that has the highest level of access. If they do not belong to any groups and you have configured group access, they receive the default user access rights configured in the authentication object for the LDAP server. If you configure group access, those settings override the default access setting in the system policy. The Sourcefire 3D System supports the following user privileges, depending on the features you have licensed: •

Admin access allows users to set up the appliance’s network configuration, manage user accounts, configure system policies and system settings. Users with Admin access also have Data, Rule, and Maintenance access.

•

Data access allows users to view and analyze intrusion events, network change events, hosts, host attributes, services, vulnerabilities, client applications, and compliance events. Data access users can also create incidents and generate reports.

•

Restricted data access provides the same privileges as Data access, but users are limited to subsets of the data. Restricted data users can have Rules access, but cannot have Data, Maintenance, or Admin access. Note that on the Defense Center you cannot select restricted data access as the default user role in the system policy, but you can modify a user’s settings on the User Management page to grant this level of access.

•

Rules access allows users to manage intrusion rules, policies, and responses, as well as compliance rules, policies, and responses.

•

Maintenance access allows users to access monitoring functions (including health monitoring, host statistics, performance data, and system logs) and maintenance functions (including task scheduling and backing up and restoring the system).

Managing LDAP Authentication Objects Requires: DC

Version 4.7

Authentication objects are server profiles for external authentication servers, containing connection settings and authentication filter settings for those servers. You can create, manage, and delete authentication objects on the Defense Center. See the following sections for details on these tasks: •

Creating Authentication Objects on page 1266

•

Authentication Object Examples on page 1275

•

Editing Authentication Objects on page 1280

•

Deleting Authentication Objects on page 1281


1265


Chapter 31

Creating Authentication Objects Requires: DC

When you create an authentication object, you define settings that let you connect to an authentication server. You also select the directory context and search criteria you want to use to retrieve user data from the server. Optionally, you can configure shell access authentication. Note that to create an authentication object, you need TCP/IP access from your local appliance to the authentication server where you want to connect. To create an authentication object:

Access: Admin

1.

Select Operations > Configuration > Login Authentication. The Login Authentication page appears.

2. Click Create Authentication Object. The Create Authentication Object page appears. 3. Identify the authentication server where you want to retrieve user data for external authentication. For more information, see Identifying the Authentication Server on page 1266. 4. Configure authentication settings to build a search request that retrieves the users you want to authenticate. Specify a user name template to format the usernames that users enter on login. For more information, see Configuring LDAP Authentication Settings on page 1267. 5. If you are using a Microsoft Active Directory server or if your LDAP server uses a filter search attribute or Pluggable Authentication Module (PAM) login attribute other than uid, specify the appropriate attributes for your server. For more information, see Configuring Attribute Mapping on page 1270. 6. Optionally, configure LDAP groups to use as the basis for default access role assignments. For more information, see Configuring Access Settings by Group on page 1271. 7.

Optionally, configure authentication settings for shell access. For more information, see Configuring Administrative Shell Access on page 1273.

8. Test your configuration by entering the name and password for a user who should successfully authenticate. For more information, see Testing User Authentication on page 1274.

Identifying the Authentication Server Requires: DC

Version 4.7

When you create an authentication object, you first specify the server and server port where you want the local appliance (3D Sensor or Defense Center) to connect for authentication. Note that if you change the encryption method after specifying the port, the port is reset to the default value. For none or TLS, the port uses the default value of 389. If you select SSL encryption, the port uses the default of 636.


1266


Chapter 31

You can specify a backup authentication server. If the number of seconds indicated in the Server Timeout field (or the timeout on the directory server) elapses without a response from the primary authentication server, the appliance then queries the backup server. If, for example, the primary server has LDAP disabled, the appliance would query the backup server. If LDAP is running on the port of the primary LDAP server and for some reason refuses to service the request (due to misconfiguration or other issues), however, the failover to the backup server does not occur. To identify an LDAP authentication server: Access: Admin

1.

Select an Authentication Method from the drop-down list.

2. Type a name and description for the authentication server in the Name and Description fields. 3. Type the IP address or host name for the primary server where you want to obtain authentication data in the Server Host Name/IP Address field. IMPORTANT! If you are using a certificate to connect via TLS or SSL, the host name in the certificate must match the host name used in this field. 4. Optionally, modify the port used by the primary authentication server in the Server Port field. 5. In the Server Host Name/IP Address Backup field, type the IP address or host name for the secondary server you want to revert to if the primary server connection fails. 6. Optionally, modify the port used by the secondary authentication server in the Server Port Backup field. 7.

Type the number of seconds that should elapse before rolling over to the secondary connection in the Server Timeout field. Continue with Configuring LDAP Authentication Settings.

Configuring LDAP Authentication Settings Requires: DC

Version 4.7

To allow an appliance to connect to the LDAP server, you need to select the encryption method for the connection. You can choose no encryption, Transport Layer Security (TLS), or Secure Sockets Layer (SSL) encryption. Note that if you


1267


Chapter 31

are using a certificate to authenticate when connecting via TLS or SSL, the name of the LDAP server in the certificate must match the name that you use to connect. For example, if you enter 10.10.10.250 as the server and computer1.example.com in the certificate, the connection fails. Changing the name of the server in the authentication profile to computer1.example.com causes the connection to succeed. When the local appliance searches the LDAP directory server to retrieve user information on the authentication server, it needs a starting point for that search. You can specify the namespace, or directory tree, that the local appliance should search by providing a base distinguished name, or base DN. If your LDAP Server uses a Pluggable Authentication Module (PAM) login attribute of uid, the local appliance checks the uid attribute value for each object in the directory tree indicated by the base DN you set. If one of the objects has a matching username and password, the user login request is authenticated. Typically, the base DN will have a basic structure indicating the company domain and operational unit. For example, the Security organization of the Example company might have a base DN of ou=security,dc=example,dc=com. You can also add a base filter that sets a specific value for a specific attribute. The base filter focuses your search by only retrieving objects in the base DN that have the attribute value set in the filter. Enclose the base filter in parentheses. For example, to filter for only users with a common name starting with F, use the filter (cn=F*). When you save the authentication object, the local appliance queries using the base filter to test it and indicates whether or not the filter appears to be correct. To test your base filter more specifically by entering a test username and password, see Testing User Authentication on page 1274. To allow the local appliance to access the user objects, you must supply user credentials for a user with appropriate rights to the authentication objects you want to retrieve. Remember that the distinguished name for the user you specify must be unique to the directory information tree for the directory server. For the authentication method specific parameters, you can use the LDAP naming standards and filter and attribute syntax defined in the RFCs listed in the Lightweight Directory Access Protocol (v3): Technical Specification, RFC 3377. Examples of syntax are provided throughout this procedure. Note that when you set up an authentication object to connect to a Microsoft Active Directory Server, you can use the address specification syntax documented in the Internet RFC 822 (Standard for the Format of ARPA Internet Text Messages) specification when referencing a user name that contains a domain. For example, to refer to a user object, you might type [email protected] rather than the equivalent user distinguished name of cn=JoeSmith,ou=security, dc=example,dc=com when using Microsoft Active Directory Server. Selecting a user name template lets you indicate how user names entered on login should be formatted, by mapping the string conversion character (%s) to the value of the PAM login attribute for the user. The user name template is the format for the distinguished name used for authentication. When a user enters a user name into the login page, the name is substituted for the string conversion character and the resulting distinguished name is used to search for the user

Version 4.7


1268


Chapter 31

credentials. For example, to set a user name template for the Security organization of the Example company, you would enter %[email protected]. To configure the authentication method for a server: Access: Admin

1.

Select one of the following encryption modes: •

To connect using Secure Sockets Layer (SSL), select SSL.

•

To connect using Transport Layer Security (TLS), select TLS.

•

To connect without encryption, select None.

IMPORTANT! Note that if you change the encryption method after specifying a port, you reset the port to the default value for that method. For none or TLS, the port uses the default value of 389. If you select SSL encryption, the port uses the default of 636. 2. Optionally, if you selected TLS or SSL encryption and you want to use a certificate to authenticate, click Browse to browse to the location of a valid TLS or SSL certificate or type the path to the certificate in the SSL Certificate Upload Path field. A message appears, indicating that the certificate was successfully uploaded. 3. Type the base distinguished name for the LDAP directory you want to access in the Base DN field. For example, to authenticate names in the Security organization at the Example company, type ou=security,dc=example,dc=com.

4. To set a filter that retrieves only specific objects within the namespace you specified as the Base DN, type the attribute type, a comparison operator, and the attribute value you want to use as a filter, enclosed in parentheses, in the Base Filter field. For example, if the user objects in a directory tree have a physicalDeliveryOfficeName attribute and users in the New York office have an attribute value of NewYork for that attribute, to retrieve only users in the New York office, type (physicalDeliveryOfficeName=NewYork).

Version 4.7


1269


Chapter 31

5. Type the distinguished name and password for the user whose credentials should be used to validate access to the LDAP directory in the User Name and Password fields. For example, if you are connecting to an OpenLDAP Server where user objects have a uid attribute and the object for the administrator in the Security division at our example company has a uid value of NetworkAdmin, you would type uid=NetworkAdmin,ou=security,dc=example,dc=com. 6. Re-type the password in the Confirm Password field. 7.

Type the user distinguished name, with the string conversion character (%s) in place of the PAM login attribute value, into the User Name Template field. For example, to authenticate all users who work in the Security organization of our example company by connecting to an OpenLDAP server where the PAM login attribute is uid, you would type uid=%s,ou=security,dc=example,dc=com in the User Name Template field. For a Microsoft Active Directory server, you could type %[email protected].

Continue with Configuring Attribute Mapping.

Configuring Attribute Mapping Requires: DC

If your LDAP Server uses a default filter search attribute of uid, when a user logs in, the local appliance (3D Sensor or Defense Center) checks the value of the uid attribute for each user record on the LDAP Server to see if it matches the user name. If you want to filter on uid, you do not need to specify a filter search attribute. However, you can map a different attribute for the local appliance to search. Setting a filter search attribute tells the local appliance to match the value of that attribute rather than the value of the uid attribute. You can use any attribute, if the value of the attribute is a valid user name for either the Sourcefire 3D System web interface or for shell access. Valid user names are unique, have no spaces and no periods in them, and do not begin with a numeral. If your LDAP Server uses a Pluggable Authentication Module (PAM) login attribute of uid, the local appliance checks the user name entered on login against the attribute value of uid. If the PAM login attribute for a server is something other than uid, you must explicitly set it. To configure attribute mapping for a server:

Access: Admin

1.

To retrieve users based on an attribute instead of the Base DN and Base Filter, type the attribute type in the Filter Search Attribute field. For example, on a Microsoft Active Directory Server, you may want to use the Filter Search Attribute to retrieve users, because there may not be a uid attribute on Active Directory Server user objects. Instead, you can search the userPrincipalName attribute by typing userPrincipalName in the Filter Search Attribute field.

Version 4.7


1270


Chapter 31

2. To retrieve users for shell access, type the attribute type you want to filter on in the PAM Login Attribute field. For example, on a Microsoft Active Directory Server, use the sAMAccountName PAM login attribute to retrieve shell access users by typing sAMAccountName in the PAM Login Attribute field. Continue with Configuring Access Settings by Group on page 1271.

Configuring Access Settings by Group Requires: DC

If you prefer to base default access settings on a user’s membership in an LDAP group, you can specify distinguished names for existing groups on your LDAP server for each of the four access roles used by your Sourcefire 3D System. When you do so, you can configure a default access setting for those users detected by LDAP that do not belong to any specified groups. When a user logs in, the Sourcefire 3D System dynamically checks the LDAP directory and assigns default access rights according to the user’s current group membership. IMPORTANT!

Group membership does not affect shell access.

Any group you reference must exist on the LDAP server, and users must be members of the group in order for the default access role to be affected by the group access settings for that role. You can reference static LDAP groups or dynamic LDAP groups. Static LDAP groups are groups where membership is determined by group object attributes that point to specific users, and dynamic LDAP groups are groups where membership is determined by creating an LDAP search that retrieves group users based on user object attributes. The access rights granted when a user logs into the Sourcefire 3D System depends on the LDAP configuration:

Version 4.7

•

If no group access settings are configured for your LDAP server, when a new user logs in, the Sourcefire 3D System authenticates the user against the LDAP server and then grants user rights based on the default access role set in the system policy.

•

If you configure any group settings, new users belonging to specified groups inherit the setting for the groups where they are members.

•

If a new user does not belong to any specified groups, the user is assigned the access role specified in the Group Controlled Access Roles section of the authentication object.

•

If a user belongs to more than one configured group, the user receives the access role for the group with the highest access.


1271


Chapter 31

You cannot modify access rights for users assigned an access role because of LDAP group membership through the Sourcefire 3D System web interface. IMPORTANT! If you use a dynamic group, the LDAP query is used exactly as it is configured on the LDAP server. For this reason, the Sourcefire 3D System limits the number of recursions of a search to four to prevent search syntax errors from causing infinite loops. If a user’s group membership is not established in those recursions, the default access role defined in the Group Controlled Access Roles section is granted to the user. To base access defaults on LDAP group membership: Access: Admin

1.

Type the distinguished name for the LDAP group containing users who should receive default access to analysis and reporting features, rule and policy configuration, system management, and all maintenance features in the Admin Group DN field. For example, to authenticate names in the information technology organization at the Example company, type cn=itgroup,ou=groups, dc=example,dc=com.

2. Type the distinguished name for the LDAP group containing users who should receive default access to analysis features in the Data Group DN field. For example, to authenticate names in the Security organization at the Example company, type cn=securitygroup,ou=groups,dc=example, dc=com. 3. Type the distinguished name for the LDAP group containing users who should receive default access to monitoring and maintenance features in the Maintenance Group DN field. For example, to authenticate names in the information technology organization at the Example company, type cn=itgroup,ou=groups, dc=example,dc=com. 4. Type the distinguished name for the LDAP group containing users who should receive default access to rules and policy configuration in the Rules Group DN field. For example, to authenticate names in the Security organization at the Example company, type cn=securitygroup,ou=groups,dc=example, dc=com. 5. Select the default access role for users that do not belong to any of the specified groups from the Default Role drop-down list. For more information on user access roles, see Adding New User Accounts on page 1283.

Version 4.7


1272


Chapter 31

6. Type the LDAP attribute that designates membership in a static group in the Group Member Attribute field. For example, if the member attribute is used to indicate membership in the static group you reference for default Rules access, type member. 7.

Optionally, type the LDAP attribute that contains the LDAP search string used to determine membership in a dynamic group in the Group Member URL Attribute field. For example, if the memberURL attribute contains the LDAP search that retrieves members for the dynamic group you specified for default Admin access, type memberURL. Continue with Configuring Administrative Shell Access on page 1273.

Configuring Administrative Shell Access Requires: DC

You can also use the LDAP directory server to authenticate accounts for shell access on your local appliance (3D Sensor or Defense Center). Specify a search filter that will retrieve entries for users you want to grant shell access. Note that you can only configure shell access for the first authentication object in your system policy. For more information on managing authentication object order, see Configuring Authentication Profiles on page 1194. Shell access is controlled entirely though the shell access filter (or PAM login attribute) you set. Shell users are not configured as local users on the appliance, even after they log in. Addition and deletion of shell access users occurs only on the LDAP server, and the filter you set here determines which set of users on the LDAP server can log into the shell. Note that a home directory for each shell user is created on login, and when an LDAP shell access user account is disabled (by disabling the LDAP connection), the directory remains, but the user shell is set to /bin/false in /etc/password to disable the shell. If the user then is re-enabled, the shell is reset, using the same home directory. The Same as Base DN check box allows you to search more efficiently if all users qualified in the base DN are also qualified for shell access privileges. Normally, the LDAP query to retrieve users combines the base filter with the shell access filter. If the shell access filter was the same as the base filter, the same query would be run twice, which is unnecessarily time-consuming. You can use the Same as Base DN option to run the query only once for both purposes. Shell users should log in using usernames with all lowercase letters. WARNING! All shell users have sudoers privileges. Make sure that you restrict the list of users with shell access appropriately.

Version 4.7


1273


Chapter 31

To configure shell account authentication: Access: Admin

h

To set a filter to retrieve administrative user entries based on attribute value, type the attribute type, a comparison operator, and the attribute value you want to use as a filter, enclosed in parentheses, in the Shell Access Filter field, or select Same as Base DN to use the same filter you specified when configuring authentication settings.

For example, if all network administrators have a manager attribute which has an attribute value of shell, you can set a base filter of (manager=shell). IMPORTANT! If you choose not to specify a shell access filter, a warning displays when you save the authentication object to confirm that you meant to leave the filter blank. Continue with Testing User Authentication.

Testing User Authentication Requires: DC

After you configure LDAP server and authentication settings, you can specify user credentials for a user who should be able to authenticate to test those settings. For the user name, you can enter the value for the uid attribute for the user you want to test with. If you are connecting to a Microsoft Active Directory Server and supplied a PAM Login Attribute in place of uid in Configuring Attribute Mapping on page 1270, use the value for that attribute as the user name. You can also specify a fully-qualified distinguished name for the user. TIP! If you mistype the name or password of the test user, the test fails even if the server configuration is correct. Test the server configuration without the additional test parameters first. If that succeeds supply a user name and password to test with the specific user. To test user authentication:

Access: Admin

1.

In the User Name and Password fields, type the uid or PAM Login Attribute value and password for the user whose credentials should be used to validate access to the LDAP directory. For example, to test to see you can retrieve the JSmith user credentials at our example company, type uid=JSmith.

Version 4.7


1274


Chapter 31

2. Click Test. A message appears, either indicating success of the test or detailing what settings are missing or need to be corrected. 3. If the test succeeds, click Save. The Login Authentication page appears, with the new object listed. To enable LDAP authentication using the object on an appliance, you must apply a system policy with that object enabled to the appliance. For more information, see Configuring Authentication Profiles on page 1194 and Applying a System Policy on page 1192.

Authentication Object Examples Requires: DC

For sample configurations showing how different configuration options might be used for connections to specific directory server types, see the following sections: •

OpenLDAP Example on page 1275

•

Microsoft Active Directory Server Example on page 1276

•

Sun Directory Server Example on page 1278

OpenLDAP Example Requires: DC

The following figure illustrates a sample LDAP login authentication object for an OpenLDAP directory server with an IP address of 10.10.3.4, with a backup server that has an IP address of 10.10.3.5. Note that the connection uses port 389 for access and that connections to the server time out after 30 seconds of disuse. This example illustrates important aspects of LDAP configuration: •

This example shows a connection using a base distinguished name of

OU=security,DC=it,DC=example,DC=com for the security organization in

the information technology domain of the Example company.

Because the user names to be retrieved are contained in the default uid attribute, no filter search attribute is specified. The Sourcefire 3D System checks the uid attribute of each object in the directory indicated by the distinguished name against the username for each user who logs into the system. Note that all objects in the directory are checked because no base filter is set.

Version 4.7

•

Because this is an OpenLDAP server that uses CN as a part of each user’s name, the user name template for the connection uses CN=%s, followed by the base distinguished name for the server directory, to indicate the template used to format user names retrieved from the server.

•

Because this is an OpenLDAP server that uses CN as a part of each user’s name, the user name template for the connection uses CN=%s, followed by the base distinguished name for the server directory, to indicate the template used to format user names retrieved from the server.


1275


Chapter 31

•

To support shell access, the CN attribute is set as the PAM login attribute.

•

A shell access filter has been applied to this configuration, allowing only those users who have a common name attribute value of jsmith to log into the appliance using a shell account.

Microsoft Active Directory Server Example Requires: DC

The following figure illustrates a sample LDAP login authentication object for a Microsoft Active Directory Server with an IP address of 10.11.3.4, with a backup server that has an IP address of 10.11.3.5. Like the OpenLDAP server, the connection uses port 389 for access and connections to the server time out after 30 seconds of disuse (or the timeout period set on the LDAP server). Aspects of this example illustrate important differences in this LDAP configuration from the configuration discussed in OpenLDAP Example on page 1275:

Version 4.7


1276


•

Chapter 31

Like the OpenLDAP server, this example shows a connection using a base distinguished name of OU=security,DC=it,DC=example,DC=com for the security organization in the information technology domain of the Example company. Again, because no base filter is applied to this server, the Sourcefire 3D System checks attributes for all objects in the directory indicated by the base distinguished name. However, because this server is a Microsoft Active Directory server, it uses the userPrincipalName attribute to store user names rather than the uid attribute. Note that the configuration includes a Filter Search Attribute of userPrincipalName. As a result, the Sourcefire 3D System checks the userPrincipalName attribute for each object for matching user names when a user attempts to log into the Sourcefire 3D System. In addition, a PAM Login Attribute of sAMAccountName causes each sAMAccountName attribute to be checked for all objects in the directory for matches when a user logs into a shell account on the appliance.

•

Version 4.7

Because this is a Microsoft Active Directory Server, the user name template for the connection uses address specification syntax documented in RFC 822 rather than the typical LDAP naming syntax.


1277


•

Chapter 31

As in the OpenLDAP server, a shell access filter has been specified for this server, allowing only those users who have a common name attribute value of jsmith to log into the appliance using a shell account. However, as noted above, a PAM Login Attribute value of sAMAccountName must be set for shell access to work on a Microsoft Active Directory server.

Sun Directory Server Example Requires: DC

The following figure illustrates a sample LDAP login authentication object for a Sun Directory Server with an IP address of 10.12.3.4, with a backup server that has an IP address of 10.12.3.5. Settings in the example illustrate important differences in this LDAP configuration from the configuration discussed in Microsoft Active Directory Server Example on page 1276:

Version 4.7


1278


•

Chapter 31

Because the Encryption for the connection is set to SSL, the Server Port is set to 636. A certificate has been uploaded to allow the SSL connection.

•

This example shows a connection using a base distinguished name of OU=security,DC=it,DC=example,DC=com for the security organization in the information technology domain of the Example company. However, note that this server does have a base filter of (cn=*smith). The filter restricts the users retrieved from the server to those with a common name ending in smith.

Version 4.7

•

Because user names can be retrieved from the uid attribute on this server, no filter search attribute is specified. The Sourcefire 3D System checks the uid attribute of each object in the directory indicated by the distinguished name against the user name for each user who logs into the system. Note that all objects in the directory are checked because no base filter is set.

•

The user name template shown uses the uid attribute value as the user name.


1279


•

Chapter 31

To allow shell access on the server, the uid attribute is named as the PAM Login Attribute and the Same as Base DN option for the shell access filter is set, allowing all users with a common name ending in smith to log in using a shell account as well. The Same as Base DN check box is a new feature to allow a more efficient search query if and only if all users qualified in the base DN are also qualified for shell access privileges.

Editing Authentication Objects Requires: DC

You can edit an existing authentication object. If the object is in use in a system policy, the settings in place at the time the policy was applied stay in effect until you re-apply the policy. To edit an authentication object:

Access: Admin

1.


Version 4.7


1280

Managing Users Managing User Accounts

Chapter 31

2. Click Edit next to the object you want to edit. The Create Authentication Object page appears. 3. Modify the object settings as needed. For more information, see the following topics: •

Creating Authentication Objects on page 1266

•

Configuring LDAP Authentication Settings on page 1267

•

Configuring Attribute Mapping on page 1270

•

Configuring Administrative Shell Access on page 1273

•

Testing User Authentication on page 1274

IMPORTANT! If you previously uploaded a certificate and want to replace it, upload the new certificate and re-apply the system policy to your appliances to copy over the new certificate. 4. Click Save. Your changes are saved and the Login Authentication page re-appears. Remember that you have to apply a system policy with the object enabled to an appliance before the authentication changes take place on that appliance. For more information, see Configuring Authentication Profiles on page 1194 and Applying a System Policy on page 1192.

Deleting Authentication Objects Requires: DC

You can delete an authentication object if it is not currently enabled in a system policy. To delete an authentication object:

Access: Admin

1.


2. Click Delete next to the object you want to delete. The object is deleted and the Login Authentication page appears.

Managing User Accounts If you have Admin access, you can use the web interface to view and manage user accounts on a Defense Center or a 3D Sensor, including adding, modifying, and deleting accounts. User accounts without Admin access are restricted from accessing management features. The navigation menu differs in appearance for each type of user.

Version 4.7


1281


Chapter 31

See the following sections for more information about managing user accounts: •

Viewing User Accounts on page 1282 explains how to access the User Management page, where you can add, modify, and delete user accounts.

•

Adding New User Accounts on page 1283 describes the different options you can use when you add a new user account.

•

Managing Externally Authenticated User Accounts on page 1287 explains how externally authenticated users are added and what aspects of the user configuration you can manage within the Sourcefire 3D System.

•

Modifying User Privileges and Options on page 1287 explains how to access and modify an existing user account.

•

Modifying Restricted Data Access Properties on page 1288 explains how to restrict the data available to a user account with restricted data access.

•

Deleting User Accounts on page 1291 explains how to delete user accounts.

•

User Account Privileges on page 1291 contains tables that list the menus and options each type of user account can access.

Viewing User Accounts Requires: DC/MDC or 3D Sensor

From the User Management page, you can view, edit, and delete existing accounts. You can determine the type of authentication for a user from the Authentication Method column. The Status column indicates whether a user is active. Note that for LDAP users, if authentication for the LDAP server is disabled, the Authentication Method column displays External (Disabled). To access the User Management page:

Access: Admin

h

Select Operations > User Management. The User Management page appears, showing each user, associated access privileges, and options to edit or delete the user account.

See the following sections for information about the actions you can perform on the User Management page:

Version 4.7

•

Modifying User Privileges and Options on page 1287

•

Modifying Restricted Data Access Properties on page 1288


1282


Chapter 31

•

Modifying User Passwords on page 1290

•

Deleting User Accounts on page 1291

Adding New User Accounts Requires: DC/MDC or 3D Sensor

When you set up a new user account, you can control which parts of the system the account can access. The User Account Access Types table contains a synopsis of each access type. For a full list of the menus available to each access type, see User Account Privileges on page 1291. Note that you cannot change the authentication type for a user after you create the user account. In addition, externally authenticated users cannot authenticate unless the LDAP server is available. User Account Access Types Access Type

Privileges

Admin Access

Provides access to analysis and reporting features, rule and policy configuration, system management, and all maintenance features. Admin users can access the main toolbar as well as all the menu options.

Maintenance Access

Provides access to monitoring and maintenance features. Maintenance users see only the main toolbar and maintenance-related options on the Operations top-level menu.

Data Access

Provides access to analysis features, including event views, network maps, host profiles, services, vulnerabilities, client applications, incidents, and reports. Data users see only the main toolbar and analysis-related options on the Analysis & Reporting and Operations menus.

Restricted Data Access

Provides access to the same features as Data access, but only for those events that match specified search criteria. See Modifying Restricted Data Access Properties on page 1288 for more information. Restricted data users see only the main toolbar and analysis-related options on the Analysis & Reporting and Operations menus.

Rule Access

Provides access to rules and policy configuration. Rules users see only the main toolbar and rule and policy-related options on the Policy & Response and Operations menus.

You can also control how and when the password for each user account is changed, as well as when user accounts are disabled. The User Account Access

Version 4.7


1283


Chapter 31

Types table describes some of the options you can use to regulate passwords and account access. IMPORTANT! After you enable Use External Authentication Method, this option no longer appears. Use the LDAP server to manage this setting. User Account Password Options Option

Description

Use External Authentication Method

Select this option if you want this user's credentials to be externally authenticated.

Force Password Reset on Login

Select this option to force the user to change his password the first time he logs in.

IMPORTANT! If you select this option for the user and the external authentication server is unavailable, that user cannot log into the web interface.

IMPORTANT! After you enable Use External Authentication Method, this option and the following options no longer appear. Use the LDAP server to manage password settings. Password Strength Check

Select this option to require strong passwords. A strong password must be at least eight alphanumeric characters of mixed case and must include at least one numeric character. It cannot be a word that appears in a dictionary or include consecutive repeating characters.

Max Number of Failed Logins

Enter a value that determines the maximum number of times each user can try to log in after a failed login attempt before her account is locked. The default setting is five tries; use 0 to allow an unlimited number of failed logins. IMPORTANT! You cannot change the maximum number of failed logins after the user account is created.

Version 4.7


1284


Chapter 31

User Account Password Options (Continued) Option

Description

Password Expiration

Enter the number of days after which the user’s password will expire. The default setting is 0, which indicates that the password never expires. IMPORTANT! You cannot change the password expiration after the user account is created.

Warning Days

Enter the number of warning days users have to change their password before their password actually expires. The default setting is 0 days. IMPORTANT! You cannot change the number of warning days after the user account is created. WARNING! The number of warning days must not exceed the number of days before the password expires.

To add a new user: Access: Admin

1.

Select Operations > User Management. The User Management page appears.

Version 4.7


1285


Chapter 31

2. Click Create User. The New User page appears.

3. In the User Name field, type a name for the new user. New user names must contain alphanumeric characters with no spaces, and must be no more than 32 characters. 4. Defense Center Only If you want this user to authenticate to an external directory server on login, select Use External Authentication Method. IMPORTANT! If you select this option, the password management options below disappear. Configure access settings and click Add User to complete configuration of the externally authenticated user. You must also create an authentication object for the directory server you want to use for authentication on your Defense Center, and apply a system policy with authentication enabled to your appliance before users can log in using credentials from an external server. For more information, see Creating Authentication Objects on page 1266 and Configuring Authentication Profiles on page 1194. 5. In the Password field, type a password (up to 32 alphanumeric characters). If you enable password strength checking, the password must be at least eight alphanumeric characters of mixed case and must include at least one numeric character. It cannot be a word that appears in a dictionary or include consecutive repeating characters. 6. In the Confirm Password field, type the password again. 7.

In the Access section, select the access check boxes that apply to the new user. For more information, see the User Account Access Types table on page 1283.

Version 4.7


1286


Chapter 31

8. In the Options section, configure the user account options. For more information, see the User Account Password Options table on page 1284. 9. Click Add User. A message appears, indicating that the user was added.

Managing Externally Authenticated User Accounts Requires: DC/MDC or 3D Sensor

When an externally authenticated user logs into an appliance that has external authentication enabled, the appliance grants the user the default access role you set by specifying group membership in the authentication object. If you did not configure access group settings, the appliance grants the default role you set in the system policy. However, if you add users locally before they log into the appliance, the user privileges you configure on the User Management page override the default settings. An internally authenticated user is converted to external authentication when all of the following conditions exist: •

You enable LDAP authentication.

•

The same username exists for the user on the LDAP server.

•

The user logs in using the password stored for that user on the LDAP server.

Once an internally authenticated user converts to an externally authenticated user, you cannot revert to internal authentication for that user. For more information on selecting a default role, see Configuring Authentication Profiles on page 1194 and Understanding User Privileges on page 1264. Note that you can only enable external authentication in a system policy on a Defense Center. You must use the Defense Center to apply the policy to managed sensors if you want to use external authentication on them. For more information on associating an external user with a set of permissions on your appliance, see Logging into the Appliance to Set Up an Account on page 32. For more information on modifying user access, see Modifying User Privileges and Options on page 1287. Note that you cannot manage passwords for externally authenticated users through the Sourcefire 3D System interface.

Modifying User Privileges and Options Requires: DC/MDC or 3D Sensor

Version 4.7

After adding user accounts to the system, you can modify access privileges, account options, or passwords at any time. The User Account Options table describes all modifiable options. Note that password management options do not apply to users who authenticate to an external directory server. Those settings are managed on the external server. However, you must configure access rights for all accounts, including those that are externally authenticated.


1287


Chapter 31

For externally authenticated users, you can only change access types. User Account Options Option

Description

Change Password

Use this option to change the user’s password. See Modifying User Passwords on page 1290 for more information.

Access Types

See the User Account Access Types table on page 1283 for a description of each option.

Password Strength Check

Select this option to require strong passwords. A strong password must be at least eight alphanumeric characters of mixed case and must include at least one numeric character. It cannot be a word that appears in a dictionary or include consecutive repeating characters.

Reset Password

Click Reset Password to force users to reset the password the next time they log in.

To modify user account privileges: Access: Admin

1.


2. Modify the account or accounts as needed. See the User Account Options table on page 1288 for a description of each option you can modify. IMPORTANT! The page reloads to save your change after each click. When enabling or disabling multiple options, you should wait for the page to reload (usually about five seconds) after each modification to ensure that your changes are applied.

Modifying Restricted Data Access Properties Requires: DC/MDC or 3D Sensor

Version 4.7

User accounts with Restricted Data access use saved searches to specify which events a user can view. You can specify this information only after the user is added. See Adding New User Accounts on page 1283 for information about adding new user accounts.


1288


Chapter 31

Restricted data users have access to only a few sections of the web interface, allowing them to: •

view the network map (Defense Center only - requires RNA)

•

view network discovery events, hosts, services, vulnerabilities, client applications, and flow data (Defense Center only - requires RNA)

•

view compliance events (Defense Center only - requires RNA)

•

view intrusion events (requires IPS)

•

use the clipboard (requires IPS)

•

generate (but not view) reports based on clipboard contents (requires IPS)

•

create (but not modify) incident reports (requires IPS)

•

change user-specific preferences such as the account password, time zone, and event view settings

•

create custom workflows and, on the Defense Center, custom tables

•

create and manage bookmarks

If you want to ensure that a user only sees data for a specific subnet, create multiple private saved searches, one for each of the event types, and then apply each saved search to the account as described in the following procedure. IMPORTANT! You must have saved private searches available before you can add restricted data values to a user account. Searches must be private. If they are saved as public, restricted data users could delete the searches and enhance their access privileges. See Searching for Events on page 1124 for more information. To add restricted network information to a user account: Access: Admin

1.


2. If the user you want to modify does not already have the Restricted Data Access option enabled, select the Restricted Data Access check box next to the user account that you want to modify. The page reloads and saves your selection. IMPORTANT! You cannot select Restricted Data Access if Admin or Data access is enabled.

Version 4.7


1289


Chapter 31

3. Next to the Restricted Data Access check box, click Edit. The Data Restriction page appears. The Defense Center version of the page is shown below.

IMPORTANT! If you created any custom tables on the Defense Center, they appear on this page. 4. For each row, select the search that you want to use to restrict the user account. 5. Click Save to save your changes, then click Back to return to the User Management page.

Modifying User Passwords Requires: DC/MDC or 3D Sensor

You can modify user passwords from the User Management page for internally authenticated users. Note that you must manage LDAP user passwords on the LDAP server. TIP! If you want to force a user to change the password on the next log-in, click Reset Password next to the user account on the User Management page. To change a user’s password from the User Management page:

Access: Admin

1.


Version 4.7


1290


Chapter 31

2. Next to the user name, click Change Password. The Manage User page appears.

3. In the Password field, type the new password (up to 32 alphanumeric characters). 4. In the Confirm Password field, re-type the new password. IMPORTANT! If password strength checking is enabled for the user account, the password must have at least eight alphanumeric characters of mixed case, with at least one number. It cannot be a word that appears in a dictionary or contain consecutive repeating characters. 5. Click Change. The password is changed.

Deleting User Accounts Requires: DC/MDC or 3D Sensor

You can delete user accounts from the system at any time, with the exception of the admin account, which cannot be deleted. To delete a user account:

Access: Admin

1.


2. Next to the user whose account you want delete, click Delete. The account is deleted.

User Account Privileges Requires: DC/MDC or 3D Sensor

Version 4.7

The following sections provide a list of the menus and toolbar options in Sourcefire 3D System and the user account privileges required to access them. •

Analysis & Reporting Menu on page 1292

•

Policy & Response Menu on page 1294

•

Operations Menu on page 1296

•

Toolbar Options on page 1297


1291


Chapter 31

Analysis & Reporting Menu Requires: IPS or DC/MDC

The Analysis & Reporting Menu table lists the user account privileges required to access each option on the Analysis & Reporting menu. An X indicates that the user can access the option. Users with either Rules or Maintenance access cannot see the Analysis & Reporting menu at all.

Analysis & Reporting Menu Menu

Admin

Maint.

Data

Res. Data

Event Summary

X

X

Intrusion Event Statistics

X

X

Event Graphs

X

X

Dashboard

X

X

RNA Statistics

X

X

X

Flow Summary

X

X

X

IPS

X

X

X

Events

X

X

X

Reviewed Events

X

X

X

Clipboard

X

X

X

Incidents

X

X

RNA

X

X

X

Network Map | Hosts

X

X

X

Network Map | Bridges

X

X

X

Network Map | Services

X

X

X

Network Map | Vulnerabilities

X

X

X

Network Map | Host Attributes

X

X

X

RNA Events

X

X

X

Hosts

X

X

X

Version 4.7


Rules

X

1292


Chapter 31

Analysis & Reporting Menu (Continued) Menu

Admin

Maint.

Data

Res. Data

Host Attributes

X

X

X

Services

X

X

X

Client Applications

X

X

X

Flow Data

X

X

X

Vulnerabilities

X

X

X

RUA

X

X

X

Users

X

X

X

RUA Events

X

X

X

Compliance

X

X

X

Compliance Events

X

X

X

White List Events

X

X

X

Custom Tables

X

X

X

Searches

X

X

X

Intrusion Events

X

X

X

RNA Events

X

X

X

Hosts

X

X

X

Host Attributes

X

X

X

Services

X

X

X

Client Applications

X

X

X

Flow Data

X

X

X

Vulnerabilities

X

X

X

Compliance Events

X

X

X

Version 4.7


Rules

X

1293


Chapter 31

Analysis & Reporting Menu (Continued) Menu

Admin

Maint.

Data

Res. Data

White List Events

X

X

X


X

X

X

Remediation Status

X

X

X

SEU Import Log

X

X

X

Audit Log

X

Health Events

X

X

X

Scan Results

X

X

X

Users

X

X

X

RUA Events

X

X

X

Custom Workflows

X

X

X

Bookmarks

X

X

X

Reporting

X

X

Rules

X

Policy & Response Menu Requires: IPS or DC/MDC

The Policy & Response Menu table lists the user account privileges required to access each option on the Policy & Response menu. An X indicates that the user can access the option. Users with either Data or Maintenance access can not see the Policy & Response menu at all.

Policy & Response Menu Menu

Admin

Maint.

Data

Res. Data

Rules

IPS

X

X

Detection & Prevention

X

X

SEU

X

X

Rules

X

X

Version 4.7


1294


Chapter 31

Policy & Response Menu (Continued) Menu

Admin

Email

X

X

OPSEC

X

X

RNA

X

X

Detection Policy

X

Host Attributes

X

X

Custom Service Detectors

X

X

Custom Fingerprinting

X

X

Custom Product Mappings

X

User 3rd Party Mappings

X

Network Map | Custom Topology

X

Compliance

X

X

Policy Management

X

X

Rule Management

X

X

White List

X

X

Traffic Profiles

X

X

Responses

X

X

Alerts

X

X

Impact Flag Alerts

X

X

RNA Event Alerts

X

X

Remediations

X

X

Groups

X

X

Version 4.7

Maint.

Data


Res. Data

Rules

1295


Chapter 31

Operations Menu Requires: DC/MDC or 3D Sensor

The Operations Menu table lists the user account privileges required to access each option on the Operations menu. An X indicates that the user can access the option. All users can access at least some options on the Operations menu.

Operations Menu Menu

Admin

Maint.

Configuration

X

RNA/RUA Event Purge

X

Detection Engines

X

High Availability

X

Estreamer

X

Visualizer

X

Login Authentication

X

RUA

X

Sensors

X

User Management

X

System Settings

X

System Policy

X

Update

X

Monitoring

X

X

Statistics

X

X

Performance | IPS

X

X

Performance | RNA

X

X

Audit

X

Task Status

X

Version 4.7

Data

X


Res. Data

Rules

X

X

1296


Chapter 31

Operations Menu (Continued) Menu

Admin

Maint.

Data

Res. Data

Rules

Syslog

X

X

Health

X

X

Tools

X

X

Scheduling

X

X

Backup/Restore

X

X

Import/Export

X

Whois

X

Scan Results

X

Scanners

X

Help

X

X

X

X

X

About

X

X

X

X

X

Online

X

X

X

X

X

Email Support

X

X

X

X

X

Support Site

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X X

Toolbar Options Requires: DC/MDC or 3D Sensor

Version 4.7

The Toolbar Options table lists the user account privileges required to access each option on the toolbar and its sub-menus. An X indicates that the user can


1297


Chapter 31

access the option. All users can access at least some of the options on the toolbar. Toolbar Options Menu

Admin

Health Preferences Preferences | Home Page

Preferences | Change Password Preferences | Time Zone Settings

Logout

Version 4.7

Data

Res. Data

Rules

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

Preferences | Event View Settings

Help

Maint.

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X


1298

Chapter 31

Scheduling Tasks

You can schedule many different types of administrative tasks to run at scheduled times, including: •

running backups

•

applying intrusion policies (requires IPS)

•

generating reports

•

running Nessus scans (Defense Center only - requires RNA)

•

synchronizing Nessus plugins (Defense Center only - requires RNA)

•

running Nmap scans

•

accepting RNA rule recommendations

•

importing Security Enhancement Updates (SEUs) (requires IPS)

•

downloading and installing software updates

•

downloading and installing vulnerability database updates (Defense Center only - requires RNA)

•

pushing downloaded updates to managed sensors (Defense Center only)

You can schedule tasks to run once or on a recurring schedule. IMPORTANT! Some tasks (such as those involving automated software and SEU updates and those that require pushing updates or intrusion policies to managed sensors) can place a significant load on networks with low bandwidths. You should always schedule tasks like these to run during periods of low network use.

Version 4.7


1299

Scheduling Tasks Configuring a Recurring Task

Chapter 32


Configuring a Recurring Task on page 1300 explains how to set up a scheduled task so that it runs at regular intervals.

•

Automating Backup Jobs on page 1302 provides procedures for scheduling backup jobs.

•

Automating Software Updates on page 1304 provides procedures for scheduling the download, push, and installation of software updates.

•

Automating Vulnerability Database Updates on page 1310 provides procedures for scheduling the download, push, and installation of software updates.

•

Automating SEU Updates on page 1315 provides procedures for scheduling rule updates.

•

Automating Intrusion Policy Applications on page 1318 provides procedures for scheduling intrusion policy applications.

•

Automating Reports on page 1320 provides procedures for scheduling reports.

•

Automating Nessus Scans on page 1321 provides procedures for scheduling Nessus scans.

•

Synchronizing Nessus Plugins on page 1324 provides procedures for synchronizing your sensor with the Nessus server.

•

Automating Nmap Scans on page 1325 provides procedures for scheduling Nessus scans.

•

Automating Acceptance of Recommended Rule States on page 1327 provides procedures for scheduling automatic acceptance of intrusion rule state recommendations based on RNA data.

•

Viewing Tasks on page 1329 describes how to view and manage tasks after they are scheduled.

•

Editing Scheduled Tasks on page 1331 describes how to edit an existing task.

•

Deleting Scheduled Tasks on page 1332 describes how to delete one-time tasks and all instances of recurring tasks.

Configuring a Recurring Task Requires: IPS or DC/MDC

The process for specifying how often you want a recurring task to run is the same for any scheduled task. Note that the time displayed on most pages on the web interface is the local time, which is determined by using the time zone you specify in your system settings. Further, the Defense Center or 3D Sensor with IPS automatically adjusts its local time display for daylight saving time (DST), where appropriate. However, recurring tasks that span the transition dates from DST to standard time and back

Version 4.7


1300

Scheduling Tasks Configuring a Recurring Task

Chapter 32

do not adjust for the transition. That is, if you create a task scheduled for 2am during standard time, it will run at 3am during DST. Similarly, if you create a task scheduled for 2am during DST, it will run at 1am during standard time. To configure a recurring task: Access: Maintenance or Admin

1.

Select Operations > Tools > Scheduling. The Scheduling page appears.

2. Click Add Task. The Add Task page appears. 3. From the Job Type list, select the type of task that you want to schedule. Each of the types of tasks you can schedule is explained in its own section. 4. For the Schedule task to run option, select Recurring. The page reloads with the recurring task options.

5. In the Start On field, specify the date when you want to start your recurring task. You can use the drop-down list to select the month, day, and year. 6. In the Repeat Every field, specify how often you want the task to recur. You can specify a number of hours, days, weeks, or months. TIP! You can either type a number or use the arrow buttons to specify the interval. For example, type 2 and select Day(s) to run the task every two days. 7.

In the Run At field, specify the time that you want to start your recurring task.

8. If you selected Week(s) in the Repeat Every field, a Repeat On field appears. Select the check boxes next to the days of the week when you want to run the task.

Version 4.7


1301

Scheduling Tasks Automating Backup Jobs

Chapter 32

9. If you selected Month(s) in the Repeat Every field, a Repeat On field appears. Use the drop-down list to select the day of the month when you want to run the task. The remaining options on the Add Task page are determined by the task you are creating. See the following sections for more information: •

Automating Backup Jobs on page 1302

•

Automating Software Updates on page 1304

•

Automating Vulnerability Database Updates on page 1310

•

Automating SEU Updates on page 1315

•

Automating Intrusion Policy Applications on page 1318

•

Automating Reports on page 1320

•


•

Synchronizing Nessus Plugins on page 1324

•

Automating Nmap Scans on page 1325

•

Automating Acceptance of Recommended Rule States on page 1327

Automating Backup Jobs Requires: IPS or DC/MDC

If you use the scheduler to automate system backups of a Defense Center or a 3D Sensor with IPS. TIP! You must design a backup profile before you can configure it as a scheduled task. For information on backup profiles, see Creating Backup Profiles on page 1243. To automate backup tasks:


1.


2. Click Add Task. The Add Task page appears.

Version 4.7


1302

Scheduling Tasks Automating Backup Jobs

Chapter 32

3. From the Job Type list, select Backup. The page reloads to show the backup options.

4. Specify how you want to schedule the backup, Once or Recurring. •

For one-time tasks, use the drop-down lists to specify the start date and time.

•

For recurring tasks, you have several options for setting the interval between occurrences of the task. See Configuring a Recurring Task on page 1300 for details.

5. In the Job Name field, type a name using up to 255 alphanumeric characters, spaces, or dashes. 6. From the Backup Profile list, select the appropriate backup profile. For more information on creating new backup profiles, see Creating Backup Profiles on page 1243. 7.

In the Comment field, type a comment using up to 255 alphanumeric characters, spaces, or periods. TIP! The comment field appears in the View Tasks section of the page, so you should try to keep it relatively short.

8. Optionally, in the Email Status To: field, type the email address (or multiple email addresses separated by commas) where you want status messages sent. IMPORTANT! You must have a valid email relay server configured to send status messages. See Configuring a Mail Relay Host and Notification Address on page 1201 for more information about configuring a relay host. 9. Click Save. The backup task is created.

Version 4.7


1303

Scheduling Tasks Automating Software Updates

Chapter 32

Automating Software Updates Requires: IPS or DC/MDC

When automating software updates for your appliance, you must schedule two separate tasks: 1.

Downloading the update.

2. Installing the update. If you use your Defense Center to automate software updates for managed 3D Sensors, you must schedule three tasks: 1.

Download the update.

2. Push the update to managed sensors. 3. Install the update on managed sensors. You should schedule these tasks to happen in succession. For example, you must always download an update before installing it. If you want to automate software updates on your managed sensors, you must always download the update first, then push it to the sensor, then install it on the sensor. Always allow enough time between tasks for the process to complete. For example, if you schedule a task to install an update and the update has not fully downloaded, the installation task will not succeed. However, if the scheduled installation task repeats daily, it will install the downloaded update when it runs the next day. Note that the tasks for pushing the update to managed sensors (on the Defense Center) and installing the update (on any appliance) automatically check the Support site to ensure that you have the latest version of the update. If your appliance cannot access the Support site, the task does not complete. This behavior also has implications for appliances that cannot access the Support site at all. Specifically, if you manually download a update to an appliance that cannot access the Support site, you cannot schedule either pushes to managed sensors (on the Defense Center) or installs (on any appliance). Instead you must manually push or install the updates as described in Updating System Software on page 1233. If you want to have more control over this process, you can use the Once option to download and install updates during off-peak hours after you learn that an update has been released. TIP! The automated update process allows you to download and install software patches and feature releases (generally when the last two digits in the four-digit version number change, such as 4.6.1 or 4.6.1.1). For larger, more comprehensive updates (such as 4.6 or 4.7), you must manually upload, push, and install the upgrade files.

Version 4.7


1304


Chapter 32


Automating Software Downloads on page 1305

•

Automating Software Pushes on page 1306

•

Automating Software Installs on page 1308

Automating Software Downloads Requires: IPS or DC/MDC

You can create a scheduled task that automatically downloads the latest software updates from Sourcefire. On the Defense Center, you can also automate vulnerability database (VDB) updates. To automate software updates:


1.


2. Click Add Task. The Add Task page appears. 3. From the Job Type list, select Download Latest Update. The Add Task page reloads to show the update options. The Defense Center version of the page is shown below.

4. Specify how you want to schedule the task, Once or Recurring.

Version 4.7

•


•



1305


Chapter 32

5. In the Job Name field, type a name using up to 255 alphanumeric characters, spaces, or dashes. IMPORTANT! If your appliance is not directly connected to the Internet, you should set up a proxy as described in Configuring Network Settings on page 1220 to allow it to download updates from the Sourcefire Support site (https://support.sourcefire.com/). 6. In the Update Items section, specify which updates you want to download. •

Select Software to download the most recent software patch.

•

Select Vulnerability Database to download the most recent vulnerability database update. (Defense Center Only)

Both options are selected by default. 7.


8. Optionally, in the Email Status To: field, type the email address (or multiple email addresses separated by commas) where you want status messages sent. IMPORTANT! You must have a valid email relay server configured to send status messages. See Configuring a Mail Relay Host and Notification Address on page 1201 for more information about configuring a relay host. 9. Click Save. The task is created.

Automating Software Pushes Requires: DC/MDC

If you are installing software or vulnerability database updates on managed 3D Sensors, you must push the software to the managed sensors before installing. When you push software updates to managed sensors, information about the push process status is reported on the Tasks page. See Viewing the Status of Long-Running Tasks on page 1259 for more information. TIP! Make sure you allow enough time for scheduled software updates to download when you create the task to push them to managed sensors.

Version 4.7


1306


Chapter 32

To push software updates to managed sensors: Access: Maintenance or Admin

1.


2. Click Add Task. The Add Task page appears. 3. From the Job Type list, select Push Latest Update. The page reloads to show the options for pushing updates.

4. Specify how you want to schedule the task, Once or Recurring. •


•


5. In the Job Name field, type a name using up to 255 alphanumeric characters, spaces, or dashes. 6. From the Sensor list, select the sensor that you want to receive updates. 7.

In the Update Items section, specify which updates you want to push to your managed sensors. •

Select Software to push the software update.

•

Select Vulnerability Database to push the VDB update. (Defense Center Only - requires RNA)

Both options are selected by default.

Version 4.7


1307


Chapter 32

8. In the Comment field, type a comment using up to 255 alphanumeric characters, spaces, or periods. TIP! The comment field appears in the View Tasks section of the page, so you should try to keep it relatively short. 9. Optionally, in the Email Status To: field, type the email address (or multiple email addresses separated by commas) where you want status messages sent. IMPORTANT! You must have a valid email relay server configured to send status messages. See Configuring a Mail Relay Host and Notification Address on page 1201 for more information about configuring a relay host. 10. Click Save. The task is added. When the software push task is performed, status information is reported on the Task Status page, where you can check its status. See Viewing the Status of Long-Running Tasks on page 1259 for more information.

Automating Software Installs Requires: IPS or DC/MDC

After you have downloaded a software update, you can install it. TIP! Make sure you allow enough time for a scheduled software update to download when you create a task to install it. If you are using a Defense Center to create a task to install a software update on a managed sensor, make sure you allow enough time between the task that pushes the update to the sensor and the task that installs the update. See Automating Software Pushes on page 1306 for information about pushing updates to managed sensors.

WARNING! Depending on the update being installed, the appliance may reboot after the software is installed. To schedule a software installation task: Access: Maintenance or Admin

1.



Version 4.7


1308


Chapter 32

3. From the Job Type list, select Install Latest Update. The page reloads to show the options for installing updates. The Defense Center version of the page is shown below.



•


5. In the Job Name field, type a name using up to 255 alphanumeric characters, spaces, or dashes. 6. If you are using a Defense Center, from the Sensor list, you have the following options:

7.

•

Select the sensor where you want to install the update.

•

Select the name of the Defense Center to install the update there.

In the Update Items section, select Software to install the software update.

8. In the Comment field, type a comment using up to 255 alphanumeric characters, spaces, or periods. TIP! The comment field appears in the View Tasks section of the page, so you should try to keep it relatively short.

Version 4.7


1309

Scheduling Tasks Automating Vulnerability Database Updates

Chapter 32

9. Optionally, in the Email Status To: field, type the email address (or multiple email addresses separated by commas) where you want status messages sent. IMPORTANT! You must have a valid email relay server configured to send status messages. See Configuring a Mail Relay Host and Notification Address on page 1201 for more information about configuring a relay host. 10. Click Save. The scheduled software installation task is added. When the task is performed, status information is reported on the Task Status page, where you can check its status. See Viewing the Status of LongRunning Tasks on page 1259 for more information.

Automating Vulnerability Database Updates Requires: DC/MDC + RNA

Sourcefire uses vulnerability database (VDB) updates to distribute new operating system fingerprints as we expand the list of operating systems that RNA recognizes. VDB updates also include new vulnerabilities discovered by Sourcefire. You can use the scheduling feature to download and install the latest VDB updates, thereby ensuring that RNA is using the most up-to-date information to evaluate the hosts on your network. TIP! If your Sourcefire 3D System deployment includes IPS and RNA monitoring the same network segments, make sure that you download and install VDB updates and SEUs on a regular basis. This ensures that your Defense Center is correctly setting the impact flag on the intrusion events generated by the traffic on your network. When automating VDB updates for your Defense Center, you must automate two separate steps: 1.

Downloading the VDB update.

2. Installing the VDB update. When automating VDB updates for managed sensors with RNA, you must schedule three tasks in this order: 1.

Download the VDB update.

2. Push the VDB update to your managed 3D Sensors that are using the RNA component. 3. Install the VDB update on the Defense Center and on those managed sensors.

Version 4.7


1310


Chapter 32

Always allow enough time between tasks for the process to complete. For example, if you schedule a task to install an update and the update has not fully downloaded, the installation task will not succeed. However, if the scheduled installation task repeats daily, it will install the downloaded VDB update when it runs the next day. If you want to have more control over this process, you can use the Once option to download and install VDB updates during off-peak hours after you learn that an update has been released. See the following sections for more information: •

Automating VDB Update Downloads on page 1311

•

Automating VDB Update Pushes on page 1312

•

Automating VDB Update Installs on page 1314

Automating VDB Update Downloads Requires: DC/MDC + RNA

You can create a scheduled task that automatically downloads the latest vulnerability database updates from Sourcefire. To automate VDB updates:


1.


2. Click Add Task. The Add Task page appears. 3. From the Job Type list, select Download Latest Update. The Add Task page reloads to show the update options.

Version 4.7


1311


Chapter 32



•


5. In the Job Name field, type a name using up to 255 alphanumeric characters, spaces, or dashes. IMPORTANT! If your appliance is not directly connected to the Internet, you should set up a proxy as described in Configuring Network Settings on page 1220 to allow it to download updates from the Sourcefire Support site (https://support.sourcefire.com/). 6. In the Update Items section, make sure Vulnerability Database is selected. Both the Software and Vulnerability Database options are selected by default. 7.


8. Optionally, in the Email Status To: field, type the email address (or multiple email addresses separated by commas) where you want status messages sent. IMPORTANT! You must have a valid email relay server configured to send status messages. See Configuring a Mail Relay Host and Notification Address on page 1201 for more information about configuring a relay host. 9. Click Save. The task is created.

Automating VDB Update Pushes Requires: DC/MDC + 3D Sensor + RNA

Version 4.7

If you are installing vulnerability database updates on managed 3D Sensors with RNA, you must push the update to the managed sensors before installing. When you push VDB updates to managed sensors, information about the process


1312


Chapter 32

status is reported on the Tasks page. See Viewing the Status of Long-Running Tasks on page 1259 for more information. WARNING! You must download vulnerability database updates before you can push them to managed sensors. To push VDB updates to managed 3D Sensors with RNA: Access: Maintenance or Admin

1.


2. Click Add Task. The Add Task page appears. 3. From the Job Type list, select Push Latest Update. The page reloads to show the options for pushing updates. 4. Specify how you want to schedule the task, Once or Recurring. •


•


5. In the Job Name field, type a name using up to 255 alphanumeric characters, spaces, or dashes. 6. From the Sensor list, select the sensor that you want to receive updates. 7.

In the Update Items section, make sure Vulnerability Database is selected. Both the Software and Vulnerability Database options are selected by default.

8. In the Comment field, type a comment using up to 255 alphanumeric characters, spaces, or periods. TIP! The comment field appears in the View Tasks section of the page, so you should try to keep it relatively short. 9. Optionally, in the Email Status To: field, type the email address (or multiple email addresses separated by commas) where you want status messages sent. IMPORTANT! You must have a valid email relay server configured to send status messages. See Configuring a Mail Relay Host and Notification Address on page 1201 for more information about configuring a relay host.

Version 4.7


1313


Chapter 32

10. Click Save. The task is added. When the software push task is performed, status information is reported on the Task Status page, where you can check its status. See Viewing the Status of Long-Running Tasks on page 1259 for more information.

Automating VDB Update Installs Requires: DC/MDC + RNA

After you have downloaded a VDB update, you can schedule the installation process. TIP! You should allow enough time for a scheduled VDB update to download when you set up a scheduled task to install it. If you are creating a task to install a VDB update on a managed sensor, you must allow enough time between the task that pushes the update to the sensor and the task that installs the update. See Automating VDB Update Pushes on page 1312 for information about pushing updates to managed sensors. To schedule a software installation task:


1.


2. Click Add Task. The Add Task page appears. 3. From the Job Type list, select Install Latest Update. The page reloads to show the options for installing updates. 4. Specify how you want to schedule the task, Once or Recurring. •


•


5. In the Job Name field, type a name using up to 255 alphanumeric characters, spaces, or dashes. 6. From the Sensor list, you have the following options:

7.

Version 4.7

•

If you want to install the update on a managed sensor, select the name of the sensor from the drop-down list.

•

If you want to install the update on the Defense Center, select the name of the Defense Center from the drop-down list.

In the Update Items section, select Vulnerability Database to install the VDB update.


1314

Scheduling Tasks Automating SEU Updates

Chapter 32

8. In the Comment field, type a comment using up to 255 alphanumeric characters, spaces, or periods. TIP! The comment field appears in the View Tasks section of the page, so you should try to keep it relatively short. 9. Optionally, in the Email Status To: field, type the email address (or multiple email addresses separated by commas) where you want status messages sent. IMPORTANT! You must have a valid email relay server configured to send status messages. See Configuring a Mail Relay Host and Notification Address on page 1201 for more information about configuring a relay host. 10. Click Save. The scheduled VDB installation task is added. When the task is performed, status information is reported on the Task Status page, where you can check its status. See Viewing the Status of LongRunning Tasks on page 1259 for more information.

Automating SEU Updates Requires: IPS or DC/MDC + IPS

You can automatically download and install Security Enhancement Updates (SEUs) provided by Sourcefire. Automating the process requires two steps: 1.

Download the latest SEU. See Automating SEU Downloads on page 1316 for more information.

2. Import the SEU. See Automating SEU Imports on page 1317 for more information. 3. After the SEU is downloaded and imported, you must modify the rule state for new and updated rules to suit your environment. Then you must re-apply your intrusion policy so that the new SEU takes affect. On the Defense Center, you also must re-apply your intrusion policies on your managed 3D Sensors with IPS. IMPORTANT! SEUs may contain new binaries. Make sure your process for downloading and importing SEUs complies with your security policies.

Version 4.7


1315


Chapter 32

Automating SEU Downloads Requires: IPS or DC/MDC + IPS

Before you can import an SEU, you must download it from the Sourcefire Support site (https://support.sourcefire.com/) to the Defense Center or 3D Sensor with IPS. You should always schedule SEU downloads so that they occur before SEU import tasks. IMPORTANT! SEUs may contain new binaries. Make sure your process for downloading and importing SEUs complies with your security policies. In addition, SEUs can be quite large, so make sure you schedule downloads during periods of low network use. To automate SEU downloads:


1.


2. Click Add Task. The Add Task page appears. 3. From the Job Type list, select Download Latest SEU. The page reloads to show the options for downloading SEUs. 4. Specify how you want to schedule the task, Once or Recurring. •


•


5. In the Job Name field, type a name using up to 255 alphanumeric characters, spaces, or dashes. 6. In the Comment field, type a comment using up to 255 alphanumeric characters, spaces, or periods. TIP! The comment field appears in the View Tasks section of the page, so you should try to keep it relatively short.

Version 4.7


1316


7.

Chapter 32

Optionally, in the Email Status To: field, type the email address (or multiple email addresses separated by commas) where you want status messages sent. IMPORTANT! You must have a valid email relay server configured to send status messages. See Configuring a Mail Relay Host and Notification Address on page 1201 for more information about configuring a relay host.

8. Click Save. The task is created.

Automating SEU Imports Requires: IPS or DC/MDC + IPS

You can schedule a task to import downloaded Security Enhancement Updates (SEUs) to the Defense Center or 3D Sensor with IPS. IMPORTANT! SEUs may contain new binaries. Make sure your process for installing SEUs complies with your security policies. Note that new rules in the SEU are automatically disabled in your custom policies. After reviewing the new rules, use the Rule State page in each custom intrusion policy to enable the rules you want to use. To automate SEU imports:


1.


2. Click Add Task. The Add Task page appears. 3. From the Job Type list, select Import Latest SEU. The page reloads to show the options for importing the SEU. 4. Specify how you want to schedule the task, Once or Recurring. •


•


5. In the Job Name field, type a name using up to 255 alphanumeric characters, spaces, or dashes.

Version 4.7


1317

Scheduling Tasks Automating Intrusion Policy Applications

Chapter 32

6. In the Comment field, type a comment using up to 255 alphanumeric characters, spaces, or periods. TIP! The comment field appears in the View Tasks section of the page, so you should try to keep it relatively short. 7.

Optionally, in the Email Status To: field, type the email address (or multiple email addresses separated by commas) where you want status messages sent. IMPORTANT! You must have a valid email relay server configured to send status messages. See Configuring a Mail Relay Host and Notification Address on page 1201 for more information about configuring a relay host.


Automating Intrusion Policy Applications Requires: IPS or DC/MDC + IPS

You can apply intrusion policies at scheduled intervals using the scheduler. This feature is useful if you need to use different policies during different times of the day. To automate intrusion policy application:


1.



Version 4.7


1318

Scheduling Tasks Automating Intrusion Policy Applications

Chapter 32

3. From the Job Type list, select Apply Policy. The page reloads to show the options for applying an intrusion policy.



•


5. In the Job Name field, type a name using up to 255 alphanumeric characters, spaces, or dashes. 6. In the Policy Name field, select the intrusion policy you want to apply from the drop-down list. Note that only custom intrusion policies appear in the list. Default policies do not appear. 7.

In the Detection Engine field, select the detection engine where you want to apply the policy.


Version 4.7


1319

Scheduling Tasks Automating Reports

Chapter 32

10. Click Save. The task is created. When the task is performed, status information is reported on the Task Status page where you can check its status. See Viewing the Status of LongRunning Tasks on page 1259 for more information.

Automating Reports Requires: IPS or DC/MDC

You can automate reports so that they run at regular intervals. However, you must design a profile for your report before you can configure it as a scheduled task. See Building a Report Profile on page 1112 for more information about using the report designer to create a report profile. To automate a report:


1.


2. Click Add Task. The Add Task page appears. 3. From the Job Type list, select Reports. The page reloads to show the options for setting up a report to run automatically. The Defense Center version of the page is displayed below.

4. Specify how you want to schedule the task, Once or Recurring.

Version 4.7

•


•



1320

Scheduling Tasks Automating Nessus Scans

Chapter 32

5. In the Job Name field, type a name using up to 255 alphanumeric characters, spaces, or dashes. 6. In the Report Profile field, select the report profile that you want to use from the drop-down list. IMPORTANT! Nokia.

You cannot run a remote report on a Sourcefire Sensor on

Requires: DC If you want to run the report on a managed sensor, in the Remote Run field, select the name of the sensor from the drop-down list.

7.

8. In the Comment field, type a comment using up to 255 alphanumeric characters, spaces, or periods. TIP! The comment field appears in the View Tasks section of the page, so you should try to keep it relatively short. 9. Optionally, in the Email Status To: field, type the email address (or multiple email addresses separated by commas) where you want status messages sent. IMPORTANT! You must have a valid email relay server configured to send status messages. See Configuring a Mail Relay Host and Notification Address on page 1201 for more information about configuring a relay host. 10. Click Save. The task is created.

Automating Nessus Scans Requires: DC + RNA

Version 4.7

You can schedule regular Nessus scans of targets on your network. Automated scans allow you to test periodically to make sure that operating system updates or other changes do not introduce vulnerabilities on your enterprise-critical systems. You can also schedule scans to test for recurrences of attacks that have happened in the past. See the following sections for more information: •

Preparing Your System to Run a Nessus Scan on page 1322

•

Scheduling a Nessus Scan on page 1322


1321


Chapter 32

Preparing Your System to Run a Nessus Scan Requires: DC + RNA

If you have not used the Nessus scanning capability before, you need to complete several Nessus configuration steps prior to defining a scheduled scan. 1.

If you do not have an existing external Nessus server, set up the Nessus server on your Defense Center. For more information on starting the server and configuring and activating a Nessus user, see Configuring a Local Nessus Server on page 610.

2. Create a scan instance to define the Nessus server to be used by your scan. For more information on setting up a Nessus server connection profile, see Creating a Nessus Scan Instance on page 612. IMPORTANT! Make note of the name of the scan instance you create. You need to select this name when prompted for the Nessus Remediation name when setting up the scheduled scan. 3. Create a scan target to define the target hosts and host ports to scan. For more information on setting up a scan target, see Creating a Nessus Scan Target on page 614. 4. Create a remediation definition to define what plugins and Nessus scan settings should be used when the scheduled scan runs. For more information on setting up a remediation definition, see Creating a Nessus Remediation on page 615. 5. Continue with Scheduling a Nessus Scan.

Scheduling a Nessus Scan Requires: DC + RNA

You can automate Nessus scanning using a specific scan remediation by scheduling the scan. To schedule Nessus scanning:


1.



Version 4.7


1322


Chapter 32

3. From the Job Type list, select Nessus Scan. The page reloads to show the options for automating Nessus scans.



•


5. In the Job Name field, type a name using up to 255 alphanumeric characters, spaces, or dashes. 6. In the Nessus Remediation field, select the Nessus remediation for the Nessus server where you want to run the scan. 7.

In the Nessus Target field, select the scan target that defines the target hosts you want to scan.


Version 4.7


1323

Scheduling Tasks Synchronizing Nessus Plugins

Chapter 32


Synchronizing Nessus Plugins Requires: DC + RNA

You can automate synchronization with the Nessus server to obtain an up-to-date list of plugins before you scan. You may want to schedule your plugin synchronization to occur shortly before your scheduled Nessus scans to make sure that you scan with the latest list of plugins. To schedule Nessus plugin synchronization:


1.


2. Click Add Task. The Add Task page appears. 3. From the Job Type list, select Synchronize Nessus Plugins. The page reloads to show the Nessus plugin synchronization options.



•


5. In the Job Name field, type a name using up to 255 alphanumeric characters, spaces, or dashes. 6. In the Nessus Instance field, select the instances with the Nessus plugins that you want to synchronize.

Version 4.7


1324

Scheduling Tasks Automating Nmap Scans

Chapter 32

In the Comment field, type a comment using up to 255 alphanumeric characters, spaces, or periods.

7.

TIP! The comment field appears in the View Tasks section of the page, so you should try to keep it relatively short. 8. Optionally, in the Email Status To: field, type the email address (or multiple email addresses separated by commas) where you want status messages sent. IMPORTANT! You must have a valid email relay server configured to send status messages. See Configuring a Mail Relay Host and Notification Address on page 1201 for more information about configuring a relay host. 9. Click Save. The task is created.

Automating Nmap Scans Requires: DC + RNA

You can schedule regular Nmap scans of targets on your network. Automated scans allow you to refresh operating system and service information previously supplied by an Nmap scan. Because RNA cannot update Nmap-supplied data, you need to rescan periodically to keep that data up to date. You can also schedule scans to automatically test for unidentified services on hosts in your network. See the following sections for more information: •

Preparing Your System for an Nmap Scan

•

Scheduling an Nmap Scan

Preparing Your System for an Nmap Scan Requires: DC + RNA

If you have not used the Nmap scanning capability before, you must complete several Nmap configuration steps prior to defining a scheduled scan. 1.

Create a scan instance to define the Nmap server to be used by your scan. For more information on setting up a Nmap server connection profile, see Creating an Nmap Scan Instance on page 578. IMPORTANT! Make note of the name of the scan instance you create. You need to select this name when prompted for the Nmap Configuration name when setting up the scheduled scan.

Version 4.7


1325

Scheduling Tasks Automating Nmap Scans

Chapter 32

2. Create a scan target to define the target hosts and host ports to scan. For more information on setting up a scan target, see Creating an Nmap Scan Target on page 580. 3. Create a remediation definition to define what plugins and Nmap scan settings should be used when the scheduled scan runs. For more information on setting up a remediation definition, see Creating an Nmap Remediation on page 581. 4. Continue with Scheduling an Nmap Scan.

Scheduling an Nmap Scan Requires: DC + RNA

You can schedule a scan of a host or hosts on your network using the Nmap utility. Once Nmap replaces a host’s operating system or services detected by RNA with the results from an Nmap scan, RNA no longer updates the information replaced by Nmap for the host. Nmap-supplied service and operating system data remains static until you run another Nmap scan. If you plan to scan a host using Nmap, you may want to set up regularly scheduled scans to keep Nmap-supplied operating system and services up to date. If the host is deleted from the network map and re-added, any Nmap scan results are discarded and RNA resumes monitoring of all operating system and service data for the host. To schedule Nmap scanning:


1.


2. Click Add Task. The Add Task page appears. 3. From the Job Type list, select Nmap Scan. The page reloads to show the options for automating Nmap scans.

Version 4.7


1326

Scheduling Tasks Automating Acceptance of Recommended Rule States

Chapter 32



•


5. In the Job Name field, type a name using up to 255 alphanumeric characters, spaces, or dashes. 6. In the Nmap Remediation field, select the Nmap remediation to use when running the scan. 7.

In the Nmap Target field, select the scan target that defines the target hosts you want to scan.


Automating Acceptance of Recommended Rule States Requires: DC + RNA + IPS

IMPORTANT! You must configure an intrusion policy to examine a network for hosts and services before you can schedule a task to accept recommendations. You can automatically accept recommended intrusion rule activations and deactivations in your intrusion policy based on RNA data for your network. When the task runs, the system automatically accepts all recommended activations, deactivations, or both for any intrusion rules associated with the hosts and services on your network. Accepted recommendations take effect the next time you apply your intrusion policy.See Configuring RNA Recommended Rules on page 816 for more information.

Version 4.7


1327

Scheduling Tasks Automating Acceptance of Recommended Rule States

Chapter 32

To accept recommendations: Access: Maintenance or Admin

1.


2. Click Add Task. The Add Task page appears. 3. From the Job Type list, select RNA Recommended Rules. The page reloads to show the options for accepting RNA recommended rules.

4. Optionally, click the policy link in the Job Type field to display the Detection & Prevention page, where you can configure RNA Recommended Rules in a policy. See Modifying Intrusion Policies on page 760 for more information. 5. Specify how you want to schedule the task, Once or Recurring. •


•


6. In the Job Name field, type a name using up to 255 alphanumeric characters, spaces, or dashes. 7.

Version 4.7

In the Update Type field, select the type of update from the drop-down list. You have the following options: •

To automatically accept all recommendations, select Activations and Deactivations.

•

To automatically accept all recommended activations, select Activations Only.


1328

Scheduling Tasks Viewing Tasks

Chapter 32

•

To automatically accept all recommended deactivations, select Deactivations Only.

•

To email a report of the recommendations at the time of the scheduled task without accepting any recommendations, select Email Report Only.

8. Next to Policies, select one or more policies where you want to schedule the Update Type you selected in step 7. You have the following options: •

In the Policies field, select one or more policies. Use the Shift and Ctrl keys to select multiple policies.

•

Click the All Policies check box to select all policies.


Viewing Tasks Requires: DC/MDC or 3D Sensor

After adding scheduled tasks, you can view them and evaluate their status. The View Options section of the page allows you to view scheduled tasks using a calendar and a list of scheduled tasks. You can use filters to specify which types of tasks you want to view for each available type. See the following sections for more information: •

Using the Calendar on page 1329

•

Using the Task List on page 1331

Using the Calendar Requires: DC/MDC or 3D Sensor

Version 4.7

The Calendar view option allows you to view which scheduled tasks occur on which day.


1329

Scheduling Tasks Viewing Tasks

Chapter 32

To view scheduled tasks using the calendar: Access: Maintenance or Admin

1.


2. You can perform the following tasks using the calendar view: •

Click to move forward one month.

•

Click >> to move forward one year.

•

Click a date to view all scheduled tasks for the specific date in a task list table below the calendar.

•

Click a specific task on a date to view the specific task in a task list table below the calendar.

IMPORTANT! For more information about using the task list, see Using the Task List on page 1331.

Version 4.7


1330

Scheduling Tasks Editing Scheduled Tasks

Chapter 32

Using the Task List Requires: DC/MDC or 3D Sensor

The Task List shows a list of tasks along with their status. The task list appears at below the calendar when you open the calendar. In addition, you can access it by selecting a date or task from the calendar. (See Using the Calendar on page 1329 for more information.) Task List Columns Column

Description

Name

Displays the name of the scheduled task.

Type

Displays the type of scheduled task.

Start Time

Displays the scheduled start date and time.

Frequency

Displays how often the task is run.

Comment

Displays the comment that accompanies the scheduled task.

Status

Describes the current status for a scheduled task. • A check mark icon indicates that the task ran successfully. • A question mark icon indicates that the task is in an unknown state. • A red X indicates that the task failed.

Creator

Displays the name of the user that created the scheduled task.

Delete

Deletes the scheduled task.

Editing Scheduled Tasks Requires: DC/MDC or 3D Sensor

You can edit a scheduled task that you previously created. This feature is especially useful if you want to test a scheduled task once to make sure that the parameters are correct. Later, after the task completes successfully, you can change it to a recurring task. To edit an existing scheduled task:


1.


2. Click either the task that you want to edit or the day on which the task appears. The Task Details table containing the selected task or tasks appears.

Version 4.7


1331

Scheduling Tasks Deleting Scheduled Tasks

Chapter 32

3. Locate the task you want to edit in the table and click Edit. The Edit Task page appears showing the details of the task you selected. 4. Edit the task to meet your needs, including the start time, the job name, and how often the task runs, once or recurring. You cannot change the type of job. The remaining options are determined by the task you are editing. See the following sections for more information: •

Automating Backup Jobs on page 1302

•

Automating Software Updates on page 1304

•

Automating Vulnerability Database Updates on page 1310

•

Automating SEU Updates on page 1315

•

Automating Intrusion Policy Applications on page 1318

•

Automating Reports on page 1320

•


•

Synchronizing Nessus Plugins on page 1324

•

Automating Nmap Scans on page 1325

•

Automating Acceptance of Recommended Rule States on page 1327

5. Click Save to save your edits. Your change are saved and the Scheduling page appears again.

Deleting Scheduled Tasks Requires: DC/MDC or 3D Sensor

There are two types of deletions you can perform from the Schedule View page. You can delete a specific one-time task that has not yet run or you can delete every instance of a recurring task. If you delete an instance of a recurring task, all instances of the task are deleted. If you delete a task that is scheduled to run once, only that task is deleted. The following sections describe how to delete tasks: •

To delete all instances of a task, see Deleting a Recurring Task on page 1332.

•

To delete a single instance of a task, see Deleting a One-Time Task on page 1333.

Deleting a Recurring Task Requires: DC/MDC or 3D Sensor

Version 4.7

When you delete one instance of a recurring task, you automatically delete all instances of that task.


1332

Scheduling Tasks Deleting Scheduled Tasks

Chapter 32

To delete a recurring task: Access: Maintenance or Admin

1.


2. On the calendar, select an instance of the recurring task you want to delete. The page reloads to display a table of tasks below the calendar. 3. Locate an instance of the recurring task you want to delete in the table and click Delete. All instances of the recurring task are deleted.

Deleting a One-Time Task Requires: DC/MDC or 3D Sensor

You can delete a one-time scheduled task or delete the record of a previously-run scheduled task using the task list. To delete a single task or, if it has already run, delete a task record:


1.


2. Click the task that you want to delete or the day on which the task appears. A table containing the selected task or tasks appears. 3. Locate the task you want to delete in the table and click Delete. The instance of the task you selected is deleted.

Version 4.7


1333

Chapter 32

Monitoring the System

The Sourcefire 3D System provides many useful monitoring features to assist you in the daily administration of your system, all on a single page. For example, on the Host Statistics page you can monitor basic host statistics, intrusion event information, and statistics for the Data Correlator and RNA processes for the current day. You can also monitor both summary and detailed information on all processes that are currently running on the Defense Center or 3D Sensor. The following sections provide more information about the monitoring features that the system provides: •

Viewing Host Statistics on page 1335 describes how to view host information such as: •

system uptime

•

disk and memory usage

•

RNA process statistics

•

Data Correlator statistics

•

system processes

•

intrusion event information

On the Defense Center, you can also use the health monitor to monitor disk usage and alert on low disk space conditions. For more information, see Understanding Health Monitoring on page 1354.

Version 4.7


1334

Monitoring the System Viewing Host Statistics

Chapter 33

•

Monitoring System Status and Disk Space Usage on page 1339 describes how to view basic event and disk partition information.

•

Viewing System Process Status on page 1339 describes how to view basic process status.

•

Understanding Running Processes on page 1342 describes the basic system processes that run on the appliance.

•

Viewing IPS Performance Statistics on page 1347 describes how to view IPS performance statistics and how to generate graphs based on these statistics.

•

Viewing RNA Performance Statistics on page 1349 describes how to view RNA performance statistics and how to generate graphs based on these statistics.

Viewing Host Statistics Requires: Any

The Statistics page lists the current status of following: •

general host statistics; see the Host Statistics table on page 1335 for details

•

Data Correlator statistics (Defense Center only - requires RNA); see the Data Correlator Process Statistics table on page 1336 for details

•

RNA process statistics (Defense Center only - requires RNA); see the RNA Process Statistics table on page 1337 for details

•

intrusion event information (requires IPS); see the Intrusion Event Information table on page 1338 for details

The Host Statistics table describes the host statistics listed on the Statistics page. Host Statistics

Version 4.7

Category

Description

Time

The current time on the system.

Uptime

The number of days (if applicable), hours, and minutes since the system was last started.

Memory Usage

The percentage of system memory that is being used.

Load Average

The average number of processes in the CPU queue for the past 1 minute, 5 minutes, and 15 minutes.


1335


Chapter 33

Host Statistics (Continued) Category

Description

Disk Usage

The percentage of the disk that is being used. Click the arrow to view more detailed host statistics. See Monitoring System Status and Disk Space Usage on page 1339 for more information.

Processes

A summary of the processes running on the system. See Viewing System Process Status on page 1339 for more information.

If your Sourcefire 3D System deployment includes a Defense Center managing 3D Sensors with RNA, you can also view statistics about the Data Correlator and RNA processes for the current day. As the 3D Sensors perform data acquisition, decoding, and analysis, the RNA process correlates the data with the fingerprint and vulnerability databases, and then produces binary files that are processed by the Data Correlator running on the Defense Center. The Data Correlator analyzes the information from the binary files, generates events, and creates the RNA network map. The statistics that appear for RNA and the Data Correlator are averages for the current day, using statistics gathered between 12:00AM and 11:59PM for each detection engine. The Data Correlator Process Statistics table describes the statistics displayed for the Data Correlator process. Data Correlator Process Statistics

Version 4.7

Category

Description

Events/Sec

Number of events that the Data Correlator receives and processes per second

Flows/Sec

Number of flows that the Data Correlator receives and processes per second

CPU Usage - User (%)

Average percentage of CPU time spent on user processes for the current day

CPU Usage - System (%)

Average percentage of CPU time spent on system processes for the current day

VmSize (KB)

Average size of memory allocated to the Data Correlator for the current day, in kilobytes

VmRSS (KB)

Average amount of memory used by the Data Correlator for the current day, in kilobytes


1336


Chapter 33

The RNA Process Statistics table describes the statistics displayed for the RNA process. RNA Process Statistics Category

Description

Packets Dropped (%)

Average percentage of packets dropped by the RNA process for the current day

Mbits/Second

Average number of megabits per second processed by the RNA process for the current day

Packets/Second

Average number of packets per second processed by the RNA process for the current day

CPU Usage - User (%)

Average percentage of CPU time spent by user processes for the current day

CPU Usage - System (%)

Average percentage of CPU time spent by system processes for the current day

VmSize (KB)

Average size of memory allocated to the RNA process for the current day, in kilobytes

VmRSS (KB)

Average amount of memory used by the RNA process for the current day, in kilobytes

On 3D Sensors with IPS and on Defense Centers that manage sensors with IPS, you can also view the time and date of the last intrusion event, the total number of events that have occurred in the past hour and the past day, and the total number in the database. IMPORTANT! For a 3D Sensor with IPS managed by a Defense Center, the event information in the Intrusion Event Information section of the Statistics page is based on events stored on the sensor, not on events sent from the sensor to the Defense Center.

Version 4.7


1337


Chapter 33

The Intrusion Event Information table describes the statistics displayed in the Intrusion Event Information section of the Statistics page. Intrusion Event Information Statistic

Description

Last Alert Was

The date and time that the last event occurred

Total Events Last Hour

The total number of events that occurred in the past hour

Total Events Last Day

The total number of events that occurred in the past twenty-four hours

Total Events in Database

The total number of events in the events database

To view the Statistics page: Access: Maintenance or Admin

Version 4.7

1.

Select Operations > Monitoring > Statistics. The Statistics page appears. The Defense Center version of the page is shown below.


1338

Monitoring the System Monitoring System Status and Disk Space Usage

Chapter 33

2. On the Defense Center, you can also list statistics for managed sensors. From the Select Device(s) box and click Select Devices. You can use the Shift and Ctrl keys to select multiple devices at once. The Statistics page is updated with statistics for the devices that you selected.

Monitoring System Status and Disk Space Usage Requires: Any

The Disk Usage section of the Statistics page provides a quick synopsis of partition status. You can monitor this page from time to time to ensure that enough disk space is available for system processes and the database. TIP! On the Defense Center you can also use the health monitor to monitor disk usage and alert on low disk space conditions. For more information, see Understanding Health Monitoring on page 1354. To access disk usage information:


1.

Select Operations > Monitoring > Statistics. The Statistics page appears.

2. Click the down arrow next to Disk Usage to expand it. The Disk Usage section expands.

On the Defense Center, to view disk usage information for a specific sensor: Access: Maintenance or Admin

1.

Select the sensor name from the Select Device(s) box, and click Select Devices. The page reloads, listing host statistics for each sensor you selected.

2. Click the down arrow next to Disk Usage to expand it. The Disk Usage section expands.

Viewing System Process Status Requires: Any

Version 4.7

The Processes section of the Host Statistics page allows you to see the processes that are currently running on an appliance. It provides general process information and specific information for each running process. If you are managing sensors with a Defense Center, you can use the Defense Center’s web interface to view the process status for any managed sensor.


1339

Monitoring the System Viewing System Process Status

Chapter 33

The Process Status table describes each column that appears in the process list. Process Status Column

Description

Pid

The process ID number

Username

The name of the user or group running the process

Pri

The process priority

Nice

The nice value, which is a value that indicates the scheduling priority of a process. Values range between -20 (highest priority) and 19 (lowest priority)

Size

The memory size used by the process (in kilobytes, unless the value is followed by m, which indicates megabytes)

Res

The amount of resident paging files in memory (in kilobytes, unless the value is followed by m, which indicates megabytes)

State

The process state: • D - process is in uninterruptible sleep (usually Input/Output) • N - process has a positive nice value • R - process is runnable (on queue to run) • S - process is in sleep mode • T - process is being traced or stopped • W - process is paging • X - process is dead • Z - process is defunct • < - process has a negative nice value

Time

The amount of time (in hours:minutes:seconds) that the process has been running

Cpu

The percentage of CPU that the process is using

Command

The executable name of the process

To expand the process list: Access: Maintenance or Admin

Version 4.7

1.

Select Operations > Monitoring > Statistics. The Statistics page appears.


1340

Monitoring the System Viewing System Process Status

Chapter 33

2. On the Defense Center, select the device or devices you want to view process statistics for and click Select Devices. 3. Click the down arrow next to Processes. The process list expands, listing general process status that includes the number and types of running tasks, the current time, the current system uptime, the system load average, CPU, memory, and swap information, and specific information about each running process.

Cpu(s) lists the following CPU usage information: •

user process usage percentage

•

system process usage percentage

•

nice usage percentage (CPU usage of processes that have a negative nice value, indicating a higher priority) Nice values indicate the scheduled priority for system processes and can range between -20 (highest priority) and 19 (lowest priority).

•

idle usage percentage

Mem lists the following memory usage information: •

total number of kilobytes in memory

•

total number of used kilobytes in memory

•

total number of free kilobytes in memory

•

total number of buffered kilobytes in memory

Swap lists the following swap usage information:

Version 4.7

•

total number of kilobytes in swap

•

total number of used kilobytes in swap


1341

Monitoring the System Understanding Running Processes

•

total number of free kilobytes in swap

•

total number of cached kilobytes in swap

Chapter 33

IMPORTANT! For more information about the types of processes that run on the appliance, see Understanding Running Processes on page 1342. To collapse the process list: Access: Maintenance or Admin

h

Click the up arrow next to Processes. The process list collapses.

Understanding Running Processes Requires: Any

There are two different types of processes that run on an appliance: daemons and executable files. Daemons always run, and executable files are run when required. See the following sections for more information: •

Understanding System Daemons on page 1342

•

Understanding Executables and System Utilities on page 1344

Understanding System Daemons Requires: Any

Daemons continually run on an appliance. They ensure that services are available and spawn processes when required. The System Daemons table lists daemons that you may see on the Process Status page and provides a brief description of their functionality. IMPORTANT! The table below is not an exhaustive list of all processes that may run on an appliance.

System Daemons Daemon

Description

crond

Manages the execution of scheduled commands (cron jobs).

dhcpcd

Manages dynamic host IP addressing.

fpcollect

Manages the collection of client and server fingerprints.

httpd

Manages the HTTP (Apache web server) process.

Version 4.7


1342


Chapter 33

System Daemons (Continued) Daemon

Description

httpsd

Manages the HTTPS (Apache web server with SSL) service, and checks for working SSL and valid certificate authentication. This daemon runs in the background to provide secure web access to the appliance.

keventd

Manages Linux kernel event notification messages.

klogd

Manages the interception and logging of Linux kernel messages.

kswapd

Manages Linux kernel swap memory.

kupdated

Manages the Linux kernel update process, which performs disk synchronization.

mysqld

Manages Sourcefire 3D System database processes.

ntpd

Manages the Network Time Protocol (NTP) process.

pm

Manages all Sourcefire processes, starts required processes, restarts any process that fails unexpectedly.

reportd

Manages reports.

rnareportd

Manages RNA reports.

safe_mysqld

Manages safe mode operation of the database. This restarts the database daemon if an error occurs and logs runtime information to a file.

SFDataCorrelator

Manages data transmission.

sfestreamer (Defense Center only)

Manages connections to third-party client applications that use the Event Streamer.

sfmgr

Provides the RPC service for remotely managing and configuring an appliance using an sftunnel connection to the appliance.

sfreactd

Manages Check Point OPSEC integration. You only see this process if Checkpoint SAM support is enabled.

SFRemediateD (Defense Center only - requires RNA)

Manages remediation responses.

sftimeserviced (Defense Center only)

Forwards time synchronization messages to managed sensors.

Version 4.7


1343


Chapter 33

System Daemons (Continued) Daemon

Description

sfmbservice (requires IPS)

Provides access to the sfmb message broker process running on a remote appliance, using an sftunnel connection to the appliance. Currently used only by health monitoring to send health events and alerts from a 3D Sensor to a Defense Center or, in a high availability environment, between Defense Centers.

sftroughd

Listens for connections on incoming sockets and then invokes the correct executable (typically the message broker, sfmb) to handle the request.

sftunnel

Provides the secure communication channel for all processes requiring communication with a remote appliance.

sshd

Manages the Secure Shell (SSH) process. This daemon runs in the background to provide SSH access to the appliance.

syslogd

Manages the system logging (syslog) process.

Understanding Executables and System Utilities Requires: Any

There are a number of executables on the system that run when executed by other processes or through user action. The System Executables and Utilities table describes the executables that you may see on the Process Status page. System Executables and Utilities

Version 4.7

Executable

Description

awk

Utility that executes programs written in the awk programming language

bash

GNU Bourne-Again SHell

cat

Utility that reads files and writes content to standard output

chown

Utility that changes user and group file permissions

chsh

Utility that changes the default login shell

correlator (Defense Center only requires RNA)

Analyzes binary files created by RNA to generate events, flow data, and the network map

cp

Utility that copies files


1344


Chapter 33

System Executables and Utilities (Continued)

Version 4.7

Executable

Description

df

Utility that lists the amount of free space on the appliance

echo

Utility that writes content to standard output

egrep

Utility that searches files and folders for specified input. It supports extended set of regular expressions not supported in standard grep.

find

Utility that recursively searches directories for specified input

grep

Utility that searches files and directories for specified input

halt

Utility that stops the server

httpsdctl

Handles secure Apache Web processes

hwclock

Utility that allows access to the hardware clock

ifconfig

Indicates the network configuration executable. Ensures that the MAC address stays constant

iptables

Handles access restriction based on changes made to the Access Configuration page. See Configuring the Access List for Your Appliance on page 1193 for more information about access configuration.

iptables-restore

Handles iptables file restoration

iptables-save

Handles saved changes to the iptables

kill

Utility that can be used to end sessions and processes

killall

Utility that can be used to end all sessions and processes

ksh

Public domain version of the Korn shell

logger

Utility that provides a way to access the syslog daemon from the command line

md5sum

Utility that prints checksums and block counts for specified files

mv

Utility that moves (renames) files


1345


Chapter 33

System Executables and Utilities (Continued)

Version 4.7

Executable

Description

myisamchk

Indicates database table checking and repairing

mysql

Indicates a database process. Multiple instances may appear.

openssl

Indicates authentication certificate creation

perl

Indicates a perl process

ps

Utility that writes process information to standard output

RNA (requires RNA)

Captures packets, decodes and performs session reassembly, correlating acquired data with the RNA fingerprint database. It then generates binary files that the Data Correlator processes to generate the network map and to populate the database with events and flow data.

sed

Utility used to edit one or more text files

sfheartbeat

Identifies a heartbeat broadcast, indicating that the appliance is active. The heartbeat is used to maintain contact between a sensor and Defense Center.

sfmb

Indicates a message broker process. The message broker handles communication between Defense Centers and sensors.

sfsnort (requires IPS)

Indicates that Snort is running

sh

Public domain version of the Korn shell

shutdown

Utility that shuts down the appliance

sleep

Utility that suspends a process for a specified number of seconds

smtpclient

Mail client that handles email transmission when email event notification functionality is enabled

snmptrap

Forwards SNMP trap data to the SNMP trap server specified when SNMP notification functionality is enabled.

ssh

Indicates a Secure Shell (SSH) connection to the appliance


1346

Monitoring the System Viewing IPS Performance Statistics

Chapter 33

System Executables and Utilities (Continued) Executable

Description

sudo

Indicates a sudo process, which allows users other than root to run executables

top

Utility that displays information about the top CPU processes

touch

Utility that can be used to change the access and modification times of specified files

vim

Utility used to edit text files

wc

Utility that performs line, word, and byte counts on specified files

Viewing IPS Performance Statistics Requires: IPS or DC/MDC + IPS

The IPS performance statistics page allows you to generate graphs that depict performance statistics for IPS over a specific period of time. Graphs can be generated to reflect number of intrusion events per second, number of megabits per second, average number of bytes per packet, and the percent of packets uninspected by Snort. These graphs can show statistics for the last hour, last day, last week, or last month of operation. To view the IPS performance statistics:


h

Select Operations > Monitoring > Performance > IPS. The IPS page appears. The Defense Center version of the page is shown below.


Version 4.7

•

Generating IPS Performance Statistics Graphs on page 1348

•

Saving IPS Performance Statistics Graphs on page 1349


1347

Monitoring the System Viewing IPS Performance Statistics

Chapter 33

Generating IPS Performance Statistics Graphs Requires: IPS or DC/MDC + IPS

You can generate graphs that depict performance statistics for a Defense Center or a 3D Sensor with IPS based on the number of alerts per second, megabits per second, or average bytes per packet. IMPORTANT! New data is accumulated for statistics graphs every five minutes. Therefore, if you reload a graph quickly, the data may not change until the next five-minute increment occurs. The IPS Performance Statistics Graph Types table lists the available graph types. IPS Performance Statistics Graph Types Graph Type

Output

Alerts/Sec

Displays a graph that represents the number of alerts that are generated on the sensor per second

Mbits/Sec

Displays a graph that represents the number of megabits of traffic that pass through the sensor per second

Avg Bytes/Packet

Displays a graph that represents the average number of bytes included in each packet

Percent Packets Dropped

Displays a graph that represents the percentage of packets uninspected by Snort

To generate IPS performance statistics graphs: Access: Maintenance or Admin

1.

Select Operations > Monitoring > Performance > IPS. The IPS page appears. The Defense Center version of the page is shown below.

2. From the Select Device list, select the detection engines whose data you want to view. 3. From the Select Graph list, select the type of graph you want to create. 4. From the Select Time Range list, select the time range you would like to use for the graph. You can choose from last hour, last day, last week, or last month.

Version 4.7


1348

Monitoring the System Viewing RNA Performance Statistics

Chapter 33

5. Click Graph. The graph appears, displaying the information you specified.

Saving IPS Performance Statistics Graphs Requires: IPS or DC/MDC + IPS

After you have generated an IPS performance statistics graph, you can save the graph as a graphic file for later use. To save the graph:


h

Right-click on the graph and follow the instructions for your browser to save the image.

Viewing RNA Performance Statistics Requires: DC + RNA

Version 4.7

The RNA Performance page allows you to generate graphs that display RNA-related performance statistics over a specific period of time. Graphs can be generated to display: •

the number of events generated by the Data Correlator per second

•

the number of megabits analyzed by the RNA process per second

•

average number of bytes included in each packet analyzed by the RNA process

•

the percentage of packets dropped by RNA

•

the number of packets, in thousands, analyzed by the RNA process per second

•

the number of established connections analyzed by the RNA process per second


1349


Chapter 33

These graphs can show statistics for the last hour, last day, last week, or last month of operation. To access the RNA Performance page: Access: Maintenance or Admin

h

Select Operations > Monitoring > Performance > RNA. The RNA page appears.


Generating RNA Performance Statistics Graphs on page 1350

•

Saving RNA Performance Statistics Graphs on page 1352

Generating RNA Performance Statistics Graphs Requires: DC + RNA

You can generate graphs that display performance statistics for managed 3D Sensors with RNA. IMPORTANT! New data is accumulated for statistics graphs every five minutes. Therefore, if you reload a graph quickly, the data may not change until the next five-minute increment occurs. The RNA Performance Statistics Graph Types table lists the available graph types. RNA Performance Statistics Graph Types

Version 4.7

Graph Type

Output

Processed Events/Sec

Displays a graph that represents the number of events that the Data Correlator processes per second

Processed Flows/Sec

Displays a graph that represents the number of flows that the Data Correlator processes per second

Generated Events/Sec

Displays a graph that represents the number of events that RNA generates per second

Mbits/Sec

Displays a graph that represents the number of megabits of traffic that are analyzed by the RNA process per second


1350


Chapter 33

RNA Performance Statistics Graph Types (Continued) Graph Type

Output

Avg Bytes/Packet

Displays a graph that represents the average number of bytes included in each packet analyzed by the RNA process

Percent Packets Dropped

Displays a graph that represents the percentage of packets dropped by RNA

K Packets/Sec

Displays a graph that represents the number of packets analyzed by the RNA process per second, in thousands

Syn/Ack/Sec

Displays a graph that represents the number of established connections observed by the RNA process per second

To generate RNA performance statistics graphs: Access: Maintenance or Admin

1.

Select Operations > Monitoring > Performance > RNA. The RNA page appears.

2. From the Select Target list, select the Defense Center, the managed 3D Sensors, or the detection engines that you want to include. Depending on whether you select a detection engine or a sensor, the Select Graph(s) list adjusts to display the available graphs. 3. From the Select Graph(s) list, select the type of graph you want to create. TIP! You can select multiple graphs by holding down the Ctrl or Shift keys while clicking on the graph type. 4. From the Select Time Range list, select the time range you would like to use for the graph. You can choose from last hour, last day, last week, or last month.

Version 4.7


1351


Chapter 33

5. Click Graph. The graph appears, displaying the information you specified. If you selected multiple graphs, each graph appears on the page.

Saving RNA Performance Statistics Graphs Requires: DC + RNA

After you have generated an RNA performance statistics graph, you can save the graph as a graphic file for later use. To save the graph:


1.

Create an RNA performance statistic graph as described in Generating RNA Performance Statistics Graphs on page 1350.

2. Right-click on the graph and follow the instructions for your browser to save the image.

Version 4.7


1352

Chapter 33

Using Health Monitoring

The health monitor provides numerous tests for determining the health of an appliance from the Defense Center. You can use the health monitor to create a collection of tests, referred to as a health policy, and apply the health policy to one or more appliances. You can create one health policy for every appliance in your system, customize a health policy for the specific appliance where you plan to apply it, or use one of the default health policies. You can also export a health policy from one Defense Center and then import it on another Defense Center. For more information on importing and exporting health policies, see Importing and Exporting Objects on page 1248. The tests, referred to as health modules, are scripts that test for criteria you specify. You can modify a health policy by enabling or disabling tests or by changing test settings, and you can delete health policies that you no longer need. You can also suppress messages from selected appliances by blacklisting them. The tests in a health policy run automatically at the interval you configure. You can also run all tests or a specific test on demand. The health monitor collects health events based on the test conditions configured. Optionally, you can also configure email, SNMP, or syslog alerting in response to health events. At the Defense Center, you can view health status information for the entire system or for a particular appliance. Fully customizable event views allow you to quickly and easily analyze the health status events gathered by the health monitor. These event views allow you to search and view event data and to access other information that may be related to the events you are investigating. You can also generate troubleshooting files for an appliance if you are asked to do so by Support.

Version 4.7


1353

Using Health Monitoring Understanding Health Monitoring

Chapter 34


Understanding Health Monitoring on page 1354

•


•

Using Health Monitor Blacklist on page 1386

•


•


•


•


•


Understanding Health Monitoring Requires: DC/MDC

You can use the health monitor to check the status of critical functionality across your Sourcefire 3D System deployment. Monitor the health of your entire Sourcefire 3D System through the Defense Center by applying health policies to each of the managed sensors and collecting the resulting health data at the Defense Center. Pie charts and status tables on the Health Monitor page visually represent the health status for monitored appliances, so you can check status at a glance, then drill down into status details if needed.

You can use the health monitor to access health status information for the entire system or for a particular appliance. The Health Monitor page provides a visual summary of the status of all appliances on your system. Individual appliance health monitors let you drill down into health details for a specific appliance. You can also view health events in the standard Sourcefire 3D System table view. From an individual sensor’s appliance health monitor, you can open a table view of occurrences of a specific event, or you can retrieve all the health events for that appliance. You can also search for specific health events. For example, if you want to see all the occurrences of CPU usage with a certain percentage, you can search for the CPU usage module and enter the percentage value.

Version 4.7


1354


Chapter 34

You can also configure email, SNMP, or syslog alerting in response to health events. A health alert is an association between a standard alert and a health status level. For example, if you need to make sure an appliance never fails due to hardware overload, you can set up an email alert. You can then create a health alert that triggers that email alert whenever CPU, disk, or memory usage reaches the Warning level you configure in the health policy applied to that appliance. Because health monitoring is an administrative activity, only users with Admin access privileges can access system health data. For more information on assigning user privileges, see Modifying User Privileges and Options on page 1287. IMPORTANT! Except for the Defense Center, Sourcefire 3D System appliances do not have health monitoring policies applied to them by default. If you want to monitor the health of a managed sensor, you have to apply a health policy to that sensor. For more information on available default health policies you can apply to a sensor, see Predefined Health Policies on page 1361. For more information on creating customized health policies, see Creating Health Policies on page 1364. For details on applying policies, see Applying Health Policies on page 1382. For more information on health policies and the health modules you can run to test system health, see the following topics: •

Understanding Health Policies on page 1355

•

Understanding Health Modules on page 1356

•

Understanding Health Monitoring Configuration on page 1359

Understanding Health Policies Requires: DC/MDC

A health policy is a collection of health module settings you apply to an appliance to define the criteria that the Defense Center uses when checking the health of the appliance. The health monitor tracks a variety of health indicators to ensure that your Sourcefire 3D System hardware and software are working correctly. When you create health policies, you choose which tests to run to determine appliance health. You can also apply one of the five default health policies to each appliance. For example, to monitor the health of a 3D Sensor with IPS, you can create a policy that monitors just the intrusion event rate and the IPS process, or you can apply the default policy, which also monitors CPU, disk, and memory usage, the Data Correlator process, and traffic status.

Version 4.7


1355


Chapter 34

Understanding Health Modules Requires: DC/MDC

Health modules, also sometimes referred to as health tests, are scripts that test for the criteria you specify in a health policy. The available health modules are described in the Health Modules table.

Health Modules Module

Description

Appliance Heartbeat

This module determines if a appliance heartbeat is being heard from the sensor and alerts based on the sensor heartbeat status.

CPU Usage

This module checks that the CPU on the appliance is not overloaded and alerts when CPU usage exceeds the threshold percentages configured for the module.


This module determines if the Data Correlator process (SFDataCorrelator) is restarting too often, which may indicate a problem with the process, and alerts when the number of restarts exceeds thresholds configured for the module. The restart counter does not count actual restarts. The module checks if any restarts occurred during the period between tests. Even if multiple restarts occur between tests, the module only increments the restart counter by one each time it checks. If any restarts occur, the module adds one to the restart count. The first time the module checks and no restarts have occurred since the last test, the module resets the counter to zero. The alert level also lowers by one level (for example, Critical is reduced to Warning or Warning is reduced to Normal). The second time the module checks and no restarts have occurred since the last test, the alert level resets to Normal. If the module finds that the process is not running at all, it increments the restart counter by one, but sets the module status to Critical for that test, regardless of the thresholds set for the module. The status remains Critical until the module finds that the process is running. At that point, the module sets status according to the restart counter value and the configured thresholds for the module. For more information on system daemons such as SFDataCorrelator, see Understanding System Daemons on page 1342.


This module ensures that there are heartbeats from connected Defense Centers and alerts based on the Defense Center status. This module only runs on Master Defense Centers.

Disk Usage

Version 4.7

This module compares disk usage on the appliance to the thresholds configured for the module and alerts when usage exceeds the threshold percentages configured for the module.


1356


Chapter 34

Health Modules (Continued) Module

Description

Estreamer Process

This module determines if the Estreamer process is restarting too often, which may indicate a problem with the process, and alerts when the number of restarts exceeds thresholds configured for the module. The restart counter does not count actual restarts. The module checks if any restarts occurred during the period between tests. Even if multiple restarts occur between tests, the module only increments the restart counter by one each time it checks. If any restarts occur, the module adds one to the restart count. The first time the module checks and no restarts have occurred since the last test, the module resets the counter to zero. The alert level also lowers by one level (for example, Critical is reduced to Warning or Warning is reduced to Normal). The second time the module checks and no restarts have occurred since the last test, the alert level resets to Normal. If the module finds that the process is not running at all, it increments the restart counter by one, but sets the module status to Critical for that test, regardless of the thresholds set for the module. The status remains Critical until the module finds that the process is running. At that point, the module sets status according to the restart counter value and the configured thresholds for the module. This module only runs on Defense Centers.

Event Stream

This module compares the number of events per second to the thresholds configured for this module and alerts if the thresholds are exceeded. If the Event Stream is zero, Estreamer process may be down or the Defense Center may not be sending events. This module only runs on Master Defense Centers.

IPS Event Rate

Version 4.7

This module compares the number of intrusion events per second to the thresholds configured for this module and alerts if the thresholds are exceeded. If the IPS Event Rate is zero, the IPS process may be down or the 3D Sensor may not be sending events. Select Analysis & Reporting > Event Summary > Intrusion Event Statistics to check if events are being received from the sensor.


1357


Chapter 34


Description

IPS Process

This module determines if the IPS process (snort) has been restarting too often, which may indicate a problem with the process, and alerts when the number of restarts exceeds the thresholds configured for the module. The IPS process (also known as snort) is the packet decoder on a 3D Sensor with that is licensed for IPS component. If the IPS process is down or has been restarting, the IPS Event Rate results may be inaccurate. The restart counter does not indicate the number of restarts. Instead, the module checks if any restarts occurred during the period between tests. Even if multiple restarts occur between tests, the module only increments the restart counter by one each time it checks. If any restarts occur, the module adds one to the restart count. The first time the module checks and no restarts have occurred since the last test, the module resets the counter to zero. The alert level also lowers by one level (for example, Critical is reduced to Warning or Warning is reduced to Normal). The second time the module checks and no restarts have occurred since the last test, the alert level resets to Normal. If the module finds that the process is not running at all, it increments the restart counter by one, but sets the module status to Critical for that test, regardless of the thresholds set for the module. The status remains Critical until the module finds that the process is running. At that point, the module sets status according to the restart counter value and the configured thresholds for the module.

Memory Usage

Version 4.7

This module compares memory usage on the appliance to the thresholds configured for the module and alerts when usage exceeds the threshold levels configured for the module.


1358


Chapter 34


Description

RNA Host License Limit

This module determines if sufficient RNA host licenses remain and alerts based on the warning threshold level configured for the module.

RNA Process

This module determines if the RNA process (rna) is restarting too often, which may indicate a problem with the process, and alerts based on the threshold number of restarts configured for the module. The restart counter does not count actual restarts. The module checks if any restarts occurred during the period between tests. Even if multiple restarts occur between tests, the module only increments the restart counter by one each time it checks. If any restarts occur, the module adds one to the restart count. The first time the module checks and no restarts have occurred since the last test, the module resets the counter to zero. The alert level also lowers by one level (for example, Critical is reduced to Warning or Warning is reduced to Normal). The second time the module checks and no restarts have occurred since the last test, the alert level resets to Normal. If the module finds that the process is not running at all, it increments the restart counter by one, but sets the module status to Critical for that test, regardless of the thresholds set for the module. The status remains Critical until the module finds that the process is running. At that point, the module sets status according to the restart counter value and the configured thresholds for the module.

Traffic Status

This module determines if the sensor currently collects traffic and alerts based on the traffic status.

Understanding Health Monitoring Configuration Requires: DC/MDC

There are several steps to setting up health monitoring on your Sourcefire 3D System, as indicated in the following procedure: 1.

Create health policies for your appliances. You can set up specific policies for each kind of appliance you have in your Sourcefire 3D System, enabling only the appropriate tests for that appliance. TIP! If you want to quickly enable health monitoring without customizing the monitoring behavior, you can apply one of the default policies provided for that purpose. For more information on setting up health policies, see Configuring Health Policies on page 1360.

2. Apply a health policy to each appliance where you want to track health status. For information on the default health policies available for immediate application, see Predefined Health Policies on page 1361.

Version 4.7


1359

Using Health Monitoring Configuring Health Policies

Chapter 34

3. Optionally, configure health monitor alerts. You can set up email, syslog, or SNMP alerts that trigger when the health status level reaches a particular severity level for specific health modules. For more information on setting up health monitor alerts, see Configuring Health Monitor Alerts on page 1390. After you set up health monitoring on your system, you can view the health status at any time on the Health Monitor page, in the Health Table Events View, or on the Status Dashboard. For more information about viewing system health data, see the following topics: •


•


•


•


Configuring Health Policies Requires: DC/MDC

A health policy contains configured health test criteria for several modules. You can control which health modules run against each of your appliances and configure the specific thresholds used in the tests run by each module. Create one health policy that can be applied to every appliance in your system, customize each health policy to the specific appliance where you plan to apply it, or use the default health policies provided for you. You can also export a health policy from one Defense Center and then import it on another Defense Center. For more information on importing and exporting health policies, see Importing and Exporting Objects on page 1248. For more information on the health modules you can configure in a health policy, see Understanding Health Monitoring on page 1354. When you configure a health policy, you decide whether to enable each health module for that policy. You also select the criteria that control which health status each enabled module reports each time it assesses the health of a process. For more information on the default health policy, which is applied to the Defense Center and Master Defense Center automatically, see Default Health Policy on page 1362. For more information, see the following topics:

Version 4.7

•

Predefined Health Policies on page 1361

•

Creating Health Policies on page 1364

•

Applying Health Policies on page 1382

•

Editing Health Policies on page 1384

•

Deleting Health Policies on page 1386


1360


Chapter 34

Predefined Health Policies Requires: DC/MDC

The Defense Center health monitor includes several default health policies to make it easier for you to quickly implement health monitoring for your appliances. The Default Health Policy is automatically applied to the Defense Center. To also monitor sensor health, you can push health policies to 3D Sensors. For more information, see the following topics: •

Default 3D Sensor Health Policy on page 1361

•

Default Health Policy on page 1362

•

Default Intrusion Sensor Health Policy on page 1363

•

Default RNA Sensor Health Policy on page 1363

Default 3D Sensor Health Policy Requires: DC/MDC

Use the Default 3D Sensor Health Policy to monitor health on any 3D Sensor. Enabled health modules for this policy are listed in the Enabled Health Modules: 3D Sensor Health Policy table. Enabled Health Modules: 3D Sensor Health Policy

Version 4.7

Module

For more information, see...

CPU Usage

Configuring CPU Usage Monitoring on page 1368


Configuring Data Correlator Process Monitoring on page 1369

Disk Usage

Configuring Disk Usage Monitoring on page 1371

IPS Event Rate

Configuring IPS Event Rate Monitoring on page 1375

IPS Process

Configuring IPS Process Monitoring on page 1376

Memory Usage

Configuring Memory Usage Monitoring on page 1378


Configuring RNA Host Usage Monitoring on page 1379

RNA Process

Configuring RNA Process Monitoring on page 1380

Traffic Status

Configuring Traffic Status Monitoring on page 1381


1361


Chapter 34

Default Health Policy Requires: DC/MDC

Use the Default Health Policy to monitor health on a Defense Center. Enabled health modules for this policy are listed in the Enabled Defense Center Health Modules - Default Health Policy table. Enabled Defense Center Health Modules - Default Health Policy

Requires: MDC

Module


Appliance Heartbeat

Configuring Appliance Heartbeat Monitoring on page 1367

CPU Usage




Disk Usage


Memory Usage




Use the Default Health Policy to monitor health on a Master Defense Center. Enabled health modules for this policy are listed in the Enabled MDC Health Modules - Default Health Policy table. Enabled MDC Health Modules - Default Health Policy

Version 4.7

Module


Appliance Heartbeat


CPU Usage





Configuring Defense Center Status on page 1370

Disk Usage


Estreamer Process

Configuring Estreamer Process Monitoring on page 1372


1362


Chapter 34

Enabled MDC Health Modules - Default Health Policy (Continued) Module


Event Stream

Configuring Event Stream Monitoring on page 1374

Memory Usage


Default Intrusion Sensor Health Policy Requires: DC/MDC

Use the Default Intrusion Sensor Health Policy to monitor health on legacy Intrusion Sensors that you have not upgraded to Version 4.7. Enabled health modules for this policy are listed in the Enabled Health Modules: Default Intrusion Sensor Health Policy table. Enabled Health Modules: Default Intrusion Sensor Health Policy Module


CPU Usage




Disk Usage


IPS Event Rate


IPS Process


Memory Usage


Traffic Status


Default RNA Sensor Health Policy Requires: DC/MDC

Version 4.7

Use the Default RNA Sensor Health Policy to monitor health on legacy RNA Sensors that you have not upgraded to Version 4.7. Enabled health modules for


1363


Chapter 34

this policy are listed in the Enabled Health Modules: Default RNA Sensor Health Policy table. Enabled Health Modules: Default RNA Sensor Health Policy Module


CPU Usage




Disk Usage


Memory Usage




RNA Process


Traffic Status


Creating Health Policies Requires: DC/MDC

If you want to customize a health policy to use with your appliances, you can create a new policy. The settings in the policy initially populate with the settings from the health policy you select as a basis for the new policy. You can enable or disable modules within the policy and change the alerting criteria for each module as needed. To create a health policy:


1.


2. On the toolbar, click Health Policy. The Health Policy page appears.

Version 4.7


1364


Chapter 34

3. Click Create Policy to create a new policy. The Create Health Policy page appears.

4. Select the existing policy that you want to use as the basis for the new policy from the Copy Policy drop-down list. 5. Enter a name for the policy. 6. Enter a description for the policy. 7.

Select Save to save the policy information. The Health Policy Configuration page appears, including a list of the modules.

8. Configure settings on each module you want to use to test the health status of your appliances, as described in the following sections:

Version 4.7

•

Configuring Policy Run Time Intervals on page 1366

•


•


•


•


•


•


•


•


•



1365


Chapter 34

•


•


•


IMPORTANT! Make sure you enable each module that you want to run to test the health status on each Health Policy Configuration page as you configure the settings. Disabled modules do not produce health status feedback, even if the policy that contains the module has been applied to an appliance. 9. Click Save to save the policy. You must apply the policy to each appliance for it to take effect. For more information on applying health policies, see Applying Health Policies on page 1382.

Configuring Policy Run Time Intervals Requires: DC/MDC

You can control how often health tests run by modifying the Policy Run Time Interval for the health policy. The maximum run time interval you can set is 99999 minutes. WARNING! Do not set a run interval of less than five minutes. To configure a policy run time interval:


1.

On the Health Policy Configuration page, select Policy Run Time Interval. The Health Policy Configuration - Policy Run Time Interval page appears.

2. In the Run Interval (mins) field, enter the time in minutes that you want to elapse between automatic repetitions of the test.

Version 4.7


1366


Chapter 34

3. You have three options: •

To save your changes to this module and return to the Health Policy page, click Save Policy and Exit.

•

To return to the Health Policy page without saving any of your settings for this module, click Cancel.

•

To temporarily save your changes to this module and switch to another module’s settings to modify, select the other module from the list at the left of the page. If you click Save Policy and Exit when you are done, all changes you made will be saved; if you click Cancel, you discard all changes.

You must apply the health policy to the appropriate appliances if you want your settings to take effect. See Applying Health Policies on page 1382 for more information.

Configuring Appliance Heartbeat Monitoring Requires: DC

Supported Platforms: Defense Center The Defense Center receives heartbeats from its managed appliances once every two minutes or every 200 events, whichever comes first, as an indicator that the appliance is running and communicating properly with the Defense Center. Use the Appliance Heartbeat health status module to track whether the Defense Center receives heartbeats from managed appliances. If the Defense Center does not detect a heartbeat from a appliance, the status classification for this module changes to Critical. That status data feeds into the health monitor and Status Dashboard. To configure Appliance Heartbeat health module settings:


1.

In the Health Policy Configuration page, select Appliance Heartbeat. The Health Policy Configuration - Appliance Heartbeat page appears.

2. Select On for the Enabled option to enable use of the module for health status testing.

Version 4.7


1367


Chapter 34



•


•



Configuring CPU Usage Monitoring Requires: DC/MDC

Supported Platforms: All Excessive CPU usage can indicate that you need to upgrade your hardware or that there are processes that are not functioning correctly. Use the CPU Usage health status module to set CPU usage thresholds. If the CPU usage on the monitored appliance exceeds the Warning threshold, the status classification for that module changes to Warning. If the CPU usage on the monitored appliance exceeds the Critical threshold, the status classification for that module changes to Critical. That status data feeds into the health monitor and Status Dashboard. The maximum percentage you can set for either threshold is 100 percent, and the Critical threshold must be higher than the Warning threshold. To configure CPU Usage health module settings:


1.

On the Health Policy Configuration page, select CPU Usage. The Health Policy Configuration - CPU Usage page appears.

2. Select On for the Enabled option to enable use of the module for health status testing. 3. In the Critical Threshold % field, enter the percentage of CPU usage that should trigger a critical health status.

Version 4.7


1368


Chapter 34

4. In the Warning Threshold % field, enter the percentage of CPU usage that should trigger a warning health status. 5. You have three options: •


•


•



Configuring Data Correlator Process Monitoring Requires: DC/MDC

Supported Platforms: All The Data Correlator, short for the system daemon SFDataCorrelator, manages data transmission. Use the Data Correlator Process health status module to set thresholds for the number of restarts that trigger a change in the health status. The restart counter does not count actual restarts. The module checks if any restarts occurred during the period between tests. Even if multiple restarts occur between tests, the module only increments the restart counter by one each time it checks. If any restarts occur, the module adds one to the restart count. The first time the module checks and no restarts have occurred since the last test, the module resets the counter to zero. The alert level also lowers by one level (for example, Critical is reduced to Warning or Warning is reduced to Normal). The second time the module checks and no restarts have occurred since the last test, the alert level resets to Normal. If the module finds that the process is not running at all, it increments the restart counter by one, but sets the module status to Critical for that test, regardless of the thresholds set for the module. The status remains Critical until the module finds that the process is running. At that point, the module sets status according to the restart counter value and the configured thresholds for the module. If the module checks the Data Correlator process as many times as configured in the Warning Number of restart1327 s threshold, and each time one or more restarts have occurred, the status classification for that module changes to Warning. If the module checks the Data Correlator process as many times as configured in the Critical Number of restarts threshold, and each time one or more restarts have occurred, the status classification for that module changes to Critical. That status data feeds into the health monitor and Status Dashboard.

Version 4.7


1369


Chapter 34

The maximum number of restarts you can set for either threshold is 100, and the Critical threshold must be higher than the Warning threshold. To configure Data Correlator Process health module settings: Access: Maintenance or Admin

1.

On the Health Policy Configuration page, select Data Correlator Process. The Health Policy Configuration - Data Correlator Process page appears.

2. Select On for the Enabled option to enable use of the module for health status testing. 3. In the Critical Number of restarts field, enter the number of process restarts that should trigger a critical health status. 4. In the Warning Number of restarts field, enter the number of process restarts that should trigger a warning health status. 5. You have three options: •


•


•



Configuring Defense Center Status Requires: MDC

Version 4.7

Supported Platforms: Master Defense Center


1370


Chapter 34

To configure Defense Center Status: Access: Maintenance or Admin

1.

In the Health Policy Configuration page, select Defense Center Status. The Defense Center Status page appears.

2. Select On for the Enabled option to enable use of the module for health status testing. 3. You have three options: •


•


•


You must apply the health policy to the appropriate Defense Center if you want your settings to take effect. See Applying Health Policies on page 1382 for more information.

Configuring Disk Usage Monitoring Requires: DC/MDC

Supported Platforms: All Without sufficient disk space, an appliance cannot run. The health monitor can identify low disk space conditions on your appliances before the space runs out. Use the Disk Usage health status module to set disk usage thresholds. If the disk usage on the monitored appliance exceeds the Warning threshold, the status classification for that module changes to Warning. If the disk usage on the monitored appliance exceeds the Critical threshold, the status classification for that module changes to Critical. That status data feeds into the health monitor and Status Dashboard. The maximum percentage you can set for either threshold is 100 percent, and the Critical threshold must be higher than the Warning threshold.

Version 4.7


1371


Chapter 34

To configure Disk Usage health module settings: Access: Maintenance or Admin

1.

On the Health Policy Configuration page, select Disk Usage. The Health Policy Configuration - Disk Usage page appears.

2. Select On for the Enabled option to enable use of the module for health status testing. 3. In the Critical Threshold % field, enter the percentage of disk usage that should trigger a critical health status. 4. In the Warning Threshold % field, enter the percentage of disk usage that should trigger a warning health status. 5. You have three options: •


•


•



Configuring Estreamer Process Monitoring Requires: DC/MDC

Supported Platforms: Defense Center The Estreamer, short for the Sourcefire Event Streamer, allows you to stream Sourcefire 3D System intrusion and network discovery data from the Sourcefire Defense Center to, for example, a Master Defense Center. Use the Estreamer Process health status module to set thresholds for the number of restarts that trigger a change in the health status. The restart counter does not count actual restarts. The module checks if any restarts occurred during the period between tests. Even if multiple restarts occur between tests, the module only increments the restart counter by one each time it checks. If any restarts occur, the module adds one to the restart count. The first time the module checks and no restarts have occurred since the last test, the

Version 4.7


1372


Chapter 34

module resets the counter to zero. The alert level also lowers by one level (for example, Critical is reduced to Warning or Warning is reduced to Normal). The second time the module checks and no restarts have occurred since the last test, the alert level resets to Normal. If the module finds that the process is not running at all, it increments the restart counter by one, but sets the module status to Critical for that test, regardless of the thresholds set for the module. The status remains Critical until the module finds that the process is running. At that point, the module sets status according to the restart counter value and the configured thresholds for the module. If the module checks the Estreamer process as many times as configured in the Warning Number of restarts threshold, and each time one or more restarts have occurred, the status classification for that module changes to Warning. If the module checks the Estreamer process as many times as configured in the Critical Number of restarts threshold, and each time one or more restarts have occurred, the status classification for that module changes to Critical. That status data feeds into the health monitor and Status Dashboard. The maximum number of restarts you can set for either threshold is 100, and the Critical threshold must be higher than the Warning threshold. To configure Estreamer Process health module settings: Access: Maintenance or Admin

1.

On the Health Policy Configuration page, select Estreamer Process. The Health Policy Configuration - Estreamer Process page appears.

2. Select On for the Enabled option to enable use of the module for health status testing. 3. In the Critical Number of restarts field, enter the number of process restarts that should trigger a critical health status. 4. In the Warning Number of restarts field, enter the number of process restarts that should trigger a warning health status.

Version 4.7


1373


Chapter 34



•


•



Configuring Event Stream Monitoring Requires: DC/MDC

Supported Platforms: Master Defense Center Use the Event Stream Status module to set thresholds for the number of seconds between events to trigger a change in the health status. If the wait exceeds the number of seconds configured in the Warning Seconds since last event threshold, the status classification for that module changes to Warning. If the wait exceeds the Critical Seconds since last event threshold, the status classification for that module changes to Critical. That status data feeds into the health monitor and Status Dashboard. The maximum number of seconds you can set for either threshold is 600, and the Critical threshold must be higher than the Warning threshold. The minimum number of seconds is 10. To configure Event Stream Status health module settings:


1.

In the Health Policy Configuration page, select Event Stream Status. The Health Policy Configuration - Event Stream Status page appears.

2. Select On for the Enabled option to enable use of the module for health status testing. 3. In the Critical Seconds since last event field, enter the maximum number of seconds to wait between events, before triggering a critical health status. 4. In the Warning Seconds since last event field, enter the maximum number of seconds to wait between events, before triggering a warning health status.

Version 4.7


1374


Chapter 34



•


•


You must apply the health policy to the Master Defense Center for your settings to take effect. See Applying Health Policies on page 1382 for more information.

Configuring IPS Event Rate Monitoring Requires: DC/MDC

Supported Platforms: IPS Use the IPS Event Rate health status module to set thresholds for the number of packets per second that trigger a change in the health status. If the event rate for the IPS process on the monitored sensor exceeds the number of events per second configured in the Events per second (Warning) threshold, the status classification for that module changes to Warning. If the event rate exceeds the number of events per second configured in the Events per second (Critical) threshold, the status classification for that module changes to Critical. That status data feeds into the health monitor and Status Dashboard. Typically, the event rate for a network segment averages 20 events per second. For a network segment with this average rate, Events per second (Critical) should be set to 50 and Events per second (Warning) should be set to 30. To determine thresholds for your system, find the Events/Sec value on the Statistics page for your sensor (Operations > Monitoring > Statistics), then calculate the thresholds using these formulas: •

Events per second (Critical) = Events/Sec * 2.5

•

Events per second (Warning) = Events/Sec *1.5

The maximum number of events you can set for either threshold is 999, and the Critical threshold must be higher than the Warning threshold.

Version 4.7


1375


Chapter 34

To configure IPS Event Rate Monitor health module settings: Access: Maintenance or Admin

1.

In the Health Policy Configuration page, select IPS Event Rate. The Health Policy Configuration - IPS Event Rate page appears.

2. Select On for the Enabled option to enable use of the module for health status testing. 3. In the Events per second (Critical) field, enter the number of events per second that should trigger a critical health status. 4. In the Events per second (Warning) field, enter the number of events per second that should trigger a warning health status. 5. You have three options: •


•


•


You must apply the health policy to the appropriate sensors if you want your settings to take effect. See Applying Health Policies on page 1382 for more information.

Configuring IPS Process Monitoring Requires: DC/MDC

Supported Platforms: IPS The IPS process (also known as Snort) is the packet decoder on a 3D Sensor with the IPS component. Use the IPS Process health status module to set thresholds for the number of restarts that trigger a change in the health status for the process. The restart counter does not count actual restarts. The module checks if any restarts occurred during the period between tests. Even if multiple restarts occur between tests, the module only increments the restart counter by one each time it checks. If any restarts occur, the module adds one to the restart count. The first time the module checks and no restarts have occurred since the last test, the module resets the counter to zero. The alert level also lowers by one level (for

Version 4.7


1376


Chapter 34

example, Critical is reduced to Warning or Warning is reduced to Normal). The second time the module checks and no restarts have occurred since the last test, the alert level resets to Normal. If the module finds that the process is not running at all, it increments the restart counter by one, but sets the module status to Critical for that test, regardless of the thresholds set for the module. The status remains Critical until the module finds that the process is running. At that point, the module sets status according to the restart counter value and the configured thresholds for the module. If the module checks the IPS process as many times as configured in the Warning Number of restarts threshold, and each time one or more restarts have occurred, the status classification for that module changes to Warning. If the module checks the IPS process as many times as configured in the Critical Number of restarts threshold, and each time one or more restarts have occurred, the status classification for that module changes to Critical. That status data feeds into the health monitor and Status Dashboard. The maximum number of restarts you can set for either threshold is 100, and the Critical threshold must be higher than the Warning threshold. To configure IPS Process Monitor health module settings: Access: Maintenance or Admin

1.

In the Health Policy Configuration page, select IPS Process. The Health Policy Configuration - IPS Process page appears.

2. Select On for the Enabled option to enable use of the module for health status testing. 3. In the Critical Number of restarts field, enter the number of process restarts that should trigger a critical health status. 4. In the Warning Number of restarts field, enter the number of process restarts that should trigger a warning health status.

Version 4.7


1377


Chapter 34



•


•



Configuring Memory Usage Monitoring Requires: DC/MDC

Supported Platforms: All Use the Memory Usage health status module to set memory usage thresholds. The module calculates free memory by adding free memory and cached memory. If the memory usage on the monitored appliance exceeds the Warning threshold, the status classification for that module changes to Warning. If the memory usage on the monitored appliance exceeds the Critical threshold, the status classification for that module changes to Critical. That status data feeds into the health monitor and Status Dashboard. The maximum percentage you can set for either threshold is 100 percent, and the Critical threshold must be higher than the Warning threshold. To configure Memory Usage health module settings:


1.

In the Health Policy Configuration page, select Memory Usage. The Health Policy Configuration - Memory Usage page appears.

2. Select On for the Enabled option to enable use of the module for health status testing. 3. In the Critical Threshold % field, enter the percentage of memory usage that should trigger a critical health status. 4. In the Warning Threshold % field, enter the percentage of memory usage that should trigger a warning health status.

Version 4.7


1378


Chapter 34



•


•



Configuring RNA Host Usage Monitoring Requires: DC/MDC

Supported Platforms: RNA Use the RNA Host Usage health status module to set RNA Host shortage thresholds. If the number of remaining RNA Hosts on the monitored sensor falls below the Warning Hosts threshold, the status classification for that module changes to Warning. If the number of remaining RNA Hosts on the monitored sensor falls below the Critical Hosts threshold, the status classification for that module changes to Critical. That status data feeds into the health monitor and Status Dashboard. The maximum number of hosts you can set for either threshold is 999, and the Critical threshold must be higher than the Warning threshold. To configure RNA Host Usage health module settings:


1.

In the Health Policy Configuration page, select RNA Host Usage. The Health Policy Configuration - RNA Host Usage page appears.

2. Select On for the Enabled option to enable use of the module for health status testing. 3. In the Critical number Hosts field, enter the remaining number of available hosts that should trigger a critical health status. 4. In the Warning number Hosts field, enter the remaining number of available hosts that should trigger a warning health status.

Version 4.7


1379


Chapter 34



•


•



Configuring RNA Process Monitoring Requires: DC/MDC

Supported Platforms: RNA Use the RNA Process health status module to set thresholds for the number of restarts that trigger a change in the health status. The restart counter does not count actual restarts. The module checks if any restarts occurred during the period between tests. Even if multiple restarts occur between tests, the module only increments the restart counter by one each time it checks. If any restarts occur, the module adds one to the restart count. The first time the module checks and no restarts have occurred since the last test, the module resets the counter to zero. The alert level also lowers by one level (for example, Critical is reduced to Warning or Warning is reduced to Normal). The second time the module checks and no restarts have occurred since the last test, the alert level resets to Normal. If the module finds that the process is not running at all, it increments the restart counter by one, but sets the module status to Critical for that test, regardless of the thresholds set for the module. The status remains Critical until the module finds that the process is running. At that point, the module sets status according to the restart counter value and the configured thresholds for the module. If the module checks the RNA process as many times as configured in the Warning Number of restarts threshold, and each time one or more restarts have occurred, the status classification for that module changes to Warning. If the module checks the RNA process as many times as configured in the Critical Number of restarts threshold, and each time one or more restarts have occurred, the status classification for that module changes to Critical. That status data feeds into the health monitor and Status Dashboard. The maximum number of restarts you can set for either threshold is 100, and the Critical threshold must be higher than the Warning threshold.

Version 4.7


1380


Chapter 34

To configure RNA Process health module settings: Access: Maintenance or Admin

1.

In the Health Policy Configuration page, select RNA Process. The Health Policy Configuration - RNA Process page appears.

2. Select On for the Enabled option to enable use of the module for health status testing. 3. In the Critical Number of restarts field, enter the number of process restarts that should trigger a critical health status. 4. In the Warning Number of restarts field, enter the number of process restarts that should trigger a warning health status. 5. You have three options: •


•


•



Configuring Traffic Status Monitoring Requires: DC/MDC

Supported Platforms: IPS, RNA Use the Traffic Status health status module to detect whether a sensor receives traffic. If the Traffic Status module determines that a sensor does not receive

Version 4.7


1381


Chapter 34

traffic, the status classification for that module changes to Critical. That status data feeds into the health monitor and Status Dashboard. WARNING! If you enable the Traffic Status module on a sensor where there are unused interfaces that are included in an interface set associated with a detection engine, the module interprets the idleness of the port as a traffic failure and alerts on traffic status. To prevent alerting on idle interfaces, remove those interfaces from all interface sets associated with detection engines. For more information on managing interface sets, see Editing an Interface Set on page 118. To configure Traffic Status health module settings: Access: Maintenance or Admin

1.

In the Health Policy Configuration page, select Traffic Status. The Health Policy Configuration - Traffic Status monitor page appears.

2. Select On for the Enabled option to enable use of the module for health status testing. 3. You have three options: •


•


•



Applying Health Policies Requires: DC/MDC

Version 4.7

When you apply a health policy to an appliance, the health tests for all the modules you enabled in the policy automatically monitor the health of the processes and hardware on the appliance. Health tests then continue to run at the intervals you configured in the policy, collecting health data for the appliance and forwarding that data to the Defense Center.


1382


Chapter 34

If you enable a module in a health policy and then apply the policy to an appliance that does not require that health test, the health monitor reports the status for that health module as disabled. IMPORTANT! When you apply a different policy to an appliance that already has a policy applied, expect some latency in the display of new data based on the newly applied tests.

IMPORTANT! Default health policies are not replicated between Defense Centers in a high availability pair. Each appliance uses the local default health policy configured for that appliance. To apply a health policy: Access: Maintenance or Admin

1.


2. Click Health Policy in the health monitor toolbar. The Health Policy page appears.

3. Click Apply next to the policy you want to apply. The Health Policy Apply page appears.

4. Check the appliances where you want to apply the health policy.

Version 4.7


1383


Chapter 34

5. Click Apply to apply the policy to the selected appliances. The Health Policy page appears, with a message indicating if the application of the policy was successful. Monitoring of the appliance starts as soon as the policy is successfully applied.

Editing Health Policies Requires: DC/MDC

You can modify a health policy by enabling or disabling modules or by changing module settings. If you modify a policy that is already applied to an appliance, the changes do not take effect until you reapply the policy. Applicable health modules for various appliances are listed in the Health Modules Applicable to Appliances table. Health Modules Applicable to Appliances

Version 4.7

Module

Applicable Appliance

Appliance Heartbeat

Defense Center

CPU Usage

All


All



Disk Usage

All

Estreamer Process

Defense Center

Event Stream Status


IPS Event Rate

3D Sensors with IPS

IPS Process

3D Sensors with IPS

Memory Usage

All


Defense Center

RNA Process

3D Sensors with RNA

Traffic Status

3D Sensors with IPS, 3D Sensors with RNA


1384


Chapter 34

To edit a health policy: Access: Maintenance or Admin

1.


2. Click Health Policy in the health monitor toolbar. The Health Policy page appears.

3. Click Edit next to the policy you want to modify. The Health Policy Configuration page appears, with the Policy Run Time Interval settings selected. 4. Modify settings as needed, as described in the following sections:

Version 4.7

•

Configuring Policy Run Time Intervals on page 1366

•


•


•


•


•


•


•


•


•


•


•


•


•



1385

Using Health Monitoring Using Health Monitor Blacklist

Chapter 34



•


•


6. Reapply the policy to the appropriate appliances as described in Applying Health Policies on page 1382.

Deleting Health Policies Requires: DC/MDC

You can delete health policies that you no longer need. If you delete a policy that is still applied to an appliance, the policy settings remain in effect until you apply a different policy. In addition, if you delete a health policy that is applied to a sensor, any health monitoring alerts in effect for the sensor remain active until you deactivate the underlying associated alert. For more information on deactivating alerts, see Activating and Deactivating Alerts on page 468. TIP! To stop health monitoring for an appliance, create a health policy with all modules disabled and apply it to the appliance. For more information on creating health policies, see Creating Health Policies on page 1364. For more information on applying health policies, see Applying Health Policies on page 1382. To delete a health policy:


1.


2. Click Health Policy in the health monitor toolbar. The Health Policy page appears. 3. Click Delete next to the policy you want to delete. A message appears, indicating if the deletion was successful.

Using Health Monitor Blacklist Requires: DC/MDC

Version 4.7

In the course of normal network maintenance, you disable appliances or make them temporarily unavailable. Because those outages are deliberate, you will not want to receive health events in response to them. You can set a Defense Center or a Master Defense Center to disable all or some of the heath events generated


1386


Chapter 34

by an appliance. For example, if you know that a segment of your network will be unavailable, you can temporarily disable health monitoring for a 3D Sensor on that segment to prevent the Defense Center from generating unnecessary health events related to the lapsed connection to the 3D Sensor. To temporarily disable health events from an appliance, go to the Blacklist configuration page, and add an appliance to the blacklist. After the setting takes effect the appliance health monitoring notifications are disabled. The Health Monitor Appliance Status Summary lists the appliance as disabled. At times it may be more practical to just blacklist an appliance’s individual health monitoring module. For example, when you run out of RNA host licenses on an appliance, you can blacklist the RNA Host License Limit status messages until you finish installing a new license with more hosts. Note that at the main Health Monitor page you can distinguish between appliances that are blacklisted if you expand to view the list of appliances with a particular status by clicking the arrow in that status row. For more information on expanding that view, refer to To use the health monitor: on page 1395 A blacklist icon ( ) and a notation is visible once you expand the view for a blacklisted or partially blacklisted appliance. IMPORTANT! On a Defense Center, Health Monitor blacklist settings are system settings. Therefore if you blacklist a sensor, then deleted it and later re-registered it with the Defense Center, the blacklist settings remain persistent. The newly reregistered sensor remains blacklisted.

Blacklisting Health Policies or Appliances Requires: DC/MDC

If you want to disable health events for all appliances with a particular health policy, you can blacklist the policy. If you need to disable the results of a group of appliances’ health monitoring, you can blacklist the group of appliances. Once the blacklist settings take effect, the appliances report a disabled status in the Appliance Status Summary. TIP! You can blacklist 3D Sensors only from a Defense Center, not a Master Defense Center. You cannot blacklist intrusion agents. To blacklist an entire health policy or group of appliances:


1.


2. On the toolbar, click Blacklist. The Blacklist page appears.

Version 4.7


1387


Chapter 34

3. Use the drop-down list on the right to sort the list by group, policy, or model. (On a Master Defense Center, sort the list by group, manager, policy or model. Groups on a Defense Center are 3D Sensors. Groups on a Master Defense Center are appliances.)

4. To blacklist all appliances in a group, model, or policy category, select the category then click Apply. (On a Master Defense Center, to blacklist all appliances associated with a manager, select manager then click Apply.) The page refreshes then indicates the Blacklisted state of the appliances.

Blacklisting an Appliance If you need to disable the results of an individual appliance’s health monitoring, you can blacklist the appliance. Once the blacklist settings take effect, the appliance shows as disabled in the Health Monitor Appliance Module Summary. To blacklist an individual appliance: Access: Maintenance or Admin

1.


2. On the toolbar, click Blacklist. The Blacklist page appears. 3. Use the drop-down list on the right to sort the list by appliance group, model, or by policy. (On a Master Defense Center, sort the list by group, manager, policy or model.) 4. To blacklist an individual appliance, select and expand a category folder, select the box next to the appropriate appliance, then click Apply.

The page refreshes then indicates the Blacklisted state of the appliances. Click Edit and refer to Blacklisting a Health Policy Module on page 1389 to blacklist individual health policy modules.

Version 4.7


1388


Chapter 34

Blacklisting a Health Policy Module Requires: DC/MDC

You can blacklist individual health policy modules on appliances. You may want to do this to prevent events from the module from changing the status for the appliance to warning or critical. Defense Center Only The Defense Center is a supported platform only for the following health policy modules. Only blacklist these health policy modules for Defense Centers: •

Appliance Heartbeat

•

CPU Usage

•


•

Disk Usage

•

Estreamer Process

•

Memory Usage

•


Master Defense Center Only The Master Defense Center is a supported platform only for the following health policy modules. Only blacklist these health policy modules for Master Defense Centers: •

CPU Usage

•


•


•

Disk Usage

•

Event Stream Status

•

Memory Usage

For details about applicable modules on all appliances, refer to the Health Modules Applicable to Appliances table on page 1384. TIP! Once the blacklist settings take effect, the appliance shows as Part Blacklisted or All Modules Blacklisted in the Blacklist page and in the Appliance Health Monitor Module Status Summary but only in expanded views on the main Appliance Status Summary page. Make sure that you keep track of individually blacklisted modules so you can reactivate them when you need them. You may miss necessary warning or critical messages if you accidentally leave a module disabled. To blacklist an individual health policy module: Access: Maintenance or Admin

Version 4.7

1.



1389

Using Health Monitoring Configuring Health Monitor Alerts

Chapter 34

2. On the toolbar, click Blacklist. The Blacklist page appears. 3. Sort by Group, Policy, or Model, then click Edit to display the list of health policy modules. The health policy modules appear.

4. Select the module that you want to blacklist, then click Save.

Configuring Health Monitor Alerts Requires: DC/MDC

You can set up alerts to notify you through email, through SNMP, or through the system log when the status changes for the modules in a health policy. You can associate an existing alert with health event levels to cause that alert to trigger when health events of a particular level occur. For example, if you are concerned that your appliances may run out of hard disk space, you can automatically send an email to a system administrator when the remaining disk space reaches the warning level. If the hard drive continues to fill, you can send a second email when the hard drive reaches the critical level. For more information, see the following topics:

Version 4.7

•

Preparing to Create a Health Alert on page 1391

•

Creating Health Monitor Alerts on page 1391

•

Interpreting Health Monitor Alerts on page 1392

•

Editing Health Monitor Alerts on page 1393

•

Deleting Health Monitor Alerts on page 1394


1390


Chapter 34

Preparing to Create a Health Alert Requires: DC/MDC

If you want to create a health alert, you first need to create the underlying alert that you associate to the health alert. If you want to use email alerting, you also need to set up your email relay host in your system policy and re-apply that policy. To prepare your system for alerting:

Access: Admin

1.

If you plan to use email alerting: •

Select Operations > System Policy.

•

Create a new policy or click Edit next to an existing one.

•

In the policy, click Email Notification.

•

Enter the name of the Mail Relay Host.

•

Click Save Policy and Exit.

•

Click Apply and apply the policy to the Defense Center where you plan to create the health alert.

2. Create email, SNMP, or syslog alerts you want to associate with health alerts: •

For more information on creating syslog alerts, see Creating Syslog Alerts on page 460.

•

For more information on creating email alerts, see Creating Email Alerts on page 464.

•

For more information on creating SNMP alerts, see Creating SNMP Alerts on page 465.

Continue with Creating Health Monitor Alerts on page 1391.

Creating Health Monitor Alerts Requires: DC/MDC

When you create a health monitor alert, you create an association between a severity level, a health module, and an alert. You can use an existing alert or configure a new one specifically to report on system health. For more information on creating the alert, see Preparing to Create a Health Alert on page 1391. When the severity level occurs for the selected module, the associated alert triggers. To create health monitor alerts:

Access: Admin

1.


Version 4.7


1391


Chapter 34

2. Click Health Monitor Alerts in the health monitor toolbar. The Health Monitor Alerts page appears.

3. Type a name for the health alert in the Health Alert Name field. 4. From the Severity list, select the severity level you want to use to trigger the alert. 5. From the Module list, select the modules for which you want the alert to apply. TIP! To select multiple modules, press Shift + Ctrl and click the module names. 6. From the Alert list, select the alert which you want to trigger when the selected severity level is reached. TIP! Click Alerts in the toolbar to open the Alerts page. For more information on creating alerts, see Creating Alerts on page 460. Click Save to save the health alert.

7.

A message appears, indicating if the alert configuration was successfully saved. The Active Health Alerts list now includes the alert you created.

Interpreting Health Monitor Alerts Requires: DC/MDC

Version 4.7

The alerts generated by the health monitor contain the following information: •

Severity, which indicates the severity level of the alert.

•

Module, which specifies the health module whose test results triggered the alert.

•

Description, which includes the health test results that triggered the alert.


1392


Chapter 34

For more information on health alert severity levels, see the Alert Severities table. Alert Severities Severity

Description

Critical

The health test results met the criteria to trigger a Critical alert status.

Warning

The health test results met the criteria to trigger a Warning alert status.

Normal

The health test results met the criteria to trigger a Normal alert status.

Error

The health test did not run.

For more information on health modules, see Understanding Health Modules on page 1356.

Editing Health Monitor Alerts Requires: DC/MDC

You can edit existing health monitor alerts to change the severity level, health module, or alert associated with the health monitor alert. To edit health monitor alerts:

Access: Admin

1.


2. Click Health Monitor Alerts in the health monitor toolbar. The Health Monitor Alerts page appears.

Version 4.7


1393


Chapter 34

3. Select the alert you want to modify in the Active Health Alerts list.

4. Click Load to load the configured settings for the selected alert. 5. Modify settings as needed. For more information, see Creating Health Monitor Alerts on page 1391. 6. Click Save to save the modified health alert. A message appears, indicating if the alert configuration was successfully saved.

Deleting Health Monitor Alerts Requires: DC/MDC

You can delete existing health monitor alerts. IMPORTANT! Deleting a health monitor alert does not delete the associated alert. You must deactivate or delete the underlying alert to ensure that alerting does not continue. For more information on deactivating alerts, see Activating and Deactivating Alerts on page 468. For more information on deleting alerts, see Deleting Alerts on page 467. To delete health monitor alerts:

Access: Admin

1.


2. Click Health Monitor Alerts in the health monitor toolbar. The Health Monitor Alerts page appears. 3. Select the alert you want to delete in the Active Health Alerts list.

Version 4.7


1394

Using Health Monitoring Using the Health Monitor

Chapter 34

4. Click Delete. A message appears, indicating if the alert configuration was successfully deleted.

Using the Health Monitor Requires: DC/MDC

The Health Monitor page provides the compiled health status for all sensors managed by the Defense Center, plus the Defense Center. The Status table provides a count of the managed appliances for this Defense Center by overall health status. The pie chart supplies another view of the health status breakdown, indicating the percentage of appliances currently in each health status category. To use the health monitor:


1.

Click Health Monitor on the toolbar. The Health Monitor page appears.

2. Select the appropriate status in the Status column of the table or the appropriate portion of the pie chart to the list appliances with that status. TIP! If the arrow in the row for a status level points down, the appliance list for that status shows in the lower table. If the arrow points right, the appliance list is hidden. The following topics provide details on the tasks you can perform from the Health Monitor page:

Version 4.7

•

Interpreting Health Monitor Status on page 1396

•


•


•


•



1395

Using Health Monitoring Using Appliance Health Monitors

Chapter 34

Interpreting Health Monitor Status Requires: DC/MDC

Available status categories, by severity, include Error, Critical, Warning, Normal, and Disabled, as described in the Health Status Indicator table.

Health Status Indicator Status Level

Status Icon

Status Color

Description

Error

White

Indicates that at least one health monitoring module has failed on the appliance and has not been successfully re-run since the failure occurred. Contact your technical support representative to obtain an update to the health monitoring module.

Critical

Red

Indicates that the critical thresholds have been exceeded for at least one health module on the appliance and the problem has not been corrected.

Warning

Yellow

Indicates that warning thresholds have been exceeded for at least one health module on the appliance and the problem has not been corrected.

Normal

Green

Indicates that all health modules on the appliance are running within the thresholds configured in the health policy applied to the appliance.

Disabled

Blue

Indicates that an appliance is disabled or blacklisted, that the appliance does not have a health policy applied to it, or that the appliance is currently unreachable.

Using Appliance Health Monitors Requires: DC/MDC

The Appliance health monitor provides a detailed view of the health status of an appliance. IMPORTANT! Your browser session will not be automatically timed out while you are viewing the Health Monitor page or the Dashboard page. To view the status summary for a specific appliance:


Version 4.7

1.



1396


Chapter 34

2. To show the list of appliances with a particular status, click the arrow in that status row. TIP! If the arrow in the row for a status level points down, the appliance list for that status shows in the lower table. If the arrow points right, the appliance list is hidden. 3. In the Sensors column of the appliance list, click the name of the appliance for which you want to view details in the health monitor toolbar. The Health Monitor Sensor page appears.

4. Optionally, in the Module Status Summary graph, click the color for the event status category you want to view. The Alert Detail list toggles the display to show or hide events. For more information, see the following sections:

Version 4.7

•

Interpreting Appliance Health Monitor Status on page 1398

•

Viewing Alerts by Status on page 1398

•

Running All Modules for an Appliance on page 1399

•

Running a Specific Health Module on page 1400

•

Generating Health Module Alert Graphs on page 1401

•

Generating Appliance Troubleshooting Files on page 1402


1397


Chapter 34

Interpreting Appliance Health Monitor Status Requires: DC/MDC

Available status categories, by severity, include Error, Critical, Warning, Normal, and Disabled, as described in the Appliance Health Status Indicator table that follows.

Appliance Health Status Indicator Status Level

Status Icon

Status Color

Description

Error

White

Indicates that the health monitoring module has failed and has not been successfully re-run since the failure occurred. Contact your technical support representative to obtain an update to the health monitoring module.

Critical

Red

Indicates that the critical thresholds have been exceeded for the health module on the appliance and the problem has not been corrected.

Warning

Yellow

Indicates that warning thresholds have been exceeded for the health module on the appliance and the problem has not been corrected.

Normal

Green

Indicates that the health is running within the thresholds configured in the health policy applied to the appliance.

Disabled

Blue

Indicates that a module is disabled or blacklisted, that the appliance does not have a health policy applied to it, or that the appliance is currently unreachable.

Viewing Alerts by Status Requires: DC/MDC

You can show or hide categories of alerts by status. To show alerts by status:


•

Click the status icon or the color segment in the pie chart that corresponds to the health status of the alerts you want to view. The alerts for that category appear in the Alert Detail list.

To hide alerts by status: Access: Maintenance or Admin

Version 4.7

•

Click the status icon or the color segment in the pie chart that corresponds to the health status of the alerts you want to view. The alerts in the Alert Detail list for that category disappear.


1398


Chapter 34

Running All Modules for an Appliance Requires: DC/MDC

Health module tests run automatically at the policy run time interval you configure when you create a health policy. However, you can also run all health module tests on demand to collect up-to-date health information for the appliance. To run all health modules for the appliance:


1.


2. To expand the appliance list to show appliances with a particular status, click the arrow in that status row. TIP! If the arrow in the row for a status level points down, the appliance list for that status shows in the lower table. If the arrow points right, the appliance list is hidden. 3. In the Sensors column of the appliance list, click the name of the appliance for which you want to view details in the health monitor toolbar. The Health Monitor Sensor page appears.

Version 4.7


1399


Chapter 34

4. Click Run All Modules. The status bar indicates the progress of the tests, then the Health Monitor Sensor page refreshes. IMPORTANT! When you manually run health modules, the first refresh that automatically occurs may not reflect the data from the manually-run tests. If the value has not changed for a module that you just ran manually, wait a few seconds, then refresh the page by clicking the sensor name. You can also wait for the page to refresh again automatically.

Running a Specific Health Module Requires: DC/MDC

Health module tests run automatically at the policy run time interval you configure when you create a health policy. However, you can also run a health module test on demand to collect up-to-date health information for that module. To run a specific health module:


1.


2. To expand the appliance list to show appliances with a particular status, click the arrow in that status row. TIP! If the arrow in the row for a status level points down, the appliance list for that status shows in the lower table. If the arrow points right, the appliance list is hidden. 3. In the Sensors column of the appliance list, click the name of the appliance for which you want to view details in the health monitor toolbar. The Health Monitor Sensor page appears.

Version 4.7


1400


Chapter 34

4. In the Module Status Summary graph of the Health Monitor Sensor page, click the color for the health alert status category you want to view. The Alert Detail list expands to list the health alerts for the selected appliance for that status category.

5. In the Alert Detail row for the alert for which you want to view a list of events, click Run. The status bar indicates the progress of the test, then the Health Monitor Sensor page refreshes. IMPORTANT! When you manually run health modules, the first refresh that automatically occurs may not reflect the data from the manually-run tests. If the value has not changed for a module that you just manually ran, wait a few seconds, then refresh the page by clicking the sensor name. You can also wait for the page to refresh automatically again.

Generating Health Module Alert Graphs Requires: DC/MDC

You can graph the results over a period of time of a particular health test for a specific appliance. To generate a health module alert graph:


Version 4.7

1.



1401


Chapter 34

2. To expand the appliance list to show appliances with a particular status, click the arrow in that status row. TIP! If the arrow in the row for a status level points down, the appliance list for that status shows in the lower table. If the arrow points right, the appliance list is hidden. 3. In the Sensors column of the appliance list, click the name of the appliance for which you want to view details in the health monitor toolbar. The Health Monitor Sensor page appears. 4. In the Module Status Summary graph of the Health Monitor Sensor page, click the color for the health alert status category you want to view. The Alert Detail list expands to list the health alerts for the selected appliance for that status category. 5. In the Alert Detail row for the alert for which you want to view a list of events, click Graph. A graph appears, showing the status of the event over time. The Alert Detail section below the graph lists all health alerts for the selected appliance. TIP! If no events appear, you may need to adjust the time range. See Setting Event Time Constraints on page 1169 for more information.

Generating Appliance Troubleshooting Files Requires: DC/MDC

Version 4.7

In some cases, if you have a problem with your appliance, Nokia Support may ask you to generate troubleshooting files to help them diagnose the problem.


1402


Chapter 34

To generate appliance troubleshooting files: Access: Maintenance or Admin

1.


2. To expand the appliance list to show appliances with a particular status, click the arrow in that status row. TIP! If the arrow in the row for a status level points down, the appliance list for that status shows in the lower table. If the arrow points right, the appliance list is hidden. 3. In the Sensors column of the appliance list, click the name of the appliance for which you want to view details in the health monitor toolbar. The Health Monitor Sensor page appears. 4. Click Generate Troubleshooting Files and confirm that you want to generate the files. The file generation task is added to the task status queue. 5. Select Operations > Monitoring > Task Status. The Task Status page appears. 6. Click the folder for the file generation job entry to expand the entry.

7.

Select Click to retrieve generated files. A File Download dialog box appears.

8. Save the files to a location on your computer. 9. Send the generated files to technical support to assist in troubleshooting your system.

Version 4.7


1403

Using Health Monitoring Working with Health Events

Chapter 34

Working with Health Events Requires: DC/MDC

The Defense Center provides fully customizable event views that allow you to quickly and easily analyze the health status events gathered by the health monitor. These event views allow you to search and view event data and to easily access other information that may be related to the events you are investigating. Many functions that you can perform on the health event view pages are constant across all event view pages. See Understanding Health Event Views on page 1404 for more information about these common procedures. From the Operations > Monitoring > Health menu, you can view health events, and can search for specific events. See the following sections for more information about viewing events: •

Understanding Health Event Views on page 1404 describes the types of events that RNA generates.

•

Viewing Health Events on page 1404 describes how to access and use the Event View page.

•

Searching for Health Events on page 1410 describes how to search for specific events using the Event Search page.

Understanding Health Event Views Requires: DC/MDC

The Defense Center health monitor logs health events, which you can see on the Health Event View page. If you understand what conditions each health module tests for, you can more effectively configure alerting for health events. For more information on the different types of health modules that generate health events, see Understanding Health Modules on page 1356. For more information about viewing and searching for health events, see the following sections: •

Viewing Health Events on page 1404

•

Understanding the Health Events Table on page 1408

•


Viewing Health Events Requires: DC/MDC

You can view the appliance health data collected by your health monitor in several ways. For more information, see the following topics:

Version 4.7

•

Viewing All Health Events on page 1405

•

Viewing Health Events by Module and Appliance on page 1406

•

Working with the Health Events Table View on page 1407

•



1404


Chapter 34

Viewing All Health Events Requires: DC/MDC

The Table View of Health Events page provides a list of all health events on the selected appliance. For a description of the health modules that generated the events that you may see on this page, see Understanding Health Modules on page 1356. When you access health events from the Health Monitor page on your Defense Center, you retrieve all health events for all managed appliances. To view all health events on all managed appliances: 1.


2. In the toolbar, click Health Events. The Events page appears, containing all health events.

IMPORTANT! If no events appear, you may need to adjust the time range. See Setting Event Time Constraints on page 1169 for more information.

TIP! You can bookmark this view to allow you to return to the page in the health events workflow containing the Health Events table of events. The bookmarked view retrieves events within the time range you are currently viewing, but you can then modify the time range to update the table with more recent information if needed. For more information, see Setting Event Time Constraints on page 1169.

Version 4.7


1405


Chapter 34

Viewing Health Events by Module and Appliance Requires: DC/MDC

You can query for events generated by a specific health module on a specific appliance. To view the health events for a specific module:


1.


2. To expand the appliance list to show appliances with a particular status, click the arrow in that status row. TIP! If the arrow in the row for a status level points down, the appliance list for that status shows in the lower table. If the arrow points right, the appliance list is hidden. 3. In the Sensors column of the appliance list, click the name of the appliance for which you want to view details in the health monitor toolbar. The Health Monitor Sensor page appears. 4. In the Module Status Summary graph of the Health Monitor Sensor page, click the color for the health alert status category you want to view. The Alert Detail list expands to list the health alerts for the selected appliance for that status category.

Version 4.7


1406


Chapter 34

5. In the Alert Detail row for the alert for which you want to view a list of events, click Events. The Health Events page appears, containing query results for a query with the name of the appliance and the name of the selected health alert module as constraints.

If no events appear, you may need to adjust the time range. See Setting Event Time Constraints on page 1169 for more information. 6. If you want to view all health events for the selected appliance, expand Search Constraints and click the Module Name constraint to remove it.

Working with the Health Events Table View Requires: DC/MDC

The Health Event View Functions table describes each action you can perform from the Event View page.

Health Event View Functions To...

You can...

learn more about the contents of the columns that appear in the Health event view

find more information in Understanding the Health Events Table on page 1408.

modify the time and date range for events listed in the Health table view


sort the events that appear, change what columns display in the table of events, or constrain the events that appear


delete health events

select the check box next to the events you want to delete and click Delete. To delete all events from every page in the table view, click Delete All.

Version 4.7


1407


Chapter 34

Health Event View Functions (Continued) To...

You can...

navigate through event view pages


navigate to other event tables to view associated events



click Bookmark This Page, provide a name for the bookmark and click Save. See Using Bookmarks on page 1177 for more information.


select Analysis & Reporting > Bookmarks or, from any event view, click View Bookmarks. See Using Bookmarks on page 1177 for more information.

generate a report based on data in the table view

click Report Designer. See Creating Reports from Event Views on page 1105 for more information.

view the details associated with a single health event

click the down arrow link on the left side of the event.

view event details for multiple health events

select the check box next to the rows that correspond with the events you want to view details for and then click View.

view event details for all events in the view

click View All.

view all events of a particular status

click the status icon in the Status column for an event with that status.

Understanding the Health Events Table Requires: DC/MDC

Version 4.7

You can use the Defense Center’s health monitor to determine the status of critical functionality within the Sourcefire 3D System. You create and apply health policies to your appliances, which monitor a variety of aspects, including hardware and software status. The Health Monitor modules you choose to enable in your health policy run various tests to determine appliance health status. When the health status meets criteria that you specify, a health event is generated. For more information on health monitoring, see Monitoring the System on page 1334.


1408


Chapter 34

The fields in the health events table are described in the Health Event Fields table. Health Event Fields Field

Description

Module Name

The name of the health module that generated the event. For a list of health modules, see the Health Modules table on page 1356.

Test Name

The name of the test. This is typically the same as the module name.

Time

The timestamp for the health event.

Description

The description of the health module that generated the event. For example, health events generated when a process was unable to execute are labeled Unable to Execute.

Value

The value (number of units) of the result obtained by the health test that generated the event. For example, if the Defense Center generates a health event whenever a sensor it is monitoring is using 80 percent or more of its CPU resources, the value could be a number from 80 to 100.

Units

The units descriptor for the result. You can use the asterisk (*) to create wildcard searches. For example, if the Defense Center generates a health event when a sensor it is monitoring is using 80 percent or more of its CPU resources, the units is a percentage sign (%).

Status

The status (Critical, Yellow, Green, or Disabled) reported for the appliance.

Sensor

The appliance where the health event was reported.

To display the table view of health events: Access: Maintenance or Admin

Version 4.7

1.



1409


Chapter 34

2. On the toolbar, click Health Events. The table view appears. For information on working with health events, see Working with Health Events on page 1404. TIP! If you are using a custom workflow that does not include the table view of health events, click Workflows. On the Select Workflow page, click Health Events.

Searching for Health Events Requires: DC/MDC

You can use Event Search to search for specific network discovery events. You can create, save, and re-use event searches. When creating new searches or modifying default searches, there are a number of options you can configure. The Health Event Search Criteria table describes each search criterion you can specify.

Health Event Search Criteria Search Field

Description

Module Name

Specify the name of the module which generated the health events you want to view. For example, to view events that measure CPU performance, type CPU. The search should retrieve applicable CPU Usage events.

Value

Specify the value (number of units) of the result obtained by the health test for the events you want to view. For example, if you specify a value of 15 and type CPU in the Units field, you retrieve events where the appliance CPU was running at 15% utilization at the time the test ran.

Description

Version 4.7

Specify the description of the events you want to view. For example, you could enter Unable to Execute to view any health events where a process was unable to execute. You can use an asterisk (*) in this field to create wildcard searches.


1410


Chapter 34

Health Event Search Criteria (Continued) Search Field

Description

Units

Specify the units descriptor for the result obtained by the health test for the events you want to view. You can use an asterisk (*) in this field to create wildcard searches. For example, if you type % in the Units field, you retrieve all events for the Disk Usage modules, because the Disk Usage module has a “%” label in the Units field (and no additional text). However, if you type *% in the Units field, you retrieve all events for any modules that contain text followed by a “%” sign in the Units field.

Status

Specify the status for the health events that you want to view. Valid status levels are Critical, Warning, Normal, Error, and Disabled. For example, type Critical to retrieve all health events that indicate a critical status.

Appliance

Specify the name of appliance. To run and save health event searches:

Access: Admin

1.

Select Analysis & Reporting > Searches > Health Events. The Search page appears.

2. Optionally, if you want to save the search, enter a name for the search in the Name field. If you do not enter a name, one is created automatically when you save the search. 3. Enter your search criteria. See Health Event Search Criteria on page 1410 for more information about the values you can enter for search criteria.

Version 4.7


1411


Chapter 34

4. Optionally, if you want to save the search so that other users can access it, disable the Save As Private check box. Otherwise, leave the check box selected to save the search as private. TIP! If you want to save a search as a restriction for restricted data users, you must save it as a private search. 5. You have the following options: •

Click Search to execute the search.

•


•

Click Save as New Search to save the search criteria. The search is saved and associated with your user account (if you selected Save As Private), so that you can run it at a later time.

For more information about searching, see the following sections: •

Loading a Saved Search on page 1412

•

Deleting a Saved Search on page 1412

Loading a Saved Search Requires: DC/MDC

If you have saved a search, you can load it, make any necessary modifications, and then execute the search. To load a saved search:

Access: Admin

1.


2. From the list of saved searches on the left of the page, select the search you want to load. 3. Click Load. The Defense Center loads the search. 4. If necessary, make any changes to the search constraints. 5. Click Search. The Defense Center lists the events that match your search constraints.

Deleting a Saved Search Requires: DC/MDC

If you have saved searches, you can delete them from the Search page. To delete a saved search:

Access: Admin

1.


Version 4.7


1412

Using Health Monitoring Using the Status Dashboard

Chapter 34

2. From the list of saved searches on the left of the page, select the search you want to delete. 3. Click Delete. The Defense Center deletes the selected search.

Using the Status Dashboard Requires: DC/MDC

The Dashboard page provides an at-a-glance view of current system status, including: •

whether any appliances have a current health status of Error, Critical, or Warning

•

recent intrusion event activity, categorized by impact, event type, or source or destination IP address

•

recent compliance activity, including compliance events, white list events, and summary views of the overall white list compliance of your network

IMPORTANT! Your browser session will not be automatically timed out while you are viewing the Dashboard page or the Health Monitor page. You can change the layout of the Dashboard page to meet your needs. You can move status indicators from one location on the page to another to highlight the indicators that are most pertinent to your system. You can also decide whether to include each of the available status indicators on the status page. IMPORTANT! The Dashboard on the Master Defense Center provides status information for the Master Defense Center itself and any managed Defense Centers.

Version 4.7


1413


Chapter 34

To view the Status Dashboard: Access: Admin

h

Select Analysis & Reporting > Event Summary > Dashboard. The Dashboard page appears.

TIP! You can change the time range for all the graphs and tables on the Dashboard. For more information on modifying event time ranges, see Setting Event Time Constraints on page 1169. For more information, see the following topics: •

Understanding Status Indicators on page 1414

•

Configuring the Status Dashboard on page 1421

Understanding Status Indicators Requires: DC/MDC

Version 4.7

Each of the status indicators on the Dashboard page summarizes information that can help you pinpoint problems with your Sourcefire 3D System at a glance. The Dashboard page presents some information in graphical format and some in


1414


Chapter 34

tabular format. The available indicators are listed in the Dashboard Status Indicators table. Dashboard Status Indicators

Version 4.7

For more information on the...

See...

Appliance Status table

Interpreting the Appliance Status Table on page 1416.

Events By Impact graph

Interpreting the Events by Impact Graph on page 1416.

Dropped Events graph

Interpreting the Dropped Events Graph on page 1417.

Appliance Status Summary graph

Interpreting the Appliance Status Summary Graph on page 1417.

White Lists Events graph

Interpreting the White List Events Graph on page 1418.

Compliance Events graph

Interpreting the Compliance Events Graph on page 1419.

Top 10 Non-Compliant Hosts graph

Interpreting the Top 10 Non-Compliant Hosts Graph on page 1419.

Network Compliance graph

Interpreting the Network Compliance Graph on page 1420.

Percent Network Compliance Over Time graph

Interpreting the Percent Network Compliance over Time Graph on page 1420.

Network Compliance Over Time graph

Interpreting the Network Compliance over Time Graph on page 1420.

Top 10 Most Active Events table

Interpreting the Top 10 Most Active Events Table on page 1421.

Top 10 Most Active Source IPs table

Interpreting the Top 10 Most Active Source IPs Table on page 1421.

Top 10 Most Active Destination IPs table

Interpreting the Top 10 Most Active Destination IPs Table on page 1421.


1415


Chapter 34

Interpreting the Appliance Status Table Requires: DC/MDC

The Appliance Status table indicates the number of appliances currently in each health status category. The counts reflect the compiled status counts for all appliances managed by the Defense Center plus the Defense Center. The overall status of an appliance indicates the highest level of severity status currently in effect among the health modules enabled in the health policy applied to that appliance. Changes in severity level occur when criteria configured in the health policy for a module are met or exceeded. If, for example, the CPU usage on the Defense Center changes from 85% to 95% and you have configured the CPU usage module to trigger a Warning status at the default threshold of 80% and a Critical status at the default threshold of 90%, the count for the Defense Center moves from the Warning column of the Appliance Status table to the Critical column. Available status categories, by severity, include: •

Error

•

Critical

•

Warning

•

Normal

•

Disabled

For more information on health appliance status categories, see Interpreting Health Monitor Status on page 1396.

Interpreting the Events by Impact Graph Requires: DC/MDC

The Events by Impact Graph provides a bar graph depicting the total number of intrusion events of each impact flag on all monitored appliances. Impact flags reflect the qualification of each intrusion event from IPS based on whether RNA deployed on the same segment detected a vulnerable service or open port on the target of the attack. If the targeted host is not vulnerable, the impact of the attack is low. However, if a targeted host is vulnerable, then the impact is high and you should act to mitigate the effects of the attack. The impact flags for events correspond to the impact flags determined through correlation of intrusion data, network discovery events, and vulnerability assessments. The graph includes a bar indicating the number of events that have occurred for each impact flag. The labels provided along the horizontal axis of the graph for each bar indicate the impact flag which each bar represents. The vertical axis of the graph corresponds to the number of events, so the height of each bar depicts the number of events in that impact flag category. TIP! For more information on impact flags, see Using Impact Flags to Evaluate Events on page 686.

Version 4.7


1416


Chapter 34

To view the number of events in each impact flag: Access: Data or Admin

h

Position your cursor over each bar in the Events by Impact graph. A tool tip appears, indicating the number of events for that impact flag.

To save a picture of the graph to include in a report: Access: Data or Admin

h

Right-click the graph and follow the instructions for your browser to save the image. For more information on using the health monitor, see Using the Health Monitor on page 1395.

Interpreting the Dropped Events Graph Requires: DC/MDC

The Dropped Events graph provides a bar graph depicting the total number of dropped events on all monitored appliances. A dropped event is notification that IPS has dropped certain malicious packets when they crossed your network, rather than allowing them to reach their intended target. You can configure drop rules, which control this behavior, by setting the rule state of specific intrusion rules to Drop rather than Enable or Disable. Note that IPS will only drop packets if you assign your IPS policy to IPS detection engines that use inline or inline with fail open interface sets. The graph includes a bar indicating the number of dropped events that have occurred. The vertical axis of the graph corresponds to the number of events, so the height of the bar depicts the number of events. TIP! For more information on drop rules, see Using the Drop Rule State on page 798. To view the number of dropped events:


h

Position your cursor over the bar in the Dropped Events graph. A tool tip appears, indicating the number of dropped events.


h


Interpreting the Appliance Status Summary Graph Requires: DC/MDC

Version 4.7

The Appliance Status Summary graph provides a pie chart indicating the percentage of appliances currently in each health status category. These percentages reflect the compiled status for all appliances managed by the Defense Center. The overall status of an appliance indicates the highest level of


1417


Chapter 34

severity status currently in effect among the health modules enabled in the health policy applied to that appliance. Changes in severity level occur when criteria configured in the health policy for a module are met or exceeded. If, for example, the CPU usage on the Defense Center changes from 85% to 95% and you have configured the CPU usage module to trigger a Warning status at the default threshold of 80% and a Critical status at the default threshold of 90%, the count for the Defense Center moves from the Warning segment of the Appliance Status Summary graph to the Critical segment. To view the count of appliances with each status: Access: Data or Admin

h

Position your cursor over each section of the Appliance Status Summary graph. A tool tip appears, indicating the system count.


h


To view more appliance status details: Access: Data or Admin

h

Click the graph to switch to the Health Monitor page. For more information on using the health monitor, see Using the Health Monitor on page 1395.

Available status categories, by severity, include: •

Error

•

Critical

•

Warning

•

Normal

•

Disabled

For more information on health appliance status categories, see Interpreting Health Monitor Status on page 1396.

Interpreting the White List Events Graph Requires: DC/MDC

Version 4.7

The White List Events Graph shows the number of white list events generated during the Dashboard’s time range. White list events are generated whenever an RNA event indicates that a host is out of compliance with a white list that is a part of an activated compliance policy.


1418


Chapter 34

You can configure the Dashboard to display the White List Events graph so that the events are separated by event priority, or you can keep the default, which is to combine all white list events regardless of priority. TIP! Position your cursor over each bar on the graph to view detailed statistics in a tool tip. For more information on compliance white lists and white list event priorities, see Using RNA as a Compliance Tool on page 340 and Setting Rule and White List Priorities on page 442.

Interpreting the Compliance Events Graph Requires: DC/MDC

The Compliance Events Graph shows the number of compliance events generated during the Dashboard’s time range. The Defense Center generates a compliance event when the activity on your network triggers a compliance rule within an activated compliance policy. You can configure compliance rules to trigger when a specific intrusion, RNA, RUA, host input, or RNA flow event occurs and the event meets criteria that you specify, or when your network traffic deviates from your normal network traffic pattern as characterized in an existing traffic profile. You can configure the Dashboard to display the Compliance Events graph so that the events are separated by event priority, or you can keep the default, which is to combine all compliance events regardless of priority. TIP! Position your cursor over each bar on the graph to view detailed statistics in a tool tip. For more information on compliance rules, including how to set their priority, see Configuring Compliance Policies and Rules on page 392.

Interpreting the Top 10 Non-Compliant Hosts Graph Requires: DC/MDC

The Top 10 Non-Compliant Hosts graph shows the 10 IP addresses that have the most compliance white list violations during the Dashboard’s time range. The graph indicates the number of violations for each host. You can configure the Dashboard to display a graph for any individual white list you configured, or you can keep the default, which is to combine statistics for all your white lists. TIP! Position your cursor over each bar on the graph to view detailed statistics in a tool tip.

Version 4.7


1419


Chapter 34

For more information on white lists, see Using RNA as a Compliance Tool on page 340.

Interpreting the Network Compliance Graph Requires: DC/MDC

The Network Compliance graph provides a pie chart indicating the percentage of appliances that are compliant, non-compliant, and not evaluated with your compliance white lists, based on the Dashboard’s time range. You can configure the Dashboard to display the graph for any individual white list, or you can keep the default, which is to combine statistics for all your white lists. TIP! Position your cursor over each section of the pie chart to view detailed statistics in a tool tip. For more information on white lists, see Using RNA as a Compliance Tool on page 340.

Interpreting the Percent Network Compliance over Time Graph Requires: DC/MDC

The Percent Network Compliance over Time graph shows you the percentage of appliances that are compliant with your compliance white lists, based on the Dashboard’s time range. This allows you to observe white list compliance trends over time. You can configure the Dashboard to display the graph for any individual white list, or you can keep the default, which is to combine statistics for all your white lists. For more information on white lists, see Using RNA as a Compliance Tool on page 340.

Interpreting the Network Compliance over Time Graph Requires: DC/MDC

The Network Compliance over Time graph shows you the number of appliances that are compliant, non-compliant, and not evaluated with your compliance white lists, based on the Dashboard’s time range. This allows you to observe white list compliance trends over time. You can configure the Dashboard to display the graph for any individual white list, or you can keep the default, which is to combine statistics for all your white lists. TIP! Position your cursor over any point on any of the lines on the graph to view detailed statistics in a tool tip. For more information on white lists, see Using RNA as a Compliance Tool on page 340.

Version 4.7


1420


Chapter 34

Interpreting the Top 10 Most Active Events Table Requires: DC/MDC

The Top 10 Most Active Events table indicates the 10 most active events for all IP addresses detected by your sensors. The event statistics used to evaluate the most active events include all events currently stored in the events database.

Interpreting the Top 10 Most Active Source IPs Table Requires: DC/MDC

The Top 10 Most Active Source IPs table indicates the 10 IP addresses that have generated the most traffic among all IP addresses detected by your sensors. The traffic statistics used to evaluate the most active source IP addresses include all traffic data currently stored in the database.

Interpreting the Top 10 Most Active Destination IPs Table Requires: DC/MDC

The Top 10 Most Active Destination IPs table indicates the 10 IP addresses that have received the most traffic among all IP addresses detected by your sensors. The traffic statistics used to evaluate the most active destination IP addresses include all traffic data currently stored in the database.

Configuring the Status Dashboard Requires: DC/MDC

Version 4.7

You can customize the default layout for the Dashboard page to meet your needs. Indicators can be added, removed, or moved to another location on the page.


1421


Chapter 34

To modify the Dashboard page layout: Access: Data or Admin

1.

On the Dashboard page, click Configure Dashboard. The Dashboard page reloads in configuration mode, with a drop-down list containing the available status indicators above each existing indicator.

2. To change an indicator, select the name of the indicator you want to replace it with from the drop-down list above the indicator. 3. To remove a indicator, select None from the drop-down list above the indicator. 4. To change the frequency with which the Dashboard page refreshes, type a different number of seconds in the Refresh Interval field at the bottom of the page. The minimum refresh interval is 30 seconds. 5. To save changes to the page, select Save Configuration. The Dashboard page reloads in configuration mode, reflecting any changes you made. 6. To return to viewing the Dashboard page in viewing mode, click Dashboard in the toolbar.

Version 4.7


1422

Chapter 34

Auditing the System

You can audit activity on your system in two ways. The appliances that are a part of the Sourcefire 3D System generate an audit record for each user interaction with the web interface, and also record system status messages in the system log. The following sections provide more information about the monitoring features that the system provides: •

Managing Audit Records on page 1424 describes how to view and manage system audit information.

•

Viewing the System Log on page 1429 describes how to view the system log, which contains system status messages.

TIP! Defense Centers and 3D Sensors with IPS also provide full-featured reporting features that allow you to generate reports for almost any type of data accessible in an event view, including auditing data. For more information, see Building and Generating Reports on page 1103.

IMPORTANT! The auditing features in this chapter apply to Nokia Defense Centers only. You must use the Network Voyager interface to view audit records for your Nokia sensor.

Version 4.7


1423

Auditing the System Managing Audit Records

Chapter 35

Managing Audit Records Requires: DC/MDC or 3D Sensor

Defense Centers and 3D Sensors log read-only auditing information for user activity. Audit logs are presented in a standard event view that allows you to view, sort, and filter audit log messages based on any item in the audit view. You can easily delete and report on audit information. The audit log stores a maximum of 100,000 entries. When the number of audit log entries exceeds 100,000, the appliance prunes the oldest records from the database to reduce the number to 100,000. For more information, see the following sections: •

Viewing Audit Records on page 1424

•

Understanding the Audit Log Table on page 1426

•


Viewing Audit Records Requires: DC/MDC or 3D Sensor

You can use the appliance to view a table of audit records. Then, you can manipulate the view depending on the information you are looking for. The predefined workflow includes a single table view of events. You can also create a custom workflow that displays only the information that matches your specific needs. For information on creating a custom workflow, see Creating Custom Workflows on page 1179. The Audit Log Actions table below describes some of the specific actions you can perform on an audit log workflow page. Audit Log Actions

Version 4.7

To...

You can...


find more information in Understanding the Audit Log Table on page 1426.

modify the time range used when viewing audit records

find more information at Setting Event Time Constraints on page 1169.






1424


Chapter 35

Audit Log Actions (Continued) To...

You can...




on a drill-down page that you created in a custom workflow, click a value within a row. Note that clicking a value within a row in a table view constrains the table view and does not drill down to the next page. TIP! Table views always include “Table View “ in the page name. For more information, see Constraining Events on page 1170.

delete audit records

use one of the following methods: • To delete some items, select the check boxes next to events you want to delete, then click Delete. • To delete all items in the current constrained view, click Delete All, then confirm you want to delete all the events.









To view audit records: Access: Admin

h

Select Operations > Monitoring > Audit. The first page of the default audit log workflow appears. If you created a custom audit log workflow and did not specify a default workflow, you must first select one. For information on specifying a default workflow, see Setting Event Preferences on page 35.

Version 4.7


1425


Chapter 35

Understanding the Audit Log Table Requires: DC/MDC or 3D Sensor

Each appliance generates an audit event for each user interaction with the web interface. Each event includes a time stamp, the user name of the user whose action generated the event, a source IP, and text describing the event. The fields in the audit log table are described in the Audit Log Fields table. Audit Log Fields Field

Description

Time

The time and date that the appliance generated the audit record.

User

The user name of the user that triggered the audit event.

Subsystem

The menu path the user followed to generate the audit record. For example, Operations > Monitoring > Audit is the menu path to view the audit log.

Message

The action the user performed. For example, “Page View” signifies that the user simply viewed the page indicated in the Subsystem, while “Save” means that the user clicked the Save button on the page.

Source IP

The IP address of the host used by the user.

Searching Audit Records Requires: DC/MDC or 3D Sensor

You can search audit records to find information specific to a user, a specific subsystem, or an audit record message. You may want to create searches customized for your network environment, then save them to re-use later. The search criteria you can use are described in the

Version 4.7


1426


Chapter 35

Audit Record Search Criteria table. Note that audit searches are case-insensitive. For example, searching for Analyst01 or analyst01 yields the same results. Audit Record Search Criteria Search Field

Description

Example

User

Enter the user name of the user who triggered the audit events you want to see. You can use an asterisk (*) as a wildcard character in this field.

jsmith returns all audit records involving the user jsmith.

Subsystem

Enter the full menu path a user would follow to generate the audit records you want to see. You can use an asterisk (*) as a wildcard character in this field.

Operations > Monitoring > Audit and *Audit both return audit records

Message

The action the user performed or the button the user clicked on the page. You can use an asterisk (*) as a wildcard character in this field.

that involve using the audit log.

*Audit* returns all of the above records, plus records that involve searching for audit records. Apply returns audit records where the user applied an intrusion policy. Save Rule returns audit records where the user saved a compliance rule. Page View returns audit records where the user viewed the page.

Time

Specify the date and time the audit record was generated. See Specifying Time Constraints in Searches on page 1130 for the syntax for entering time.

> 2006-01-15 13:30:00 returns all audit

Source IP

Enter the IP address of the host that you want to view audit records for.

172.16.1.37 returns all audit records

IMPORTANT! You must type a specific IP address. You cannot use IP ranges when searching audit logs.

records generated after January 15, 2006 at 1:30pm.

generated by a user from the 172.16.1.37 IP address.

For more information on searching, including how to load and delete saved searches, see Searching for Events on page 1124.

Version 4.7


1427


Chapter 35

To search for audit records: Access: Admin

1.

Select Analysis & Reporting > Searches > Audit Log. The Audit Log search page appears.

TIP! To search the database for a different kind of event, select it from the Table list. 2. Optionally, if you want to save the search, enter a name for the search in the Name field. If you do not enter a name, the web interface automatically creates one when you save it. 3. Enter your search criteria in the appropriate fields, as described in the Audit Record Search Criteria table. If you enter multiple criteria, the appliance returns only the records that match all the criteria. 4. If you want to save the search so that other users can access it, clear the Save As Private check box. Otherwise, leave the check box selected to save the search as private. TIP! If you want to save a search as a restriction for restricted data users, you must save it as a private search.

Version 4.7


1428

Auditing the System Viewing the System Log

Chapter 35


Click Search to start the search. Your search results appear in the default audit log workflow. If you created a custom audit log workflow and did not specify a preferred workflow, you must select one. For information on specifying a preferred workflow, see Setting Event Preferences on page 35.

•


•


Viewing the System Log Requires: DC/MDC or 3D Sensor

The System Log (syslog) page provides you with system log information for the appliance. The system log displays each message generated by the system. The following items are listed in order: •

date the message was generated

•

time the message was generated

•

host that generated the message

•

the message itself

IMPORTANT! System log information is local. For example, you cannot use the Defense Center to view system status messages in the system logs on your managed sensors. You can view system log messages for specific components by using the filter feature. For more information, see Filtering System Log Messages on page 1430.

Version 4.7


1429


Chapter 35

To view the syslog: Access: Maint or Admin

h

Select Operations > Monitoring > Syslog. The System Log page appears. The Defense Center version of the page is shown below.

Filtering System Log Messages Requires: DC/MDC or 3D Sensor

You can view system log messages for specific components by using the filter feature. Filtering allows you to search for specific messages based on content. The filter functionality uses the UNIX file search utility Grep, and as such, you can use most syntax accepted by Grep. This includes using Grep-compatible regular expressions for pattern matching. You can use a single word as a filter, or you can use Grep-supported regular expressions to search for content. WARNING! The System Log page does not allow the use of pipe characters for OR expressions. For example, if you use [word_1|word_2], you will receive an invalid filter error.

Version 4.7


1430


Chapter 35

The System Log Filter Syntax table shows the regular expression syntax you can use in System Log filters: System Log Filter Syntax Syntax Component

Description

Example

.

Matches any character or white space.

Admi. matches Admin, AdmiN, Admi1, and Admi&

[[:alpha:]]

Matches any alphabetic character.

[[:alpha:]]dmin matches Admin, bdmin, Cdmin, and so on.

[[:upper:]]

Matches any uppercase alphabetic character.

[[:upper:]]dmin matches Admin, Bdmin, Cdmin, and so on.

[[:lower:]]

Matches any lowercase alphabetic character.

[[:lower:]]dmin matches admin, bdmin, cdmin, and so on.

[[:digit:]]

Matches any numeric character.

[[:digit:]]dmin matches 0dmin, 1dmin, 2dmin, and so on.

[[:alnum:]]

Matches any alphanumeric character.

[[:alnum:]]dmin matches 1dmin, admin, 2dmin, bdmin, and so on.

[[:space:]]

Matches any white space, including tabs.

Feb[[:space:]]29 matches logs from

*

Matches one or more instances of the pattern it follows.

ab* matches ab, abb, abbb, abbbb, and so on. [ab]* matches ab, abab, ababab, and so on.

?

Matches zero or one instances.

ab? matches a or ab.

\

Allows you to search for a character typically interpreted as regular expression syntax.

alert\? matches alert?.

February 29th.

The System Log Filter Examples table shows some example filters you can use on the System Log page. System Log Filter Examples

Version 4.7

To search for all log entries that...

Use...

are generated on November 5

Nov[[:space:]]*5


1431


Chapter 35

System Log Filter Examples (Continued) To search for all log entries that...

Use...

contain the user name “Admin”

Admin

contain authorization debugging information on November 5

Nov[[:space:]]*5.*AUTH.*DEBUG

To search for specific message content in the system log: Access: Maint or Admin

1.

On the System Log page, enter a word or query in the Filter field. See the System Log Filter Syntax table on page 1431 and the System Log Filter Examples table on page 1431 for more information about the filter syntax you can use. IMPORTANT! Only Grep-compatible search syntax is supported. For example, you could search for all NTP-related system log messages by using ntp as a filter, or search for all messages generated in November by using Nov as a filter. You could view messages from November 27th by using Nov[[:space:]]*27 or Nov.*27, but you could not, however, use Nov 27 or Nov*27 to view these messages.

2. Optionally, to make your search case-sensitive, check Case-sensitive. (By default, filters are case-insensitive.) 3. Optionally, check Exclusion to search for all system log messages that do not meet the criteria you entered. 4. Click Go. The messages that match the filter appear.

Version 4.7


1432

Appendix B

Detected Operating Systems and Services

The RNA component of the Sourcefire 3D System detects a wide variety of operating systems, client applications, and services. The following sections provide a full list of what is detected: •

Detected Operating Systems on page 1433

•

Detected Client Applications on page 1436

•

Detected Services on page 1437

Detected Operating Systems Requires: DC + RNA

RNA detects the operating systems listed in the Detected Operating Systems table. Detected Operating Systems Operating System Apple Mac OS

Versions • OS 9.0-9.2 • OS X 10.1-10.5

Version 4.7

Caldera Linux

• 1.3

Cisco IOS

• 11 and 12

Cisco Catalyst

• 3500, 5500, and 6500


1433

Detected Operating Systems and Services Detected Operating Systems

Appendix A

Detected Operating Systems (Continued) Operating System

Versions

Debian Linux

• 2.2.20

FreeBSD

• 3.1 - 4.5 • 4.6, 4.6.2 • 4.7, 4.8 • 5.0 - 5.4

HP LaserJet

• 2100, 4100, and 8550

HP OpenVMS

• 7.x

HP-UX

• 10.2 • 11.0, 11.11

HP VMS MultiNet

• V4.2 (16)

IBM AIX

• 4.3.2 and earlier • 5.1 and 5.2

IBM z/OS

• V1.0-1.7

Linux

• 2.1.19-2.2.20* • 2.4 - 2.6**

Microsoft Windows

• 98, 98SE • ME • NT 4.0, including SP1, SP3, SP5, and SP6 • 2000 Professional, including SP1-SP4 • 2000 Server and Advanced Server • XP and XP Professional, including SP1 and SP2 • 2003 Server Standard, Enterprise, and Web Editions • Optimized for IIS • Vista

NetBSD

• 1.5.2, 1.6 • 2.0

Novell Netware

Version 4.7

• 5.0, 5.1, and 6.0


1434

Detected Operating Systems and Services Detected Operating Systems

Appendix A

Detected Operating Systems (Continued) Operating System OpenBSD

Versions • 2.4 - 2.8 • 3.0 - 3.3

SGI Irix

• 6.3 • 6.5, 6.5.12

Sun Solaris

• 5.7 - 5.10 Sparc • 5.8 - 5.10 Intel

*The Linux 2.1.19-2.2.20 kernels are used by a variety of operating systems, including but not limited to the following:

Operating Systems Identified as Linux 2.1.19-2.2.20 Red Hat 6.0

Mandrake 8.0

SuSE 7.2

Red Hat 7.0

Mandrake 7.2

Trustix 1.5

**The Linux 2.4-2.6 kernels are used by a variety of operating systems, including but not limited to the following:

Operating Systems Identified as Linux 2.4-2.6

Version 4.7

Knoppix 3.3

Red Hat 7.2

SuSE 7.3

Mandrake 8.1

Red Hat 7.3

SuSE 8.0

Mandrake 8.2

Red Hat 7.4

SuSE 8.1

Mandrake 9.0

Red Hat 8.0

SuSE 8.2

Mandrake 9.1

Red Hat 9.0

Trustix 2.0

Red Hat 7.1

Ubuntu 6.0


1435

Detected Operating Systems and Services Detected Client Applications

Appendix A

Detected Client Applications Requires: DC + RNA

RNA detects the client applications listed in the Detected Client Applications table. Detected Client Applications Application Type Instant Messaging Client

Client Applications • AOL Instant Messenger • Microsoft MSN Messenger • Skype • Yahoo! Messenger

HTTP Browser

• Konqueror • Microsoft Internet Explorer 4.01-7.0

SMTP Agent

• AOL • Apple Mail • KMail • Lotus Notes • Microsoft Outlook • Microsoft Outlook Express • Mutt • Qualcomm Eudora • Qualcomm Eudora Pro • SquirrelMail • Mozilla Thunderbird • Ximian Evolution

Version 4.7


1436

Detected Operating Systems and Services Detected Services

Appendix A

Detected Services Requires: DC + RNA

RNA detects the services listed in the Detected Services table. Detected Services

Version 4.7

RNA Service Name

Description

aim

AOL Instant Messenger service (AIM)

bgp

Border Gateway Protocol services (BGP)

bootps

Bootstrap Protocol services (bootps)

dcerpc

Distributed Computing Environment - Remote Procedure Call services (DCE-RPC)

domain

Domain Name Service (DNS) servers

exec

Remote execution services (exec, rexec)

ftp and ftp-data

File Transfer Protocol (FTP) services

http

Hypertext Transfer Protocol (HTTP/Web) services

imap

Internet Message Access Protocol (IMAP) mail servers

imap3

IMAP version 3 mail servers

ircd

Internet Relay Chat services

login

Login services (login, rlogin)

mysql

MySQL database services

netbios-dgm

NETBIOS Datagram Service

netbios-ns

NETBIOS Name Service

netbios-ssn

NETBIOS Session Service

nntp

Network News Transfer Protocol (NNTP) Internet News services

ntp

Network Time Protocol (NTP) services


1437

Detected Operating Systems and Services Detected Services

Appendix A

Detected Services (Continued)

Version 4.7

RNA Service Name

Description

pop3

Post Office Protocol Version 3 (POP3) mail services

printer

Printer services

radacct

Remote Authentication Dial-In User Service (radius) client services

radius

Remote Authentication Dial-In User Service

rfb

Remote Frame Buffer services (which may include remote desktop applications such as VNC or Bochs)

rsync

File synchronization services (rsync)

shell

Shell services (shell, rshell)

smtp

Simple Mail Transport Protocol (SMTP) service

snmp and snmp-trap

Simple Network Management Protocol (SNMP) service

ssh

Secure Shell services

ssl

Secure Sockets Layer services

sunrpc

Sun RPC services (which may include ToolTalk Server, cmsd, status, alis, rexd, mountd, nfs, portmap)

telnet

RFC 854 Telnet services

tftp

Trivial File Transfer Protocol (TFTP) services


1438

Glossary

3D Sensor

An appliance-based sensor that, as part of the Sourcefire 3D System, can run the IPS component, the RNA component, or both.

alert

A message that notifies you when an intrusion event, health event, RNA event, white list event, or compliance event is generated. You can send alerts to an external syslog server, a specific email address, or an SNMP trap server. See email alerting, SNMP alerting, and syslog alerting.

alert rule

An intrusion rule that, when triggered, generates an intrusion event and logs the details of the packet that triggered the rule. Compare with pass rule and drop rule.

audit log

A record of user interactions with the web interface. The audit log comprises audit events.

audit event

An event that describes a specific user interaction with the web interface. Each audit event contains a time stamp, the user name of the user whose action generated the event, a source IP address, and text describing the event. You can view audit events in the audit log.

banner

The first 256 bytes of the first packet detected by a service. A banner is collected only once, the first time a service is detected by RNA. Banners provide additional context to the information gathered by RNA.

bit mask

The notation used to identify which bits in an IP address correspond to the network address and subnet portions of the address.

Version 4.7


1439

bookmark to compliance rule

Glossary

bookmark

A saved link to a specific location and time in an event analysis. Bookmarks retain information about the workflow you are using, the part of the workflow you are viewing, the page number within the workflow you are viewing, the time range you selected, and any columns you disabled as well as any constraints you imposed. The bookmarks you create are available to all users with unrestricted data access.

bridge

A device that forwards traffic between network segments. RNA identifies bridges as network devices that communicate using Cisco Discovery Protocol (CDP) or Spanning Tree Protocol (STP). RNA may identify switches and routers as bridges.

Classless InterDomain Routing (CIDR) notation

A notation that defines IP address ranges by combining an IP address with a bit mask that signifies the subnet mask used to define the number of IP addresses in the specified range. For example, if you want to define the network described by 192.168.1.x with a subnet mask of 255.255.255.0, use 192.168.1.1/24, where 24 signifies the number of bits in the subnet mask.

client application

An application that runs on one host and relies on another host (a server) to perform some operation. For example, email clients are client applications that allow you to send and receive email. When RNA detects that a user on a host is using a specific client application to access another host, it reports that information in the host profile and network map, including the name and version (if available) of the client application.

client application event

Information that describes client application activity on monitored hosts. For each detected client application, RNA logs the IP address that used the application and when the application was last used, as well as the application name, version, and the number of times its use was detected.

clipboard

A holding area where you can copy up to 25,000 intrusion events that you can later add to incidents. The contents of the clipboard are sorted by the date and time that the events were generated.

complex condition

A complex way of qualifying compliance rules, flow trackers, host profile qualifications, and traffic profiles. A complex condition comprises at least two simple conditions, linked to each other with an AND or an OR operator.

compliance event

An event generated by the Defense Center when a compliance rule triggers. You can search, view, and delete compliance events and can configure the number of compliance events saved in the database. Note that white list events, generated by white list violations, are a special kind of compliance event.

compliance policy

Describes the network activity that constitutes a security policy violation, using compliance rules and compliance white lists. You can specify responses to each rule or white list within a policy.

compliance rule

Along with compliance white lists, one of the ways you can specify criteria that network traffic must meet in order to violate a compliance policy. You can use the

Version 4.7


1440

compliance white list to Defense Center

Glossary

Defense Center to configure compliance rules to trigger (and generate a compliance event) when a specific intrusion event, RNA event, or flow event occurs, or when your network traffic deviates from your normal network traffic pattern as characterized in a traffic profile. You can constrain compliance rules with host profile qualifications, flow trackers, snooze periods, and inactive periods. You can also configure the Defense Center to launch a response, such as an alert or remediation, when a compliance rule triggers. compliance white list

Along with compliance rules, one of the ways you can specify criteria that network traffic must meet in order to violate a compliance policy. You can use the Defense Center to configure compliance white lists to specify which operating systems, services, client applications, and protocols are allowed to run on the hosts in a specific subnet. You can also configure the Defense Center to launch a response, such as an alert or remediation, when a white list is violated. Note that a compliance white list is not associated with the white list of IP addresses that you can configure in certain remediations.

compliance white list event

See white list event.

custom fingerprint

See fingerprint.

custom table

A table you can construct that combines fields from two or more of the predefined tables delivered with the Sourcefire 3D System. For example, you could combine the host criticality information from the host attributes table with information from the flow data table to examine flow data in a new context. Custom tables include Sourcefire-defined custom tables, which are custom tables delivered with the Defense Center.

custom workflow

A workflow that you create to meet the unique needs of your organization. Compare with predefined workflow and, on the Defense Center, saved custom workflow.

dashboard

A feature on the Defense Center that provides you with a single-page overview of current system status that summarizes recent event activity as well as the health status of the Defense Center and its managed sensors.

data correlator

A program that generates events and creates the network map on the Defense Center, using the data collected by RNA.

decoder

A component of IPS that places sniffed packets into a format that can be understood by a preprocessor.

Defense Center

A central management point that allows you to manage sensors and automatically aggregate the events they generate. You can also push policies created on the Defense Center and software updates to managed sensors. If you manage 3D Sensors with IPS and RNA with a Defense Center, the Defense Center correlates intrusion events with host vulnerabilities and assigns impact

Version 4.7


1441

defragmentation policy to event

Glossary

flags to the intrusion events. Impact correlation lets you focus on attacks most likely to affect high-priority hosts. defragmentation policy

Describes how the IP defragmentation preprocessor (a component of IPS) should reassemble fragmented IP packets, based on the target host’s operating system.

detection engine

The mechanism that is responsible for analyzing the traffic on the network segment where a sensor is connected. A detection engine has two main components: an interface set and a detection resource. RNA uses RNA detection engines; IPS use IPS detection engines.

detection policy

See RNA detection policy.

detection resource

A portion of a sensor's computing resources used as part of a detection engine.

DNS cache

Temporary storage of previously resolved IP addresses. Configuring DNS caching allows you to resolve those IP addresses without performing additional lookups. This can reduce the amount of traffic on your network and speed the display of event pages.

drill-down page

An intermediate workflow page used to constrain event views. Generally, a drilldown page presents constraints that you can select to advance to a more narrowly constrained page or a table view.

drop event

An intrusion event generated when a drop rule triggers. Drop events are marked with black inline result flags on RNA compliance event views and IPS intrusion event views.

drop rule

An intrusion rule whose rule state is set to Drop. When a malicious packet triggers the rule, IPS drops the packet and generates an intrusion event (specifically, a drop event). You can only use a drop rule within an inline intrusion policy that is applied to detection engines that are deployed inline. Compare with alert rule and pass rule.

email alerting

The transmission of an alert as an email message.

Estreamer

See Event Streamer.

event

Information that is stored as an event. An event contains multiple fields that describe the activity that caused the event to be generated. IPS generates intrusion events, which also include drop events and preprocessor events. RNA generates network discovery events and flow events, as well as events that provide general information about your network topology: client application events, host events, host attributes, and service events. A vulnerability is also considered an RNA event. You can use the policy and response feature to configure your Defense Center to generate compliance events and white list events, as well as remediation status events. In addition, every appliance

Version 4.7


1442

Event Streamer to flow tracker

Glossary

generates records of user activity called audit events. The health monitor on the Defense Center also generates health events. Event Streamer

Also known as Estreamer, a component of the Sourcefire 3D System that allows you to stream event data from the Defense Center to external client applications.

event suppression

A feature that allows you to use suppress intrusion events when a specific IP address or range of IP addresses triggers a rule. Event suppression is useful for eliminating false positives. For example, if you have a mail server that transmits packets that look like a specific exploit, you can suppress events for the rules that are triggered by your mail server, so that you only see the events for legitimate attacks.

event thresholding

A feature that allows you to limit the number of times the system logs and displays an intrusion event, based on how many times the event is generated within a specified time period. Use event thresholding if you are overwhelmed with a large number of identical events.

external authentication

A method (such as LDAP authentication) that uses externally stored user credentials to authenticate user names and passwords when users log into Sourcefire 3D System appliances. Compare with internal authentication.

fail-open card

A network interface card that allows network traffic to pass through a 3D Sensor that uses IPS detection engines that are deployed inline, even if the appliance itself fails or loses power.

feature license

A license you can add to an appliance that enables additional features, including IPS, Intrusion Agents, and the ability to monitor a number of hosts with RNA.

fingerprint

An established definition that RNA compares against specific packet header values and other unique data from network traffic to identify a host's operating system. If RNA misidentifies or cannot identify a host's operating system, you can create a custom fingerprint that identifies the host.

flow data

See flow event.

flow event

An event generated when RNA detects that a connection between a monitored host and any other host is terminated. Flow events include information about the collected traffic, including the first packet of the transaction, the last packet of the transaction, the source IP address and port, the destination IP address and port, the number of packets and bytes sent and received by the monitored host, and the client application and URL involved in the transaction, if applicable.

flow tracker

One or more conditions that constrain a compliance rule so that after the rule’s initial criteria are met, RNA begins tracking certain flows. The rule then triggers only if the tracked flows meet additional criteria.

Version 4.7


1443

gateway to host attribute

Glossary

gateway

A device that acts as an entrance to and controls traffic within your organization’s network. When you set up your 3D Sensor or Defense Center, you must specify the IP address of the gateway device for your network.

GID (generator ID)

A number that indicates which component of the Sourcefire 3D System generated an intrusion event. GIDs help you analyze events more effectively by categorizing the type of event in the same way a rule’s SID offers context for the packets that trigger rules.

health alert

An alert generated by the Defense Center or Master Defense Center when a specific health event occurs.

health event

An event that is generated when one of the appliances in your deployment meets (or fails to meet) performance criteria specified in a health module. Health events indicate which module triggered the event and when the event was triggered.

health monitor

A feature that continuously monitors the performance of the appliances in your deployment. The health monitor uses health modules to test various performance aspects of the appliances. You configure the health monitor using a health policy.

health module

A test of a particular performance aspect of one of the appliances in your deployment. For example, you can monitor CPU usage or available disk space. You can configure health modules to generate health events and health alerts when the performance aspects they monitor reach a certain level.

health policy

The criteria used when checking the health of an appliance in your deployment. Health policies use health modules to indicate whether your Sourcefire 3D System hardware and software are working correctly. The Defense Center and Master Defense Center are delivered with default health policies; you can modify them or create your own.

high availability

A feature that allows you to designate redundant Defense Centers to manage groups of sensors. Event data streams from managed sensors to both Defense Centers and certain configuration elements are maintained on both Defense Centers. If your primary Defense Center fails, you can monitor your network without interruption using the secondary Defense Center.

hop

The trip a packet takes from one router or intermediate point to another in the network. RNA detects the number of network hops that exist between the sensors and the hosts they monitor, which provides you with information about the physical location the hosts on your network.

host

A device that is connected to a network and has a unique IP address. To RNA, a host is any identified network device that is not categorized as a bridge or a router.

host attribute

A tool you can use to provide information about hosts detected by RNA and to classify them in ways that are important to your network environment. For

Version 4.7


1444

host criticality to impact

Glossary

example, you could create a host attribute that designates the physical location of each host on your network. You can use and configure the two predefined host attributes, host criticality and notes, as well as create your own host attributes. In addition, when you create a compliance white list, RNA automatically creates a host attribute that indicates the compliance of the host. You can use host attributes in compliance rules and compliance white lists, and you can search for hosts with specific host attribute values. You also can generate reports based on host attributes. host criticality

A host attribute that indicates the business criticality (importance) of any given host detected by RNA. You can use host criticality values when searching for hosts or when creating compliance rules and compliance white lists.

host event

An event indicating that RNA has detected a host. RNA collects information about the hosts on monitored network segments. The information that RNA collects comprises that host’s host profile.

host profile

Collected information about a specific host detected by RNA, including its name, the name of the sensor that detected it, its distance in hops from the sensor that detected it, its operating system and the confidence that RNA has in reporting that operating system, its MAC addresses and TTL values, its host type, its host attributes, the protocols it uses, the services it is running, and its detected vulnerabilities.

host profile qualification

A constraint placed on a traffic profile or compliance rule. A host profile qualification within a compliance rule specifies that the Defense Center should generate a compliance event only if the host involved meets certain criteria. A host profile qualification within a traffic profile limits the hosts that are profiled.

host statistics

Information you can obtain about an appliance, including uptime, system memory usage, load average, disk usage, a summary of system processes, and, on the Defense Center, information about data correlator processes.

host view

The final page in workflows based on RNA events (with the exception of workflows based on vulnerabilities, which use the vulnerability detail page). The host view displays the host profiles of the hosts involved in the events you are viewing.

HTTP Inspection

A preprocessor that decodes and normalizes URI data sent to and received from web servers on your network, detects and generates events against possible URI-encoding attacks, and makes the normalized data available for additional rule processing. This is important because HTTP traffic can be encoded in a variety of formats, making it difficult for IPS to inspect packets accurately.

impact

The qualification of each intrusion event on a Defense Center based on whether RNA deployed on the same segment detected a vulnerable service or open port on the target of the attack. If the targeted host is not vulnerable, the impact of the

Version 4.7


1445

impact flag to Intrusion Agent

Glossary

attack is low. However, if the targeted host is vulnerable, then the impact is high and you should act to mitigate the effects of the attack. impact flag

For intrusion events, an indicator of the correlation between intrusion data, RNA network discovery events, and vulnerability information. A red impact flag means that the host is vulnerable to the attack represented by the intrusion event, orange means it is potentially vulnerable, and so on. Intrusion events detected on network segments not monitored by RNA have gray impact flags; this indicates that the Defense Center cannot determine the events’ impact.

inactive period

An interval during which a compliance rule does not trigger. You can configure an inactive period to occur daily, weekly, or monthly and to begin at a specified time and last a specified number of minutes. For example, you might perform a nightly Nessus scan on your internal network to look for vulnerabilities. In that case, you could set a daily inactive period on the affected compliance rules for the time and duration of your scan so those rules do not trigger erroneously. See also snooze period.

incident

One or more iintrusion events that you suspect are involved in a possible violation of your security policy. The Sourcefire 3D System provides incident-handling features that you can use to collect and process information that is relevant to your investigation of the incident.

inline

A type of interface set that allows you to deploy a 3D Sensor inline on a network. In this configuration, the IPS component can affect the traffic flow on the monitored network, including dropping malicious packets.

inline intrusion policy

An intrusion policy that you apply to an IPS detection engine configured with an inline or inline with fail open interface set. Inline intrusion policies can contain intrusion rules that not only generate intrusion events based on network traffic content, but that also can drop malicious packets and replace their content with benign alternatives. Compare with passive intrusion policy.

inline with fail open

A type of interface set that allows you to use a compatible fail-open card that allows network traffic to continue flowing if the appliance fails for any reason.

interface set

One or more sensing interfaces on a 3D Sensor that you can use to monitor network segments for one or more detection engines. You can use passive, inline, or inline with fail open interface sets.

internal authentication

An authentication method that stores user credentials in a local database. When a user logs into the appliance, the user name and password are checked against the information in the database. Compare with external authentication.

intrusion

A security breach, attack, or exploit that occurs on your network.

Intrusion Agent

Software that can be installed on certain Red Hat Linux, FreeBSD or Sun Solaris servers to transmit intrusion events generated by Snort to the Defense Center.

Version 4.7


1446

intrusion event to MAC address

Glossary

You can use the Defense Center to aggregate event information from Intrusion Agents with data from 3D Sensors with IPS. intrusion event

A record of the network traffic that violated an intrusion policy. Intrusion event data includes the date, time, and the type of exploit, as well as other contextual information about the source of the attack and its target.

intrusion policy

Either an passive intrusion policy or an inline intrusion policy. Intrusion policies include a variety of components that you can configure to inspect your network traffic for intrusions and policy violations. These components include preprocessors; intrusion rules that inspect the protocol header values, payload content, and certain packet size characteristics; and tools that allow you to control how often events are logged and displayed.

intrusion rule

A set of keywords and arguments that, when applied to captured network traffic, identify potential intrusions, policy violations, and security breaches. IPS compares packets against the conditions specified in each rule and, if the packet data matches all the conditions specified in the rule, the rule triggers and generates an intrusion event. Intrusion rules include alert rules, drop rules, and pass rules.

IP address

A 32-bit number, usually represented in dot notation (for example, 192.168.34.166), that identifies the host that sends or receives packets on the Internet or on the local network.

IPS

A component of the Sourcefire 3D System, separately licensable on 3D Sensors, that provides intrusion detection and prevention capabilities. If you configure a 3D Sensor with IPS with an inline or inline with fail open interface set and use an inline intrusion policy, you can alert on and drop malicious traffic. If instead you use the IPS component with a passive interface set and a passive intrusion policy, then the IPS component can only alert on malicious traffic and cannot affect the network traffic flow.

LDAP authentication

A form of external authentication that verifies user credentials by comparing them to a Lightweight Directory Access Protocol (LDAP) directory stored on an LDAP directory server.

link state propagation mode

An option you can enable for an inline interface set. When this option is enabled and one of the interfaces goes down, the other interface in the set is automatically brought down within a few seconds. When the first interface comes back up, the second interface is also brought up automatically. This feature is not available for fiber interface cards.

MAC address

Media Access Control address. A MAC address is a NIC’s (network interface card’s) unique hardware address. RNA detects the MAC addresses of the NICs on the hosts, bridges, and routers on your network.

Version 4.7


1447

managed sensor to object, for import or export

Glossary

managed sensor

A 3D Sensor, Intrusion Agent, or software sensor configured and managed by a Defense Center.

management interface

The network interface that you use to administer the Defense Center. In most installations, the management interface is connected to an internal, protected network. Compare with sensing interface.


A special-purpose appliance that is capable of aggregating intrusion events and compliance events from up to ten other Defense Centers. A Master Defense Center is also able to collect health status from its managed Defense Centers.

Nessus

An open source vulnerability scanner developed through the Nessus Project (http://www.nessus.org/) that uses Nessus plugins to test for vulnerabilities on the hosts that it scans.

Nessus plugin

A Nessus script written in the Nessus Attack Scripting Language (NASL) that tests for a specific vulnerability on your system. Over 9000 Nessus plugins exist.

Nessus plugin family

A group of Nessus plugins of a particular type. The Sourcefire 3D System integration with Nessus allows you to select the plugins used to scan by enabling or disabling plugin families.

Nessus scan

A network scan for vulnerabilities that emulates the actions of an attacker. Nessus scans use plugin families (see Nessus plugin family) to test for specific vulnerabilities on your network. You can manually run Nessus scans, or you can schedule periodic scans. Within a compliance policy, you can configure a Nessus scan as a response (or remediation) to a compliance event or white list event.

network discovery event

A kind of RNA event that communicates the details of changes to the hosts on your monitored network. New events are generated for newly discovered network features, and change events are generated for any change in previously identified network assets. Settings in the system policy determine the types of network discovery events that are stored in the RNA database.

network map

A detailed representation of your network generated by RNA. The network map allows you to view your network topology in terms of the hosts, bridges, and routers running on your network as well as their associated host attributes, services, and vulnerabilities.

NTP

Network Time Protocol. NTP uses Coordinated Universal Time (UTC time) to synchronize the computer clocks in a network. You can synchronize the Defense Center’s time with an NTP server. You can also configure a Defense Center as an NTP server so that managed sensors can synchronize time with it.

object, for import or export

A policy or rule that is created on an appliance and can be exported from that appliance and imported by another appliance. Depending on the type of appliance and the components you are licensed to use, you can import and export system

Version 4.7


1448

packet to policy violation

Glossary

policies, intrusion policies, custom intrusion rules and rule classifications, RNA detection policies, and health policies. packet

A unit of data routed between a source and a destination on a network. When data travels from one place to another on a network, the file is divided into chunks of an efficient size, called packets, for routing. The packets that comprise a single file may travel different routes through the network, but can be reassembled into the original file at the receiving end. If you are licensed for the IPS component, you can view the portion of a packet that was captured as part of an intrusion event.

packet view

A type of workflow page that provides detailed information about the packet that triggered an intrusion rule or the preprocessor that generated an intrusion event. The packet view is the final page in workflows based on intrusion events.

pass rule

An intrusion rule that, when triggered, does not generates an intrusion event and does not log the details of the packet that triggered the rule. Pass rules allow you to prevent packets that meet specific criteria from generating an event in specific situations, as an alternative to disabling the intrusion rule. Compare with alert rule and drop rule.

passive

A type of interface set that allows you to deploy a 3D Sensor passively on a network. In this configuration, the IPS component cannot affect the traffic flow, and should be used with a passive intrusion policy.

passive intrusion policy

An intrusion policy applied to an IPS detection engine configured with a passive interface set, although you can apply a passive intrusion policy to an IPS detection engine that uses an inline or inline with fail open interface set. Compare with inline intrusion policy.

PCRE

Perl-compatible regular expression. You can search packet payloads for content using PCREs. This is useful if you want to search for content that could be displayed in a variety of ways; the content may have different attributes that you want to account for in your attempt to locate it within a packet’s payload.

policy

A mechanism for applying settings to an appliance or detection engine. See intrusion policy, passive intrusion policy, inline intrusion policy, defragmentation policy, compliance policy, RNA detection policy, health policy, system policy, and security policy.

policy and response

A feature you can use to build a compliance policy that responds in real-time to threats on your network. In addition, the remediation component of policy and response provides a flexible API that allows you to create and upload your own custom remediation modules to respond to policy violations.

policy violation

A security breach, attack, exploit, or other misuse of your network as detected by a compliance policy.

Version 4.7


1449

port to protected network

Glossary

port

The endpoint of a logical connection on a TCP or UDP network. Each port on a host has a number, which identifies the type of port. Many services have default ports; for example, HTTP traffic typically uses port 80. TCP and UDP use port numbers to separate data transmissions on the same network interface on the same host. With IPS, when you tune your intrusion policy, you can define, in both variables and rules, specific port numbers, such as ports susceptible to shell code exploits, HTTP (or web server) ports, and database server ports. This lets you specify the level of granularity of inspection so that rules execute against ports appropriate to your network needs.

portscan

A form of network reconnaissance that is often used by attackers as a prelude to an attack. In a portscan, an attacker sends specially crafted packets to a targeted host. By examining the packets that the host responds with, the attacker can often determine which ports are open on the host and, either directly or by inference, which services are running on these ports.

predefined table

A database table delivered with the Sourcefire 3D System. You can use the web interface to view the event information in the predefined tables. Predefined tables cannot be modified. Compare with custom table.

predefined workflow

A workflow delivered with the Sourcefire 3D System. You cannot modify predefined workflows. Compare with custom workflow and saved custom workflow.

preprocessor

A feature of IPS that normalizes traffic and helps identify network layer and transport layer protocol anomalies by identifying inappropriate header options, defragmenting IP datagrams, providing TCP stateful inspection and stream reassembly, and validating checksums. Preprocessors can also render specific types of packet data in a format that the detection engine can analyze; these preprocessors are called data normalization preprocessors, or application-layer protocol preprocessors. Normalizing application-layer protocol encoding allows the detection engine to effectively apply the same content-related rules to packets whose data is represented differently and obtain meaningful results. Preprocessors generate preprocessor events whenever packets trigger preprocessor options that you configure.

preprocessor event

A type of intrusion event that is generated when a packet triggers specified preprocessor options. Preprocessor events can help you detect anomalous protocol exploits.

private search

A named set of search terms that is tied to your user account. Only you and users with Admin access can use your private searches.

protected network

Your organization’s internal network that is protected from users of other networks by a device such as a firewall. Many of the intrusion rules delivered with the Sourcefire 3D System use variables to define the protected network and the unprotected (or outside) network.

Version 4.7


1450

remediation to RNA event

Glossary

remediation

An action that mitigates potential attacks on your system. You can configure remediations and, within a compliance policy, associate them with compliance rules and compliance white lists so that when they trigger, the Defense Center launches the remediation. This not only can automatically mitigate attacks when you are not immediately available to address them, but also can ensure that your system remains compliant with your organization’s security policy. The Defense Center ships with predefined remediation modules: three that are designed for a particular firewalls and routers, and a fourth that lets you perform Nessus scans. You also can use a flexible API to create custom remediations.

remediation status event

An event generated when a remediation is launched.

replace rule

When using an inline IPS detection engine, you use the replace keyword in a custom standard text rule to replace a specific string with exactly the same number of characters. This allows you to replace the content of malicious packets with benign alternatives. Only the first instance of the content found by the rule is replaced. The sensor automatically updates the packet checksum so that the destination host can receive the packet without error.

report profile

A template for an event report. You can create and save custom report profiles. You can then manually run reports based on the profiles, or schedule the Sourcefire 3D System to generate reports automatically. You can use report profiles to add your company logo to reports, define the set of events that appear, specify the amount of detail, and specify the report’s output file format.

response

A reaction to a compliance policy violation—either an alert or a remediation.

RNA

A component of the Sourcefire 3D System that is installed by default on the 3D Sensor and that passively analyzes your network traffic to provide you with a complete, persistent view of your network. RNA identifies new and changed hosts on your network as well as tracks the sessions involving monitored hosts. For each detected host, RNA discovers the services and client applications that they use as well as vulnerabilities to which the host is susceptible. Note that you must add a feature license in the form of an RNA host license on the Defense Center that manages the sensor before you can view RNA data.

RNA detection policy

A policy that you apply to RNA detection engines that specifies the kinds of data RNA collects, as well as the network segments each RNA detection engine monitors.

RNA event

An event generated by RNA. RNA events include network discovery events, which communicate the details of changes to the hosts on your monitored network, and flow events, which are records of sessions involving monitored hosts. RNA events also include client application events, host events, host attributes, and service events, which provide general information about your network topology. A vulnerability is also considered an RNA event.

Version 4.7


1451

RNA Visualizer to service

Glossary

RNA Visualizer

A client-side application that generates a three-dimensional model of your network architecture based on accumulated RNA data and, when using an Event Streamer connection, provides real-time notification of network changes, impact flags, and compliance policy violations. See your sales representative for more information about RNA Visualizer.

router

A network device, located at a gateway, that forwards packets between networks. RNA identifies network devices as routers if they are detected communicating using CDP or if they meet other qualifying criteria. For example, if multiple hosts appear to be using the same MAC address, that MAC address is often identified as the router to which the multiple hosts are connected.

rule

A construct that provides criteria against which network traffic is examined. Rules can detect a variety of intrusions, attacks, exploits, and suspicious traffic. See compliance rule, intrusion rule, alert rule, pass rule, and drop rule.

rule state

Whether an intrusion rule is enabled, disabled, or set to Drop within an intrusion policy. If you enable a rule, it is used to evaluate your network traffic; if you disable a rule, it is not used. A drop rule drops any packets that trigger the rule; note that you can set the Drop rule state only in an inline intrusion policy.

saved custom workflow

A custom workflow that is based on a custom table and delivered with the Defense Center. Unlike predefined workflows, you can modify saved custom workflows.

scheduled task

An administrative task that you can schedule to run once or at recurring intervals. Depending on the appliance where you are creating the task, you can schedule tasks to run backups, apply intrusion policies, generate reports, download and install SEUs, run Nessus scans and synchronize Nessus plugins, download and install software and vulnerability database updates, and push downloaded updates to managed sensors.

security policy

An organization's guidelines for protecting its network. For example, your security policy might forbid the use of wireless access points. A security policy may also include an acceptable use policy (AUP), which provides employees with guidelines of how they may use their organization’s systems. For example, your AUP might forbid the use of instant messaging client applications.

sensing interface

A network interface on a sensor that you use to monitor a network segment. You can connect sensing interfaces to your network in various ways. How you plan to deploy your detection engines (passively or inline) affects how you connect them to your network. Compare with management interface.

sensor group

On the Defense Center, a logical group that can contain or more managed sensors so you can more readily manage them. For example, you can easily apply a system policy to, or install updates on, multiple sensors at once.

service

Work performed by a server. NTP, SSH, HTTP, and AIM are examples of services.

Version 4.7


1452

service event to Snort

Glossary

service event

An event indicating that RNA has detected a service running on a specific host. RNA collects information about all services run by hosts on monitored network segments. The information that RNA collects includes the name of the service, the protocol used by the service, the IP address of the host running a service, and the port on which the service is running.

SEU (Security Enhancement Update)

An as-needed product update that contains new and updated standard text rules and shared object rules. In addition, SEUs can provide your Defense Centers and 3D Sensors with an updated version of Snort, as well as features such as new preprocessors and decoders.

shared object rule

An intrusion rule delivered as a binary module compiled from C source code. You can use shared object rules to detect attacks in ways that standard text rules cannot. You cannot modify the rule keywords and arguments in a shared object rule; you are limited to either modifying variables used in the rule, or modifying aspects such as the source and destination ports and IP addresses and saving a new instance of the rule as a custom shared object rule. Shared object rules have a GID (generator ID) of 3.

SID

A unique identifying number assigned to each intrusion rule. When you create a new rule or modify an existing standard text rule, it is given a SID (Signature ID, also called Snort ID) of 1,000,000 or greater. The SIDs for shared object rules and standard text rules delivered with the Defense Center are lower than 1,000,000. Also, preprocessors and decoders use SIDs to identify the different types of packets they detect.

simple condition

A single constraint placed on a compliance rule, flow tracker, host profile qualification, or traffic profile. You can link simple conditions with other simple or complex conditions using AND or OR operators.

SNMP alerting

The transmission of an alert as an SNMP trap. Each event SNMP trap contains information identifying the server's name, the sensor’s IP address, and the event data.

SNMP trap

A message sent by a network device on UDP port 162 using the simple network management protocol (SNMP) when errors or specific events occur on the network. See also SNMP alerting.

snooze period

An interval specified in seconds, minutes, or hours after a compliance rule triggers during which the Defense Center stops firing that rule, even if the rule is violated again during the interval. When the snooze period has elapsed, the rule can trigger again (and start a new snooze period). See also inactive period.

Snort

An open-source intrusion detection system that performs real-time traffic analysis and packet logging on IP networks. Snort can perform protocol analysis, content searching and matching, and can detect a variety of attacks and probes. Snort uses a flexible rules language to describe network traffic that it should collect or

Version 4.7


1453

Sourcefire-defined custom table to system settings

Glossary

pass. The IPS detection engines use Snort to test packets against decoders, preprocessors and intrusion rules. Sourcefire-defined custom table

A table that is delivered with the Defense Center that contains fields from two or more predefined tables.

standard text rule

An intrusion rule created based on the identifiers, keywords and arguments available in the rule editor. You can create your own custom standard text rules and modify existing standard text rules provided by Sourcefire. A standard text rule has a GID (generator ID) of 1.

stateful inspection

A preprocessor that makes sure that only packets that are part of a TCP session established with a legitimate three-way handshake between a client and server can generate intrusion events. This allows analysts to focus on these events rather than the volume of events caused by denial of service (DoS) attacks like stick or snot.

stream reassembly

A preprocessor that IPS uses to collect and reassemble all of the packets that are part of a TCP session’s server-to-client or client-to-server communication stream. Stream reassembly allows the detection engine to inspect the stream as a single entity rather than only the individual packets, which allows the detection engine to identify stream-based attacks.

subnet mask

A bit mask used to identify which bits in an IP address correspond to the network address, and which correspond to the subnet portion of the address.

suppression

See event suppression.

switch

A multiport bridge.

syslog

A logging system, also called the system log, used by many operating systems. You can configure the Defense Center to perform syslog alerting.

syslog alerting

The transmission of an alert as a message to an external syslog. All syslog messages include both a facility and a priority level. The facility indicates the subsystem (for example, FTP, NTP, or MAIL) that created the message and the priority defines the importance of the message.

system policy

Settings such as access configuration, authentication profiles, database limits, DNS cache settings, the mail relay host, a notification address for database prune messages, language selection (English or Japanese), login banner, RNA settings, and time synchronization settings.

system settings

Settings that are specific to a single appliance, such as appliance name, IP address, time settings, licensing, and remote management settings. You can also use the system settings pages to shut down or reboot an appliance and to restart its software.

Version 4.7


1454

table view to Unified file

Glossary

table view

A type of workflow page that displays event information. Table views include a column for each of the fields in the database. For example, the table view of intrusion events includes columns such as Time, Priority, Impact Flag, Source IP, Destination IP. As another example, the table view of RNA network discovery events includes such columns as Time, Event, IP Address, MAC Address, and so on. Generally, you use drill-down pages to constrain the events you want to investigate before moving to the table view that shows you the details about the events you are interested in. The table view is the next to last page in predefined workflows; advancing from the table view leads to the packet view (for workflows based on intrusion events), the host view (for workflows based on RNA events), or the vulnerability detail page (for workflows based on vulnerabilities).

task queue

A queue of jobs that the Defense Center needs to perform. When you apply a policy, push updates, install software, and perform other long-running jobs, the jobs are queued and their status reported on the Task Status page. The Task Status page provides a detailed list of jobs and refreshes every ten seconds to update their status.

three-way handshake

The process two hosts use to establish a TCP/IP connection. A three-way handshake occurs when the originating host sends a SYN (synchronization) packet to the destination host. The destination then sends its own SYN packet and an ACK (acknowledgement) packet. The originator then returns an ACK which acknowledges the SYN/ACK packets the destination sent. With IPS, you can configure intrusion rules evaluate the data in established TCP sessions only (where a three-way handshake has occurred) or on all traffic, including orphaned packets.

thresholding

See event thresholding.

traffic profile

A profile of the traffic on your network, based on flow data collected by RNA over a time span that you specify. You can create profiles using all the traffic on a monitored network segment, or you can create more targeted profiles using criteria based on the data in flow events. Then, you can use the policy and response feature to detect abnormal network traffic by evaluating new traffic against an existing profile.

transparent inline mode

A setting that allows 3D Sensors configured with inline interface sets that forward packets regardless of whether they contain MAC addresses that are valid for the monitored network.

unidentified host

A host whose operating system cannot be identified because RNA has not yet gathered enough information about the host. Compare with unknown host.

unknown host

A host whose traffic has been analyzed by RNA, but whose operating system does not match any known fingerprints. Compare with unidentified host.

Unified file

A binary file format that the Sourcefire 3D System uses to log event data.

Version 4.7


1455

UTC time to white list event

Glossary

UTC time

Coordinated Universal Time. Also known as Greenwich Mean Time (GMT), UTC is the standard time common to every place in the world. The Defense Center uses UTC, although you can set the local time using the Time Zone feature.

variable

A representation of a value that is commonly used in intrusion rules. The Defense Center uses pre-configured variables to define networks and port numbers. Rather than hard-coding these values in multiple rules, to tailor a rule to accurately reflect your network environment, you can change the variable value. You can use a variable within an intrusion policy or a specific IPS detection engine.

VLAN

A virtual local area network. VLANs map hosts not by geographic location, but by some other criterion (such as by department or primary use). This is useful if you want to separate hosts into small, logical network segments. A host’s host profile shows any VLAN information associated with the host.

vulnerability

A description of a specific compromise to which a host is susceptible. The Defense Center provides information on the vulnerabilities to which each of your hosts is vulnerable in the hosts’ host profiles. In addition, you can use the vulnerabilities network map to obtain an overall view of the vulnerabilities that RNA has detected on your entire monitored network. If you deem that a host or hosts is no longer vulnerable to a specific compromise, you can deactivate, or mark as invalid, a specific vulnerability.

vulnerability database

A database of known vulnerabilities to which hosts may be susceptible. The database includes such technical details as vulnerability title and identification number, technical details, whether any exploits are known to take advantage of the vulnerability, known solutions, and so on. RNA correlates the operating system and services detected on each host with the vulnerability database to help you determine whether a particular host increases your risk of network compromise.

vulnerability detail page

A page in a workflow that provides information about a specific vulnerability, including technical details and known solutions. The vulnerability detail page is the final page in workflows based on vulnerabilities.

white list

Either a compliance white list or a list of IP addresses that you can configure within a remediation to exempt the IP addresses from some kind of action. For example, you could configure a firewall-based remediation to block all hosts that trigger a specific compliance rule, with the exception of hosts specified in a white list.

white list event

An event generated when RNA detects that a valid target host has become non-compliant with a compliance white list. For example, you can configure the Defense Center to generate a white list event when RNA detects a new non-compliant service running on a target host. Note that a white list event is a special kind of compliance event.

Version 4.7


1456

whois to workflow

Glossary

whois

A mechanism for finding contact and registration information for IP addresses. If your Defense Center is connected to the Internet, you can use the web interface to look up information about an IP address using the whois feature, which uses ARIN's (American Registry for Internet Numbers) WHOIS service.

workflow

A series of pages you can use to view and evaluate events by moving from a broad view of event data to a more focused view that contains only the events of interest to you. Workflows can include three types of pages, each of which performs a unique function: drill-down pages, table views, and a final page (which could be, depending upon the type of analysis you are performing, a packet view, host view, or vulnerability detail page).IPS provides two categories of workflows: predefined workflows and custom workflows. The Defense Center provides three categories of workflows: predefined workflows, custom workflows, and saved custom workflows.

Version 4.7


1457

Index

Symbols $AIM_SERVERS 780 $DNS_SERVERS 780 $EXTERNAL_NET 780 $HOME_NET 780 $HTTP_PORTS 780 $HTTP_SERVERS 781 $ORACLE_PORTS 781 $SHELLCODE_PORTS 781 $SMTP_SERVERS 781 $SNMP_SERVERS 781 $SQL_SERVERS 781 $TELNET_SERVERS 781 %U encoding (HTTP Inspect option) 895

Numerics 3D Sensors 26, 27 disabling communications 62 health policy 1361 host name 62, 63 management concepts 45 managing 44, 48 restarting 62

Version 4.7

sensor attributes 59 sensor information 60 Sensors page 49 stopping 62 time sync 63 unregistering 70

A accessing the appliance 30, 32 ack packet view 684 rule keyword 988 Active Directory server user accounts 1276 active scanning 571, 591 analyzing results 629, 630 monitoring scans 626 Nmap 578 Nmap scans 572 scan results 625 searching for scan results 627 selecting a scanner 572 add scan result (RNA event type) 224 Additional Information (vulnerability detail) 198


1458

Index additional MAC detected (RNA event type) 220 Address Resolution Protocol 642 Admin access 1283 alerting compliance responses 457 creating alerts 460 creating syslog alerts 460 impact flag alerting 470 RNA events 468 SNMP alerting 722 alternate timeout (stream 5 option) 885 any, in variables and intrusion rules 775 appliance groups 96 creating 96 deleting 97 editing 97 appliance heartbeat monitoring 1356, 1367 appliance information 60, 1213 application layer decoders 889 ARP 642 ARP (packet view) 683 ASCII encoding (HTTP Inspect option) 895 asn1 (rule keyword) 997 auditing audit records 1424 field descriptions 1426 introduction 1423 predefined workflows 1159 searching 1426 understanding 1426 viewing 1424 authentication objects creating 1266 deleting 1281 editing 1280 RUA 1076 authentication profiles 1194 available exploits (vulnerability detail) 198, 270

B Back Orifice detecting 932 generator ID 852 Back Orifice Detector SIDs 854 backup and restore 1239 remote backups 1244

Version 4.7

scheduling backups 1302 backup files creating 1240 location 1243 restoring 1245 backup profiles 1243 banners (detected services) 190 bare byte UTF-8 (HTTP Inspect option) 895 base 36 encoding (HTTP Inspect option) 895 blacklists health monitoring 1386, 1389 RNA recommended rules 829 system settings 1213, 1230 bookmarks 1177 creating 1177 deleting 1178 viewing 1178 bridges (on the network map) 155 browser requirements 30 Bugtraq ID network map 158 vulnerability detail 197, 270 byte_jump (rule keyword) 968 using in SID 1965 1040, 1041 byte_test (rule keyword) 971 using in SID 1965 1042

C can 637 capture banners (RNA policy option) 141 capture HTTP URLs (RNA policy option) 141 Check Point FW-1 473, 730 Check Point OPSEC SAM 473 activating the SAM client 744 adding the OPSEC instance 477 certificate creation 734 clearing responses 741 configuring the sensor 734 creating the OPSEC application 474, 730 disabling responses 744 filter options 742 firewall responses 738 FWHosts 742 intrusion event responses 730 OPSEC block 481, 484, 487, 490 viewing OPSEC debug messages 745 viewing SAM client information 745


1459

Index checksum packet view 683, 685 validation 864 CIDR notation in event searches 1131 in variables and intrusion rules 775 Cisco IOS routers adding a Cisco IOS instance 494 configuring remediations 493 IOS block 496, 498, 499, 500 Cisco PIX firewalls adding a Cisco PIX instance 502 Cisco PIX block 504, 506 remediations 501 classtype (rule keyword) 958 using in sample rule 1022 client application detection (RNA policy option) 141 client application timeout (RNA event type) 220 client application timeout (RNA settings) 1205 client applications field descriptions 264 host profiles 193 introduction 261 searching 265 viewing 262 white lists 362 client fingerprints 537 client ports (stream 5 reassembly option) 886 client requirements 30 clientonly (stream 4 reassembly option) 880 clipboard 706 clipboard reports 696 copying events 668, 669, 674 deleting intrusion events 698 introduction 695 code (packet view) 686 comments (in intrusion rules) 1013 communications channel 1223 compliance events aggregating 76 field descriptions 450 introduction 447 predefined workflows 1156 searching 452 understanding 450 viewing 447 compliance policies activating and deactivating 446 adding responses 443 adding rules 441 adding white lists 441

Version 4.7

creating 439 deleting 446 editing 446 email alerts 464 introduction 392 managing 445 Nessus scans 506 remediations 471 response groups 530 responses 456 setting rule and white list priorities 442 SNMP alerts 465 compliance responses 468 activating and deactivating alerts 468 adding to rules and white lists 443 alerts 457 creating alerts 460 creating syslog alerts 460 deleting alerts 467 editing alerts 467 email alerting 464 introduction 456 Nessus scans 506 response groups 530 SNMP alerts 465 compliance rules adding to compliance policies 441 building rules 429 conditions 433, 435 creating 394 creating rule groups 438 deleting 438 deleting rule groups 439 editing 437 flow data triggers 398 flow trackers 415 host profile qualification triggers 412, 427 host profile qualifications 411 inactive periods 428 introduction 392 intrusion event triggers 401 managing 437 RNA event triggers 402 RUA 426 rule groups 438 snooze periods 428 traffic profile triggers 406 triggers 396 velocity data triggers 407 compliance white lists, see white lists compound constraints 1173


1460

Index conditions (in compliance rules) 433, 435 confidence 227 detected services 190 host profile 178 host view 236 confidence (detected services) 188 constraining regular expressions 942 content (rule keyword) 962 in rule 1965 1043 using in sample rule 1027 context menus 39 correlator process 1344 counts, in the packet view 680 CPU usage monitoring 1356, 1368 creating alerts 460 authentication objects 1266 backup files 1240 backup profiles 1243 bookmarks 1177 compliance policies 439 compliance rule groups 438 compliance rules 394 custom service detectors 553 custom tables 1140 custom workflows 1179 Defense Center groups 96 detection engine groups 109 detection engines 105 email alerts 464 health monitor alerts 1391 health policies 1364 incidents 712 inline intrusion policies 752 interface sets 116 intrusion event suppressions 771 intrusion rules 1008 Nessus remediations 615 Nessus scan instances 612 Nessus scan targets 614 Nessus scans 506 passive intrusion policies 756 report profiles 1112 response groups 530 sample intrusion rules 1020 sensor groups 57 shared host profiles 371 SNMP alerts 465 syslog alerts 460 system policies 1190 traffic profiles 319

Version 4.7

user accounts 1283 user-defined host attributes 203 variables for intrusion rules 784 white list targets 355 white lists 350 criticality 201 host view 235 CSV reports 1115 custom fingerprints 536 login banner 1203 logos 1122 OS mappings 192, 540, 546, 563, 565 report footers 1115 workflows 1159, 1179 custom service detectors 552 activating 556 creating 553 deleting 557 editing 557 groups 558, 559 managing 556 custom tables and workflows 1143 creating 1140 deleting 1143 editing 1142 introduction 1136 searching 1144 table combinations 1137 understanding 1137 custom topology 162 activating 170 creating 164 deleting 170 editing 170 importing 165, 166 managing 169 manually editing 167 topology information 165 CVE ID network map 158 vulnerability detail 198

D dangerous plugins 596 dashboard 1413


1461

Index configuring 1421 status indicators 1414 Data access 1283 data correlator process monitoring 1356, 1369 data length (IP datagrams) 682 data link layer 642, 681 database limits 1197 database purging 1232 datasets 286, 316 date published (vulnerability detail) 198, 270 DCE/RPC preprocessor 921 generator ID 853 reassembly options 922 decoders custom service detectors 552 decoding errors 932 decoding packets 641, 864, 865 HTTP Inspect 891 RPC decoder 890 decoy portscan 936 default detection engines 104 Defense Center 44 disabling communications 62 health status 1356, 1370 introduction 28 managing 3D Sensors 48 managing with a Master Defense Center 73 restarting managed sensors 62 time sync 63 Defense Center groups creating 96 deleting 97 managing 96 delete host/network (RNA event type) 224 delete service (RNA event type) 224 deleting authentication objects 1281 bookmarks 1178 compliance policies 446 compliance response alerts 467 compliance rule groups 439 compliance rules 438 custom service detectors 557 custom tables 1143 custom workflows 1185 Defense Center groups 97 detection engine groups 109 detection engines 108 events 668, 669, 674 fingerprints 550 generated reports 1108

Version 4.7

health alerts 1394 health policies 1386 host attributes 207 host profiles from white lists 369 interface sets 119 intrusion events from the clipboard 698 intrusion policies 764 Nessus remediations 622 Nessus scan instances 620 Nessus scan targets 625 remediation modules 472 report profiles 1119 response groups 532 RNA detection policies 147 RNA Visualizer user accounts 635 saved searches 1129 scheduled tasks 1332 sensor groups 58 shared host profiles 377 suppression conditions 773 system policies 1192 thresholds 770 user accounts 1291 variables 786 variables in a detection engine 113 white list targets 358 white lists 370 depth (rule keyword) 967 description (vulnerability detail) 198 destination IPs packet view 682 rules 953 destination MAC 681 destination ports packet view 684, 685 rules 954 detect_state_problems (stream 4 option) 878 detected services 185 detection engine groups 109 creating 109 deleting 109 detection engines assign variable values 111 creating 105 creating variables 112 default 104 definition 103 deleting 108 deleting variables 113 detection engine groups 109 detection engine types 106


1462

Index editing 107 in searches 1133 interface set types 103 introduction 102 managing 105 resetting variables 113 understanding 103 variables 110 detection options, see keyword DHCP 1221 IP address changed (RNA event type) 220 IP address reassigned (RNA event type) 220 differentiated services (DS) in rules 985 packet view 682 directory transversal (HTTP Inspect option) 896 disable_evasion_alerts (stream 4 option) 878 disabling communications between appliances 62 high availability 70 disk usage monitoring 1356, 1371 distance (rule keyword) 966 in SID 1965 1039 distributed portscan 936 DNS configuring the cache 1200 primary server 1221 SIDs 864 DNS preprocessor experimental options 927 documentation resources 40 domain name 1220 don’t fragment (packet view) 682 double encoding (HTTP Inspect option) 896 downloading patches 198, 199 drill-down pages 1148 flow data 309 intrusion events 662 drop new hosts (RNA settings) 1205 drop rules 798 definition 948 dsize (rule keyword) 1000

E EAP 642 EAPOL 642 editing

Version 4.7

authentication objects 1280 compliance policies 446 compliance response alerting 467 compliance rules 437 custom service detectors 557 custom tables 1142 custom workflows 1185 detection engines 107 fingerprints 551 health alerts 1393 health policies 1384 host attributes 206 incidents 714 interface sets 118 intrusion policies 760 intrusion rules 1011 Nessus remediations 621 Nessus scan instances 619 Nessus scan targets 624 network interfaces 120 response groups 531 RNA detection policies 147 RNA Visualizer user accounts 635 scheduled tasks 1331 sensor attributes 59 sensor groups 58, 97 shared host profiles 373 system policies 1191 traffic profiles 330 user privileges 1287 variables in intrusion policies 781 white list targets 357 white lists 370 email alerting 726 configuring 729 creating 464 email notification 1201 email relay host 1201 enforce state (stream 4 option) 878 Estreamer 29 health module 1357 managing Estreamer clients 1256 process monitoring 1357, 1372 Ethernet 642 Ethernet II (packet view) 681 event aggregation 74 compliance events 76 intrusion events 75 limitations 76 event database limits 1197 event graphs 657


1463

Index event logging (RNA settings) 1207 event preferences 35 event statistics intrusion events 653 IPS 656 RNA events 211 event summary event breakdown (RNA) 214 intrusion events 653 OS breakdown (RNA) 216 protocol breakdown (RNA) 215 service breakdown (RNA 215 statistics summary (RNA) 212 event view time range 1169 events acknowledging 661 configuring view time range 1169 copying to the clipboard 668, 669, 674 database 644 deleting 668, 669, 674 event graphs 657 generating 644 generating events 644 host profile 178 intrusion event summary 653 IPS and RNA correlation 686 packet decoder 865 reports 1105 restoring events from backup files 1246 searching 1124 time frame 699 experimental DNS options 927 experimental TCP options 866 exporting health policies 1249 introduction 1248 intrusion policies 1249 multiple policies 1251 policies 1248 RNA detection policies 1250 system policies 1250 Extensible Authentication Protocol 642 external alerting email alerting 726 SNMP alerting 722

Version 4.7

F factory default settings 1247 failed logins 1284 FDDI 642 feature licenses adding 1217 viewing 1217 filter configuration 93 fingerprints activating 549 client fingerprints 537 deactivating 550 deleting 550 editing 551 introduction 536 managing 549 OS mappings 192, 540, 546, 563, 565 server fingerprints 543 fixes (vulnerability detail) 198, 199 flags packet view 684 rule keyword 988 flow (detected services) 186, 194 flow (rule keyword) 990 using in sample rule 1026 using in SID 1965 1035 flow data aggregated flow data 306 changing graph types 313 custom flow data workflows 1181 datasets 286 definition 129 detaching graphs 318 exporting 318 field descriptions 294, 296 graph types 284 graphs 283, 289, 305, 313 introduction 275 line graphs 312 predefined workflows 1156 searching 299 selecting datasets 316 summaries 277 tables 291 understanding 279 viewing 299 workflows 307, 309 flow data enabled (RNA policy option) 140 flow summaries 277 field descriptions 296


1464

Index graph types 278 understanding 282 flow tracker events syntax 425 flow trackers 415 syntax 422 flowbits (rule keyword) 1006 flush on alert (stream 4 option) 878 fragbits (rule keyword) 983 fragment offset (packet view) 683 fragmentation, in IP datagrams 869 fragoffset (rule keyword) 1000 FTP decoder 909 generator ID 853 SIDs 862

G generating events 644 generator IDs (GIDs) 851 table of GIDs 851 global host profiles 345, 359 global policy management 78 graphs changing flow data graphs 313 detaching flow data graphs 318 flow data 283, 305 health monitoring 1401 intrusion events 657 performance statistics 1348 groups appliance groups 96 compliance response groups 530 compliance rule groups 438 custom service detectors 558, 559 Defense Center groups 96 detection engines 109 intrusion rules 792 sensor groups 56

H HA pair 63 header length (packet view) 682, 684 health alerts 1390, 1391 creating 1391

Version 4.7

deleting 1394 editing 1393 understanding 1392 health events 1404 field descriptions 1409 predefined workflows 1159 searching 1410 viewing 1404 health modules 1356 running all modules 1399 running specific modules 1400 health monitor 1395 blacklist 1213, 1386, 1389 status indicators 1396 health monitoring alerts 1390 appliance monitoring 1396 blacklists 1230 configuring 1359 creating alerts 1391 dashboard 1413 deleting alerts 1394 editing alerts 1393 events 1404 graphs 1401 health modules 1356 health monitor 1395 health policies 1355 introduction 1353 running health modules 1399, 1400 status icons 1398 troubleshooting 1402 understanding 1354 understanding alerts 1392 health policies 1355 applying 1382 configuring 1360 creating 1364 defaults 1361 deleting 1386 editing 1384 exporting 1249 high availability configuration guidelines 66 configuring 63 disabling 70 monitoring 69 pausing communications 71 restarting communications 71 setting up 67 shared configurations and data 63


1465

Index hits (detected services) 190 home page 38 hops hops change (RNA event type) 220 host profile 176 host view 235 host attribute add (RNA event type) 224 host attribute delete (RNA event type) 224 host attribute delete value (RNA event type) 224 host attribute set value (RNA event type) 224 host attribute update (RNA event type) 224 host attributes attribute types 203 creating 203 definition 128 deleting 207 editing 206 field descriptions 246 host profiles 181 introduction 244 network map 161 predefined 201 remediations 520 restrictions 203 searching 248 set value (RNA event type) 224 setting attributes 247 understanding 246 user-defined 202 viewing 244 host criticality 201 host view 235 host deleted (RNA event type) 220 host dropped (RNA event type) 221 host input 559 custom product mappings 568 event types 223 events 218, 225 patch tools 564 service identification 567 third-party tools 561 vulnerabilities 566 host profile qualifications compliance rules 411 in traffic profiles 325 syntax 326 host profiles activating vulnerabilities 199, 200 basic information 176 client applications 193 creating white lists 185

Version 4.7

definition 128 host attributes 181 host criticality 201 host protocols 182 impact qualification 198 introduction 172 network map 152 notes 202 predefined host attributes 201 scan results 207 services 185 shared host profiles 346 viewing 175 VLAN tags 180 vulnerabilities 195 vulnerability details 197 white list violations 183 white lists 344, 358 host protocols 182 host statistics 1335 IPS 653, 655 host timeout (RNA event type) 221 host timeout (RNA settings) 1205 host type changed to router/bridge (RNA event type) 221 hostname 1220 hosts host attributes 244 host criticality 235 host name (host profile) 176 host type (host profile) 178 introduction 231 IP address 234 last seen 178, 234 last user (host profile) 178 MAC addresses 235 misidentification 534 NETBIOS name 235 new host (RNA event type) 221 searching 239 traffic profiles 237 viewing 232 viewing on the network map 154 VLAN ID 235 white list 238 whois information 238 HTML reports 1115 HTTP Inspect 891 configuring 901 generator ID 852 normalization options 892, 893, 894


1466

Index server profiles 897 SIDs 859

I ICMP 642 ICMP (packet view) 686 ICMP header values 986 icmp_id (rule keyword) 986 icmp_seq (rule keyword) 986 icode (rule keyword) 987 ID packet view 682 rule keyword 983 IEEE 802.11 642 IEEE 802.3 Ethernet (packet view) 681 IIS backslash (HTTP Inspect option) 896 IIS encoding (HTTP Inspect option) 895 impact (vulnerability detail) 198 impact flags 686 alerting 470 definition 131 descriptions 687 impact qualification 198 impact qualification 199 importing guidelines 1252 introduction 1248 inactive periods 428 incidents common processes 708 creating 712 default incident types 711 definition 708 editing 714 incident handling basics 708 incident types 716 introduction 707 reports 715 inline intrusion policies 749, 750, 752 integer (host attribute type) 203, 204 interface sets 114 creating 116 definition 103 deleting 119 editing 118 introduction 102 link state propagation mode 116

Version 4.7

transparent inline mode 115 types 103, 115 Internet Control Message Protocol, see ICMP Internet Protocol, see IP introduction 25 intrusion agents 29 intrusion detection and prevention, see IPS intrusion event responses 645 Check Point OPSEC SAM responses 730 email alerting 726 introduction 718 SNMP alerting 722 syslog alerting 719, 721 intrusion events aggregating 75 analyzing 644 clipboard 695 constraining events 671 drill-down pages 662 event statistics 656 field descriptions 659 impact flags 686 introduction 651 intrusion event responses 718 packet view 665, 673 portscan events 939 predefined workflows 1150 reviewing 661 sample analysis 698 searching 689 suppression 771 table view of events 664 thresholding and suppression 766 understanding 659 unreviewing 661 viewing 658, 667 whois information 695 workflows 662 intrusion policies adding a threshold 768 applying 764 benefits 649 changing rule state 794 creating inline policies 752 creating passive policies 756 default policies 749 definition 747 deleting 764 detection challenges 848 drop rule state 798 editing 760


1467

Index exporting 1249 importing local intrusion rules 837 importing SEUs 833, 834, 836 introduction 747 intrusion rule examples 1018 managing 760 planning 750 predefined variables 779 preprocessors 846 rule groups 792 rule states 789 scheduling policy applications 1318 suppression 766, 771 thresholding 766, 767 variables 778, 781 writing intrusion rules 948 intrusion rules changing rule state 794 comments 1013 creating 1008 creating a sample 1020 definition 948 drop rules 798 editing 1011 examples 1018 exploring SID 1965 1031 ICMP header values 986 importing local rule files 837 importing SEUs 833, 834, 836 introduction 948 IP header values 982 keywords 956 operators 956 parts of a rule 949 replacing content 1044 rule actions 952 rule groups 792 rules headers 951 searching for 1014 source IPs 953 source ports 954 TCP header values 987 thresholding 766 tips and recommendations 1051 understanding creation process 1019 invalid IP options (packet decoder) 865 invalid RFC delimiters (HTTP Inspect option) 896 IP (Internet Protocol) 642 IP addresses excluding 776 host view 234

Version 4.7

in rules 953 in variables and intrusion rules 773 in variables and rules 774 syntax for searches and reports 1130 IP defragmentation 869 exploits 869 generator ID 853 SIDs 861 target-based policies 870 IP header values 982 IP layer (packet view) 681 IP/CIDR (stream 5 option) 885 IP_Proto (rule keyword) 984 IPoption (rule keyword) 984 IPS analyzing intrusion events 644 architecture 640 deployments 646 introduction 27, 637 intrusion event responses 645 intrusion events 651 intrusion policies 747 sample analysis 698 IPS event rate monitoring 1357, 1374, 1375 IPS policies creating 753 definition 752 IPS process monitoring 1358, 1376 isdataat (rule keyword) 1000 ISDN for Linux 642 itype (rule keyword) 986

J JPEG logos 1122

K keyword ack 988 asn1 997 byte_jump 968 byte_test 971 classtype 958 content 962


1468

Index Active Directory server 1276 and RUA 1055, 1064, 1075 authentication objects 1265 authentication profiles 1194 examples 1275 logging in 32 managing user accounts 1287 OpenLDAP directory server 1275 settings 1267 Sun directory server 1278 legacy reassembly (stream 5 option) 885 length data link layer 681 packet view 680, 685 licenses adding 1217 feature licenses 1217 managing 1215 requesting 1217 verifying 1216 viewing 1217 line graphs (flow data) 312 link mode, editing 120 link state propagation mode 116 Linux SLL (cooked mode) 642 list (host attribute type) 203, 205 listeners 277 load balancers and RNA 136 logging into the appliance 30 using LDAP 32 logging multiple packets per stream 943 logging out of the appliance 33 login banner 1203 logos, adding 1122

depth 967 distance 966 dsize 1000 flags 988 flow 990 flowbits 1006 fragbits 983 fragoffset 1000 icmp_id 986 icmp_seq 986 icode 987 ID 983 IP_Proto 984 IPoption 984 isdataat 1000 itype 986 metadata 981 msg 957 nocase 964 offset 967 pcre 973 priority 958 rawbytes 965 reference 962 resp 1002 rpc 996 sameip 1000 seq 992 stream,_size 992 tag 1005 threshold 1003 tos 985 ttl 985 urilen 998 window 992 within 967

M

L language 1202 last seen (host view) 178, 234 last used (detected services) 188 latency thresholding 803 configuring 810 tuning 804 understanding 804 layer (host profile) 183 LDAP 1263, 1274

Version 4.7

MAC addresses additional MAC detected (RNA event type) 220 host profile 178 host view 235 information change (RNA event type) 221 mail relay host 1201 Maintenance access 1283 management interface 1220 management virtual network 1223 managing 3D Sensors 44


1469

Index Defense Centers 73 managed sensor system settings 59 sensors 45, 48 Sourcefire Sensors 50, 51, 54, 56 time settings 63 Master Defense Center 73 adding a Defense Center 81, 84 appliance groups 96 deleting a Defense Center 87 editing settings for the Defense Center 91 event aggregation 74 filter configuration 93 global policy management 78 health policies 79 intrusion policies 78 managing Defense Centers 73 policy limitations 80 RNA detection policies 79 system policies 80 system settings 98 maximum chunk size (HTTP Inspect option) 896 maximum TCP window (stream 5 option) 884 maximum transmission unit (MTU) 869 memcap DCE/RPC reassembly 922 memory usage monitoring 1358, 1378 metadata (rule keyword) 981 Microsoft %U encoding (HTTP Inspect option) 895 Active Directory 1055, 1057, 1064, 1263 IIS encoding (HTTP Inspect option) 895 minimum TTL (stream 5 option) 884 monitored networks, configuring 134, 135 more fragments (packet view) 682 msg (rule keyword) 957 MTU 869 multi-rule search engine 643 multi-slash obfuscation (HTTP Inspect option) 896

N NAT devices and RNA 136 Nessus ID, in the network map 158 Nessus scans adding a Nessus scan instance 508 creating 506 creating remediations 615 creating scan instances 612

Version 4.7

creating scan targets 614 dangerous plugins 596 deleting Nessus remediations 622 deleting scan instances 620 deleting scan targets 625 editing Nessus remediations 621 editing scan instances 619 editing scan targets 624 example scans 606, 607, 608 importing scan results 626 introduction 591 local server 610 managing 618 Nessus settings 597 Nessus user 611 Nessus vulnerability database 630 on-demand scans 622 plugin families 592 plugins 592 remediations 506, 621 safe checks 596 sample scanning profiles 605 scan instances 619 scan targets 623 scheduling plugin synchronization 1324 scheduling scans 1321 setting up 609 strategies 601 NetBIOS name host profile 176 host view 235 NetBIOS name change (RNA event type) 221 NetFlow adding devices 1231 information in NetFlow records 130 licenses 1217, 1218 limitations 128, 130, 131 prerequisites 133 RNA detection policies 134, 135, 141, 145 system settings options 1213 network behavioral analysis 319 network gateway 1220 network interfaces 120 network layer 642, 681 preprocessors 868 network map bridges and routers 155 Bugtraq ID 158 custom topology 162 CVE ID 158 definition 128


1470

Index host attributes 161 hosts 152 introduction 149 Nessus ID 158 RNA ID 158 services 157 SIDs 159 understanding 150 viewing hosts 154 vulnerabilities 158 network settings configuring 1220 using DHCP 1221 using static 1221 network surveys (white lists) 352 Network Voyager 50, 51 new client application (RNA event type) 221 new host (RNA event type) 221 new network protocol (RNA event type) 222 new TCP service (RNA event type) 222 Nmap scans introduction 572 managing 587 on-demand scans 589 remediations 514, 581, 589 sample scanning profiles 575 scan instances 578, 587 scan targets 580 scheduling 1325 setting up 578 no_alert_large_fragments (RPC decoder) 891 nocase (rule keyword) 964 Nokia Network Voyager 50 non-RFC characters (HTTP Inspect option) 896 notes in the host profile 202 notification email alerting 726 SNMP alerting 722

O obsolete TCP options 867, 926 offset (rule keyword) 967 on-demand scans 589, 608, 622 OpenLDAP 1056, 1057, 1064, 1263, 1270, 1275 operators, in rules 956 OPSEC, see Check Point OPSEC SAM order of execution, of preprocessors 849

Version 4.7

OS breakdown 216 OS confidence update (RNA event type) 222 OS custom fingerprints 536 OS information update (RNA event type) 222 OS mappings 192, 540, 546, 563, 565 OS names host profile 177 host view 235 OS vendor (host view) 235 OS version (host view) 235 overlap limit (stream 4 option) 879 overlap limit (stream 5 option) 884 overlapping TCP segments 878

P packet decoder capturing packets 641 disabling events 865 dropping decoder packets 865 experimental TCP options 866 invalid IP options 865 invalid TCP options 866 obsolete TCP options 867, 926 SIDs 856 T/TCP options 868 TCP options with invalid lengths 868 uncommon TCP options 866 understanding 864 packet information (packet view) 680 packet inspection, using in rule 1965 1036 packet latency thresholding 803 packet view 673 copying events to the clipboard 668, 669, 674 datalink layer 681 definition 665 deleting events 668, 669, 674 event information 676 ICMP packets 686 network layer 681 packet information 680 payload 686 portscans 940 setting thresholds 678 suppression options 679 TCP packets 684 transport layer 684 UDP packets 685


1471

Index packets capturing 641 data link layer 642 decoding 641, 864 payload 686 processing 642 passive intrusion policies 750, 756 passwords changing 34, 1290 duration 1285 failed logins 1284 for RNA Visualizer users 634 force reset 1284 password options 1284 reset 1288 strength check options 1284, 1288 patches (for vulnerabilities) 198, 199 payload (packet view) 686 pcre (rule keyword) 973 PDF reports 1115 peer manager 68 performance boost TCP option (stream 5) 885 UDP option (stream 5) 887 performance monitor 932 performance statistics 1347, 1349 Perl-compatible regular expressions 973, 975 examples 979 options 977 plugins 592 scheduling plugin synchronization 1324 PNG logos 1122 Point-to-Point Protocol 642 Point-to-Point Protocol over Ethernet 642 ports detected services 186 in variables 773 in variables and intrusion rules 777 ports (stream 4 reassembly option) 880 portscans 933 configuring 937 decoy portscan 936 distributed portscan 936 generator ID 852 packet view 940 portscan events 939 portscan types 935 portsweep 935 sensitivity levels 937 SIDs 860 portsweep 935

Version 4.7

PPP 642 PPPOE 642 predefined host attributes 201 preferences 34 changing passwords 34 event preferences 35 home page 38 time zone 37 preprocessors Back Orifice detection 932 configuring 943 generator IDs 851 introduction 846 IP defragmentation 869 network layer 868 order of execution 849 performance monitor 932 processing packets 642 reading events 850 stateful inspection 875 stream 4 877 stream 5 882 primary Defense Center 64, 66, 67 priority (rule keyword) 958 processing packets 642 profile conditions (in traffic profiles) 331 profiling time window (PTW) 319 options 328 protocol breakdown 215 protocols detected services 186 host profile 183 packet view 682 white lists 364 purging the RNA/RUA databases 1232 pushing updates to sensors 1235

R rawbytes (rule keyword) 965 Real-time Network Awareness, see RNA Real-time User Awareness, see RUA reference (rule keyword) 962 using in SID 1965 1044 refresh interval 35 registration ID 52, 68, 83, 86 registration key 52, 68, 83, 86 regular expressions, in intrusion rules 973


1472

Index remediation events 524 field descriptions 526 searching 527 understanding 525 viewing 524 remediations 471 adding a Cisco IOS instance 494 Check Point FW-1 473 Cisco IOS routers 493 Cisco PIX 501 deleting modules 472 installing new modules 472 Nmap remediations 581, 589 status events 524 remote (vulnerability detail) 198, 270 remote backups 1244 remote database access (RNA Visualizer) 632 remote management 1223, 1226 remote reports 1120 remote updates 1235 replace rules 1044 report designer 1112 report profiles creating 1112 deleting 1119 introduction 1109 logos 1122 summary reports 1121 using 1116 viewing generated reports 1107 reports clipboard reports 696 creating report profiles 1112 deleting 1108 deleting report profiles 1119 downloading 1108 event graphs 657 footers 1115 from event views 1105 incidents 715 introduction 1103 logos 1122 remote reports 1120 report profiles 1109 scheduling reports 1320 summary reports 1121 using a report profile 1116 viewing generated reports 1107 requesting feature licenses 1217 require TCP handshake (stream 5 option) 885 resetting management 56

Version 4.7

resp (rule keyword) 1002 response groups 530 activating and deactivating 532 creating 530 deleting 532 editing 531 restarting the appliance 1222 restoring from a CD-ROM 1247 from backup files 1245 to factory defaults 1247 Restricted Data access 1283, 1288 right-click menus 39 RNA 26 analyzing RNA events 218 client applications 261 compliance events 447 compliance policies 392 compliance policy remediations 471 compliance responses 456 compliance rules 392 data collection 127 detecting custom services 552 enhancing detection 533, 534 event statistics 211 flow data 129, 275 host attributes 128, 202 host profiles 128, 172 impact flags 131 introduction 26, 125 load balancers and NAT devices 136 misidentifications 534, 535 network map 128, 149 predefined workflows 1154 purging the database 1232 remediation events 524 RNA detection policies 134 RNA event alerts 468 RNA events 129, 210 RNA ID 158, 197 RNA settings in system policies 1204 RNA Visualizer 132 services 251 summary reports 1122 traffic profiles 129, 275 understanding 126 vulnerabilities 131, 267 vulnerability ID 270 white lists 340 rna (executable name) 1346 RNA detection policies


1473

Index applying 146 configuration strategies 134 creating 138 deleting 147 editing 147 exporting 1250 introduction 134 NetFlow options 141, 145 options 140 RNA events analyzing 218 definition 129 event breakdown 214 event statistics 211 event types 220, 224 field descriptions 226 introduction 210 OS breakdown 216 protocol breakdown 215 purging the database 1232 searching 228 service breakdown 215 statistics summary 212 viewing 225 workflows 217 RNA host usage monitoring 1359, 1379 RNA ID 158 vulnerability detail 197 RNA process monitoring 1359, 1380 RNA recommended rules 811 accepting recommendations 819 blacklists 829 configuring 816 network maps 813 scheduling 1327 RNA Visualizer 29, 132, 631 activating user accounts 636 changing passwords 634 creating user accounts 632 deactivating user accounts 636 deleting user accounts 635 editing user accounts 635 remote database access 632 routers (on the network map) 155 rpc (rule keyword) 996 RPC decoder 890 generator ID 852 options 891 SIDs 854 RUA 1053 and 3D Sensors 1059, 1065, 1083

Version 4.7

and LDAP 1055, 1064, 1075 authentication objects 1076 compliance rules 426 correlating user identity 1068 event searches 1100 introduction 1053 licenses 1217, 1219 purging RUA events 1232 RUA agents 1058, 1064, 1080 RUA events 1096 user identity 1086 user searches 1092 Rule access 1283 rule categories 789 rule classifications importing 1249 intrusion event searches 693 rule editor 1008 rule groups 792 rule headers 951, 956 destination IPs 953 destination ports 954 source IPs 953 source ports 954 rule latency thresholding 803, 807 rule states 789 changing 794 RNA recommended rules 819 rules categories 789 creating 1008 destination IPs 953 destination ports 954 keywords 956 operators 956 source IPs 953 source ports 954 tuning 649 Rules access (user role) 702

S safe checks 596 SAM, see Check Point OPSEC SAM sameip (rule keyword) 1000 save unknown OS data (RNA policy option) 140 save unknown service data (RNA policy option) 140 saved searches 1129, 1412


1474

Index deleting 1129, 1412 loading 1129, 1412 scan results host profiles 207 scanning 571 analyzing results 629, 630 monitoring scans 626 Nessus scans 591 Nmap 578 Nmap scans 572 scan results 625 searching for scan results 627 selecting a scanner 572 scheduling tasks backups 1302 deleting 1332 editing 1331 introduction 1299 intrusion policy applications 1318 Nessus scans 1321 Nmap scans 1325 recurring tasks 1300 reports 1320 RNA recommended rules 1327 SEU downloads 1316 SEU imports 1315, 1317 software downloads 1305 software installs 1308 software pushes 1306 software updates 1304 synchronizing Nessus plugins 1324 using the calendar 1329 using the task list 1331 VDB downloads 1311 VDB installs 1314 VDB pushes 1312 VDB updates 1310 viewing 1329 searching active scan results 627 audit records 1426 client applications 265 compliance events 452 custom tables 1144 events 1124 flow data 299 health events 1410 host attributes 248 hosts 239 intrusion events 689 intrusion rules 1014

Version 4.7

loading a saved search 1128 remediation events 527 RNA events 228 RUA events 1100 RUA user identity 1092 services 256 SEU import logs 842 specifying detection engines 1133 specifying ports 1132 using time constraints 1130 using wildcards 1129 vulnerabilities 272 white list violations 389 white lists 382 secondary Defense Center 64, 66, 67 sensor groups creating 57 deleting 58 editing 58, 97 managing 56 sensor software 25 seq (rule keyword) 992 sequence (packet view) 684 Serial Line Internet Protocol 642 server (stream 4 reassembly option) 880 server fingerprints 543 server ports (stream 5 reassembly option) 886 serveronly (stream 4 reassembly option) 880 service breakdown 215 service detectors 552 service timeout (RNA settings) 1205 services banners 190 custom service detectors 552 details 189 detected services 187 field descriptions 254 host profiles 185 introduction 251 misidentified 535 network map 157 searching 256 understanding 254 viewing 251, 254 viewing from the network map 158 white lists 361 serving time to managed sensors 1210 SEUs 833 import log 838, 839 importing automatically 836 importing manually 834


1475

Index scheduling downloads 1316 scheduling imports 1315, 1317 searching import logs 842 shared host profiles 371 adding 366 creating 371 deleting 377 editing 373 shell access 1273 shutting down the appliance 1222 SIDs Back Orifice detector 854 DNS 864 FTP decoder 862 HTTP Inspect 859 IP defragmentation 861 mapped to vulnerabilities 270 network map 159 packet decoder 856 portscans 860 RPC decoder 854 SID 1965 rule example 1031 SMTP decoder 862 stream 4 855 stream 5 863 Telnet decoder 863 vulnerability detail 197 SLIP 642 SMTP decoder generator ID 853 SIDs 862 SNMP alerting 722 configuring 724 creating 465 SNMP decoding 905 snooze periods 428 Snort ID, see SID software updates 1233 installing 1233 scheduling downloads 1305 scheduling installs 1308 scheduling pushes 1306 scheduling updates 1304 solution (vulnerability detail) 198 source (detected services) 187 source IPs in packet view 682 in rules 953 source MAC 681 source ports in packet view 684, 685

Version 4.7

in rules 954 Sourcefire Sensors adding a base license 54 adding to a Defense Center 51 and Network Voyager 51 managing 50 resetting management 56 state problems 878 stateful inspection 875 anomalies (stream 5 option) 885 disabling 878 generator ID (stream 4) 852 generator ID (stream 5) 853 stream 4 options 878 statistics events 653 host 655 performance 1347, 1349 status dashboard 1413 stream 4 preprocessor 877 compared to stream 5 874 configuring 880 generator ID 852 SIDs 855 stateful inspection options 878 stream reassembly options 880 stream 5 preprocessor 882 compared to stream 4 874 configuring 887 generator ID 853 SIDs 863 stream reassembly options 886 target-based policies 882 TCP policy options 884 UDP session tracking 887 stream reassembly 876 generator ID (stream 4) 852 generator ID (stream 5) 853 reassembly options (stream 4) 880 reassembly options (stream 5) 886 stream-based attacks 877 stream_size (rule keyword) 992 summary reports 1121 Sun directory server 1055, 1057, 1064, 1263, 1278 suppression configuring 771 creating 771 deleting suppression conditions 773 in the packet view 679 introduction 766 SYN flag 878


1476

Index syslog alerting 721 filer examples 1431 filter syntax 1430 priority levels 721 severity levels 462 syslog facilities 461, 720 viewing 1429 system daemons 1342 system management backup and restore 1239 introduction 1187 IPS performance statistics 1347 RNA performance statistics 1349 software updates 1233 system policies 1189 system settings 1211 uninstalling software updates 1235 updating software on managed sensors 1235 using the restore CD-ROM 1247 VDB updates 1233 system monitoring disk usage 1339 host statistics 1335 introduction 1334 system processes 1339 system status 1339 system policies 1189 applying 1192 authentication profiles 1194 creating 1190 custom login banner 1203 database limits 1197 deleting 1192 DNS cache 1200 editing 1191 exporting 1250 language 1202 mail relay host 1201 RNA settings 1204 time sync 1208 system processes understanding 1342 viewing 1339 system settings 1211 appliance information 1213 introduction 1211 licenses 1215 managing with a Defense Center 59 Master Defense Center 98 NetFlow devices 1231

Version 4.7

network settings 1220 remote management 1223, 1226 restarting the appliance 1222 shutting down the appliance 1222 time sync 1229 system utilities and executables 1344

T T/TCP options 868 tab obfuscation (HTTP Inspect option) 896 table view of events 1148 features 1167 intrusion events 664 tag (rule keyword) 1005 talkers, in flow summaries 277 task queue 1259 task status 1259 TCP 642 experimental options 866 invalid length options 868 invalid options 866 new TCP service (RNA event type) 222 obsolete options 867, 926 policy OS (stream 5 option) 884 port closed (RNA event type) 222 port timeout (RNA event type) 222 service information update (RNA event type) 222 T/TCP options 868 uncommon options 866 TCP header values 987 TCP service confidence update (RNA event type) 222 TCP services (RNA event type) 222 technical description (vulnerability detail) 198 Telnet decoder 909 SIDs 863 telnet decoder generator ID 853 testing authentication 1274 text (host attribute type) 203 third-party tools 561 host identification 534 patch tools 564 service identification 567 vulnerabilities 535, 566 threshold (rule keyword) 1003 thresholding 1003


1477

Index adding a new threshold 768 configuring 766 deleting a threshold 770 global 768 in the packet view 678 introduction 766 options 767 per intrusion policy 766 TIFF logos 1122 time constraints (in searches) 1130 time frame configuring 1169 event analysis 699 time sync 1208, 1210 serving time 1210 setting manually 1229 setting time on a managed sensor 63 time zone 37 timeout defragmentation option 873 DNS cache option 1201 host timeout 221 stream 4 option 879 TCP policy option (stream 5) 884 TCP port timeout (RNA event type) 222 UDP port timeout (RNA event type) 223 UDP session tracking (stream 5) 887 timestamp host view 178, 234 service view 254 timestamp (packet view) 680 time-to-live (TTL) values 682 title (vulnerability detail) 198 Token Ring 642 tos (rule keyword) 985 traffic profiles activating 330 creating 319 definition 129 editing 330 host profile qualifications 325 host view 237 introduction 275 profile conditions 324, 331 saving 329 specifying conditions 324 viewing 337 traffic status monitoring 1359, 1381 Transmission Control Protocol, see TCP transparent inline mode 115 transport layer 642, 684

Version 4.7

detecting uncommon TCP options 866 preprocessors 873, 874 transport protocol (RNA event type) 222 trend graphs 657 troubleshooting files 1402 TTL host profile 178 packet view 682 rule keyword 985 variance (stream 4 option) 879 type (packet view) 686 types, packet (data link layer) 681

U UDP 642 and Back Orifice 932 new service (RNA event type) 222 options (session tracking) 887 packet view 685 port closed (RNA event type) 222 port timeout (event type) 223 session tracking 887 UDP service confidence update (RNA event type) 223 UDP service information update (RNA event type) 223 uninstalling software updates 1235 unreviewing events 661 update interval (RNA policy option) 140 updating the software 1233, 1235 urgent pointer (packet view) 685 urilen (rule keyword) 998 URL (host attribute type) 203 user accounts access types 1283 account management 1261 creating 1283 deleting 1291 editing 1287 externally authenticated user accounts 1287 for RNA Visualizer 632, 635 LDAP users 1287 managing 1281 menu access per access type 1291 password options 1284 privileges 1264 shell access 1273


1478

Index user authentication 1261 viewing 1282 user authentication 1261 external authentication 1263 internal authentication 1263 LDAP authentication objects 1265 User Datagram Protocol, see UDP user preferences 34 changing event preferences 35 changing passwords 34 home page 38 time zone 37 USER_CONF 787 USER_CONF (reserved variable) 121 UTF-8 (HTTP Inspect option) 895

V variables and detection engines 110 assigning values for detection engines 111 creating 784 creating in detection engines 112 deleting 786 editing 781 predefined 779 USER_CONF 787 USER_CONF (reserved variable) 121 using IP addresses 773 VDB updates 1237 scheduling downloads 1311 scheduling installs 1314 scheduling pushes 1312 scheduling updates 1310 version (detected services) 187, 189 VLAN ID (host view) 235 VLAN tags host profiles 180 information update (RNA event type) 223 vulnerabilities activating and deactivating 199, 200 deactivating 158, 271 definition 131 field descriptions 270 host profiles 195 impact qualification 199 introduction 267 invalidating 158

Version 4.7

mapped to SIDs 270 misidentified 535 network map 158 searching 272 third-party tools 536, 566 viewing 267 vulnerability details 197 vulnerability database 1233 Nessus vulnerability database 630 vulnerability impact 198 vulnerability impact qualification (RNA event type) 225 vulnerability lookup (RNA settings) 1207 vulnerability mappings 192, 540, 546, 563, 565 vulnerability set invalid (RNA event type) 225 vulnerability set valid (RNA event type) 225

W web browser requirements 30 white list events 378 viewing 379 white list targets 343 configuring network segments 355 creating 355 deleting 358 editing 357 white lists adding to compliance policies 441 client applications 362 configuring targets 355 creating 350 creating from host profiles 185 creating shared host profiles 371 creating targets 355 dashboard 1418 definition 340 deleting 370 deleting host profiles 369 editing 370 events 378 field descriptions 381, 388 global host profiles 345, 359 host profiles 344, 358 host view 238 introduction 340 managing 370 operating systems 359


1479

Index protocols 364 searching 382 services 361 shared host profiles 346, 366, 371 surveying your network 352 target evaluations 348 targets 343 understanding 342, 381 violations 183, 349, 385, 389 white list events 349 whois 238, 695 wildcards (in searches) 1129 window packet view 684 rule keyword 992 within (rule keyword) 967 using in SID 1965 1039 workflows and custom tables 1143 and flow data 307, 309 common functionality 1166 components 1148 compound constraints 1173 constraining events 1170 constraining time 1169 creating 1179 custom flow data workflows 1181 deleting 1185 editing 1185 introduction 1147 intrusion events 662 navigating between workflows 1175 navigating to other pages 1175 predefined audit workflow 1159 predefined compliance workflows 1156 predefined flow data workflows 1156 predefined health event workflows 1159 predefined intrusion event workflows 1150 predefined RNA workflows 1154 predefined vs.custom workflows 1149 RNA event 217 saved custom workflows 1159 selecting 1162 sorting pages 1174 table view of events 1167 using bookmarks 1177 using workflows 1161 viewing custom workflows 1184 workflow toolbar 1165

Version 4.7

X xlink2state 905

Z zero flushed packets (stream 4 option) 878


1480

Sourcefire 3D System for Nokia User Guide - Check Point

Sourcefire 3D System for Nokia User Guide - Check Point

Suggest Documents

Sourcefire 3D System Appliances Specs

Nokia Standard Document Template - Check Point

Nokia 305 User Guide

Nokia 3586i User Guide

Nokia N95 User Guide

Nokia E73 User Guide

Nokia 220 User Guide

Nokia 700 User Guide

Nokia 100 User Guide

Nokia 206 User Guide

Nokia 110 User Guide

Nokia 301 User Guide

Nokia E72 User Guide

Nokia 3100 and Nokia 3120 User Guide

Nokia N86 8MP User Guide

Nokia 3100 User Guide - Rogers

Nokia N8-00 User Guide

Nokia 2126 User Guide - pdfstream.manualsonline.com

SOURCEFIRE 3D SENSOR

Nokia Lumia 830 User Guide

Nokia Lumia 1520 User Guide

Nokia N95 8GB User Guide

PDF Nokia E71 User Guide

Nokia C7–00 User Guide