Guest

Product Support

Identifying and Mitigating Exploitation of the CSA for Linux DoS Vulnerability

Advisory ID: cisco-amb-20061101-csa

http://tools.cisco.com/security/center/content/CiscoAppliedMitigationBulletin/cisco-amb-20061101-csa

Revision 1.0

For Public Release 2006 November 1 16:00  UTC (GMT)


Contents

Cisco Response
Device Specific Mitigation and Identification
Additional Information
Revision History
Cisco Security Procedures
Related Information

Cisco Response

Vulnerability Characteristics

The Cisco Security Agent (CSA) for Linux port scan denial of service (DoS) vulnerability can be exploited remotely with no authentication and no user interaction is necessary. Successful exploitation may allow the attacker to cause a DoS condition. The attack vector is through port scans of Linux hosts running vulnerable versions of CSA. This vulnerability is not covered by a CVE ID.

This document contains information to assist Cisco customers in mitigating attempts to exploit this vulnerability.

Vulnerable, non-affected and fixed software information is available in the PSIRT Security Advisory at http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20061025-csa.

Mitigation Technique Overview

Cisco devices provide several countermeasures for the CSA for Linux port scan DoS vulnerability. The most preventive control is provided by Cisco IOS routers and firewalls at the network level using transit access control lists or stateful packet inspection. It should be noted that an attack may still be successful against this vulnerability if that attack originates on the same local network where the vulnerable hosts reside. Therefore, access control should be enforced as close to the target endpoint as possible to minimize potential attack vectors. Detective controls can be performed by Cisco IOS devices, PIX/ASA firewalls, and Cisco IPS devices.

Risk Management

Organizations are advised to follow their standard risk evaluation and mitigation processes to determine the potential impact of [this vulnerability|these vulnerabilities]. Triage refers to sorting projects and prioritizing efforts that are most likely to be successful. Cisco has provided documents that can help organizations develop a risk-based triage capability for their information security teams. Risk Triage for Security Vulnerability Announcements and Risk Triage and Prototyping can help organizations develop repeatable security evaluation and response processes.

Device-specific Mitigation and Identification

Specific information on mitigation and identification is available for these devices:

Internet Edge Routers

caution Caution: The effectiveness of any mitigation technique depends on specific customer situations such as product mix, network topology, traffic behavior, and organizational mission. As with any configuration change, evaluate the impact of this configuration prior to applying the change.

Mitigation

Interface Access Lists

The following access control list blocks IP packets from untrusted sources destined for the target Linux devices on the 192.0.2.0/24 network. Added access control list entries should be implemented as part of a transit access control list policy that filters transit and edge traffic at network ingress points.

For more information on ACLs, refer to Transit Access Control Lists: Filtering at Your Edge.


!-- Permit IP packets from trusted source addresses (192.168.1.0/24) !-- to the destination Linux hosts (192.0.2.0/24).

access-list 100 permit ip 192.168.1.0 0.0.0.255 192.0.2.0 0.0.0.255

!-- Deny IP packets from unknown and untrusted source addresses !-- to the destination Linux hosts (192.0.2.0/24). 
access-list 100 deny ip 10.0.0.0 0.255.255.255 192.0.2.0 0.0.0.255
access-list 100 deny ip 172.16.0.0 0.15.255.255 192.0.2.0 0.0.0.255
access-list 100 deny ip 192.168.0.0 0.0.255.255 192.0.2.0 0.0.0.255

!-- Permit/deny all other IP traffic in accordance with !-- existing security policies and configurations. 
!

!-- Apply access list to interface in the inbound direction.

interface FastEthernet0
  ip access-group 100 in
!

Identification

Interface Access Lists

With a transit access control list, after the interface access control list is applied, the show access-list command can be used to identify the number of packets being filtered. Filtered packets should be investigated to determine if they are attempts to exploit this vulnerability. Example output for show access-list 100 follows. In the example, there were 82 packets dropped by access-list 100, which is applied in the inbound direction on interface FastEthernet0.

edge-router#show access-list 100
Extended IP access list 100
     10 permit ip 192.168.1.0 0.0.0.255 192.0.2.0 0.0.0.255
     20 deny ip 10.0.0.0 0.255.255.255 192.0.2.0 0.0.0.255 (20 matches)
     30 deny ip 172.16.0.0 0.15.255.255 192.0.2.0 0.0.0.255 (22 matches)
     40 deny ip 192.168.0.0 0.0.255.255 192.0.2.0 0.0.0.255 (40 matches)
edge-router#

Branch Office Routers

caution Caution: The effectiveness of any mitigation technique depends on specific customer situations such as product mix, network topology, traffic behavior, and organizational mission. As with any configuration change, evaluate the impact of this configuration prior to applying the change.

