Cisco Secure Intrusion Detection System (CSIDS)

Most of this book focuses on ways to prevent outside unauthorized entities from connecting to your network. This section differs in that the focus is on how patterns of abuse are detected from both internal and external sources. After a pattern of abuse is noted, you can respond in real time to the threat. The phrase patterns of abuse is used because the Cisco Secure Intrusion Detection System (CSIDS) looks at the format and the amount of data traversing your network to determine the likelihood and severity of threats. The patterns within the data traversing the network are analyzed to determine whether an attack has been launched.

This section covers the CSIDS. The CSIDS is differentiated from the Cisco IOS Firewall IDS and the Cisco Secure PIX Firewall IDS in that the CSIDS is designed to run both independently and in conjunction with the existing hardware on a network. Additionally, the abilities of the CSIDS to detect and respond to threats are much greater than those built into either the Cisco IOS Firewall or the Cisco Secure PIX Firewall. These additional abilities are available because routing or performing firewall functions is not the main purpose of the CSIDS. The main purpose of the CSIDS is to detect and respond to patterns of abuse in real time.

A full explanation of the details of installation, maintenance, and configuration of the CSIDS is beyond the scope of this book. However, this section gives you the theory necessary to begin your investigations into the CSIDS. This section provides an overview of the most important features and issues involved with the CSIDS, the basics of Sensor deployment, Director deployment, signatures, alarms, and log files.

Intrusion detection monitors against three forms of attack.

• Reconnaissance attacks— A reconnaissance attack is where an attempt is made to discover and map services, vulnerabilities, and systems for purposes of later access or denial of service (DoS) attacks. As little information about your network should be revealed as possible, because excessive revelations might show possible weaknesses that have not yet been addressed. For example, an internal user might scan the ports on a server to prepare for breaking into that server for confidential information.

• Access attacks— An access attack occurs when users actively attempt to access services to which they do not have authority. For example, an internal user sitting at a desk and repeatedly trying to log into a server with another user's name and different passwords is considered an access attack.

• Denial of service (DoS) attacks— A DoS attack occurs when an attempt is made to prevent valid use of a network or system. Many examples of DoS attacks, including the ping of death attack, are discussed throughout this book.

The CSIDS is designed to monitor for these types of attack and to notify the appropriate personnel in the event of such an attack. Logs are built that detail the suspicious packets. The CSIDS can also respond by denying service to the perpetrators of all three forms of attack.

Cisco has chosen to implement a packet-based detection method to determine when an attack is in progress. This method relies on comparing the data within each packet with a “signature” that indicates a possible attack. There are some differences between the signatures used within the Cisco IOS software used on routers and those found on the Cisco IDS equipment. One difference is the number of signatures: although the Cisco IOS has implemented 59 signatures and the PIX Firewall has implemented 57 signatures, the CSIDS has a much larger number of signatures. Additionally, CSIDS allows a skilled administrator to create new signatures. This allows the protection of the network to evolve as new threats emerge.

The CSIDS was formerly called NetRanger, and many of the existing URLs on the Cisco web site still refer to this product with the old name. Keep the old name in mind when searching the Cisco web site for specific information about the CSIDS.

Overview of the CSIDS Components

The CSIDS comprises three components: the Sensor, the Post Office Protocol, and the Director. Each has a unique function. This section provides an overview of the functions of each before the rest of the chapter goes on to delve into the specifics of each component.

CSIDS Sensor

The CSIDS Sensor is a high-performance hardware appliance used to detect intrusion attempts. In essence, this is a packet sniffer that analyzes all of the network traffic on a given network segment, comparing the packets to an attack signature database. When a packet with qualities matching a signature within the database is detected, the Sensor notifies the Director and logs alarm activities.

The Sensor can be configured to reset a TCP connection automatically, block an offending IP address, or log the session. The Sensor reassembles fragmented IP packets as necessary to determine the full threat posed by the packets.

CSIDS Post Office Protocol

The Post Office Protocol is responsible for delivering between the Sensors and the Directors. This protocol, using a UDP format on port 4500, is considered reliable because it requires an acknowledgement of all data sent and resends data as necessary.

The Post Office Protocol can be configured to send messages to up to 255 alternate Directors if the primary Director is unavailable. Directors are specified by IP address.

CSIDS Director

