Discussion:
[c-nsp] ASA shun 'bug' acknowledged
Jeff Kell
2006-05-04 02:50:52 UTC
Permalink
As I asked about earlier on the list, there is indeed an issue with the
ASA's shun behavior running 7.x software. If you're using shuns as an
IPS measure, take note.

If you issue a 'shun x.x.x.x' for an outside IP address, any existing
[TCP] connections with that IP are not affected. Traffic to and from
the IP continues to pass through the device. No *new* connections are
allowed with that IP as a source.

The bug ID is CSCse10714.

Jeff
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Christian Zeng
2006-05-04 06:54:21 UTC
Permalink
Hi,
Post by Jeff Kell
If you issue a 'shun x.x.x.x' for an outside IP address, any existing
[TCP] connections with that IP are not affected. Traffic to and from
the IP continues to pass through the device. No *new* connections are
allowed with that IP as a source.
The bug ID is CSCse10714.
I do not understand why Cisco acknowledged this as a bug, because the
behavior of the ASA is documented.

Only a full qualified shun, including destination information etc., will
drop existing connection. Subsequent connections to/from the shunned IP
will be dropped, regardless if additional information are given to the
shun command. Or did you see a different behavior?

Of course, the shun approach of the ASA is not perfect; I'd expect that
shunning an IP address results in a drop of all existing connections
without additional configuration.


Christian
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Jeff Kell
2006-05-04 15:14:39 UTC
Permalink
Post by Christian Zeng
I do not understand why Cisco acknowledged this as a bug, because the
behavior of the ASA is documented.
Only a full qualified shun, including destination information etc., will
drop existing connection. Subsequent connections to/from the shunned IP
will be dropped, regardless if additional information are given to the
shun command. Or did you see a different behavior?
The shun command allows you to apply a blocking function to the
interface receiving the attack. Packets containing the IP source
address of the attacking host are dropped and logged until the
blocking function is removed manually or by the Cisco IPS master
module. No traffic from the IP source address is allowed to traverse
the security appliance.
Note the last sentence.

This *was* the behavior of the shun command prior to 7.x on a PIX. Our previous 515E/6.x had no problems, the new ASA/7.x does. We have relied on this feature for bot mitigation, executing a shun on the bot C&C IP would stop communications between all infected hosts and the C&C server. But not now.

Jeff

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Christian Zeng
2006-05-04 16:33:33 UTC
Permalink
Post by Jeff Kell
Note the last sentence.
Ahh, I see. Very strange, indeed...


Christian
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Loading...