Using the Shun Command on the PIX/ASA

Wednesday, May 18, 2011

Global Knowledge

0dc5fdbc98f80f9aaf2b43b8bc795ea8

Article by Doug McKillip

One command that had a fairly long history first with the PIX Firewall and now the ASA is the shun command.

In this post we’ll examine this command’s history, why it’s useful, and its new-found resurgence in threat detection implementation.

The earliest operating system release that shows support for shun is PIX OS 6.0. As a long-time Cisco security instructor, I remember this being released nearly eleven years ago!

Although not explicitly stated, this command provides for immediate blocking of either specific connections or all traffic originating from a particular host.

This blocking action can be implemented either manually or via an Intrusion Detection (IDS) or Intrusion Prevention System (IPS) automatic signature triggered action.

While IDS/IPS blocking on a router uses an access-list, this solution would be unwork-able for a PIX or ASA because of the way access-lists operate on the security appliances — only the initial packet of any connection is examined.

To take this a step further, once a source IP address is in the connection table, any applied access-list deny statement for this IP source address is irrelevant for those existing connections.

The shun command “fills the gap” by being used to stop any/all traffic from even those source addresses that already have established connections.

The syntax for the shun command in the original PIX OS6.0 document is as follows:

[no] shun src_ip [dst_ip sport dport [protocol]]

Note that this syntax includes provision for connection-related ports and protocol. The emphasis is given here because as the IPS Blocking course material indicates, the shun command is limited to blocking hosts.

The writer further investigated this discrepancy and noted that even though a signature might be configured for Block Connection, the actual implementation on the ASA via the telnet or ssh session is only for blocking the source IP address.

In addition, the IPS sensor will both stay logged into the ASA after being provisioned for connectivity and will remove the shun after a configurable time interval.

When PIX/ASA version 8.0 code was introduced in 2008, a new feature was added which expanded the use of shun beyond either a manual or IPS-initiated implementation.

A three-tiered implementation of Threat Detection, when properly configured, could not only identify attackers attempting reconnaissance or Denial of Service (DoS) but also stop an attacker if the Scanning option was enabled, again using the shun command.

The table below from the Configuring Threat Detection chapter of the Cisco ASA 5500 Series Configuration Guide shows the history of this capability:

image

As the above table indicates, the allowance for expiration of the applied shun was not in the originally deployment. What is not shown above is the ability to exclude hosts from being shunned.

This is typically implemented by creating an object group of a host or network from which vulnerability analysis (typically scanning) originates and is consequently misinterpreted as malicious.

Cross-posted from Global Knowledge

Possibly Related Articles:
14993
Firewalls
Information Security
Firewalls Cisco Operating Systems IDS/IPS PIX/ASA
Post Rating I Like this!
850c7a8a30fa40cf01a9db756b49155a
J. Oquendo I think clarity may be in order here. Author stated: "Although not explicitly stated, this command provides for immediate blocking of either specific connections or all traffic originating from a particular host."

shun blocks from specific connections period. So the comment: "blocking of either specific connections or all traffic originating from a particular host." is redundant.

E.g.:

shun 1.2.3.4 8.8.8.8 tcp

This would block ALL connections from 1.2.3.4 attempting to reach 8.8.8.8 via TCP yet 1.2.3.4 would be able to reach 8.8.8.8 via UDP

shun 1.2.3.4 8.8.8.8 80 80 tcp

This would block ALL connections from 1.2.3.4 from port 80 attempting to reach 8.8.8.8 via HTTP however, there is no guarantee that 1.2.3.4 is using 80 to connect to 80 so its a useless rule.

I think the author may have meant: "blocking of connections from specific ports to specific destinations on specific ports, or all traffic originating from a specific source"

Mind you, even those rules block an attacker from a specific originating point to a specific destination point. If there were another server say at 8.8.8.9, that server would be reachable. The workaround is to leave OUT the destination address:

shun 1.2.3.4

Source is the only mandatory field when using shun on pix
1305733987
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.