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.

Components of WBM | Web-Based Management

Components for WBM can be written in any language, including HyperText Markup Language (HTML), Common Gateway Interface (CGI) scripts, and Java.

HTML provides a standardized way to create pages of Web-based information and embed hyperlinks that lead the user to other pages. While HTML pages are usually static and textual, they can be made interactive by embedding graphics and active elements, such as Java applets and CGI applications, within the page. HTML is the ideal tool for displaying tables, such as network inventory details and IP address listings.

CGI is not a language: it is a protocol used to access database information. For example, a WBM application may need to display the current number of incomplete work orders. This data could be stored in the database of a proxy workstation. A CGI application written in Java or Perl can be used to query the database and format an HTML page to display the information.

Java is rapidly emerging as an important tool for managing an intranet through a WBM system. Java is an interpretive programming language. Java code is not compiled before run time but is interpreted by a Java Virtual Machine (JVM) at run time. JVMs are available for many processor environments and are included with some Web browsers, such as Netscape Navigator and Microsoft Internet Explorer, enabling these browsers to execute Java code.

While Java can be used to build standalone applications and does not have to be scripted for Web-accessible applications, the importance of Java for Web-based management systems is its built-in Web-enabled capabilities. Applets, self-contained Java programs, are sent from the server to a browser-equipped client where they are run locally (Figure 1). Other CGI scripting languages such as Perl, another popular language used for Web-based applications development, run on the server. The back and forth nature of Perl has the drawback of consuming processing resources and network bandwidth, which can inhibit the application's performance.

Figure 1: Java applets work in one direction: server to client.

Applets have browser-imposed security restraints that limit access to network resources and prevent access to local system resources, such as memory and disk. Thus, applets can be run on the receiving machine with minimal risk while ensuring network security.

Java applets, which can be served from both proxy and embedded Web-server WBM implementations, can be used for:

§  Displaying dynamic graphs that interpret network operations

§  Illustrating complex situations, such as interactive views of chassis hubs or modules of a stackable hub

§  Displaying real-time data that are updated from polling and traps

§  Adding graphics, including animation

Because Java can produce applications that are portable across Unix, Windows, and other environments, a JVM can be embedded in an end device and the device agent can then execute Java code. This capability enables code to be ported across other devices with JVMs. A key facet of this capability is that the code can be distributed dynamically, ported from a management proxy to devices, and ported between devices or components within a device (Figure 2).

Figure 2: An embedded agent with a Java Virtual Machine.

The use of Java within an embedded agent can increase management capabilities by enforcing policy-based management or security rules. For example, assume that an administrator wants to enable remote network access between 6:00 a.m. and 6:00 p.m. Traditional methods, such as SNMP sets, have been used to enforce such restrictions but at the cost of increasing network traffic and with the difficulty of scaling to handle thousands of devices. While a device-resident agent could perform this function, agent releases are typically infrequent. An embedded agent with a JVM could independently create the scheduling routine and dynamically distribute the policy to restricted devices, bypassing the need for an agent release.

H.323 Architecture Components

H.323 specifies components, protocols, and procedures for real-time point-to-point and multipoint multimedia communications over packet-based networks. It also sets interoperability guidelines for communication between H.323-enabled networks and the H.32X-based family of conferencing standards.

An H.323 implementation requires four logical entities or components. These are terminals, gateways, gatekeepers, and MCUs. A fifth component element, known as border elements, is optional. Terminals, gateways, and MCUs are collectively known as endpoints. Although an H.323 network can be configured with only terminals, the other components are essential to provide greater practical usefulness of the services.

Terminal

A terminal, or a client, is an endpoint where H.323 data streams and signaling originate and terminate. In an IP-PBX system, it may be an IP telephone; a non-IP communications device, such as an analog telephone with an IP adapter module; or a PC client softphone with an H.323 compliant stack. A terminal must support audio communication; video and data communication supports are optional.

Gateway

A gateway is an optional component in an H.323-enabled network. A gateway will be required if at least one of the terminals does not conform to H.323 standards but is designed for a different type of network. The gateway is usually located at the interface between the two networks. Through the provision of gateways in H.323, it is possible for H.323 terminals to interoperate with other H.32X-compliant conferencing terminals. For example, a PC client softphone station user can talk to a station user on an analog telephone. A gateway provides data format translation, control signaling translation, audio and video codec translations, and call setup and termination functionality on both sides of the network. Gateway equipment is composed of a Media Gateway Controller (MGC) and a Media Gateway (MG), which may co-exist or exist separately. The MGC handles call signaling and other nonmedia-related functions, and the MG handles the media. There are different types of gateways required to support H.310, H.320, H.321, H.322, or H.324 endpoints.

Gatekeeper

A gatekeeper is an optional component of an H.323-enabled network. Gatekeepers ensure reliable, commercially feasible communications and are used for admission control and address resolution. The gatekeeper may allow calls to be placed directly between endpoints or it may route the call signaling through itself to perform functions, such as followme/find-me, forward on busy, etc. A gatekeeper is often referred to as the controller of the H.323 enabled network, because it provides central management and control services. When a gatekeeper exists, all end- points (terminals, gateways, and MCUs) must be registered with it. Registered endpoints’ control messages are routed through the gatekeeper.

The gatekeeper and the endpoints it administers form a management zone. A gatekeeper provides several services to all endpoints in its zone.

Address translation. A gatekeeper maintains a database for translation between aliases, such as international phone numbers, and network addresses.

Admission and access control of endpoints. This control can be based on bandwidth availability, limitations on the number of simultaneous H.323 calls, or the registration privileges of endpoints.

Bandwidth management. Network administrators can manage bandwidth by specifying limitations on the number of simultaneous calls and by limiting authorization of specific terminals to place calls at specified times.

Routing capability. A gatekeeper can route all calls originating or terminating in its zone. This capability provides numerous advantages: accounting information of calls can be maintained for billing and security purposes; a gatekeeper can reroute a call to an appropriate gateway based on bandwidth availability; and rerouting can be used to develop advanced services such as mobile addressing, call forwarding, and voice mail diversion.

Multipoint Control Unit

The MCU is an optional component of an H.323-enabled network. It is responsible for managing multipoint conferences (two or more endpoints engaged in a conference). It consists of a mandatory Multipoint Controller (MC) that manages the call signaling and optional Multipoint Processors (MPs) to handle media mixing, switching, or other media processing. Although the MCU is a separate logical unit, it may be combined into a terminal, gateway, or gatekeeper.

The MC provides a centralized location for multipoint call set-up. Call and control signaling are routed through the MC so that endpoint capabilities can be determined and communication parameters negotiated. An MC may also be used in a point-to-point call, which can later be extended into a multipoint conference. The MC may also determine whether to unicast or multicast the audio and video streams depending on the capability of the underlying network and the topology of the multipoint conference.

The MCU is required in a centralized multipoint conference, where each terminal establishes a point-to-point connection with the MCU. The MCU determines the capabilities of each terminal and sends each a mixed media stream. In the decentralized model of multipoint conferencing, an MC ensures communication compatibility, but the media streams are multicast and the mixing is performed at each terminal.

Border Elements

Border elements are often colocated with a gatekeeper. They exchange addressing information and participate in call authorization between administrative domains. Border elements may aggregate address information to reduce the volume of routing information passed through the network and assist directly in call authorization/authentication between two administrative domains or via a clearinghouse.