Select the three IP protocols that Snort supports for suspicious behavior according to your text
Decoder Snort DetectionDecoder Snort DetectionSnort is a free and open-source intrusion prevention system that uses a rule-based language to detect malicious network traffic. The NetWitness Platform Decoder offers compatibility with Snort detection rules, sometimes referred to as Snort signatures. NetWitness supports importing existing Snort rules into the Decoder, extending the known threats that can be detected. There are many sources for Snort rules, as it is an open source solution. In most cases, the behavior of Snort rules in the Decoder is the same as the rules in other network analysis tools. However, the Decoder does not have coverage for all Snort rule options. The topics in this section highlight NetWitness Platform Decoder-specific details of how to set up Snort parsers, how Snort rules are handled, and explain cases where Decoder might differ in behavior from Snort. Show
Using Snort Rules in Decoders Using Snort Rules in DecodersThe Snort Detection engine is implemented as a built-in native parser in Decoders. The parser's identifier is Snort, and can be found in the Decoder Parsers Configuration page along with the other native parsers enabled by default. The Snort parser reads files from the directory /etc/netwitness/ng/parsers/snort. All files in this directory are read during the Decoder service restart. Files that end in the extension .conf are treated as configuration files. The format for configuration files matches the configuration file format for Snort, although not all configuration directives are supported. Further details are in Configuration Directives . Files that end in the extension .rules are treated as Snort rules files. A rules file can contain one or more rules, and the Snort directory can contain more than one rules file. The rule file format is the same as for Snort itself. The Snort rule files can be loaded into the Decoder by any of the following methods:
However, note the following:
Note: NetWitness recommends that the maximum number of Snort rules in use per Decoder is 1,000. Initial Decoder Snort Configuration Initial Decoder Snort ConfigurationFollow these steps to set up an initial configuration of Snort on a Decoder.
Note: Only the Snort V2.x rules are supported. There are some rule options that are not supported, which are described in Snort Parser Capabilities . Snort Parser OutputSnort Parser OutputWhen a Snort rule matches a session, it produces meta items. The meta items generated may change depending on the configuration of the Snort parser. Snort parser meta key usage has been updated with a new option for the Snort parser. The option, Snort="udm=true" (set to true by default), uses the Aligned Unified Data Model (UDM) key set. For information about UDM, see https://community.netwitness.com/t5/netwitness-platform-unified-data/introduction-to-the-rsa-netwitness-platform-unified-data-model/ta-p/565620. By default, the Aligned UDM key set is used. Note: To pass options to parsers, you must first give the name of the
parser and then the options to be passed in this format: The following keys are generated in the Aligned Unified Data Mode:
The following keys are generated in Legacy Key Mode:
If you want to use the legacy key set which contains keys that are consistent with previous releases for Snort parser meta keys, follow these steps.
Rule Statistics Rule StatisticsThe Snort parser maintains counters to monitor the activity of each rule. These counters can be retrieved using the running snrtStat on the Decoder's /decoder/parsers node, which can be accessed through the NwConsole utility or the REST interface. The statistics reported for each rule are:
To review the Snort statistics when using the Decoder console:
The output is a JSON structure listing the number of evaluations and hits performed, along with the options evaluated, for each Snort ID. Configuration Directives Configuration DirectivesDecoder supports a limited number of configuration directives. Variable Definitions Variable DefinitionsDecoder supports definitions of variables that hold the value of IP ranges using ipvar or Port ranges using portvar. For example, Snort rules usually make use of HOME_NET, EXTERNAL_NET and HTTP_PORTS variables. These have to be defined in your configuration file. If they are undefined, they default to the special value any. ruletype ruletypeThe definition of additional rule types is supported. However, only rules that have a base rule type of alert are supported. Rule type definitions follow the same definition format as Snort configuration. Other Configuration Entries Other Configuration Entriesconfig detection: debugAdding this configuration line turns on debug messages that are generated as the rule is being processed. These debug messages are generally emitted only emitted when a rule matches a session by one of the content patterns, but then fails to match other options within the rule. This is useful for debugging complex filters in Snort rules, to determine why they may not be matching as expected. config nopcreAdding this configuration line turns off the PCRE (regular expression) capability. config classificationClassification configuration influences how meta is generated when a rule matches a session. Meta output from Snort rule matches is described in Snort Parser Output. Snort Parser Capabilities Snort Parser CapabilitiesThe general format of a Snort rule is that it contains a rule header and rule options. The rule header consists of the rule action, protocol type, source-destination criteria (IP addresses, ports), and the direction of traffic. The rule options consist of the message (msg) which describe what the rule has detected, the references related to the threat or where the rule was generated, the classification of the rule, the unique signature (rule) identifier, and a long list of attributes (for example, flow, content, pcre) to define how the traffic is identified. The specific details on which header and rule options are supported are outlined in the remainder of this section. Rule SectionsRule Sections
Content ContentThe Snort content statement makes up the bulk of the Snort pattern detection capability. For best performance, Decoder strives to map content patterns to the Token Parser used by most NetWitness parsers. Therefore, the content strings are the main mechanism to activate the rule matching engine on a session for a particular rule. If the rule does not have any content patterns, it is effectively unsupported. The Snort parser allows for very short strings patterns in content, but be aware that a rule that contains only very short content may have to be evaluated for every session, which will make the Snort Engine run much more slowly. The Snort parser supports most forms of content statements, including the following modifiers. All modifiers effect the last content pattern declared in the rule.
These content modifiers are supported if the Snort parser is used in conjuction with AppHTTP native parser:
Further detail on the HTTP related modifiers is described below in HTTP Parsing . FlowFlowThe flow directive verifies that the rule is only applied to the client or server stream. It supports the following options.
Fast Pattern Fast PatternThe Snort parser uses content tagged with fast_pattern to indicate tokens that should always be used as tokens in the Decoder's token scanner. Decoder supports the fast_pattern and fast_pattern:only directives, but it does not support the fast_pattern:offset,length directive. PCRE PCREThe Snort parser implements pcre regex matching using the same libpcre library as other tools. It supports most of the flags documented for the pcre tag, with a few minor exceptions as described later in this document. HTTP Parsing HTTP ParsingThe Snort parser relies on the native HTTP parser to notify it when HTTP is being parsed. The HTTP parser feeds information to the Snort engine to let it know which regions of the session should be used to evaluate the http content flags. The pcre implementation has option flags analogous to the http content options, and these are supported as well. If the native HTTP parser is disabled, then these features are also disabled in the Snort parser. File DataFile DataThe Snort parser supports the file_data tag for HTTP response bodies only. This functionality relies on the native HTTP parser being enabled. If the Native HTTP parser has the decompression feature turned on, the Snort parser also uses decompressed responses to implement rule matching inside of file_data regions. You can enable the HTTP decompression feature by adding the token HTTP="decompress=true" to the configuration field /decoder/config/parsers.options. The Decoder has a Javascript normalization parser that functions similarly to the normalize_javascript feature in Snort's HTTP preprocessor. It also affects data presented to Snort rules using file_data. To enable the Javascript normalization parser, add the token JSNormalize="unescape=true" to the configuration field /decoder/config/parsers.options. The Snort parser emulates the file_data behavior in the same way as Snort. Directives that appear after file_data are implicitly evaluated whenever a content match is found inside of a file_data region. Because of this, file_data has side effects on other statements that appear after it in a rule. Binary (byte) Directives Binary (byte) DirectivesThe Snort parser supports the byte_test, byte_extract and byte_jump directives. The detection engine supports most options on these directives:
The 'byte_extract directive stores values in variable names that can be used to substitute a number into a few specific locations elsewhere in the rule. These locations are supported:
The byte_jump option explicitly moves the DOE (Detection Offset End) pointer for use by subsequent directives, like byte_test, content marked with distance or within, or PCRE patterns marked as relative. There are some less common byte operations that are not supported:
Default option / fallback Default option / fallbackWhen the Snort parser encounters rule options it does not yet support, it skips those options and assumes they did not prevent the rule from matching. In such cases it relies on the implementation of options it does support, such as the content or pcre statements, to determine if the rule matches. This behavior means that the Snort parser is more likely to fail in the false-positive direction rather than the false-negative direction when using features that Decoder does not yet support. Packet Scanning/Scoping Packet Scanning/ScopingDepending on how the rule is formed, it may be intended to match content entirely within single packets, or it may be intended to match data that spans multiple packets. The Snort parser attempts to handle both cases. Rule statements that are implicitly packet-scoped may be evaluated for every packet available in a session at parse time, and the Snort parser correctly scopes such rules so they only match if the elements of the rule match in a single packet. Conversely, if the rule uses a feature that implies reassembly and reconstruction, such as file_data, the Snort parser will allow the rule to be evaluated for the reconstructed portion of the stream that the rule references. This allows the Snort parser to emulate the various buffers that the Snort product provides. Known Limitations for Snort Parser Known Limitations for Snort ParserDecoder Token Match Limits Decoder Token Match LimitsThe Snort Parser is activated by token scanning in Decoder, and therefore is subject to the same limitations on matches as all Decoder parsers. Configuration items such as parse.bytes.min, parse.bytes.max, timeouts, and size limits all apply to the Snort parser. The Decoder configuration guide describes these parameters in great detail. The Snort parser is implemented on top of reassembled sessions only so that features that require an assembled session can be supported. Flow Bits Flow BitsFlow bit directives, which start with the keyword flowbits, are currently mostly ignored by the Snort detection engine. Statements in rules that test flow bits currently always pass. However, the detection engine will honor flowbit directives that specify noalert. Rules marked as noalert never generate meta, even if they match. DCE Preprocessor DCE PreprocessorThe Snort parser does not currently implement any DCE preprocessors, so any features that rely on the DCE preprocessor are not implemented. Thresholds and Filters Thresholds and FiltersThe Snort parser implements the threshold filters option only. It does not yet implement the detection_filter filter. Raw Byte Scanning Raw Byte ScanningThe Snort parser does not currently allow rules to individually bypass the normalization or decoding using tags like rawbytes. IPv6 IPv6The Snort rule parser does not currently allow rules to utilize IPv6 addresses as part of their header. Note: Only the Snort V2.x rules are supported. Performance Considerations Performance ConsiderationsThe performance of the Snort parser is dependent entirely on the rules that are being evaluated. Therefore it will vary greatly from one installation to another. Content Tokens Content TokensContent tokens form the main entry point into the Snort engine. Hence they are the main factor affecting rules performance. The more times that a content string is found in the packet stream, the more work the Snort parser performs, and the more CPU time it uses. Therefore, it's important to use content tokens that are long, unique, and unlikely to appear in random data. Short tokens will spuriously activate the Snort parser, wasting CPU time. Negation NegationStatements like content and pcre support negation, meaning they only allow the rule to match if a content string is not found or if a regex doesn't match. These are usually detrimental to performance because they still tend to contain strings that will activate rule evaluation, yet will often fail since they are intended to filter out patterns. For example, a negated pcre search still has to be evaluated if it is negated, and if it is used to filter out common text. it will produce lots of CPU activity on traffic that does not actually match the Snort rule. |