Network Security Fundamentals [Electronic resources] نسخه متنی

Network-Based IDSs

Similar to host IDSs are network-based IDSs, which are an integral part of the monitoring phase of the security policy.

Network-based intrusion detection is the deployment of real-time monitoring probes at vital locations in the network infrastructure. These probes, also called

network sensors , analyze the traffic and detect unauthorized activity as well as malicious activity. Depending on the type of offensive strategy an organization has chosen, the probes take appropriate action, as discussed later in this section.

One of the main advantages of deploying network-based systems over host-based systems is the fact that network administrators are able to continually monitor their networks no matter how the networks grow. Adding hosts does not necessarily require the addition of extra network-based intrusion sensors.

Network Sensor Components and Architecture

The network IDS has two interfaces, which are typically connected to different segments of an organization's network. The first one, called the monitoring port, is responsible for capturing data for analysis. The monitoring port should be connected to the network segment that has potential targets connected, such as mail servers, web servers, and so on. The second port, often referred to as the command and control port, is responsible for sending triggers (alarms) to the management platform. Similar to the host-based Cisco Secure Agent Manager, this platform is used for configuring the network sensors, logging and displaying the alarms, and generating reports on request. Figure 10-9 illustrates the configuration being attacked.

Figure 10-9. Network-Based IDS Overview

[View full size image]

The following list outlines the steps involved in the attack and its rebuff:

An attack is launched on the mail server via the Internet (public network).

Packets travel over the network to the destination, which is the mail server in this case. The data port of the network sensor also captures all these packets.

For fragmented packets in different frames, packet reassembly is required. This happens at the packet's final destination (the mail server) and also at the network sensor.

The network sensor compares the data against the configured rules set.

For all detected attacks, the network sensor generates a log and notifies the network management station.

The network management station sends alarms, generates a log, and starts a response action to the attack.

NOTE

Cisco often refers to the IDSs management station as the

director . The director is part of the Cisco Secure Policy Manager (CSPM) and can be a standalone UNIX director or, in the latest releases, part of the CiscoWorks VMS suite.

From an architectural viewpoint, the network-based IDSs have three separate components: the network sensor, the director, and the communication mechanism between the previous two. This section focuses on the network sensor architecture. Figure 10-10 illustrates the basic architecture of the IDS sensor.

Figure 10-10. Network-Based IDS Architecture

[View full size image]

The network-based IDS sensor runs on Linux and has multiple components (software services), each interconnected and handling different processes. One of the main components is the cidWebServer. The web server uses different servlets to provide IDS services. The cidWebServer communicates with the event server, transaction server, and IP log server servlets using the Remote Data Exchange Protocol (RDEP). RDEP serves as the sensor's communication protocol.

Table 10-5 illustrates some of the network IDS components and their functionality.

Table 10-5. Main Network IDS Architecture Components
Component	Function
cidWebServer	HTTP/HTTPS communication with event server (IEV), transaction server (configure/control sensor), IP log server (IP logging alarms to external systems).
cidCLI	Command-line interface or CLI used for troubleshooting and configuration of the sensor via Telnet or SSH.
NAC	Network access controller is used to communicate with network devices for IP blocking.
SensorApp	Core engine of the sensor, processes signature and alarms.

The combination of these different services results in a security system that is robust and resilient. New trends can be easily added, which makes this solution easily scalable.

Deploying Network-Based Intrusion Detection in the Network

Network IDSs are developed so that when deployment is carefully planned at designated network points, the network administrator or security personnel can monitor the data (network activity). When the monitoring takes place, the data is traveling only on the network. Therefore, the administrator has the opportunity to take proper action without needing to know what the exact target of the attack is because the IDS monitors the complete segment.

A number of steps or tasks need to be considered when deploying network sensors in your network. Installing the network sensors requires some planning before actually starting to connect the sensors to the network. It is the task of the security network administrators to determine what traffic needs to be monitored to protect all critical assets of the organization.

When planning for sensor placement, a network administrator must consider the size and complexity of the network, interconnectivity with other networks, and the amount and type of network traffic. After collecting this information and also knowing what information requires protection, the sensor location and sensor type (based on bandwidth) can be defined.

Sensors placed on the inside network have different duties than sensors placed on the outside network. Figure 10-11 illustrates the network sensor placement using a scenario that includes a number of attacks on a web server connected on a DMZ.

Figure 10-11. Network-Based IDS Sensor Placement

Cisco Catalyst 4000 series switches: http://www.cisco.com/en/US/products/hw/switches/ps663/products_configuration_guide_chapter09186a008012236172

Cisco Catalyst 6500 series switches: http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_guide_chapter09186a008007f323l

After connecting the network sensor interfaces, the sensor can be configured either locally via a console or remotely using a network management station.

Before starting to tune the sensor, which is the most important part of the network IDS deployment, it is recommended to use the sensor with the initial sensor configuration and analyze the alarms generated the first couple days. Analyzing the different alarms and tuning out the false positives produces a high-performing security system. Also keep in mind that not every sensor needs to trigger an alarm on every event. Here again, the importance of clearly defined network security policies is obvious. It is also clear that tuning the sensors is an iterative process. Traffic patterns can and do change over time, and sensor tuning is a must.

Once the initial tuning phase is finished, the network administrator can selectively implement response actions. Small organizations that are willing to investigate the deployment of IDSs can start deploying Cisco IOSbased IDSs on a router or PIX-based IDS, instead of buying standalone sensors. The following section presents a brief overview of router IDS and PIX IDS.