The Director can be considered the focal point of the CSIDS components, because this is where displays and logs about alarms are stored. The administrator uses the Director to manage and respond to alarms through a graphical user interface (GUI). The Director can also be configured to send e-mail or to execute a user script when an alarm is received.

The Director also allows for management and configuration of remote Sensors through the configuration management utility. This feature is especially useful in cases where a large corporation with multiple locations has chosen to centralize their security efforts.

Unit Identification

Both Directors and Sensors are identified uniquely. There are three parts to this identification, two of which are assigned by the administrator. The three parts are

• Host ID

• Organizational ID

• Application Identifier

Host ID

The Host ID is set to any number greater than zero. For example, one Sensor might be assigned number 1, a Director is assigned 2, and another Sensor is assigned 3.

Organizational ID

The Organizational ID is any number greater than zero. This is commonly used to group devices together according to region or function. For example, all Sensors and Directors in South America could be assigned 2000, while all Sensors and Directors within North America are assigned 3000. This makes it easier for the administrator of a large system to know where a device is located.

The Host and Organizational ID are combined by adding a period (.) between the Host and Organizational ID numbers. Examples of this are 3.2000 and 2.2000.

Alpha Identifiers

Associated with the Host and Organizational IDs are the Host Name and Organization Name, respectively. The names are joined together in the same manner as their numeric counterparts. These also allow for easier identification of devices. For example, Sensors might be labeled sensor1.southamerica and sensor2.southamerica, while Directors might be labeled director1.northamerica or director2.northamerica. Although there is no specific rule stating that any naming conventions should be used, labeling devices logically and consistently greatly eases both administration and training of new personnel.

Application Identifiers

The Application Identifier is a statistically unique number assigned by the software. This allows for a combination among the three parts of the Identifier that should always be unique. These identifiers are used to route all communications between devices.

The Sensor, the Post Office Protocol, and the Director work together to form the CSIDS. The next sections delve deeper into a discussion of the hardware associated with the CSIDS Sensor, an explanation of the Post Office Protocol, and a discussion of the requirements for the CSIDS Director.

The CSIDS Sensor

The CSIDS Sensor comes in two basic models. The first model is a standalone rack-mountable version, and the second model is a Catalyst switch module, also called a blade, residing within the Catalyst 6000 series.

With the standalone rack-mountable version, there is a floppy disk provided for software upgrades and password recovery. The front cover is also lockable.

The standalone module number is based on the type of network interface used for monitoring. The CSIDS Sensor can be used on Ethernet, Fast Ethernet, Single or Dual FDDI, and Token Ring. There are a number of connections available on the back of the Sensor.

There are connections on the back for power, in addition to a COM port, and a monitor and a keyboard, which are used for initial configuration. Connecting a cable to the COM port of a computer is done in the same manner as with a router that uses the COM port.

Notice that there are two network interface ports on the rear of the Sensor. The built-in horizontal network port, called the Command NIC, is used for communications with routers and the Director. The vertically mounted Monitoring NIC port is used to monitor the network segment. Although a standard Ethernet connection could be used to monitor a network with a number of Fast Ethernet connections, such a configuration could easily cause the Ethernet link to become overused because of the large amount of traffic that is typically traversing such a network. Both NICs must be connected for the Sensor to operate properly.

When connecting the Monitoring NIC to a switch, ensure that SPAN monitoring is enabled for that port within the switch. Because a switch, by default, forwards packets only to the appropriate ports, failing to enable port monitoring on the switch will result in the Sensor being unable to see attacks that are not directed toward the Sensor itself. In the event that multiple VLANs are in use, the Sensor can monitor more than one VLAN, if the switch is properly configured with port monitoring on the desired VLANs through the Monitor NIC port.

The second form of the CSIDS Sensor is available in the form of a blade module for the Catalyst line of switches. This version of the Sensor becomes an integral part of the switch.

The advantage of using this form of the Sensor is that all data destined for the Sensor travels over the backplane of the switch. Assume for a moment that the network you wish to monitor uses a Cisco Catalyst 6509 with four sets of 48-port Fast Ethernet modules. There is very real possibility that the amount of data traveling through this switch could exceed the capacity of the single Fast Ethernet connection of Monitoring NIC on a standalone version. Having this data travel through the backplane of the switch on the blade version means that the maximum amount of data inspected is not limited by a Fast Ethernet connection (100 Mbps). The limitation while using the blade version comes from the processing speed of the Sensor itself, instead of the Ethernet connection. The configuration of the Sensor is virtually the same, whether the standalone or the blade version is used. Because a larger number of the standalone versions are used, the remainder of this section will focus on this form of the Sensor.

