Enterasys Intrusion Prevention System Manual page 20

Network Sensor Policies
Dragon Filter Module
The Dragon Filter module allows you to eliminate the reporting of events that you know are not
significant on your network—that is, are just "background noise" that can safely be ignored. For
example, you may use the SNMP public community for your network management. When you
use the Enterasys IPS reporting tools to view Enterasys IPS events being generated on your
network, you may notice that there are thousands of SNMP:PUBLIC events being generated from
a source IP address that matches the address of your management station. In such a case, you can
safely ignore those events, so you would write a Dragon filter that would drop (not report)
SNMP:PUBLIC events if the source IP address equals the IP address of your management station.
The events that can be filtered with Dragon filters include those generated by signatures applied
to a sensor (for example, the signature with the name SNMP:PUBLIC) as well as internal events
generated by a network policy applied to a sensor (for example, the ICMP:BD-REPLY event is
generated by backdoor analysis configured with the Covert Channel Analysis module).
Dragon filters are applied after data has been inspected, unlike Application filters that are applied
before data has been inspected. Therefore, Dragon Filter statements could be considered more
CPU intensive, in the sense that they can only be applied after the pattern matching operations are
completed. However, since both Dragon Filters and Application Filters are fairly quick operations,
neither greatly impacts the sensor's performance (unless there are hundreds of them).
Dynamic Module
The Dynamic Module is one of the default modules added to every custom policy. It enables the
sensor to record packets from IP addresses that are involved in events. When an event occurs, the
Network Sensor makes a best effort to grab subsequent packets from the source and destination IP
addresses of the event packet. The number of recorded packets is determined by the specific alarm
or signature. Additional Dynamic packet logging can be set for all events, by specifying the
number of Cushion packets the Network Sensor should collect in addition to the normal number
of packets specified by the signature or alarm.
For example, if a PHF attack signature has a Dynamic packet capture level of 10 packets and the
Cushion value is set to 5 packets in this module, the Network Sensor will attempt to collect 15
packets. This parameter is meant as an easy way to quickly turn up the sensitivity of a Network
Sensor. The extra logging may have a negative impact on system performance or on Network
Sensor hard drive space.
Header Search Module
The Header Search module allows you to configure the Network Sensor to search IP and TCP
headers for a specific string of data. When you configure a Header Search rule, you identify:
• A start byte and a stop byte in the header of either IP or TCP traffic. These bytes specify the
part of the header to check.
• The frequency, in packets, of the check. A frequency of 0 means check all packets.
• The pattern to search for.
• The name of the event to generate when the rule is matched.
Refer to
to search for.
1-6 Network Sensor Overview
"Specifying Search Strings" on page 2-29 for information about how to specify the pattern