Blocking/shunning attackers with Cisco IPS and ASA

As we all know Cisco IPS 4200 series of sensors can be set up in four ways or modes in our network:

  • Promiscuous mode
  • Inline interface pair mode
  • Inline VLAN pair mode
  • VLAN Group Mode
  •  
    We will deal with all modes later on this blog. For now we will blog a little bit about blocking function of IPS device. This blocking is a way to prevent an attacker accessing network after being identified as an attacker. Blocking is usually done when an IPS is in promiscuous mode, because other ways of preventing an attacker such as denying inline are not possible if IPS is not inline. So how this blocking stuff works?

    Well, we have our IPS setup in such way that one of its interfaces is set up in promisc mode and that interface is enabled and assigned to one of four virtual sensors. Our switch or switches must be set up so that the traffic for designated VLAN is sent over to this IPS port by means of SPAN/RSPAN. Now let’s imagine the scenario in which we have ASA cluster terminating VPN connections. We have quite a few B2B partners and we would like to screen them and see what they are doing and probably block them if they are doing nasty things. NDA is a great thing, but I think it is not enough in some cases. After terminating on ASAs outside interface and decrypting, this IPSec traffic gets forwarded to the enterprise network through some VLAN. This VLANs traffic will be sent to our IPS. Because our IPS is not inline, we can only see a copy of the traffic and try to send a block request to ASA cluster. ASA will now block this attacker for a period of time we set up on our IPS. This period of time is 60 minutes by default. On ASA this blocking is done with “shun” command and is automatically removed by IPS after 60 minutes.

    Before we go with the setup, it’s worth noting that our IPS can use IOS router for blocking/rate limitting and also Cat6500 switches. For now, let’s focus on ASA.

    The most often mistake in setting IPS for blocking is omitting adding ASA’s SSH public key in the “Known Host Key” list. This needs to be done only if we are using SSH for connecting to ASA. This step is not required if using telnet. So we go to Sensor Management->Known Host Keys, click Add and in the “IP Address” field type the ASA’s IP address in. Click “Retreive Host Key”. We should get something like this:

    We should have in mind the fact that ASA should allow SSH from sensor’s IP address and should allow SSH version one. It is not clear to me why we have to use SSHv1, but even in the most recent version of IPS software SSH version two is not supported!

    Now let’s go to Blocking->Properties and ensure that the blocking is enabled and that sensor’s IP address never gets blocked:

    After this is set up, we need to create a login profile. This profile contains username, password and enable password which are required to log in to the ASA device:

    Now is time to add a blocking device. This device or devices will be used to accept blocking request from the sensor and issue the shun command. Go to Blocking Devices->Add:

    We could repeat this step for any additional ASA clusters we have.

    Time to verify: if we done all correctly, we should see a user used for logging to ASAs logged in through SSH session. This user stays logged forever. Until we remove a blocking device at least. Let’s verify:

    ASABN1/pri/act#
    ASABN1/pri/act# show ssh sess

    SID Client IP Version Mode Encryption Hmac State Username
    1 192.168.1.x 1.5 - 3DES - SessionStarted BlockREQ
    ASABN1/pri/act#

    We can see that the IP address of the sensor is 192.168.1.x, the SSH version is one and the username is BlockREQ. This username could be local or on AAA server, depending on how we set up our ASA to accept SSH logins.

    It is time to verify our setup. We are going to tweak one of many signatures so its action will request blocking and then we will try to fire that signature. Personally I like sig ID of 3152/0. This sig is going to fire if somebody who is logged in to a FTP server tries to jump to root’s folder. Go to Policies->vlan4->All Signatures->Filter, select Sig Name, type in root and click Filter. Edit the action to include “Request Block Host” (vlan4 is just the name of virtual sensor. This is most often sig0):

    Let’s try firing this sig. We open command prompt, telnet to “dmz1” machine, log in as “spop” and try to jump to root’s folder. As we can see this connection was blocked:

    At the same time we can verify that signature was actually fired:

    If we go to Configuration->Sensor Monitoring->Host Blocks, we could see that this host block is indeed active:

    This can be verified on ASA as well:

    ASABN1/pri/act#
    ASABN1/pri/act# show shun
    shun (inside) 10.x.0.y 0.0.0.0 0 0 0
    ASABN1/pri/act#

    We can see that the attacker has an IP address of 10.x.0.y, is comming from inside and is shunned. This shun will be removed by IPS after blocking period of 60 minutes passes or after we manually unblock it.

    Advertisements
    This entry was posted in ASA, Cisco, IPS and tagged , , , , . Bookmark the permalink.

    One Response to Blocking/shunning attackers with Cisco IPS and ASA

    1. Pingback: Cisco IPS sensor scenario one – Promiscuous mode | popravak

    Leave a Reply

    Fill in your details below or click an icon to log in:

    WordPress.com Logo

    You are commenting using your WordPress.com account. Log Out / Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out / Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out / Change )

    Google+ photo

    You are commenting using your Google+ account. Log Out / Change )

    Connecting to %s