- Title Page
- Introduction & Preface
- Logging into the FireSIGHT System
- Using Objects and Security Zones
- Managing Devices
- Setting Up an IPS Device
- Setting Up Virtual Switches
- Setting Up Virtual Routers
- Setting Up Aggregate Interfaces
- Setting Up Hybrid Interfaces
- Using Gateway VPNs
- Using NAT Policies
- Getting Started with Access Control Policies
- Blacklisting Using Security Intelligence IP Address Reputation
- Tuning Traffic Flow Using Access Control Rules
- Controlling Traffic with Network-Based Rules
- Controlling Traffic with Reputation-Based Rules
- Controlling Traffic Based on Users
- Controlling Traffic Using Intrusion and File Policies
- Understanding Traffic Decryption
- Getting Started with SSL Policies
- Getting Started with SSL Rules
- Tuning Traffic Decryption Using SSL Rules
- Understanding Intrusion and Network Analysis Policies
- Using Layers in Intrusion and Network Analysis Policies
- Customizing Traffic Preprocessing
- Getting Started with Network Analysis Policies
- Using Application Layer Preprocessors
- Configuring SCADA Preprocessing
- Configuring Transport & Network Layer Preprocessing
- Tuning Preprocessing in Passive Deployments
- Getting Started with Intrusion Policies
- Tuning Intrusion Rules
- Tailoring Intrusion Protection to Your Network Assets
- Detecting Specific Threats
- Limiting Intrusion Event Logging
- Understanding and Writing Intrusion Rules
- Blocking Malware and Prohibited Files
- Logging Connections in Network Traffic
- Working with Connection & Security Intelligence Data
- Analyzing Malware and File Activity
- Working with Intrusion Events
- Handling Incidents
- Configuring External Alerting
- Configuring External Alerting for Intrusion Rules
- Introduction to Network Discovery
- Enhancing Network Discovery
- Configuring Active Scanning
- Using the Network Map
- Using Host Profiles
- Working with Discovery Events
- Configuring Correlation Policies and Rules
- Using the FireSIGHT System as a Compliance Tool
- Creating Traffic Profiles
- Configuring Remediations
- Using Dashboards
- Using the Context Explorer
- Working with Reports
- Understanding and Using Workflows
- Using Custom Tables
- Searching for Events
- Managing Users
- Scheduling Tasks
- Managing System Policies
- Configuring Appliance Settings
- Licensing the FireSIGHT System
- Updating System Software
- Monitoring the System
- Using Health Monitoring
- Auditing the System
- Using Backup and Restore
- Specifying User Preferences
- Importing and Exporting Configurations
- Purging Discovery Data from the Database
- Viewing the Status of Long-Running Tasks
- Command Line Reference
- Security, Internet Access, and Communication Ports
- Third-Party Products
- glossary
Configuring External Alerting for Intrusion Rules
While the FireSIGHT 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.
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 Filtering Intrusion Event Notification Per Policy for more information.
There is another type of alerting you can perform in the FireSIGHT System, outside of your intrusion policies. You can configure email, SNMP, and syslog alert responses for other types of events, including intrusion events with specific impact flags, or connection events logged by specific access control rules. For more information, see Configuring External Alerting.
See the following sections for more information on external intrusion event notification:
- Using SNMP Responses 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.
- Using Syslog Responses 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 Email Alerting describes the options you can configure to send notifications of intrusion events by email.
Using SNMP Responses
An SNMP trap is a network management notification. You can configure the device 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 device that detected it
- the name of the device that detected it
- the event data
You can set a variety of SNMP alerting parameters. Available parameters vary depending on the version of SNMP you use. For details on enabling and disabling SNMP alerting, see Configuring Advanced Settings in an Intrusion Policy.
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
.
For SNMP v2, you can specify the options described in the following table.
For SNMP v3, you can specify the options described in the following table.
Note When using SNMP v3, 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.
For information about configuring SNMP Alerting, see Configuring SNMP Responses.
Configuring SNMP Responses
You can configure SNMP alerting in an intrusion policy. After you apply the policy as part of an access control policy, the system notifies you of any intrusion events it detects via SNMP trap. For more details on SNMP alerting, see Using SNMP Responses.
To configure SNMP alerting options:
Step 1 Select Policies> Intrusion > Intrusion Policy.
The Intrusion Policy page appears.
Step 2 Click the edit icon ( ) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.
The Policy Information page appears.
Step 3 Click Advanced Settings in the navigation panel on the left.
The Advanced Settings page appears.
Step 4 You have two choices, depending on whether SNMP Alerting under External Responses is enabled:
The SNMP Alerting page appears.
A message at the bottom of the page identifies the intrusion policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy for more information.
Step 5 Specify the trap type format that you want to use for IP addresses that appear in the alerts, as Binary or as String .
Note 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.
Step 6 Select either SNMP v2 or SNMP v3:
- 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.
- 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 for more information.
Note You must select SNMP v2 or SNMP v3.
Note When you enter an SNMP v3 password, the password displays in plain text during initial configuration but is saved in encrypted format.
Step 7 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.
Using Syslog Responses
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 intrusion policy as part of an access control policy, the system 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 following 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 Linux-based system) indicates which facilities are saved to which log files on the server.
Select one of the following standard syslog priority levels to display on all notifications generated by this alert:
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 Responses
You can configure syslog alerting in an intrusion policy. After you apply the policy as part of an access control policy, the system notifies you of any intrusion events it detects via the syslog. For more information on syslog alerting, see Using Syslog Responses.
To configure syslog alerting options:
Step 1 Select Policies > Intrusion > Intrusion Policy.
The Intrusion Policy page appears.
Step 2 Click the edit icon ( ) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.
The Policy Information page appears.
Step 3 Click Advanced Settings in the navigation panel on the left.
The Advanced Settings page appears.
Step 4 You have two choices, depending on whether Syslog Alerting under External Responses is enabled:
The Syslog Alerting page appears.
A message at the bottom of the page identifies the intrusion policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy for more information.
Step 5 Optionally, in the Logging Hosts field, enter the remote access IP address you want to specify as logging host. Separate multiple hosts with commas.
Step 6 Select facility and priority levels from the drop-down lists.
See Using Syslog Responses for details on facility and priority options.
Step 7 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.
Understanding Email Alerting
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)
- timestamp, protocol, event message, and session information (source and destination IPs and ports with traffic direction) for each event (if Summary Output is off)
Note If multiple intrusion events originate from the same source IP, a note appears beneath the event that displays the number of additional events.
For each rule or rule group, you can enable or disable email alerting on intrusion events. Your email alert settings are used regardless of which intrusion policy you apply to the device as part of an access control policy.
The following list describes the parameters you can set for email alerting.
Enables or disables email notification.
Specifies the email address or addresses from which the system sends intrusion events.
Specifies the email address where the system sends intrusion events. To send email to multiple recipients, separate email addresses with commas. For example:
Specifies the maximum number of intrusion events the system sends via email in the time frame specified by Frequency (seconds).
Specifies how often the system mails intrusion events. The Frequency setting also specifies the frequency with which email settings are saved.
Minimum frequency: 300 seconds
Maximum frequency: 4 billion seconds
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.
Enables or disables brief email alerting, which is suitable for text-limited devices such as pagers. Brief email alerts contain:
– for Defense Centers, the IP address for the device that generated the event
– the number of intrusion events generated against the same source IP
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.
Configuring Email Alerting
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)
- make sure that both the managed device and the Defense Center can reverse resolve their own IP addresses
To configure email alerting options:
Step 1 Select Policies > Intrusion > Email .
The Email Alerting page appears.
Step 2 Next to State , select on to enable email alerting.
Step 3 In the From Address field, type the address you want to display in the From field in the email alerts.
Step 4 In the To Address field, type the address where you want to receive the email alerts.
Step 5 In the Max Alerts field, type the maximum number of events you want included in a single email.
Step 6 In the Min Frequency field, type the number of seconds for the minimum frequency with which you want to receive email alerts.
Step 7 To group events by IP address, next to Coalesce Alerts , select on .
Step 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.
Step 9 In the Time Zone field, select your time zone from the drop-down list.
Step 10 To enable email alerting per rule, click Email Alerting per Rule Configuration .
Tip To receive email alerts for all rules in all categories, select Select All.
Step 11 Perform one or both of the following:
The system saves your email alerting configuration. When applicable intrusion events occur, you receive email alerts.