About This Paper
Tuning Step 1: Correct IPS Deployment
Step 2: The IPS Tuning Process
1. A Cisco Advanced Inspection and Prevention Security Services Module 40 (AIP-SSM 40) protecting a data center server. The management IP address is 172.16.254.204. This device will detect and report all data traversing the network that matches a signature or threat protection algorithm used by the Cisco IPS.
2. A scanning device that is known to network and security administrators. This device is used by network and security administrators to find security holes (vulnerabilities) in their network devices. A scanning device like this is usually running 24x7; for simplicity in this case study, we are running it on demand so the alerts being tuned are manageable. The IP address is 172.16.50.40.
3. Two devices used to generate real attacks on the server. The IP addresses are 172.16.50.60 and 10.1.1.1.
4. Two data center servers that are being protected by the IPS. These servers are unpatched and the IP addresses are 172.16.50.70 and 10.1.1.2.
1. The first and most critical task for ensuring that the IPS does not overburden you with alerts is to place the IPS in your network behind a perimeter filtering device. This simple placement task may reduce the number of alerts that you need to filter by several thousand events per day.
2. Deploy your IPS with the default signatures in place. There are no specialized profiles or specialized parameters that need to be configured to deploy a Cisco IPS. The default signature set will provide you with a high security protection posture. You can view all the IPS signatures on your sensor using Cisco IPS Manager Express and browsing to Configuration > IPS-Name > Policies > IPS Policies > All Signatures. You can view only your active signatures by browsing to Configuration > IPS-Name > Policies > IPS Policies > Active Signatures.
Note: This case study uses the default Cisco IPS signature set. The Cisco IPS signature team has spent thousands of person hours determining the most secure default signature settings. If you think you may have inadvertently changed some signature values, select all signatures, click the button "Restore default" and then click "Apply."
3. Set the event action override to drop packets with a risk rating greater than 90. This is the default configuration and will help ensure that high risk alerts will be stopped immediately.
Note: By default, the sophisticated Cisco IPS risk rating calculation feature will accurately identify risks and report a risk rating value for each alert that is fired. The higher the risk rating, the more dangerous the attack.
Check your default event action override by using Cisco IPS Manager Express and browsing to Configuration > IPS-Name > Policies > IPS Policies. Following is the screen capture for this case study.
Click the "Edit" icon and then the Advanced tab to view the current override settings. HIGHRISK should be set to 90.
4. Now that the IPS device is set to a default signature set located correctly in the network and overrides are set correctly, we can start the case study. The following steps will be taken to generate both benign and real alerts on the IPS device.
• The scanning device (172.16.50.40) will run one NMAP scan to the data center server (172.16.50.70).
• Using the same IP addresses, the scanning device will run one default Nessus scan to the data center server.
• During these scans, the attack servers (172.16.50.60 and 10.1.1.1) will launch several real attacks against the data center servers.
• During the scans, the 10.1.1.1 or 10.1.1.2 attack devices will generate both high- and low-priority attacks to help demonstrate some high-level security analysis used to decide how to respond to these attacks.
5. After this scan and attack traffic is generated, there will be a few hundred alerts fired by the IPS. All of these alerts are not what would be considered actionable alerts, so harmless events need to be eliminated.
Begin the Filtering Process
Note: Just scanning a single target for three minutes generated almost 700 events. That's 233 events per minute per scanner on your network. It's not unusual for a company to run multiple scanners: consider that if you have five scanners on your network, you will generate 1,006,5560 benign events per day!
a. Configure the Cisco IPS device to ignore these alerts in the future.
b. Allow the Cisco IPS device to fire the alerts and then use Cisco IPS Manager Express to only filter the benign events.
1. To filter all events from the scanner, enter (not equal) != 172.16.50.40 into the attacker IP address field. This will immediately get rid of all the primary alerts generated by the scanner and significantly reduce the number of alerts you need to work with. We've gone from 800 alerts to 14.
2. The next step is to look at the remaining attacks and see if anything jumps out. The most obvious is the attacks that are destined for an IP address of 0.0.0.0. Enter !=0.0.0.0 in the destination IP address field. We are now down to 7 alerts.
3. The next step is to filter attacks that have been dropped. Scroll though the list and you can easily see those alerts. Keep in mind that even though these are high-level alerts, they are not overly concerning because they have been blocked. No forensics need to be performed on these alerts unless you want to check the attacking IP address.
4. The next step is to filter information alerts. Uncheck the box labeled "Informational." Even though these events are filtered out, they could warrant investigation. In many cases, including this example, the low-priority events may indicate that another device is doing reconnaissance on a device protected by the IPS.. Network administrators should research these source addresses to see if the reconnaissance on those machines is being caused by malware or an employee. If it's an infected machine, remove the malware or restore the infected device to a known good condition. There are now five alerts remaining.
5. At this point, the tuning process is essentially complete: all the benign scanning events, alerts for invalid destination address, informational alerts, and stopped attacks have been filtered. The remaining alerts are considered actionable information. They represent the greatest threat to your network and therefore must be analyzed. Researching these events with Cisco IPS Manager Express is a straightforward process.
1. The event in the case study to be analyzed is Cisco sig ID 5867/0. The following steps must be taken.
Research the alert: Right-click on the event and select the "Explanation" tab. The description says, "The signature fires on attempts to instantiate the WinZip ActiveX control. A vulnerability exists in the ActiveX control that was never intended to be used in Internet Explorer." A second section in the explanation tab tells you if other actions besides an attack can cause this signature to fire. In this case, it says "Individuals browsing proof of concept code may cause this signature to trigger." This description is telling us that either someone browsed to a Webpage and looked at proof of concept code or there was an actual attack. We are going to assume that an attack was attempted because if it was an incident during browsing, the port should have been HTTP TCP/80, but it was port 39630. There are a few steps you want to take because this may have been a successful attack.
Fix the attack source: If the attack originated from a device on your network, remove malware or reinstall the source OS, and install current security patches and applications. You may also want to take a look at the person who owns the machine. Keep in mind that another attacker may have exploited that machine; in other words, the machine owner may also be a victim.
Fix the destination host: Use a vulnerability scanner and see if the destination host was vulnerable to the attack that was reported. If not, there is a good chance the machine has not been compromised. If the vulnerability does exist, take the same steps to restore the system: remove malware or reinstall the source OS, and install current security patches and applications.
Modify IPS policy to provide more information: It can sometimes be difficult to determine if an attack occurred. A best practice is to use verbose logging, which will capture the entire packet that triggers an alert. When an alert is triggered, you can view data in the packet; this provides you with more precise information to determine if an attack is successful.
• To globally enable verbose alert reporting and critical signatures, browse to Configuration > Policies > IPS Policies. Click "Edit" on the desired virtual sensor. See the following panel.
2. Click "Add" to define a new global action. For medium-risk attacks, create an action that will product verbose output for alerts that have a risk rating between 70 and 89. See the following panel for a configuration example.