Ask the Expert: Intrusion Prevention Systems (IPS)

Welcome to the Cisco Support Community Ask the Expert conversation. This is an opportunity to discuss configuration and troubleshooting IDS/IPS sensors with Cisco expert Madhu Kodali.

Madhu is a senior QA engineer on the Intrusion Prevention Systems development team in Austin, Texas, which supports the quality assurance of Cisco's intrusion detection and prevention solutions. He has been with Cisco for 10 years. His expertise lies in intrusion detection and prevention and the associated range of Cisco management products including Cisco IPS Manager Express and Cisco Adaptive Security Device Manager. Kodali holds a master's degree in computer science from the University of Texas at Dallas and currently holds CCSP and CISSP certification.

Remember to use the rating system to let Madhu know if you have received an adequate response.

Madhu might not be able to answer each question due to the volume expected during this event. Remember that you can continue the conversation on the Security sub-community discussion forum shortly after the event. This event lasts through June 1, 2012. Visit this forum often to view responses to your questions and the questions of other community members.

This discussion thread is limited to Intrusion Prevention Systems (IPS) related questions. Looks like the Network Infrastructure (LAN Switching and Routing) would be the right community for you to post your question. As a friendly tip please include relevant details when posting your question to that forum.

- No the default account of cisco cannot be deleted. You can disable it using the no password cisco command, but you cannot remove it. To use the no password cisco command, there must be another administrator account on the sensor. Removing the cisco account through the service account is not supported. If you remove the cisco account through the service account, the sensor most likely will not boot up, so to recover the sensor you must reinstall the sensor system image. More details are on http://www.cisco.com/en/US/docs/security/ips/7.1/configuration/guide/idm/idm_logging_in.html#wp1249663

3)My IPS is in promiscous mode, i want to add blocking device which is using SSH v2, does it supported by IPS.

- Sensor does not support ssh v2 however we do support the use of 3des option for a more secure connection under network-access service as shown below

qssp-8083(config-net-fir)# communication ?

ssh-3des Establish SSH session using 3DES encryption.

telnet Establish Telnet session.

4) Recently i have seen huge number of signature update (approx. 1 per week), so i want to automate the signature update can IPS run behind proxy ?

- Sensor cannot be configured with a proxy server, but if you are using CSM to manage the server then you can configure a proxy on the CSM for both CCO downloads and local FTP server. If you are not using the CSM then maybe you can tweak the destination server to use some kind of port forwarding. On a side note if you are using the auto-update feature of the sensor then you wont need to automate this process.

First I would like to clarify on the terminology that we are using here. When you say "rule" I assume you are referring to "signature" in the IPS. By "drop" we would mean any deny-packet or deny-connection of the traffic packets.

Dropping a packet can result from a combination of factors like event-action of deny on the signature or an override of deny-packet-inline/deny-connection-inline actions or a deny due to global correlation reputation updates, etc. When the event-action of a signature is deny-packet or deny-connection the packets will be dropped on the trigger of that signature, unless you have a filter to stop the drops. Drop can also occur due to event-action overrides that add deny actions when the risk-rating of the alert exceeds a particular threshold. When the risk rating of the alert exceeds a value of 90, a deny-packet-inline will be added because of the default deny-packet-inline rule configured on the sensor as shown below :

To address your concern I would not suggest disabling the rule unless you are completely convinced that the alert is a false positive. In your case looks like signature is getting triggered when it should not have. To being with you should approach Cisco TAC to raise a bug for this problem. Then you can follow up with reducing the severity of the signature. A couple of trial tunings will help you set the severity to bring down the risk rating threshold at which the deny-packet-inline override will not be added.

For any future sig updates a better practice to prevent legitimate traffic from being dropped here are the options you have

- To have the signature alerting but reducing the severity.

- Reduce the risk rating range for the deny-packe-inline override to a lesser range

- Alternatively you can add a filter under event-action-rules service to filter the "drop action" for that particular signature

You can disable the signature after it is confirmed that you really have a false positive case.

I am new to ASA config and support and I noticed some time ago that our 5520 has a

ASA-SSM-20 in slot 1

Name: "slot 1", DESCR: "ASA 5500 Series Security Services Module-20"

PID: ASA-SSM-20 , VID: V01 , SN: JAF10431785

but not in use.

I suppose it would be good to actually make use of this IPS but I have no idea how to place it inline or what usefulness it really has for us. And appearently none of my predicessors had any use or interest in it.

If we did use it would it significantly slow processing and could it be activated without a reload?

