Cisco IPS Fun

Since I’ve recently had some fun working with the Cisco 5585-X and the IPS blades, I wanted to document some of the information I learned while getting them online. Some of this came from various sources around the ‘net including the TAC IPS group, other parts are from consultants, or what we just figured out on our own while working with it. The first thing you need to understand is how traffic gets to / from the IPS. The easiest way to explain it, is that the IPS sits inside the firewall. It will be sent traffic, from a matched ACL, after the interface has performed it’s own inbound ACL filtering. In our situation, we simply defined an ACL that stated permit ip any any — but depending on the application, you may only want to filter traffic in certain directions. Below, we have an example that filters traffic with a destination defined in our object-group. The ACL you defined is matched in a class-map, which is matched in your global_policy policy-map. The command ips inline fail-open sensor vs0 actually sends the traffic (via the backplane) to the IPS blade. This command also states, that if the ASA detects an issue with the IPS, to bypass it, and continue to pass traffic as if it was never installed. To cease the flow of traffic to the sensor, remove this command from the policy-map… This would be rather usefull if a bad set of signatures were deployed and the IPS was erroneously dropping traffic.

object-group network IPS-RANGES
 network-object 10.0.0.0 255.0.0.0
 network-object 4.2.2.0 255.255.255.0
!
access-list IPS-ACL permit ip any object-group IPS-RANGES
!
class-map IPS-CLASSMAP
 match access-list IPS-ACL
!
policy-map global_policy
class IPS-CLASSMAP
 ips inline fail-open sensor vs0

Once traffic is flowing through the IPS, you should take a look at the following command. At the bottom you will see statistics of packets sent to, and receieved from the blade. As well as the number of drops.

ASA-FW# sh service-policy  

Global policy: 
  Service-policy: global_policy
    Class-map: inspection_default
      Inspect: dns preset_dns_map, packet 14803467, lock fail 0, drop 39, reset-drop 0
      Inspect: ftp, packet 1298420, lock fail 0, drop 0, reset-drop 0
      Inspect: h323 h225 _default_h323_map, packet 0, lock fail 0, drop 0, reset-drop 0
               tcp-proxy: bytes in buffer 0, bytes dropped 0
      Inspect: h323 ras _default_h323_map, packet 0, lock fail 0, drop 0, reset-drop 0
      Inspect: rsh, packet 0, lock fail 0, drop 0, reset-drop 0
      Inspect: rtsp, packet 0, lock fail 0, drop 0, reset-drop 0
               tcp-proxy: bytes in buffer 0, bytes dropped 0
      Inspect: esmtp _default_esmtp_map, packet 31147261, lock fail 2, drop 388, reset-drop 0
      Inspect: sqlnet, packet 0, lock fail 0, drop 0, reset-drop 0
      Inspect: skinny , packet 0, lock fail 0, drop 0, reset-drop 0
               tcp-proxy: bytes in buffer 0, bytes dropped 0
      Inspect: sunrpc, packet 0, lock fail 0, drop 0, reset-drop 0
               tcp-proxy: bytes in buffer 0, bytes dropped 0
      Inspect: xdmcp, packet 0, lock fail 0, drop 0, reset-drop 0
      Inspect: sip , packet 0, lock fail 0, drop 0, reset-drop 0
               tcp-proxy: bytes in buffer 0, bytes dropped 0
      Inspect: netbios, packet 278, lock fail 0, drop 0, reset-drop 0
      Inspect: tftp, packet 0, lock fail 0, drop 0, reset-drop 0
      Inspect: ip-options _default_ip_options_map, packet 0, lock fail 0, drop 0, reset-drop 0
      Inspect: icmp, packet 77268, lock fail 0, drop 832, reset-drop 0
      Inspect: ipsec-pass-thru _default_ipsec_passthru_map, packet 2533443, lock fail 0, drop 0, reset-drop 0
      Inspect: pptp, packet 0, lock fail 0, drop 0, reset-drop 0
     Class-map: IPS-CLASSMAP
      IPS: card status Up, mode inline fail-open, sensor vs0
        packet input 40316913, packet output 40316927, drop 7, reset-drop 0
    Class-map: class-default

      Default Queueing      Set connection policy:         drop 0
      Set connection decrement-ttl

Enabling and Configuring Automatic Updates