CSIDS Sensor Deployment

The CSIDS Sensor can be deployed in a number of ways. Because all networks vary, there can be no single method of deployment that fulfills the needs of all networks. This section will show the more common methods available and discuss the benefits and deficits of each.

Some items to consider while planning a Sensor deployment include the size and complexity of the network, the amounts and types of data traveling over the segment, and the connections between this network and other trusted and untrusted networks. Decisions also need to be made to determine which parts of the network should be monitored. If the sensor is placed on the outside of a firewall, that Sensor can be used to monitor attacks directed against the firewall from the outside. However, the Sensor will not be able to watch for threats originating on the inside of the firewall and directed only to machines inside the firewall. Conversely, placing the Sensor inside the firewall will not allow the sensor to monitor any attacks originating from the Internet directed toward the firewall. As with most networking decisions, a balance must be found that suits the administrator's individual situation.

The following sections cover some practical ways to deploy the CSIDS Sensor.

Simple CSIDS Deployment

Figure 6-3 shows a simple deployment where the Sensor monitors the interior of the network. The Director is also located on the interior network. The switch must be configured to send port-monitoring data to the Monitoring NIC. Notice that the area monitored is limited by the PIX Firewall.

CSIDS Monitoring Beyond the Firewall

Figure 6-4 shows an example of how the Sensor could be deployed for purposes of monitoring the data transferred from the perimeter router to the firewall. In this model, the Command NIC is connected to inside the firewall, while the Monitoring NIC is connected to outside the firewall. The Command NIC sends information about possible attacks to the Director through the Command NIC. In this scenario, the administrator will be made aware of both when an attack on the firewall from the Internet occurs, and the form of the attack.

Because the PIX allows packets to travel from the inside to the outside interface by default, the Sensor is also able to communicate with the perimeter router. In the event that an attack is observed, the Sensor can be configured to add an access control list on the perimeter router to bypass the attack. Adding the access control list is referred to as shunning. For shunning to occur, Telnet services on the router must be enabled, the router must be added to the Sensor's management list, and an access control list must not be present on the interface in the same direction as the access list that will be applied by the CSIDS.

Monitoring Remote Sites

In some networks, there exists a need to monitor a network segment connected through a nonsecured medium. A remote site that has the capability of configuring a connection to the main office can use a Sensor on either the protected or the unprotected portion of the network. Figure 6-5 shows an example of a Sensor at a remote site that is configured to monitor the unprotected portion of the remote site's network. As in the case when a local site monitors the unprotected network, the Monitoring NIC is connected between the perimeter router and the PIX Firewall. The Command NIC is connected to the protected network with an IP address on that network.

Notice that the remote site does not have a directly connected CSIDS Director. The requirement is that two-way UDP connectivity between the Command NIC and the Director should be maintained. As long as the firewalls on each side allow UDP connectivity, there are no requirements for the location of the Director.

In Figure 6-5, the connection from the remote site is over an encrypted tunnel. This is critical to the security of your network. Although there is no requirement by the Sensor or the Director that the path between the two is secure, it would be foolish to transfer data about the current vulnerabilities through the Internet. In the case that the connection to the remote site is through a more secure method such as dedicated Frame Relay, it might not be necessary to encrypt the connection. However, if the connection is not encrypted, any user with access to intermediate routers might be able to watch traffic traveling between the Sensor and the Director.

Noncontrolling Deployment

Another configuration is possible, although it is not recommended. It is pointed out to show how a common mistake can be avoided. Looking at Figure 6-6, notice that the Monitoring NIC is connected to the unprotected network, but the Command NIC is used to build a separate network to the Director. In this case, the Command NIC and the Director have no access to the perimeter router, because the Sensor does not route between the interfaces and only sends commands out through the Command NIC. Should an attack be discovered, there is no path from the Command NIC to the perimeter router that can be used to adjust the access control list on the perimeter router to block the attack. This scenario only allows for passive monitoring and logging of the network, while denying the functionality of responding to attacks in a real-time manner. Therefore, this configuration is not recommended.

CSIDS Sensor Guidelines

So far, this section gave an overview of the CSIDS Sensor hardware and different common deployments. As with most other network configurations, a lot of the decisions on how to deploy something are individual to the needs of the particular network. There are, however, a few guidelines that should be remembered when deploying Sensors.

