El proceso de trabajo con el Index para la inclusión

Many of the existing parallel approaches try to reduce the input into the NIDS through pre-őltering of packets and to avoid synchronization problems between various IDS threads by turning off pipeline stages which has far-reaching consequences for the detection capabilities of the systems. This section discusses these consequences for three existing parallelization approaches. The Gnort approach of Vasiliadis et al. [74] switches off the preprocessing, the rule evaluation, and the logging (see Fig. 3.7). This essentially leads to a kind of network grep10

, but not to a functional NIDS. Later the same authors have developed a system, called MIDeA [135], that enables at least the preprocessing stage, but continued to disable the rule processing and the logging. This expands the capabilities of the system from a pure packet-based analysis to a ŕow- based analysis. The load-balancing approach presented in the publication, however, has the problem that it cannot distribute bidirectional ŕows (bi-ŕows). Thus, the analysis of attacks in which both communication directions are related to each other (e.g., the client request has to be correlated with the server response to detect the attack) is not possible. Another approach by Jamshed et al. ś Kargus [128] ś disables the pre-processing stage and applies data parallelism on a packet level. Since this approach does not allow analyzing ŕows, it essentially disables the rule evaluation with respect to the ŕow state. This means, for example, that search patterns which span multiple packets cannot be detected in the multi-pattern search. In addition, attacks that require a correlation of multiple data ŕows among themselves, e.g., port scans during the reconnaissance, are not recognized in the rule evaluation.

10

3 Local High-Speed Monitoring with Parallel NIDS

data acquisition/

packet decoder pre-processor multi pattern_{search evaluation}rule signatures alerts/events alerts/ events network logging signature analysis flows / packets packets packets

Figure 3.7: Typically removed pipeline stages in current parallel NIDS approaches Moreover, the way in which parallel NIDS systems are evaluated is questionable. Turn- ing off pipeline stages, for example, shifts the baseline of the experiments, which is not discussed in any of these papers. This is illustrated in Table 3.5. As can be seen in this table, turning off the preprocessor for the ŕow analysis speeds up the performance between 50% and 300%. Therefore, it is unclear whether the performance of previous parallelization approaches (which are unfortunately often not speciőed as performance increases over a clear baseline) result from the parallelization or from the shut-down of pipeline stages. The table also shows how extremely the shut-down of the őrst pipeline stage inŕuences the detection rate of Snort. It detected only between 19 and 24% of the attacks.

ŕows enabled ŕows disabled detected

MBit/s kpkt/s MBit/s kpkt/s speedup attacks

west_pt 298.5 256.4 428.9 368.3 1.44 24.1%

acsac06 258.2 59.4 771.0 177.4 2.99 19.4%

Table 3.5: Performance versus accuracy of Snort with/without ŕow analysis Further questionable assumptions of former approaches are the distribution of normal and attack data in traffic: (1) Typically it is assumed that more than 99% of the net- work traffic are normal data which do not contain any attacks. NIDS are optimized for this case and are signiőcantly less efficient if this distribution changes. (2) In the understanding of these approaches, an attack is often based on one attacker, one vul- nerability, and one target. Sometimes multiple targets are attacked, but the limitation to one attacker and one vulnerability often persists. Real attack behavior is, however, different. Figure 3.8 represents different traffic situations that may occur during an attack. The NSA data sets used in the Section 3.1 have already shown that an attacker usually does not exclusively attack a single system, but also executes DOS attacks for distraction purposes (left side of the őgure). Traffic patterns that are found during a DOS attack possess an 1:n relationship, e.g., one attacker, one host, n connections for SYN ŕooding, or one attacker and many hosts during DOS attacks on multiple hosts. Other DOS attack options are reŕection attacks with an n:1 relationship, e.g., during a SYN ŕooding attack with a forged sender address, in which the answers are sent to

3.4 Design Options for Fully Functional Parallel NIDS Architectures     



Figure 3.8: Reconnaissance, takover, and DOS behavior

the destination of the faked address (upper left part of the figure). Some reflection attacks have a 1:1 relationship, i.e., the attacker sends small packets to a server by means of a faked source address. The typically larger response of the server compared to the input is then sent to the faked address (lower left part of the figure). At the same time, the attacker performs his/her targeted attacks (right side of the figure). In the first phase (reconnaissance) this involves massive scans of the target network with similar traffic characteristics as in DOS attacks. After that there are usually tar- geted infections (takeover) of individual hosts, which are sometimes lost in the noise of the DOS attacks. If the transmitted malicious software has its own distribution routines, another harmful traffic emanates from each infected host, e.g., as observed during worm propagation. All of these traffic patterns typically produce a massively larger traffic volume, as assumed in former analyses of parallel NIDSs. Unfortunately, NIDSs are not optimized for this kind of traffic and respond with a huge decrease in analysis efficiency.

3.4 Design Options for Fully Functional Parallel

NIDS Architectures

For each parallelization approach, it is important to determine in advance the compo- nents, functions, and algorithms that are crucial for the computing time. The micro- benchmark mechanism of Snort used in Section 3.1 has provided first indications for this (cf. Table 3.3). It identified the detection engine as the most compute-intensive component. In addition, this component can be parallelized in a safe manner without any major impact on the other pipeline stages which is necessary for a fully func-