Shunning traffic through a firewall

Malicious hosts can open connections into your clients' protected networks. Learn how you can use shun commands to block malicious connections through a firewall.

Sometimes it might be possible for malicious hosts to open connections into the protected network. This could occur...

if the inbound access list policies are not configured correctly or tightly. As soon as these connections are noticed (after they are built), you might want to react by blocking connections coming from the malicious source address.

To do this, you could edit the access list each time the source of an attack is discovered. This would deny any future connections; xlate entries would also need to be cleared to drop existing connections. This would also quickly become an administrative burden.

A more efficient alternative is the shun command. When a shun is activated, all current connections from a malicious host can be dropped and all future connections blocked.

Connections are shunned regardless of the firewall interface being traversed. The firewall examines the connection table and the connection building process to identify and shun the specified connections.

Shuns can be configured through the firewall command-line interface (CLI) or through an automatic action from a Cisco Intrusion Protection System or an integrated feature such as Threat Detection. After shuns are configured, they remain in place until they are removed.

Shuns are dynamic in nature, and are not stored as a part of the firewall configuration. If the firewall loses power or reloads, any active shuns are lost. As well, shuns are not maintained in a failover firewall pair. If the units failover, any active shuns are lost.

You can use the following steps to configure a shun:

  • 1. Manually shun connections:
    ASA, FWSM Firewall# shun src_ip [dst_ip sport dport [protocol]] [vlan_id]
    PIX 6.3 Firewall# shun src_ip [dst_ip sport dport [protocol]]

    You can shun any new connections (any IP protocol) passing through the firewall originating from source address src_ip. This is most useful to stop an attack that is in progress from the source address to many destinations. Any existing connections stay up, however. Those must idle out of the xlate and conn tables normally, or you can clear any related xlate entries to manually kill the connections.

    Read more about controlling access through a firewall
    Download Chapter 6 of Cisco ASA, PIX, and FWSM Firewall Handbook by David Hucaby.

    For more granular shunning, you can also identify the destination address dst_ip, the source and destination ports sport and dport, and the protocol. You can only define one shun entry per source and destination address pair. When a shun is defined, all existing and future connections are blocked until the shun is later removed.

  • 2. Display active shuns:

    Firewall# show shun [src_ip]

    All active shuns are listed. If a specific source address src_ip is given, only shuns involving that address are shown.

    As an example, the following output displays the four shuns that are currently active. The source interface is automatically determined and shown in parentheses.

    Firewall# show shun shun (outside) 0 0
    shun (outside) 0 0
    shun (inside) 0 0 0
    shun (outside) 0 80 6

    Notice in the shaded output line that an inside host has been the target of a shun. Shuns can be used on any host located on any interface. In this case, the inside host was playing the role of the malicious user, attacking hosts on the outside of the firewall.

  • You can monitor the activity of each active shun with the show shun statistics command. Each of the firewall interfaces are shown, along with the current shun activity. The firewall looks at its routing information to determine the interfaces where shun source addresses can be found. These interfaces are shown as "ON". A cumulative count of shunned connections is also shown.

    Each configured shun is listed with its source address, a cumulative count of shunned connections, and the total elapsed time since the shun was enabled.

    For example, a firewall is configured with a long list of shun commands. Notice that the outside interface, where malicious hosts on the public Internet were discovered, has had 17,184,951 shunned connections. The inside interface has had even more! In this case, a number of inside hosts have been discovered to be compromised and participating in malicious activity toward the outside network. Until these hosts can be cleaned, they have been "quarantined" through the use of firewall shuns.

    Firewall# show shun statistics
    stateful=OFF, cnt=0
    dmz2=OFF, cnt=0

    outside=ON, cnt=17184951
    inside=ON, cnt=255823449

    Shun cnt=32502918, time=(112:04:34)
    Shun cnt=0, time=(112:04:32)
    Shun cnt=0, time=(112:04:35)
    Shun cnt=0, time=(112:04:35)
    Shun cnt=0, time=(112:04:34)
    Shun cnt=21277328, time=(112:04:33)
    Shun cnt=0, time=(112:04:34)
    Shun cnt=21264263, time=(112:04:33)
    Shun cnt=0, time=(243:35:21)
    Shun cnt=0, time=(243:35:18)
    Shun cnt=0, time=(243:35:16)
    Shun cnt=21311395, time=(112:04:33)
    Shun cnt=0, time=(243:35:12)
    Shun cnt=0, time=(243:35:10)
    Shun cnt=334699, time=(112:04:34)
    [output omitted]


    To avoid sifting through long lists of shun statistics to find a single source address, you can filter the output through the include or grep commands. In this example, only the shun for source address is needed. It is shown to have blocked 334,699 packets, and has been active for 112 hours, 13 minutes, and 19 seconds:

    Firewall# show shun statistics | include

    Shun cnt=334699, time=(112:13:19)


    You can remove an existing shun for a specific source address with the following global configuration command:

    Firewall(config)# no shun src_ip

    Printed with permission from Cisco Press. Copyright 2007. Cisco ASA, PIX, and FWSM Firewall Handbook by Dan Hucaby. For more information about this title and other similar books, please visit www.ciscopress.com.

    Dig Deeper on Managed network services technology