Router IDS Features and Network Modules

The router IDS feature is a built-in functionality in Cisco IOS, enabling the router to be configured as network intrusion detection sensors. The sensors have only a limited number of signatures.

Because Cisco Secure Integrated Software is an in-line device, it inspects packets as they traverse the router's interfaces. This impacts network performance to a certain extent. When a packet, or a number of packets in a session, matches a signature, the router configured as network IDS can perform the following configurable actions:

Alarm
Sends an alarm to syslog server or management station
Drop
Drops the packet
Reset
Resets the TCP connection

The router IDS module is a hardware router module that can be installed in an empty slot in either a 2600, 3600a or 3700 router. Once the module is plugged into the router, it acts similar to a standalone IDS network sensor and can be configured and monitored via a remote management console.

NOTE

With the introduction of the router IDS module, a new monitoring concept was developed for Cisco routers, namely the monitoring interfaces. The two Fast Ethernet monitoring interfaces are the "internal" backplane interface for receiving copies of LAN or WAN traffic sent through a special packet-monitoring feature in the router's Cisco IOS software, and an "external" interface for receiving traffic directly from local or remote LAN ports.

The data sheet on the router IDS module can be found at the following URL:

http://www.cisco.com/en/US/products/sw/secursw/ps2113/products_data_sheet09186a008017dc22l.

PIX IDS

The PIX Firewall can also be configured as a network intrusion detection sensor in a manner similar to the router IDS.

The IDS integrated software for the PIX makes it possible, although in a very limited way, to customize the amount of traffic that needs to be audited and logged. Application-level signatures can be audited only for active sessions through the PIX. This audit needs to be applied to either the inbound or outbound interface of the PIX Firewall.

For auditing performed inbound, the PIX looks at the IP packets as they arrive at an input interface. For instance, if a packet triggers a signature and the configured action does not drop the packet, the same packet can trigger other signatures.

Response to Events and Alerts

IDSs can respond to attacks in a few different ways, including by passively creating IP session logs or by actively terminating the session or blocking the attacking host.

IP Session Logging

After a sensor detects an attack, an alarm is generated by the sensor and sent to the management station. The information is saved in a memory-mapped file on both the sensor and the management platform. This memory-mapped file is in binary format file. As discussed in the next section, the sensor uses RDEP to communicate with the external world; so does the IP logging feature. It is an HTTP communication that is client-server and two-way based, whereby the client (sensor) sends an RDEP request, which is answered by the management station with an RDEP response. All RDEP messages consist of two parts:

Header
Entity body

Figure 10-12 illustrates the IP logging capability of the network IDSs.

Figure 10-12. Network-Based IDS Logging

The IP logging feature allows the network administrator to easily archive the data, write scripts for parsing the data, and monitor the attacks. The IP logging feature is helpful to analyze events, but it does impact sensor performance; therefore, disk utilization needs to be watched carefully.

Active ResponseTCP Resets

After a sensor detects an attack, an alarm is generated by the sensor and sent to the management station. The network IDS may terminate the Layer 4 session by sending a TCP RST packet to the attacked server and the host. Figure 10-13 illustrates the TCP reset capability of the network IDSs.

Figure 10-13. Network-Based IDS Active Response (TCP Response)

The TCP Reset is initiated from the data-capturing port to both the server and the cracker's host. The network administrator should be aware that certain applications automatically reconnect and resend data. A solution would be to implement a blocking mechanism.

Active ResponseShunning or Blocking

After a sensor detects an attack, an alarm is generated by the sensor and sent to the management station. The network IDS can shut the attacker out of the network, usually by setting access control rules on a border device such as a router or firewall. Figure 10-14 illustrates the IP blocking capability of the network IDSs.

Figure 10-14. Network-Based IDS Active Response (Shunning or Blocking)

In Figure 10-14, the sensor connects to the router and configures an access list to block traffic originated for the offending host with IP address 10.0.0.1.

Special precautionary measures should be taken when implementing these active responses. The attacker (who is also aware of these features) can inappropriately deny service for authorized user traffic. General guidelines on responses to alerts and events are difficult to outline. But it is not recommended to use active responses during the tuning period. Shunning or blocking should be used only as the administrator gains experience with the traffic patterns in the network. Starting with TCP resets is recommended instead. And last but not least, keep in mind that the initial trigger packet still makes it to the destination.

Notification and Reporting

The graphical user interface of the management station provides an excellent vehicle to view alarms generated by the various sensors throughout the network. Each alarm is displayed with a unique color based on the severity of the alarm. The administrator can quickly view all the intrusions occurring in the network at any time based on the generated alarms. This alarm information can also be saved in a text log file.

From a notification viewpoint, there are two options. The system can be configured to inform security personnel either by an e-mail message or by pager. Both mechanisms have their advantages and disadvantages, including notification time, ability to keep records for tracking, and so on.

The Cisco Secure Policy Manager and the Cisco VMS Management Center for IDS have a powerful alarm-reporting feature that provides the network security administrator with a tool to generate customized intrusion detection reports. These reports can be generated via HTTP, HTTPS, or on the network management console.

The following list gives an idea of some available reports:

Intrusion detection summary
Top sources of alarms
Top destinations of alarms
Alarms by day
Alarms by sensor