The Roles of Network IDS in a Perimeter Defense

IDS sensors serve several purposes in a good perimeter defense. In some cases, they are uniquely suited to the task they perform. Besides identifying attacks and suspicious activity, you can use IDS data to identify security weaknesses and vulnerabilities, including policy violations. IDS data is also an invaluable part of network forensics and incident-handling efforts. Network IDS complements other perimeter defense components by performing functions that they cannot, such as full protocol and payload analysis. IDS sensors can also work with other defense components to halt active attacks. Network IDS is valuable in most environments for creating and maintaining a strong overall security solution.

Identifying Weaknesses

It is absolutely crucial that you identify vulnerabilities and weaknesses and reduce or eliminate them. If you don't take care of them, attackers will most likely find and exploit them, and hosts might be compromised. If a host is compromised, an attacker is likely to use it as a jumping-off point for attacks against other hosts in your environment. By preventing that host from being compromised, or by being alerted immediately after it has been, you can achieve a much better outcome. You can use IDS proactively to find vulnerabilities and weaknesses and identify early stages of attacks, and you can use it reactively to detect attacks against hosts and log what occurs.

Security Auditing

Network IDS can assist in security auditing. You can use the IDS logs and alerts to identify weaknesses in network defenses. For example, if a sensor sends alerts about suspicious Telnet activity from an Internet-based host and your firewall is supposed to be blocking all incoming Telnet activity, either your firewall is not blocking the traffic properly or your network has an additional connection to the Internet that is not secured properly.

Policy Violations

Some IDSs enable you to receive alerts when certain protocols or well-known port numbers are used. For example, if your users are not permitted to use the Internet Relay Chat (IRC) protocol, you could tune your IDS to alert you whenever it sees IRC traffic on the network. Because many Trojans, such as Sdbot, and other malicious code use IRC for communication, IRC traffic on your network could indicate that an incident has occurred. It could also indicate a user who is violating your security policy. Either way, it's activity you're likely to want to know about.

Along the same lines, IDS sensors can be useful in finding misconfigured systems on your own networks, such as a host that isn't using your web proxy server and is reducing the overall security level of your environment. Sensors can also help you find rogue systems that unauthorized personnel are running; for example, a user might set up a web server for her consulting business on her corporate workstation. When reviewing your IDS logs, you would see port 80 traffic directed to this box. Identifying improperly configured hosts and addressing their problems is a key part of reducing the vulnerabilities in your environment.

Detecting Attacks from Your Own Hosts

Although network IDS sensors used to be thought of as only identifying suspicious activity that enters a network from the Internet, it's important to consider that you can also use IDS sensors to identify outgoing attacks. This use is particularly valuable in environments where outbound access is largely unrestricted. You certainly want to be aware of attacks that your internal hosts are performing on external entities; your users could be causing these attacks, or the attacks could signal that another party or a worm is using compromised machines to attack others.

In an environment where firewalls and packet filters are configured to let almost any activity out of your organization, an IDS is probably the only method you have of identifying such attacks. If your border devices place some restrictions on outbound activity, you might identify an attack by reviewing your firewall logs, but this is far less likely to happen because most firewalls have no signature capabilities and can't identify most attacks. Also, reviewing firewall logs is much more resource-intensive than reviewing the logs of an IDS sensor that checks outgoing traffic.

Incident Handling and Forensics

In an ideal world, your organization would have staff monitoring your IDS logs and alerts 24 hours a day and reacting immediately to suspicious activity. Although organizations are increasingly implementing 24-hour monitoring, it's more likely than not that yours has not. You probably receive a page when the most serious alerts occur, and you review your IDS alerts and logs as often as you can, given all your other duties. It's important that you review alerts as often as possible so that you can quickly identify serious attacks and react appropriately to them.

Even if you don't notice that an attack is occurring until the damage has been done, the IDS data can still be invaluable to you. It can show you which hosts were attacked and what attacks were used against them. This critical information can help you recover from incidents much more quickly and identify the likely source of an attack. It gives you the basic information you need when starting to handle an incident, and it indicates other hosts that might have related data, such as firewalls that the traffic passed through or other hosts that were attacked.

Along the same lines, many people do not consider the forensic uses of IDS. You can use IDS logs to investigate an incident. Also, some IDS products enable you to monitor and log specified types of traffic. For example, if you don't permit IRC to be used on your network, you might want to set your IDS to log all IRC traffic, which could then capture IRC communications between malware on one of your machines and a remote IRC server. Of course, you need to consider the privacy rights of your users before configuring your IDS this way; legitimate users might be chatting with each other using IRC, and the IDS might record their conversations.

Complementing Other Defense Components

Part of the purpose of network IDS is to correlate the activity that individual hosts might see. If 100 hosts each record one failed Telnet attempt, no one might notice; but if an IDS sensor records 100 failed Telnet attempts, it's much more likely to trigger an alert. IDS sensors may work with perimeter defense components to stop attacks in progress. IDS sensors can also perform functions that other perimeter defense components generally can't.

For example, firewalls and packet filters have limited capabilities to examine traffic. Typically, they do not look at the contents of packet payloads, although some might do some basic protocol analysis. Firewalls generally look at some of the most basic characteristics of traffic and accept, deny, or reject it accordingly. A firewall might try to stop certain services from passing through by blocking certain port numbers, but it generally does little or nothing to evaluate traffic that uses allowed port numbers. IDS sensors are designed to examine the contents of packets; some IDS sensors are even capable of doing full protocol analysis, which means that they can examine the contents of an entire session as it occurs and alert you if the traffic does not match its expectations, without matching the traffic against a known attack signature.

A simple example of this is the identification of applications that run on unexpected ports. For example, a Trojan that is installed on a host might use TCP port 21 (usually associated with FTP control connections) for all communications with its Trojan master. If your firewall is configured to let internal users FTP to external sites, the Trojan could initiate a connection to its master, and your firewall would respond as though it were an FTP connection and permit it. However, the IDS sensor would actually analyze the content of the packets and alert you that the traffic was not FTP. You could then review the IDS logs for more information and investigate the host in question.

A more complex example of the value of protocol analysis is the identification of various known and unknown attacks. One of the most commonly used attack techniques is the buffer overflow, in which the attacker sets various fields or arguments to overly large or long values to attempt to overwrite memory locations. By performing protocol analysisfor example, validating the header and payload values in a DNS querythe IDS can identify anomalous values that are possible signs of buffer overflow attempts. Although stateful firewalls might do some protocol analysis, they are usually poor logging tools and have no signature capabilities. Other types of firewalls generally don't do protocol analysis at all.