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:
1.
|
Manually shun connections:
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. |
||||||
2.
|
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. |
||||||
3.
|
(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.
found at: http://flylib.com/books/en/1.297.1.49/1/
Comments
Post a Comment