The AIP SSM does not have an external interface to receive the traffic other than the management interface to connect externally. This module runs the IPS software which provides advanced protection capabilities agains worms and viruses and other threats. In line mode the traffic can be denied proactively. You can start with first placing the module in promiscuous mode and then switch to inline once you are comfortable with its operations. It should not have significant impact on the performance. The module can be activated without reloading the ASA. Below are some more details that will help you get started.

On ASA any traffic that enters the appliance is subjected to a firewall policy that is configured. This traffic is then sent to AIP SSM over the backplane. Based on the security policy that is configured on SSM appropriate actions are taken. Valid traffic is sent back to the ASA over the back plane and SSM may block some traffic according to the policies. Different actions are taken by the ASA based on the feedback from SSM. Traffic then exits the appliance.

Step 1 Session in to the AIP SSM using an account with administrator privileges

asa# session 1

Step 2 Enter the setup command. The System Configuration Dialog is displayed.

Step 3 Specify the hostname. The hostname is a case-sensitive character string up to 64 characters. Numbers, "_" and "-" are valid, but spaces are not acceptable. The default is sensor.

Step 4 Specify the IP interface. The IP interface is in the form of IP Address/Netmask,Gateway: X.X.X.X/nn,Y.Y.Y.Y, where X.X.X.X specifies the sensor IP address as a 32-bit address written as 4 octets separated by periods, nn specifies the number of bits in the netmask, and Y.Y.Y.Y specifies the default gateway as a 32-bit address written as 4 octets separated by periods.

Step 5 Enter yes to modify the network access list

a. If you want to delete an entry, enter the number of the entry and press Enter, or press Enter to get to the Permit line

b. Enter the IP address and netmask of the network you want to add to the access list.

For example, 10.0.0.0/8 permits all IP addresses on the 10.0.0.0 network (10.0.0.0-10.255.255.255) and 10.1.1.0/24 permits only the IP addresses on the 10.1.1.0 subnet (10.1.1.0-10.1.1.255). If you want to permit access to a single IP address than the entire network, use a 32-bit netmask. For example, 10.1.1.1/32 permits just the 10.1.1.1 address.

c. Repeat Step b until you have added all networks that you want to add to the access list, and then press Enter at a blank permit line to go to the next step.

Step 7 You must configure a DNS server or an HTTP proxy server for global correlation to operate

a. Enter yes to add a DNS server, and then enter the DNS server IP address.

There are different aspects of your question. Your options are Standalone IPS vs Integrated IPS modules (within ASA).If you are planning to have a standalone IPS appliance then here are some guidelines and implications :

The most common place for IPS is at the internet border and dmz. Placing IPS outside the firewall will give an early indication of the scanning but has the risk of more false positives. The source destination addresses could be NATed causing more research to determine which organization is being attacked. The other con of this is you cannot see the traffic that goes from inside to dmz.

Placing inside the firewall minimizes the false positives and also IPS events will include real non NATed IPs. You can differentiate the traffic to/from DMZ and Internal segments. The traffic coming out of the firewall will be already normalized and inspected to some extent. The con for this is that you will need two IPS appliances. In either case the sizing of the IPS for the required bandwidth is an important consideration.

The otter option is to go for the integrated IPS module that can be placed inside the ASA 5540 and 5520. Once you instal the module, the ASA can be configured with different policies for the inspection needs. The con of having integrated module can be bandwidth limitation on the ASA.

Here is the link to give you an idea about the bandwidth capabilities for SSM-20 and SSM-40 modules

You will need to protect both the internal zone and DMZ zone. With that in view I was suggesting two IPS appliances - one after the firewall in the DMZ zone and other appliance after the firewall in the INSIDE zone (192.168.x.x).

Since you have two ASA (one with integrated IPS) you maybe better off using just one ASA. It depends on the load that is expected across the ASA. If you expect higher load then you can use ASA 5540. In this case you can procure one SSM-40 to insert in the ASA5540. If the traffic loads can meet ASA-5520 then please use this with the integrated module SSM-10. Either case configure appropriate policies on the SSM module for protecting the zones. This way you save one ASA to be used at some other place in the network.

Here is the link for data sheet for load handling capabilities of different ASA models

ASA and IPS have different areas of application. ASA firewall provides the access control and sometimes vpn services. They also provide some basic application inspection and threat protection but a more advanced protection against malware, evasions, trojans and worms is provided by IPS. To inspect packets and streams beyond layer 4 an IPS would be needed as firewalls usually don't have intensive deep packet inspection capabilities.

We have a pair of IDSM-2 modules, one in each of our core 7613 routers. We are using these in inline mode, with VLAN pairs. One module is dedicated to protecting our inbound internet connection. It handles two VLAN pairs, one is behind the firewall, and the second is behind our F5 load balancer, which does SSL offload.