• The Sensor must be able to communicate with the Director through the Command NIC, using the UDP protocol on port 4500.

• The communications between the Sensor and the Director can provide hackers with data about the vulnerability of your network. Therefore, these communications should be treated as any other vital data.

• The Sensor only monitors a single segment at a time.

• The Catalyst IDS Sensor module accepts data at backplane speeds, bypassing the limitations of an Ethernet, Token Ring, or FDDI connection.

The CSIDS Post Office Protocol

The Post Office Protocol is used for communications between the Sensor and the Director. Both the Director and the Sensor can send a Post Office Protocol message. There are six types of messages that can be sent between the Sensor and the Director.

• Heartbeat

• Error

• Redirect

• Alarm

• Command log

• IP log

Each of these is explored in turn in the following sections.

Heartbeat

The heartbeat is used by the Sensor to poll the primary Director, and by a Director to poll the Sensor. As with all communications, a reply is expected. In the event that heartbeat packets do not receive a response, the Sensor assumes that the primary Director has gone off line and initiates communications with the next secondary Director. The Director, failing to hear a Sensor, believes that a malfunction has occurred.

Error

An error message is sent in the event that a malfunction has occurred. This can be because of a hardware issue, loss of connectivity on the monitoring NIC, or a problem within the operating system software.

Command

A command is used for configuration purposes. Commands can be used to change certain parameters, such as the level of alarms.

Alarm

An alarm is a message sent by the Sensor to the Director that an event of noticeable severity has been monitored. By default, there are five alarm levels, although the administrator can configure up to 255 levels.

Command Log

A command log is an entry made to record the commands issued between Sensors and Directors. All commands are recorded to the command log by default.

IP Log

An IP log message contains information concerning TCP sessions. This log is only written when a triggering event takes place. Once writing to an IP log initiates, the log continues to be written for a specified amount of time. Because IP is the only protocol supported at this time, there are no Internetwork Packet Exchange (IPX) or Systems Network Architecture (SNA) logs. These messages contain information such as the time, the source and destination IP addresses, and the associated ports.

The CSIDS Director

The CSIDS Director is a software package designed to operate in conjunction with the CSIDS Sensors. The main function of the Director is to manage the configuration of the Sensors.

Although it is possible to configure multiple directors to manage a given Sensor simultaneously, this should be avoided for two reasons. First, it is extremely easy for multiple Directors to give conflicting commands to a Sensor. Second, security is increased if only a single Director manages any Sensor at any given time. This, however, does not imply that it is wrong for more than one Director to be used to manage a Sensor on a routine basis. As long as only one Director is managing at any time, it is perfectly reasonable to have more than one Director capable of managing a Sensor. For example, the structure of a company might dictate that from 0800 through 1600 GMT time, Directors in the London office maintain Sensors. From 1600 through 2400 GMT, Directors in the Hong Kong office manage Sensors, and from 2400 through 0800, Directors in the San Francisco office manage Sensors. The CSIDS is perfectly capable of handling this scenario.

Director services are available in two forms: through the Cisco Secure Policy Manager and as a standalone server. Although the inner workings of these two forms of the Director vary, the basic available features are the same. The Cisco Secure Policy Manager is covered in Chapter 8, “Cisco Secure Policy Manager (CSPM).” The remainder of this section will deal with the standalone server version of the Director.

Configuration on the standalone version is accomplished through the CSIDS Configuration Management Utility, also called nrConfigure. This utility allows multiple configurations to be saved for each Sensor and downloaded to the Sensor when appropriate. One scenario where this can be advantageous is when the security requirements for a network change on a regular basis. For example, if a remote site should never have any network traffic over a holiday weekend, the administrator can download a very restrictive configuration that runs a script to page the administrator when any traffic traverses the network. Another benefit of the ability to maintain numerous configurations is that the administrators can test each of them to find the one that works best with their particular network.

Server-Based Director Hardware Requirements

The standalone CSIDS Director is designed to run on SPARC or HP processor platforms. As with most hardware requirements, the following should be considered the absolute minimum required to run the CSIDS Director software.

The minimum SPARC platform consists of the following:

• Solaris 2.51, 2.6, or 2.7 Operating System

• 50 MB CSIDS install partition

• 2 GB CSIDS log partition