The simplest/easiest method to enable and configure the Auto/Cisco.com Update feature is via the sensor GUI (IDM). Once you login, head to Configuration > Sensor Management > Auto/Cisco.com Update. From there, make sure Enable Signature and Engine Updates from Cisco.com is checked, and head into the Cisco.com Server Settings. You must supply a valid CCO username/password, and configured a scheduled start time for the update.. Updates are released once every 1 – 2 weeks, so hourly checks are overkill. Updates happen over https, and the IPS must have the ability to connect without using a proxy. If you wish to perform a test, simply update the schedule to reflect a time in the near future. The current system time can be obtained from the CLI using the show clock command.

After an update attempt has occurred, details can be found in Auto Update Statistics section of the show stat host command. Other than authentication failures, connectivity failures are the most common and are generally due to the IPS being unable to reach the update server on tcp port 443.

ASA-IPS# show stat host | begin Auto Update
Auto Update Statistics
   lastDirectoryReadAttempt = 12:20:00 GMT-05:00 Wed May 01 2011
    =   Read directory: http://[email protected]//swc/esd/guest/
    =   Success
   lastDownloadAttempt = 12:20:00 GMT-05:00 Wed May 01 2011
    =   Download: http://[email protected]//swc/esd/guest/IPS-sig-S563-req-E4.pkg
    =   Success
   lastInstallAttempt = 12:20:30 GMT-05:00 Wed May 01 2011
    =   IPS-sig-S563-req-E4: Update completed successfully
    =   Success
   nextAttempt = 12:20:00 GMT-05:00 Thu May 02 2011

Signatures

The nomenclature surrounding IPS Signatures is a bit confusing. For instance Enable/disable does NOT select/de-select signatures to be used by IPS, that functionality is called Retire/Unretire. When a signature is retired, it means the IPS will NOT compile that signature into memory for scanning. Unretiring a signature instructs the IPS to compile the signature into memory and to use the signature to scan traffic. Enable/disable is to enforce/disregard the action associated with the signatures by the IPS when packets or packet flows match the signature. Therefore in order to perform an action against a packet / packet flow a signature must be unretired AND enabled.

When customizing your signature base there are a number of things to keep in mind. Current IPS signature definition releases contain over 5,000 individual signatures, but only a limited amount are enabled/active by default. The signatures that are enabled/active by default is determined by Cisco’s IPS Signature development team and changes from release to release as new signatures are added and old signatures become obsolete.

A new user may be inclined to select and enable all or most of the signatures thinking this would provide the most protection possible, however this is not the case. Signatures may have been retired for any number of reasons including large numbers of false positives, the signature being replaced by a newer/better one, the signature being overly complex or causing noticeable performance/stability issues, the threat no longer being relevant, etc… As such, it is never a good idea to attempt to enable and unretire bulk signatures. Doing so will almost certainly result in some serious issues like legitimate traffic being denied, bad performance, sensor crashes, etc.. Signatures that are manually enabled and/or unretired should always be thoroughly researched and understood prior to doing so.

If you wish to return the sensor’s current signature policy to default, issue the following commands…

IPS# conf t
IPS(config)# service signature-definition sig0
IPS(config-sig)# default signatures
IPS(config-sig)# exit
Apply Changes?[yes]: yes

SNMP Traps

The idea behind trap-directed notification is that it is impractical for a server to poll or request information from every SNMP object on every device. The solution is for each device to notify the server of events without solicitation. It does this by sending a message known as a trap of the event. To enable global trap notification configure the following service replacing key bits as necessary.

sensor# conf t
sensor(config)# service notification
sensor(config-not)# trap-destination 192.168.69.10
sensor(config-not-tra)# trap-community-name public
sensor(config-not-tra)# trap-port 162
sensor(config-not-tra)# exit
sensor(config-not)# enable-notifications true
sensor(config-not)# exit
Apply Changes?[yes]: yes

By default traps are not generated for events, the Request SNMP Trap Action can be added to an EAO (Event Action Override) to add a trap as an Action whenever a signature fires.

In the example provided, all Alerts will generate traps you may instead specify specify a desired Risk Rating range. (100-90 for High, 89-70 for Medium, 69-1 for Low)

sensor# conf t
sensor(config)# service event-action-rules rules0
sensor(config-eve)# overrides request-snmp-trap
sensor(config-eve-ove)# override-item-status enabled
sensor(config-eve-ove)# risk-rating-range 1-100
sensor(config-eve-ove)# exit
sensor(config-eve)# exit
Apply Changes?[yes]: yes

If you wish these traps may be added to a specific signature (instead of the EAO) by using the Request SNMP Trap Action on a per-signature basis.