Creating a Forensic Settings profile
Forensics profiles provide a mechanism to define and load different pairings of settings and rules profiles. Settings profiles define pre-processor settings that let you tune performance; rules profiles define which forensic rules are to be processed during analysis to catch threats against particular target operating systems and web servers. Because Observer performs signature matching on existing captures rather than in real time, its preprocessor configuration differs from that of native Snort. When you import a set of Snort rules that includes configuration settings, Observer imports rules classifications, but uses its own defaults for the preprocessor settings.
Note: There is a difference between enabling the preprocessor and enabling logs for the preprocessor. For example, you can enable IP defragmentation with or without logging. Without logging, IP fragments are simply reassembled; only time-out or maximum limit reached messages are noted in the Forensics Log and in the Forensic Analysis Summary window. If logging is enabled, all reassembly activity is displayed in the Forensics Log (but not displayed in the Forensic Analysis Summary).
1. On the Home tab, in the Capture group, click GigaStor.
2. Click the Forensic Analysis tab.
3. Right-click anywhere on the Forensic Analysis tab and choose Forensic Settings from the menu. The Select Forensic Analysis Profile window opens.
4. Choose your profile and click Edit. The Forensic Settings window opens.
5. From the Forensic Settings window, complete the following:
Import Snort rules
Define Forensic Settings.
Define Rule Settings—Select the rules you want to enable.
6. Close all of the windows, then right-click anywhere on the Forensic Analysis tab and choose Analyze from the menu.
applies the rules and filters to the capture data and displays the results in the Forensics Summary tab.
The top portion of the Rules window lists the rules that were imported, grouped in a tree with branches that correspond to the files that were imported.
Rule classifications offer another level of control. Check the “Rules must also match rule classifications” box to display a list of defined rule classifications. Classifications are defined at import time by parsing the Snort config classification statements encountered in the rule set. Rules are assigned a classification in the rule statement’s classtype option.
Select the rule classification(s) you want to enable. If classification matching is enabled, a rule and its classification must both be enabled for that rule to be processed. For example, suppose you want to enable all policy violation rules: simply right-click on the rule list, choose Enable all rules, and then enable the policy violation classification.
Table 37. Forensic Settings options
Settings Profile
Settings Profiles provide a mechanism to save and load different preprocessor settings, and share them with other Observer.
IP Flow
Packets belong to the same IP flow if they share the same layer 3 protocol, and also share the same source and destination addresses and ports. If this box is checked, forensic analysis identifies IP flows (also known as conversations), allowing Snort rules to isolate packets by direction and connection state via the flow option. If this pre-processor is disabled, flow keywords are ignored, but the rest of the rule is processed. The remaining settings allow you to throttle flow analysis by limiting the number of flows tracked, and by decreasing the time window within which a flow is considered active.
IP Defragmentation
Some types of attacks use packet fragmentation to escape detection. Enabling this preprocessor causes forensic analysis to identify and reconstruct fragmented packets based on the specified fragment reassembly policy. Rules are then run against the reconstructed packets during forensic analysis. The fragment reassembly policy mimics the behavior of various operating systems in what to do when ambiguous fragments are received. Choose the policy to match the OS of the server (or servers) being monitored. If the buffer contains traffic targeting hosts with different operating systems, use post-filtering to isolate the traffic before forensic analysis so that you can apply the correct policy.
Defragmentation Policy is:
BSD=AIX, FreeBSD, HP-UX B.10.20, IRIX, IRIX64, NCD Thin Clients, OpenVMS, OS/2, OSF1, SunOS 4.1.4, Tru64 Unix, VAX/VMS
Last data in=Cisco IOS
BSD-right=HP JetDirect (printer)
First data in=HP-UX 11.00, MacOS, SunOS 5.5.1 through 5.8
Linux=Linux, OpenBSD
Windows=Windows (95/98/NT4/W2K/XP)
Refer to for more detailed version-specific information. The remaining options allow you to enable logging of alerts and reconstruction progress, limit the number of activepacket fragments to track, and change the length of fragment inactivity that causes the fragment to be dropped from analysis.
TCP Stream Reassembly
Another IDS evasion technique is to fragment the attack across multiple TCP segments. Because hackers know that IDS systems attempt to reconstruct TCP streams, they use a number of techniques to confuse the IDS so that it reconstructs an incorrect stream (in other words, the IDS processes the stream differently from that of the intended target). As with IP fragmentation, forensic analysis must be configured to mimic how the host processes ambiguous and overlapping TCP segments, and the topology between attacker and target to accurately reassemble the same stream that landed on the target. Re-assembly options are described below:
TCP Stream Reassembly (Continued)
Log preprocessor events—Checking this box causes forensic analysis to display all activity generated by the TCP stream assembly preprocessor to the log.
Maximum active TCP streams tracked—If this value is set too high given the size of the buffer being analyzed, performance can suffer because of memory consumption. If this value is set too low, forensic analysis can be susceptible to denial of service attacks upon the IDS itself (i.e., the attack on the target is carried out after the IDS has used up its simultaneous sessions allocation).
Drop TCP streams inactive for this duration—A TCP session is dropped from analysis as soon as it has been closed by an RST message or FIN handshake, or after the time-out threshold for inactivity has been reached. Exercise caution when adjusting the time-out, because hackers can use TCP tear-down policies (and the differences between how analyzers handle inactivity vs. various operating systems) to evade detection.
TTL delta alert limit—Some attackers depend on knowledge of the target system’s location relative to the IDS to send different streams of packets to each by manipulating TTL (Time To Live) values. Any large swing in Time To Live (TTL) values within a stream segment can be evidence of this kind of evasion attempt. Set the value too high, and analysis will miss these attempts. Setting the value too low can result in excessive false positives.
Overlapping packet alert threshold—The reassembly preprocessor will generate an alert when more than this number of packets within a stream have overlapping sequence numbers.
Process only established streams—Check this box if you want analysis to recognize streams established during the given packet capture.
Reconstruct Client to Server streams—Check this box to have analysis actually reconstruct streams received by servers.
Reconstruct Server to Client streams—Check this box to have analysis actually reconstruct streams received by clients.
Overlap method—Different operating systems handle overlapping packets using one of these methods. Choose one to match the method of the systems being monitored.
TCP Stream Reassembly (Continued)
Reassembly error action—Discard and flush writes the reassembled stream for analysis, excluding the packet that caused the error. Insert and flush writes the reassembled stream, but includes the packet that caused the error. Insert no flush includes the error-causing packet and continues stream reassembly.
Reassembled packet size threshold range—Some evasion strategies attempt to evade detection by fragmenting the TCP header across multiple packets. Reassembling the stream in packets of uniform size makes this easier for attackers to slip traffic past the rules, so forensic analysis reassembles the stream using random packet sizes. Here you can set the upper and lower limits on the size of these packets.
Reassembled packet size seed value—Changing the seed value will cause forensic analysis to use a different pattern of packet sizes for stream reassembly. Running the analysis with a different seed value can catch signature matches that would otherwise escape detection.
Port List—Enabling the Port List option limits analysis to (or excludes from analysis) the given port numbers.
HTTP URI Normalization
Many HTTP-based attacks attempt to evade detection by encoding URI strings in UTF-8 or Microsoft %u notation for specifying Unicode characters. This preprocessor includes options to circumvent the most common evasion techniques. To match patterns against the normalized URIs rather than the unconverted strings captured from the wire, the VRT Rules use the uricontent option, which depends on this preprocessor. Without normalization, you would have to include signatures for the pattern in all possible formats (using the content option), rather than in one canonical version.
Log preprocessor events—Checking this box causes forensic analysis to save any alerts generated by the HTTP preprocessor to the log, but not the Forensic Summary Window.
Maximum directory segment size—Specifies the maximum length of a directory segment (i.e., the number of characters allowed between slashes). If a URI directory is larger than this, an alert is generated. 200 characters is reasonable cutoff point to start with. This should limit the alerts to IDS evasions.
Unicode Code Page—Specify the appropriate country code page for the traffic being monitored.
Normalize ASCII percent encodings—This option must be enabled for the rest of the options to work. The second check box allows you to enable logging when such encoding is encountered during preprocessing. Because such encoding is considered standard, logging occurrences of this is not recommended.
HTTP URI Normalization (Continued)
Normalize percent-U encodings—Convert Microsoft-style %u-encoded characters to standard format. The second check box allows you to enable logging when such encoding is encountered during preprocessing. Because such encoding is considered non-standard (and a common hacker trick), logging occurrences of this is recommended.
Normalize UTF-8 encodings—Convert UTF-8 encoded characters to standard format. The second check box allows you to enable logging when such encoding is encountered during preprocessing. Because Apache uses this standard, enable this option when monitoring Apache servers. Although you might be interested in logging UTF-8 encoded URIs, doing so can result in a lot of noise because this type of encoding is common.
Lookup Unicode in code page—Enables Unicode codepoint mapping during pre-processing to handle non-ASCII codepoints that the IIS server accepts.
Normalize double encodings— This option mimics IIS behavior that intruders can use to launch insertion attacks. Normalize bare binary non ASCII encodings—This an IIS feature that uses non-ASCII characters as valid values when decoding UTF-8 values. As this is non-standard, logging this type of encoding is recommended.
Normalize directory traversal—Directory traversal attacks attempt to access unauthorized directories and commands on a web server or application by using the /./ and /../ syntax. This preprocessor removes directory traversals and self-referential directories. You may want to disable logging for occurrences of this, as many web pages and applications use directory traversals to reference content.
Normalize multiple slashes to one—Another directory traversal strategy is to attempt to confuse the web server with excessive multiple slashes.
Normalize Backslash—This option emulates IIS treatment of backslashes (i.e., converts them to forward slashes).
ARP Inspection
Ethernet uses Address Resolution Protocol (ARP) to map IP addresses to a particular machine (MAC) addresses. Rather than continuously broadcasting the map to all devices on the segment, each device maintains its own copy, called the ARP cache, which is updated whenever the device receives an ARP Reply. Hackers use cache poisoning to launch man-in-the-middle and denial of service (DoS) attacks. The ARP inspection preprocessor examines ARP traffic for malicious forgeries (ARP spoofing) and the traffic resulting from these types of attacks.
Log preprocessor events—Checking this box causes forensic analysis to save any alerts generated by the ARP Inspection preprocessor to the log, but not the Forensic Summary Window.
Report non-broadcast requests—Non-broadcast ARP traffic can be evidence of malicious intent. Once scenario is the hacker attempting to convince a target computer that the hacker’s computer is a router, thus allowing the hacker to monitor all traffic from the target. However, some devices (such as printers) use non-broadcast ARP requests as part of normal operation. Start by checking the box to detect such traffic; disable the option only if analysis detects false positives.
Telnet Normalization
Hackers may attempt to evade detection by inserting control characters into Telnet and FTP commands aimed at a target. This pre-processor strips these codes, thus normalizing all such traffic before subsequent forensic rules are applied.
Log preprocessor events—Checking this box causes forensic analysis to save any alerts generated by the Telnet Normalization preprocessor to the log, but not the Forensic Summary Window.
Port List—Lets you specify a list of ports to include or exclude from Telnet pre-processing. The default settings are appropriate for most networks.
Variable Name
A scrollable window located below the preprocessor settings lists the variables that were imported along with the Snort rules. Variables are referenced by the rules to specify local and remote network ranges, and common server IP addresses and ports. You can edit variable definitions by double-clicking on the variable you want to edit.
The VRT Rule Set variable settings (and those of most publicly-distributed rule sets) will work on any network without modification, but you can dramatically improve performance by customizing these variables to match the network being monitored. For example, the VRT rules define HTTP servers as any, which results in much unnecessary processing at runtime.
Address variables can reference another variable, or specify an IP address or class, or a series of either. Note that unlike native Snort, Observer can process IPv6 addresses.
Port variables can reference another variable, or specify a port or a range of ports. To change a variable, simply double-click the entry. The Edit Forensic Variable dialog shows a number of examples of each type of variable which you can use as a template when changing values of address and port variables.