Cisco ASA shunned connection

Shunning Traffic

Sometimes it might be possible for malicious hosts to open connections into the protected network. This could occur if the inbound access list policies aren't 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 CLI or through an automatic action from a Cisco Intrusion Protection System. After shuns are configured, they remain in place until they are removed.
Shuns are dynamic in nature and are not stored as 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 fail over, any active shuns are lost.
You can follow these steps to configure a shun:
Manually shun connections:

FWSM 2.x
Firewall# shun src_ip [ dst_ip sport dport [ protocol ]] [ vlan_id ]
PIX 6.x
Firewall# shun src_ip [ dst_ip sport dport [ protocol ]]
PIX 7.x
Firewall# shun src_ip [ dst_ip sport dport [ protocol ]] [ vlan_id ]

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.

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 define only 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.

Display active shuns:


show shun




The output from this command displays all active shuns. If a specific source address src_ip is given, only shuns involving that address are shown.

For example, the following output displays the four shuns that are currently active. In PIX 7.0, the source interface is automatically determined and shown too:


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 played the role of the malicious user , attacking hosts on the outside of the firewall.

(Optional) Remove an existing shun:


no shun


This command removes any active shuns for source address src_ip from the firewall.

You can monitor the activity of each active shun with the show shun statistics command, which displays each of the firewall interfaces, 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.
In the following 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.

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 by using the include or grep commands. In the following example, only the shun for source address is needed. It is shown to have blocked 334,699 packets, and it has been active for 112 hours, 13 minutes, and 19 seconds:

show shun statistics


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

Shun Example

A host at is discovered to be involved in malicious activity. (In this example, only a Telnet connection is shown for simplicity.) A shun is configured on the firewall to stop any current or future connections involving that host.
First, look at an active connection involving

show conn

1 in use, 3 most used
TCP out in idle 0:00:04 Bytes 138 flags UIOB

That host does have at least one active connection, so a shun is put into place:


Shun successful

show conn

1 in use, 3 most used
TCP out in idle 0:04:25 Bytes 138 flags UIOB

Indeed, the current connection has become unresponsive from (as shown by the increasing idle time), and it is also unable to start new sessions through the firewall. But why is the connection still shown in the firewall's connection table?
First, look at the buffered Syslog information on the firewall. Hopefully it will show something interesting:

show logging

Syslog logging: enabled
    Facility: 20
    Timestamp logging: enabled
    Standby logging: disabled
    Console logging: disabled
    Monitor logging: disabled
    Buffer logging: level informational, 3523423 messages logged
    Trap logging: level informational, 3523423 messages logged
        Logging to outside (EMBLEM format)
    History logging: disabled
    Device ID: hostname "Firewall"

401002: Shun added: 0 0

111008: User 'enable_15' executed the 'shun' command.

401004: Shunned packet: ==> on interface outside

401004: Shunned packet: ==> on interface outside

401004: Shunned packet: ==> on interface outside

401004: Shunned packet: ==> on interface outside

The Syslog record shows that the shun was put into place and that it is actively shunning new packets. Why didn't the active connection drop immediately? The answer is this: As soon as the shun became active, the firewall began dropping packets involving The TCP connection shown in the connection table was already established, after a three-way handshake. As soon as packets started being dropped, the TCP connection became isolated; each host in the connection no longer could hear from the other end.
As a result, the TCP connection becomes a " half-open " or "half-closed" connection until either it times out or both endpoints handshake with a FIN flag. The firewall keeps the shunned connection in its table until its own half-closed timer expires . You can see this by verifying the timer value and the shun statistics:

show conn

1 in use, 3 most used
TCP out in idle 0:06:48 Bytes 138 flags UIOB

sh timeout

timeout xlate 3:00:00
timeout conn 1:00:00

half-closed 0:10:00

udp 0:02:00 rpc 0:10:00 h225 1:00:00
timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute

show shun statistics

outside=ON, cnt=13
inside=ON, cnt=0
dmz=OFF, cnt=0

Shun cnt=0, time=(121:03:07)
Shun cnt=0, time=(119:52:22)
Shun cnt=13,



Indeed, the half-closed timer is 10 minutes, and the active connection has been shunned for only 3 minutes 58 seconds. After 10 minutes has elapsed, the TCP connection is deleted from the firewall's table. 


Popular posts from this blog

Securing the Pi-hole with fail2ban to prevent DNS Amplification attacks

How to clean DB from old logs in Magento 1.x

Python pxssh failed on login. could not set shell prompt