Mitigation

Cisco IOS Firewall

Cisco IOS Firewall, also known as Context-Based Access Control (CBAC), is a stateful security software component of Cisco IOS that enables the device on which it is configured to act as a stateful inspection firewall. This function is performed by denying incoming packets from outside networks unless those packets are the result of valid connections from the Linux hosts on the inside networks. Cisco IOS Firewall dynamically opens a pinhole in an access control list applied on a Cisco router that would normally block incoming traffic. Cisco IOS Firewall may not be appropriate for deployment on an enterprise Internet edge router because of performance limitations. As with any configuration change, evaluate the impact of this configuration prior to applying the change.

For more information on Cisco IOS Firewall, refer to Cisco IOS Firewall Design Guide.


!-- Deny RFC1918 and probable spoofed address space.

access-list 100 deny ip 10.0.0.0 0.255.255.255 any
access-list 100 deny ip 127.0.0.0 0.255.255.255 any
access-list 100 deny ip 169.254.0.0 0.0.255.255 any
access-list 100 deny ip 172.16.0.0 0.15.255.255 any
access-list 100 deny ip 192.0.2.0 0.0.0.255 any
access-list 100 deny ip 192.168.0.0 0.0.255.255 any

!-- Permit IP packets for specific hosts and services provided to the Internet. !-- In this example, the machine at address 192.0.2.20 provides domain name !-- services to the Internet and the machine at address 192.0.2.30 is a !-- publicly accessible web server. 
access-list 100 permit udp any host 192.0.2.20 eq domain
access-list 100 permit tcp any host 192.0.2.20 eq domain
access-list 100 permit tcp any host  192.0.2.30 eq www

!-- Deny IP packets from unknown outside source addresses to all !-- the inside destination addresses. 
access-list 100 deny ip any any

!-- Create an inspect list to open holes in the inbound access control list !-- for valid return packets. 
ip inspect name firewall dns
ip inspect name firewall smtp
ip inspect name firewall http
ip inspect name firewall tcp
ip inspect name firewall udp

!-- Apply access control list to outside interface in the inbound direction !-- and inspect list to outside interface in the outbound direction. 
interface FastEthernet0
  ip access-group 100 in
  ip inspect firewall out
!

Additional information on the ip inspect command can be found in the IOS Security Command Reference.

Identification

Cisco IOS Firewall Logging

The following log messages show packets arriving and being dropped from untrusted hosts by the CBAC function in Cisco IOS.

Oct 24 2006 15:29:53.140 MDT: %FW-6-DROP_PKT:
   Dropping tcp pkt 192.168.50.50:35674 => 192.0.2.32:80
Oct 24 2006 15:30:41.376 MDT: %FW-6-DROP_PKT:
   Dropping tcp pkt 192.168.40.40:9384 => 192.0.2.32:25

The show access-list 100 command can also be used with a CBAC scenario to determine the number of packets being filtered. In this example, 18 packets were dropped by access list 100, which is applied in the inbound direction on interface FastEthernet0.

edge-router#show access-list 100
Extended IP access 100
    10 deny ip 10.0.0.0 0.255.255.255 any
    20 deny ip 127.0.0.0 0.255.255.255 any
    30 deny ip 169.254.0.0 0.0.255.255 any
    40 deny ip 172.16.0.0 0.15.255.255 any
    50 deny ip 192.0.2.0 0.0.0.255 any
    60 deny ip 192.168.0.0 0.0.255.255 any
    70 permit udp any host 192.0.2.20 eq domain
    80 permit tcp any host 192.0.2.20 eq domain
    90 permit tcp any host  192.0.2.30 eq www
    100 deny ip any any (18 matches)

Cisco PIX, ASA, and FWSM Firewalls

caution Caution: The effectiveness of any mitigation technique is dependent on specific customer situations such as product mix, network topology, traffic behavior, and organizational mission. As with any configuration change, evaluate the impact of this configuration prior to applying the change.

Mitigation

Cisco ASA, PIX, and FWSM firewalls provide effective mitigation for the CSA for Linux port scan DoS vulnerability when deployed between the untrusted network and the vulnerable hosts with a basic configuration. The basic configuration of Cisco firewalls prevents connection attempts, including port scans from the outside networks to inside networks with higher security levels. The most preventive control is provided by Cisco firewalls at the network level. It should be noted that an attack may still be successful against this vulnerability if that attack originates on the same local network where the vulnerable hosts reside.

Identification