• 110 MB HP OpenView partition

• 12 MB Java Runtime Partition

• 96 MB RAM

• HP OpenView 4.11, 5.01, or 6.0 to display the CSIDS GUI

• A Java-compatible Web browser for displaying the Network Security Database (NSDB)

The minimum HP-UX platform consists of the following:

• HP-UX 10.20

• 50 MB CSIDS install partition

• 2 GB CSIDS log partition

• 65 MB HP OpenView partition

• 10 MB Java Runtime Partition

• 96 MB RAM

• HP OpenView 4.11, 5.01, or 6.0 to display the CSIDS GUI

• A Java compatible Web browser for displaying the NSDB

Before attempting to install Director, several items should be checked for completeness. Among these items are

• HP OpenView completely installed and tested

• DNS configured and tested, if used

• UNIX host name configured and tested

• Web browser configured and tested

• IP address, subnet mask, and default gateway configured and tested

• All devices with concurrent times and time zones^[1]

  ^[1] This is a critical item, because the times that activities occur will be recorded. All equipment, such as routers, the Director, and the Sensor, should have identical times. In cases where a network traverses multiple time zones, a single time zone, such as the GMT, should be chosen for all equipment. Using NTP to synchronize times on the equipment is recommended.

Managed Devices Requirements

The CSIDS is capable of changing access control lists on a router to shun an attack. There are only a few requirements to allow a device to be managed.

• Telnet must be allowed.

• A vty password must be set.

• An enable password must be set.

Director Deployment

One Director can be configured to manage multiple Sensors. The actual number of Sensors that can be successfully managed by a single Director is based on a number of factors, including the memory and CPU speed of the Director and the amount of data sent to the Director by the Sensors.

Directors can be configured in a hierarchical manner that allows messages to have propagation through the hierarchies. Using a hierarchical configuration allows personnel to monitor and respond to situations presented by locally placed Directors, while still allowing a centralized monitoring site to maintain an overview of the whole network. Alarms can be sent to the higher-level Directors through the locally administered Directors without broadcasting.

As shown in the example in Figure 6-7, the Director in Western Europe reports to the Director in Eastern Europe, which in turn reports to the Director in the Eastern United States. The Directors in South America report to Director in the Western United States, which in turn reports to the Director in the Eastern United States. The Director in Australia reports directly to the Director in the Eastern United States.

Signatures

A signature is a set of rules based on activity typically seen when an intrusion is attempted. This set of rules is matched to packets on the network. When a match is found, a unique response is generated. When a match occurs, a trigger is set that causes the Sensor to react by adjusting an access control list on a router, notifying the Director, or acting in another predefined manner. The CSIDS signatures are categorized according to the structure, implementation, and class of packets. A large number of signatures are included with the Sensor. The administrator can add to this list and change the characteristics of any signature.

Signature Structures

There are two types of signature structures: atomic and composite. A single packet triggers an atomic signature, while multiple packets trigger a composite signature.

For example, an IP packet with identical source and destination addresses might be considered an atomic signature. An intruder sweeping through port ranges would trigger a composite attack.

Signature Implementation

There are also two types of signature implementations: context and content. A content implementation is triggered by data contained within the packet payload. A context implementation is triggered by the data contained within the packet header.

For example, a packet containing data with the string “hack attack” would be a content implementation. An IP packet with a bad option can be considered a context implementation.

Signature Classes

There are four types of signature classes.

• Reconnaissance Class— A Reconnaissance Class triggers because of network activity that can be used to discover systems, services, and vulnerabilities on the network. Reconnaissance attacks include ping sweeps and port sweeps.

• Access Class— Access Class signatures trigger on activity that could lead to unauthorized system access, escalation of privileges, or data retrieval. Access Class attacks include phf (WWW), Back Orifice, and IP fragment attacks.

• DoS Class— A DoS Class signature is triggered when packets monitored could lead to the disabling of network equipment, systems, or services. DOS attacks include ping of death, half-open SYN attacks, and UDP bombs.

• Information Class— Information Class signatures trigger on packets that are normal within a network but still can be used maliciously. Information Class signatures are also triggered to enable the administrator to determine the validity and severity of an attack and to form a record for possible use in legal proceedings. Information Class signatures include TCP connection requests, UDP connections, and ICMP Echo Requests.

Signature Series

