[ LiB ] |
The Cisco IDS 4.0 software runs on the Red Hat Linux operating system (OS) as opposed to version 3.x, which ran on the Sun Solaris OS. You should familiarize yourself with several components that interact with IDS 4.0 software in preparation for the exam. Some of these components monitor traffic, some control the sensor, and others collect events and logs.
The Cisco IDS system has five major applications and components that make everything interact with one another: IDS application program interface (IDAPI), EventStore , mainApp , logApp , and Authentication. Figure 5.1 displays the main applications that interact with the IDS system, and Table 5.1 describes each application part.
Applications | Description |
---|---|
mainApp | The mainApp is the very first application that starts, and it is responsible for configuring the operating systems with settings such as Internet Protocol (IP) addresses on interfaces. This application is also responsible for starting and stopping all other Cisco IDS applications and processes. |
logApp | The logApp application is responsible for writing all application log messages to log files and writes application error messages to the EventStore . |
Authentication | The Authentication application is in charge of managing authentications for users and determining what role a user has been assigned and the appropriate permissions that should be given to the user on the sensor. |
EventStore | The EventStore is a 4GB shared memory-mapped file used to store all events and alerts. When the file fills up, then old records are overwritten with new records. |
IDAPI | IDAPI is the application interface used to handle internal communications between programs. The heart of system internal communication, it provides a way to share and store data between IDS applications. |
The mainApp application is responsible for starting and stopping all other applications. |
The Cisco IDS has several parts that connect to outside devices. Most are for configuration and management, whereas the others monitor traffic and control managed devices. Figure 5.2 displays several of the interfaces that interact with Cisco's IDS system. The figure displays the four primary ways to access the IDS system: the cidWebServer , SSH/Telnet, NAC, and SensorApp .
You can access the command-line interface (CLI) via Secure Shell (SSH) or Telnet. The access point communicates with a process called cidCLI . The cidCLI shell process starts when a user logs on to the sensor and sees an Internetwork Operating System (IOS) CLI style interface used for management and monitoring.
Older versions allowed access to the operating system's files and directory structures. In IDS 4.0, this access is restricted to the account set with the service level privilege. |
The cidWebServer is the sensor's Web server that has the ability to support Hypertext Transfer Protocol (HTTP) and Secure HTTP (HTTPS) communications between the sensor and the clients . cidWebServer interfaces with four Web servlets that provide a communication channel to applications outside the IDS 4.0 sensor. Table 5.2 describes these four servlets systems.
Servlet | Description |
---|---|
IDS Device Manager (IDM) | A single sensor Web-based management interface used to control and configure the sensor. |
Transaction Server | The Transaction Server provides interface ability to other management systems such as IDS Management Center (IDS MC) to control and configure the sensor. |
Event Server | The Event Server is used to provide events to external systems such as IEV and Security Monitor and log information. It uses a communication protocol known as the Remote Data Exchange Protocol (RDEP) for communication with Event Server. |
IP Log Server | The IP Log Server presents the IP logs created on the sensor to external systems such as Security Monitor. It uses the RDEP for communications. |
The cidWebServer servlets, Transaction Server, Event Server, and IP Log Server all use a communication protocol called the Remote Data Exchange Protocol (RDEP). |
You use the Network Access Controller (NAC) to send shunning and access control lists (ACLs) to managed devices such as Private Internet Exchange (PIX) Firewalls and IOS-based Cisco Routers. It works in conjunction with another module called the ctlTransSource that is not shown in Figure 5.2.
Shunning are commands sent to PIX Firewalls to block hosts or networks. They behave very similarly to ACLs. |
The NAC can connect to IOS Router and PIX Firewall using either Telnet or SSH. |
The sensorApp is the application that actually detects IP traffic and monitors for signature matches to generate alerts and events that are written to the EventStore (see Figure 5.3).
The sensorApp application is the only process that writes alert events to the EventStore . |
The sensorApp supports two internal processes: the VirtualSensor and the VirtualAlarm . The new IDS 4.0 was designed to support multiple VirtualSensor processes; however, it currently supports only one. When multiple VirtualSensor s become available, you have the flexibility to define different signature settings for each one.
The VirtualSensor process is designed to receive packets and process them for a matching alarm signature. This process contains several other processes that each manage and break down packets received from the monitoring interfaces. Table 5.3 lists and describes the processes that make up the VirtualSensor .
Process | Description |
---|---|
CaptureProducer | Receives packets from the monitoring interface and pushes them to other processors. |
Layer2Handler | Takes care of Layer 2 inspection and dispatching and traps for packets. It also processes the Layer 2 Address Resolution Protocol (ARP) packets and passes the Ethernet packet to the next processor. |
FragmentReassembler | Reassembles IP fragments , known as fragment reassembler units (FRUs). |
DatabaseHandler | Takes care of internal storage for tracking streams and cross packets analysis. |
StreamReassembler | Reassembles the Transmission Control Protocol (TCP) streams, known as stream reassembler units (SRUs). |
SignatureHandler | Dispatches and controls all nonstream signature engines. |
In future versions for the IDS software, more than one virtual sensor will be possible. However, you can create only one now. The name of that sensor is VirtualSensor . |
The VirtualAlarm process, also known as AlarmChannel , is responsible for outputting alarms to the downstream.
[ LiB ] |