We are experiencing unacceptably high inspection loads whenever our internet traffic goes above 50Mbps. We see high latency (around 1000ms) and packet drops. So we are compelled to bypass IDSM-2, which is rated at 500Mbps, when the traffic exceeds 100Mbps. We are not using custom rules, or any heavy logging.

The traffic primarily consists of a high number of small file transfers from mobile devices. I understand that 500Mbps may be under ideal conditions, but we're not getting even close. Is there anywhere we can look to improve performance?

The IDSM2 is rated at 500 Mbps based on http traffic with average segment size of 650 bytes. Any other traffic profile with lesser packet size and non-TCP protocol can adversely impact the performance. However 50 Mbps sounds very low for any traffic profile. Here are some trouble shooting steps you can follow to debug this issue :

- Configure bypass mode to ON on the IDSM2 to see if that resolves the issue of high latency and inspection load. If it does not resolve the issue then check the memory usage and CPU as IDSM2 has been prone to the HDD issue needing the disk to cool down for approximately 30 min.

- If bypass mode resolves the issue then it is the type of traffic that is causing the high inspection load. If the traffic is primarily TCP then check to see if the normalizer sigs are firing. These sigs are 1330/1300 sigs that show up under "show statistics virtual-sensor". In this case there maybe some tuning needed for the sigs. If normalizer is not an issue then please check if there are any other settings like event action overrides or custom signatures that maybe causing the delay in traffic.

- If the traffic is not TCP then have the traffic sample captured and contact Cisco TAC for further assistance. Cisco TAC can help reproduce the issue and suggest the next appropriate steps. Please provide the software version on the IDSM2 and the output of "show tech-support" while opening a case.

Thanks for your response. This gives me a few places to look for clues.

If I bypass the sensor, then the problem goes away, so the inspection load is definitely the problem.

I have about 10 event action overrides, mostly to disable events generated by external/internal security scans (Qualys, etc.). Is processing these rules very resource intensive? I could probably pare these down if I had to, but 10 seems like a fairly modest number.

I was seeing a lot of the normalization signatures firing, but I disabled these signatures in an attempt to reduce the load.

I was able to reduce the load on the IDSM2 by disabling a number of lower priority and normalization related signatures, but I still find inspection load maxing out at around 100Mbps throughput. The traffic is around 95% TCP.

Please check if you are at the latest sig level as there were a few sigs that were affecting the performance in file transfer scenarios. A show version on the IDSM2 would tell us the major version and also the Sig level. If you are at the latest sig level, then you may need to use Regex Depth setting to get better performance with file transfers (under the RegexDepth setting )

The even action overrides should not add to the processing load. I suspect it is the type of traffic that IPS is analyzing. If possible please provide a sample capture of the packets which would truly represent the traffic. This would give us an idea of the protocol and ports that are being used for the file transfer.

The traffic is predominantly http and https. The IDSM-2 is inline behind the firewall, so traffic is mostly https at this point. Then the traffic goes through the load balancer, where it is decrypted to http and then fed through the IDSM-2 again. We have two VLAN pairs set up.

File transfer is not really how I would characterize the traffic. These are 1000s of mobile devices, each uploading 100K-1000K payloads.

I tried the RegexDepth setting to 800000 but it made no difference. The bug report suggested a lower value could be tried. Do have any suggestions how I should step it down? Is 700000 a reasonable next step?

The smartnet on these ran out 4/1/2012. We are reluctant to renew if these are not going to sufficient for our use case, so I'm in a bind to find some way to tune the performance to handle 100Mbps easily (two 50Mbps VLAN pairs).

Changing the inline-TCP-session-tracking-mode made a huge difference. Performance seems to be almost 2X what it was before. I was able to leave the IDS inline during a period of peak traffic (over 120Mbps counting both VLAN pairs). At this rate the inspection load was about 70.

Thanks again for your time - this conversation has been extremely helpful.

We have a pair of 5520 with IPS modules fitted in each. We have had to reinstall the IPS module on the secondary but I would like it to syncronise configuration with the IPS module in the Active ASA. Could you let me know what needs to be done, I have done the 'basic' setup on the IPS module so it has the correct IP addressing and same software ver (7.0(6))as the Active IPS but nothing seems to be syncronising.

Configuration on IPS is not synchronized between ASA failover pair. For IPS we have to manually copy the same configuration on both modules. Once you have configured the first IPS fully you can copy that to a tftp or a ftp server and then copy that configuration back on the second IPS.