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.