Saturday

Network Intrusion Detection Systems Types



NIDSs are normally classified according to the methods they use for attack detection; either as signature-based, or anomaly detection. Note, though, that almost all current NIDSs use a mixture of these approaches. Signature-based approaches, as mentioned earlier in this chapter, rely on some type of pattern matching. NIDS sensors parse the entire IP packet, and make decisions by means of a simple rule-based logic that is based upon signatures or regular expression matching. In other words, they compare the data within a packet payload to a database of predefined attack signatures (a string of bytes). Additionally, statistical or historical algorithms may supplement static pattern matching. Attack signatures usually consist of one or more of the following fields:
  • Source and destination IP addresses, or an address or range
  • TCP/UDP source and destination ports and ICMP type/code
  • IP header flags and options
  • TCP header flags and options
  • A definition of the payload data to search (hex or ASCII)
  • A starting point for the payload search (offset) and the search depth
Analysis of packet headers can be done economically since the locations of packet header fields are restricted by protocol standards. However, the payload contents are, for the most part, unconstrained. Therefore, searching through the payload for multiple string patterns within the datastream can be a computationally expensive task. The requirement that these searches be performed at wirespeed only adds to the cost.
Anomaly detection NIDSs are based on the assumption that normal traffic can be defined, and that attack or misuse patterns will differ from “normal” traffic. Heuristic-based signatures, on the other hand, use some type of algorithmic logic on which to determine their alarm decisions.
Note 
Heuristic is the art and science of discovery and invention. The word comes from the same Greek root as “eureka,” which means “I find.” Heuristics defines a problem-solving technique in which the most appropriate solution is selected at successive stages of a program for use in the next step of the program. Heuristic approaches utilize simplification or an educated guess to reduce or limit the search for solutions. A heuristic can be a single algorithmic solution to a problem, but unlike an algorithm, heuristics does not guarantee optimal, or even feasible, solutions.
These algorithms are often statistical evaluations of the type of traffic being inspected. An example of a heuristic signature is a signature used to detect a port scan. This signature defines a particular threshold number of external probes against unique ports or a specific combination of ports. The signature may be further restricted by specification of the types of packets (for instance, SYN only) it reacts to. Interesting trends can be learned from these data, and it is possible to detect ongoing attacks based on these algorithms; however, the information that these systems provide is generally very nonspecific and requires extensive human investigation before actionable intelligence is gathered.
By creating baselines of normal behavior, anomaly-based NIDSs are able to detect when current network behavior deviates statistically from the norm. This capability theoretically gives an anomaly-based NIDS the capacity to detect new attacks that are either unknown or to detect attacks for which no signatures exist.
The major problem with this type of approach is that normal network traffic is difficult or impossible to define. Since normal network behavior can change easily and readily,anomaly-based NIDSs are prone to false positives. Additionally, inconsistency of detector performance, training issues (for example, how often an anomaly-based detection system should be retrained to ensure acceptable performance), and inadvertent incorporation of intrusive behavior into an NIDS concept of normal behavior during training negatively affect performance.

Tuesday

Network Intrusion Detection Systems Components


Most NIDSs are configured in a client- (sensor) to-server (management console) configuration. Many sensors normally report to one or several management consoles. Sensors can be dedicated appliances, can run as an application on a host running other applications, or can run independently in a virtual subsystem such as VMware or Xen. Note that if the sensor does not reside on a dedicated appliance, then the OS of the host computer should be hardened.
Because NIDSs do not reside in the datapath (normally one NIC is used as a sensor and a second NIC is used for management traffic), the sensor Ethernet interface can be configured in a number of ways as receive only. Sensor hardware requirements are not particularly strict since the sensor application normally inspects packets, and upon finding a signature or pattern match, sends the subsequent data upstream to the management console for processing and visualization.
The term “signature” refers to a set of conditions that, when met, indicate some type of intrusion event. Typical modern sensors contain a signature database consisting of 1000 to 2000 entries. Often, sensors inspect traffic based upon a mixture of signature matching as well as pattern matching. Pattern matching is based on looking for a fixed sequence of bytes in a single packet. A more sophisticated method is stateful pattern matching. Stateful pattern matching is useful when the intrusion signature spans more than a single packet. Similar to antivirus software, a signature-based IDS requires regular access to an up-to-date database of attack signatures so recent exploits are not missed.
Figure 1 is a simple illustration of the basic logic used by NIDS management stations when resolving an event reported by a remote sensor. The “Match IDS Rule” logic normally resides on the sensor. When a rule is matched (for example: “packet from outside to inside contains illegal SIP rerouting headers”), the data is forwarded to the management console where it is prioritized, logged, and visualized.


Figure 1: NIDS Logic
The management console (MC) hardware requirement is normally stricter than that of the sensor since the MC is responsible for data correlation from multiple sensors, as well as storage, alerting, and visualization. Often, the MC also includes an integrated sensor.
Related Posts with Thumbnails

Link Exchange