There are three different scenarios with different messages or warnings that will appear on a PIX/ASA firewall that could be employed to identify an attempt to exploit this vulnerability. The first scenario involves a PIX/ASA configured for NAT with a Linux host behind the firewall that is not configured for NAT. These messages show inbound TCP connections being set up and then torn down with the expiration of the SYN timer timeout. These messages are logged at the informational level.

Oct 25 2006 10:00:04: %PIX-6-302013: Built inbound TCP connection 3837
   for outside:10.89.236.135/42682 (10.89.236.135/42682)
   to inside:192.0.2.45/373 (192.0.2.45/373)
Oct 25 2006 10:00:05: %PIX-6-302013: Built inbound TCP connection 3838
   for outside:10.89.236.135/42682 (10.89.236.135/42682)
   to inside:192.0.2.45/32773 (192.0.2.45/32773)
Oct 25 2006 10:00:05: %PIX-6-302013: Built inbound TCP connection 3839
   for outside:10.89.236.135/42682 (10.89.236.135/42682)
   to inside:192.0.2.45/1392 (192.0.2.45/1392)
Oct 25 2006 10:00:05: %PIX-6-302013: Built inbound TCP connection 3840
   for outside:10.89.236.135/42682 (10.89.236.135/42682)
   to inside:192.0.2.45/6006 (192.0.2.45/6006)
Oct 25 2006 10:00:06: %PIX-6-302014: Teardown TCP connection 3547
   for outside:10.89.236.135/42681 to inside:192.0.2.45/5632
   duration 0:00:30 bytes 0 SYN Timeout
Oct 25 2006 10:00:06: %PIX-6-302014: Teardown TCP connection 3548
   for outside:10.89.236.135/42681 to inside:192.0.2.45/3986
   duration 0:00:30 bytes 0 SYN Timeout
Oct 25 2006 10:00:07: %PIX-6-302014: Teardown TCP connection 3549
   for outside:10.89.236.135/42681 to inside:192.0.2.45/416
   duration 0:00:30 bytes 0 SYN Timeout
Oct 25 2006 10:00:07: %PIX-6-302014: Teardown TCP connection 3550
   for outside:10.89.236.135/42681 to inside:192.0.2.45/2605
   duration 0:00:30 bytes 0 SYN Timeout

The second scenario has a PIX/ASA configured for NAT and the Linux host is configured for NAT through the firewall. Some services will most likely be allowed to this Linux host. In this example, DNS and WWW are allowed, all else is dropped. In this case you will get useful syslog information at the warnings level.

Oct 25 2006 10:07:41: %PIX-4-106023: Deny tcp src outside:10.89.236.135/62412
   dst inside:10.89.236.134/1723 by access-group linux"
Oct 25 2006 10:07:41: %PIX-4-106023: Deny tcp src outside:10.89.236.135/62412
   dst inside:10.89.236.134/389 by access-group "linux"
Oct 25 2006 10:07:41: %PIX-4-106023: Deny tcp src outside:10.89.236.135/62412
   dst inside:10.89.236.134/25 by access-group "linux"
Oct 25 2006 10:07:41: %PIX-4-106023: Deny tcp src outside:10.89.236.135/62412
   dst inside:10.89.236.134/21 by access-group "linux"
Oct 25 2006 10:07:41: %PIX-4-106023: Deny tcp src outside:10.89.236.135/62412
   dst inside:10.89.236.134/23 by access-group "linux"
Oct 25 2006 10:07:41: %PIX-4-106023: Deny tcp src outside:10.89.236.135/62412
   dst inside:10.89.236.134/443 by access-group "linux"
Oct 25 2006 10:07:41: %PIX-4-106023: Deny tcp src outside:10.89.236.135/62412
   dst inside:10.89.236.134/22 by access-group "linux"
Oct 25 2006 10:07:41: %PIX-4-106023: Deny tcp src outside:10.89.236.135/62412
   dst inside:10.89.236.134/554 by access-group "linux"
Oct 25 2006 10:07:41: %PIX-4-106023: Deny tcp src outside:10.89.236.135/62412
   dst inside:10.89.236.134/3389 by access-group "linux"
Oct 25 2006 10:07:42: %PIX-4-106023: Deny tcp src outside:10.89.236.135/62413
   dst inside:10.89.236.134/3389 by access-group "linux"

In the third scenario, the PIX/ASA is not configured for NAT and the Linux host has some services allowed. In this example, DNS and WWW are allowed, and all else is dropped. In this case, you will also get useful syslog information at the warnings level.

Oct 25 2006 10:14:47: %PIX-4-106023: Deny icmp src outside:10.89.236.135
   dst inside:192.0.2.10 (type 8, code 0) by access-group "linux"
Oct 25 2006 10:14:48: %PIX-4-106023: Deny icmp src outside:10.89.236.135
   dst inside:192.0.2.10 (type 8, code 0) by access-group "linux"
