|[ LiB ]|
The Sensor software includes a set of signatures that detect known attacks and are enabled by default. These signatures are called built-in or default signatures. As you saw in Chapter 9, you cannot add to or delete from the group of default signatures, nor can they be renamed . However, you can and should tune them to your network environment; once you modify a default signature, it is called a tuned signature.
You also saw in Chapter 9 that you can create new signatures called custom signatures. Custom signatures have signature ID numbers of 20000 and above. You can create and configure custom signatures to detect reconnaissance, flood, and DoS attacks or specific text patterns, for example.
You cannot add to the set of built-in signatures, also called the default signatures; however, you can create new signatures, which are custom signatures.
Chapter 9 discussed a wide range of specific signature engine parameters. Here are the basic configurable parameters:
Enable status Enables or disables the signature
Severity level Assigns the severity level (informational, low, medium, or high)
Signature action Assigns the action or actions to be taken when the signature is triggered
You saw in Chapter 9 that there are four possible actions when a signature is triggered:
IP Log If this option is selected, the Sensor writes the IP session data to an IP log file, allowing you to capture raw, unaltered packets that can be used for forensic evidence or damage assessment.
TCP Reset If you select the TCP reset action, the Sensor sends a TCP reset command to the attacking session. It is available only for TCP attackbased signatures. Recall also that you might need to configure your switch port to allow TCP resets using the inpkts enable command.
Block Host If you select the Block Host option, the Sensor instructs a managed device such as a router to dynamically modify an access control list (ACL) with an additional access control entry (ACE). The ACE will deny only the source IP address of the offending host. Following is an example of a ACE created on the blocking device:
deny ip host 10.5.20.66 any
Block Connection Similar to the Block Host option, if you select the Block Connection action, the Sensor instructs a managed device to modify an ACL to dynamically change the access policy. The ACL changes to deny the IP packets from the source IP address to a specific destination IP address; port and service. Following is an example of an ACE created by a Block Connection signature action:
deny tcp host 10.5.20.66 host 10.1.25.70 eq http
In this example, all HTTP connections between the two hosts will be blocked; however, the 10.5.20.66 host will still be able to connect to the 10.25.1.70 host using Telnet, FTP, or other services not using port 80.
Signature filtering, like alarm throttling, can reduce false positives and limit the number of security events reported . Signature filtering allows you to specify source and destination IP addresses for any given signature and whether the filter will include or exclude the matched conditions.
The following list describes the filtering process:
An attack against the protected network is detected .
The sensing engine within the Sensor determines whether a filter exists for this signature.
If a filter exists, the Sensor checks the source and destination addresses designated by the filter's parameters against the incoming traffic that triggered the attack.
One of the following actions then happens:
If the traffic doesn't match the filter conditions, an alert is generated.
If the traffic matches the source and destination addresses and the filter is exclusive, no alarm is generated.
If the traffic matches the source and destination addresses and the filter is inclusive, then the configured signature action is taken (log, reset, block host, or block connection).
You configure signature filters by navigating to the Configuration, Settings page on the IDS MC and clicking the Filters link on the TOC. You then see a list of available filters, if any. The steps to add a new signature follow:
Filter exceptions allow you to configure a separate signature response for a specific host or server. In certain situations, it might be useful to configure a filter exception for a unique server or host. Consider a situation, for example, where you have a server farm composed entirely of Windows 2000 servers, except for a single Apache server supporting an extranet portal to a supplier.
One day, Internet traffic generates a large amount of alarms from an attacker attempting to infect the entire server farm with the Apache/mod_ssl worm. Although all servers are targets of the worm attack, only the Apache server is vulnerable.
In this situation, you can configure an exclusive filter for your Apache.mod_ssl Worm Buffer Overflow signature. The exclusive filter will specify the entire range of server addresses as the destination address. You then configure a filter exception for the one Apache server that is vulnerable to the attack, thus minimizing unnecessary alarms generated by the signature.
Before going through a scenario where you tune a default signature, we briefly outline the steps for signature tuning:
A cross-company task group has set up an FTP server with prerelease marketing content to test multicast functionality over a satellite IP network. The project manager wants to detect all unauthorized attempts to log in to the FTP server. Based on the threat posed by an attack, the signature should meet the following requirements:
A high severity alarm should be triggered after two failed login attempts.
An alarm should be sent each time an attack is detected.
The attacking session should be terminated .
To tune this signature, follow these steps:
Finally, before tackling a scenario where you create a custom signature, we briefly run through the relevant configuration steps. To configure a custom signature, follow these steps:
Type of attack
When considering which signature engine to use to create a custom signature, make sure that you take the following into consideration: network protocol, target address and port, type of attack, and whether any payload inspection is required.
Anna requests to have virtual private network (VPN) access from her home in the south of France to a development network in London. Her manager Jeff agrees and decides to log her activities by detecting IP Security (IPSec), Encapsulating Security Payload (ESP), and Authentication Header (AH) packets that traverse the network. These are the steps necessary to configure this custom signature:
SigVersion / 20002
MaxProto / 51
MinProto / 50
SigStringInfo / ESP / AH Packet
|[ LiB ]|