The CSIDS signatures are grouped in numbered series. There are seven series, each relating to signatures within the series level. The CSIDS signature series are shown in Table 6-1.

Signature Severity Levels

Each signature has an associated severity level that indicates the probability that the signature is an actual attack. The default security levels for all signatures are preset, and the administrator can change the setting at any time. The five signature severity levels are shown in Table 6-2.

Responding to Alarms

Now you have examined the hardware and software associated with the CSIDS. You have looked at signatures. This section also explores what happens when a packet on the monitored network matches a signature. This section walks through a theoretical attack on an e-mail server to illustrate how the CSIDS is capable of reacting to an attack.

Take a moment to review Figure 6-8. In this example, there is a Sensor monitoring the unprotected network between the perimeter router and the PIX Firewall. The Command NIC is connected to the local LAN, where the Director resides.

As shown in Figure 6-8, a hacker on the Internet has decided to attempt a DoS attack against the internal e-mail server through the use of half-open TCP connections. Although the PIX Firewall is fully capable of resisting such an attack, the Sensor still notices the attack the moment it has been launched. The FloodGuard algorithm on the PIX Firewall will not start to drop half-open connections until the defined threshold has been exceeded. The Sensor sends a message to the Director stating that an attack is under way. Entries are made in the log showing the packets received. This example uses the ability of the CSIDS to deny packets from the attacker through the adjustment of an access control list on the serial interface of the perimeter router.

The configuration of the signature definition for this type of attack specifies that a number of actions happen when this type of attack occurs. The first action is that e-mail is sent from the Director to the administrator stating that an attack is under way. The second action is that this type of attack notifies the administrator at the Director that a severe attack is under way. The third action is for the perimeter router's access control list on the serial interface to be changed by the Sensor to deny the IP address of the attacker. This is shown in Figure 6-9.

After the attack is stopped, the cleanup process begins. The PIX and the mail server automatically drop the half-open connections after a timeout period expires. Similarly, the Sensor removes the dynamically created access control list from the perimeter router after a specified amount of time.

The preceding example is meant to be purely illustrative in nature. Nearly all responses to signature detections, as well as the signatures themselves, are definable by the administrator. There is no requirement that any of the actions illustrated in the preceding example need to be taken. Instead of sending e-mail to the administrator, the signature definition could have easily had the Director run a script that defined actions to be taken. The administrator could have also chosen to allow all half-open connections from a particular host. The flexibility inherent within the CSIDS gives additional benefits to the administrator.

One benefit that the CSIDS has over other IDSs is because of this flexibility. Many IDSs do not allow the administrator to bypass certain types of apparent attacks. No two networks have the same characteristics regarding protocol distribution, number of broadcasts, and so on. Unless a detection system allows the administrator to completely adjust the parameters used to detect an attack, that system quickly becomes unusable in a number of networks. For example, the authors were once asked to install another manufacturer's IDS on a stockbroker's network. This network was unusual, because broadcasts were the main form of data transfer. Broadcasts were used so that all workstations received updates whenever any workstation requested a real-time quote. The IDS chosen by management was unable to recognize that the high number of broadcasts was not an attack on the system, and therefore, it was never successfully deployed. The CSIDS does not suffer from these shortcomings.

The CSIDS allows the administrator to ignore types of apparent attacks, ignore apparent attacks from individual or groups of hosts, and maintain multiple configurations that allow near-instantaneous changes to those signatures to which the Sensor will react. This flexibility allows the CSIDS to become a viable IDS for most networks.

Interpreting Logs

It is sometimes necessary to look at the actual log file to determine exactly what has occurred. This section explores how to interpret a log file.

The CSIDS stores four levels of logging to a comma-delimited file. The active log is stored in the /usr/nr/var directory with a file name of YYYYMMDDHHMM. By default, when the active log has reached 300 KB, or the elapsed time since the log creation has exceeded 240 minutes, the file is archived under the same name in the /usr/nr/nav/new directory.

The log file has a defined format and is easy to read. The following is a sample record from a log:

4,1034121,2001/04/08,14:04:01,11008,6,300,IN, OUT, 212,8543,51304,TCP/IP,
172.30.1.8,172.31.2.1,1015,25,0.0.0.0,hack attack,69576 ... AEBA0

The fields within the log file are described in Table 6-3.

Now that you have seen an overview of the major components of CSIDS, the next sections cover the Cisco IOS Firewall IDS and the Cisco PIX Firewall IDS.