Oct 25 2006 10:14:58: %PIX-4-106023: Deny tcp src outside:10.89.236.135/60305
   dst inside:192.0.2.10/3389 by access-group "linux"
Oct 25 2006 10:14:58: %PIX-4-106023: Deny tcp src outside:10.89.236.135/60305
   dst inside:192.0.2.10/22 by access-group "linux"
Oct 25 2006 10:14:58: %PIX-4-106023: Deny tcp src outside:10.89.236.135/60305
   dst inside:192.0.2.10/23 by access-group "linux"
Oct 25 2006 10:14:58: %PIX-4-106023: Deny tcp src outside:10.89.236.135/60305
   dst inside:192.0.2.10/443 by access-group "linux"
Oct 25 2006 10:14:58: %PIX-4-106023: Deny tcp src outside:10.89.236.135/60305
   dst inside:192.0.2.10/256 by access-group "linux"
Oct 25 2006 10:14:58: %PIX-4-106023: Deny tcp src outside:10.89.236.135/60305
   dst inside:192.0.2.10/636 by access-group "linux"

Cisco Switches

caution Caution: The effectiveness of any mitigation technique is dependent on specific customer situations such as product mix, network topology, traffic behavior, and organizational mission. As with any configuration change, evaluate the impact of this configuration prior to applying the change.

Mitigation

Interface Access Lists The following access control list permits IP packets from trusted sources destined for the target Linux devices on the 192.0.2.0/24 network, which is implemented on VLAN2. Added access control list entries should be applied as part of a transit access control list policy that filters transit and edge traffic at network ingress points. For more information on access control lists, refer to Transit Access Control Lists: Filtering at Your Edge.


!-- Permit IP packets from trusted source addresses (192.168.1.0/24) !-- to the destination Linux hosts (192.0.2.0/24).

access-list 100 permit ip 192.168.1.0 0.0.0.255 192.0.2.0 0.0.0.255

!-- Deny IP packets from unknown and untrusted source addresses !-- to the destination Linux hosts (192.0.2.0/24). 
access-list 100 deny ip any 192.0.2.0 0.0.0.255

!-- Permit/deny all other IP traffic in accordance !-- with existing security policies and configurations. 
!

!-- Apply access list to interface in the outbound direction.

Interface VLAN2
   ip access-group 100 out
!

Identification

Interface Access Control Lists With a transit access list, after the interface access list is applied, the show access-list command can be used to identify the number of packets being filtered. Filtered packets should be investigated to determine if they are attempts to exploit this vulnerability. Example output for show access-lists 100 follows. In the example, there were 63 packets dropped by access-list 100, which is applied in the outbound direction on interface VLAN2.

edge-router#show access-list 100
Extended IP access list 100
      10 permit ip 192.168.1.0 0.0.0.255 192.0.2.0 0.0.0.255
      20 deny ip any 192.0.2.0 0.0.0.255 (63 matches)
edge-router#

Cisco Intrusion Prevention System (IPS)

Mitigation

The Cisco Intrusion Prevention System (IPS) provides detection and mitigation for the CSA for Linux port scan DoS vulnerability starting with Cisco IPS Signature Updates S2, S158, and S160.

IPS signatures 3002/0, 2157/0, and 4003/0 can detect exploitation of this vulnerability. Response actions in addition to alarms can be configured and are most effective when using an IPS device that is deployed in inline mode.

Identification

The following signatures were triggered when an Nmap scan was run against an unprotected vulnerable host to trigger the DoS:

signature: description=TCP SYN Port Sweep id=3002 version=S2
signature: description=ICMP Hard Error DoS id=2157 version=S158
signature: description=Nmap UDP Port Sweep id=4003 version=S160

When these signatures trigger, it may indicate potential attempts to exploit the CSA for Linux port scan DoS vulnerability. These alarms should be investigated.

Cisco Security Monitoring, Analysis, and Response System (CS MARS)

Identification

As depicted in the following example, the Cisco Security Monitoring, Analysis, and Response System (CS MARS) console can be monitored for attempts to exploit the CSA for Linux port scan DoS vulnerability. The example below shows the Event and Session information correlated to the attempted exploits of this vulnerability and the subsequent trigger of several port scans or sweeps on the IPS device. In this example, several TCP SYN, TCP FIN, and TCP Frag FIN port sweeps are displayed.

cisco-amb-20061101-csa-01.gif

Additional Information

THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME.

Revision History

Revision 1.0

2006-November-01

Initial public release.

Cisco Security Procedures

Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's worldwide website at http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html. This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at http://www.cisco.com/go/psirt.

Related Information