Section 6-7. Shunning Traffic | CCNP BCMSN Exam Certification Guide (3rd Edition)

6-7. 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:

 Firewall# show shun [src_ip]

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:

 Firewall# show shun shun (outside) 172.21.104.93 0.0.0.0 0 0 shun (outside) 172.21.196.50 0.0.0.0 0 0 shun (inside) 192.168.198.24 0.0.0.0 0 0 0 shun (outside) 10.10.1.1 172.21.4.19 0 80 6 Firewall#

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:

 Firewall(config)# no shun src_ip

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

TIP

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.

 Firewall# show shun statistics stateful=OFF, cnt=0 dmz2=OFF, cnt=0 outside=ON, cnt=17184951 inside=ON, cnt=255823449 Shun 172.21.96.89 cnt=32502918, time=(112:04:34) Shun 172.21.61.83 cnt=0, time=(112:04:32) Shun 172.21.24.79 cnt=0, time=(112:04:35) Shun 172.21.108.68 cnt=0, time=(112:04:35) Shun 192.168.93.16 cnt=0, time=(112:04:34) Shun 172.21.184.106 cnt=21277328, time=(112:04:33) Shun 192.168.97.9 cnt=0, time=(112:04:34) Shun 172.21.184.107 cnt=21264263, time=(112:04:33) Shun 192.168.228.11 cnt=0, time=(243:35:21) Shun 192.168.228.12 cnt=0, time=(243:35:18) Shun 192.168.228.13 cnt=0, time=(243:35:16) Shun 172.21.184.108 cnt=21311395, time=(112:04:33) Shun 192.168.228.14 cnt=0, time=(243:35:12) Shun 192.168.228.15 cnt=0, time=(243:35:10) Shun 172.21.72.99 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 172.21.72.99 is needed. It is shown to have blocked 334,699 packets, and it has been active for 112 hours, 13 minutes, and 19 seconds:

 Firewall# show shun statistics | include 172.21.72.99 Shun 172.21.72.99 cnt=334699, time=(112:13:19) Firewall#

Shun Example

A host at 172.21.4.8 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 172.21.4.8:

 Firewall# show conn 1 in use, 3 most used TCP out 172.21.4.8:4334 in 192.168.199.100:23 idle 0:00:04 Bytes 138 flags UIOB Firewall#

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

 Firewall# shun 172.21.4.8 Shun 172.21.4.8 successful Firewall# show conn 1 in use, 3 most used TCP out 172.21.4.8:4334 in 192.168.199.100:23 idle 0:04:25 Bytes 138 flags UIOB Firewall#

Indeed, the current connection has become unresponsive from 172.21.4.8 (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:

 Firewall# 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 192.168.199.10 (EMBLEM format)     History logging: disabled     Device ID: hostname "Firewall" 401002: Shun added: 172.21.4.8 0.0.0.0 0 0 111008: User 'enable_15' executed the 'shun 172.21.4.8' command. 401004: Shunned packet: 172.21.4.8 ==> 169.54.89.249 on interface outside 401004: Shunned packet: 172.21.4.8 ==> 169.54.89.249 on interface outside 401004: Shunned packet: 172.21.4.8 ==> 169.54.89.249 on interface outside 401004: Shunned packet: 172.21.4.8 ==> 169.54.89.249 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 172.21.4.8. 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:

 Firewall# show conn 1 in use, 3 most used TCP out 172.21.4.8:4334 in 192.168.199.100:23 idle 0:06:48 Bytes 138 flags UIOB pix-f# 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 Firewall# show shun statistics outside=ON, cnt=13 inside=ON, cnt=0 dmz=OFF, cnt=0 Shun 10.1.1.1 cnt=0, time=(121:03:07) Shun 192.168.200.199 cnt=0, time=(119:52:22) Shun 172.21.4.8 cnt=13, time=(0:03:58) Firewall#

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.