The Pix does not support Connection Shunning.
It only supports full Host Shunning.
Realize that both the following commands will shun the entire 200.122.333.213 address.
shun (outside) 200.122.333.213 0.0.0.0 0 0 0
shun (outside) 200.122.333.213 192.168.1.1 5555 25 tcp
The first command lists only the source address, while the second lists all information about a connection. Both, however, will shun the entire source address.
The connection information in the second command does not limit the shun to just that connection. Instead the additional connection information just allows the Pix to remove that particular connection from it's internal connection table.
Why is that needed if the entire source is being shunned anyway?
The first reason is some basic cleanup of the connection table.
The second reason is to ensure that specific connection is torn down. Without removing the connection from the Pix's connection table there is a small possibility that after the sensor removes the shun command the connection will still be in the Pix's connection table. This means that in the case of an attack, the attacker may be able to continue his original tcp connection after the shun is removed because the original connection is still in the Pix's connection table.
This is briefly mentioned in the Examples section of the Pix Shun Command reference:
http://www.cisco.com/en/US/products/sw/secursw/ps2120/products_command_reference_chapter09186a00800ec9eb.html#1026366
Since the Pix itself does not support a Connection shun, the sensor can only send Host shuns to the Pix.
Sometimes these Host shuns will contain connection information and sometimes just the source IP Address.
But in either case it is still a Host shun.
When does it send connection information and when does it not?
When users select Host Shun event actions the Shun is generally sent with Connection Information. This is because the shun request from sensorApp contains the Connection Information.
When users select Connection Shun event actions the sensor generally winds up sending a Shun with connection information (even though it actually winds up a Host Shun on the Pix). This is because sensorApp's shun request contains connection information.
When multiple shun connections are seen with the same source address, the sensor will upgrade these connection shuns to a full Host Shun. In this scenario the Host Shun is an intental upgrade and not a sensorApp shun request. As an internal upgrade from multiple connections it does not have conenction information for it. SO the sensor sends the shun with just the Source IP.
Right now it is actually considered a very low severity bug that the sensor sends a Connection Shun to the Pix that winds up being a Host Shun.
In future versions the sensor won't send the Connection Shuns to the Pix until they have been upgraded to Host Shuns.
It is low severity because most connection shuns wind up upgraded to Host shuns anyway.
So when only shunning on the Pix it is best to just use the Shun Host event actions and not do Connection Shun event actions since they wind up being the same anyway.
Now if you are managing routers or switches instead of the Pix, then you can take advantage of connection shunning event actions.
