cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
281
Views
1
Helpful
3
Replies

Policy Set to block specific IP address after a so many failed logins

fcs-lingle
Level 1
Level 1

Our ISE environment only authenticates wired connections and passes VPN authentication from our ASA firewalls on to our Active Directory.  One of our VPN firewalls gets brute forced hit pretty hard.  Luckily it is with attempts with usernames we don't have, so no users get locked out due to our actual AD user names and email addresses are different (the attempts are vastly email usernames).  But recently we did have one user who actually gives out his email address alias that is his actual AD username and these hackers got a hold of it and his account would get locked out on the AD as soon as it was re-enabled due to the brute force attempts.   We had to get creative in adding something to our Policy set for our guest VPN firewall to get it to stop passing authentication traffic to our AD for this particular user and keep it from locking them out.  But we don't want to have to do that each time they get a hold of a real AD username.   The Context Visibility and RADIUS Live Logs show they only do a few usernames attempts at a time over and over, the MAC is always different, but the attempts will come from the same IP for about 2-3 minutes before it changes.  Is there a way to set something up that after so many failed authentications on our AD from the same public IP that ISE will block anymore attempts from that IP for good unless we remove it from a list?  And if it can be done, would it require using Threat-Centric NAC and Adaptive Network Control?   I found something online say it may be possible using those two, but it did not elaborate on details.  Any help and insight is appreciated.

1 Accepted Solution

Accepted Solutions

@fcs-lingle you can "shun" the source IP address directly on the ASA using the threat detection feature, which helps prevent DoS attacks from IPv4 addresses by automatically blocking the host IP address that exceeds the configured thresholds.

These threat detection features are supported in the next Cisco Secure Firewall ASA versions:

  • 9.16 version train-> supported from9.16(4)67and newer versions within this specific train.
  • 9.17 version train-> supported from9.17(1)45 and newer versions within this specific train.
  • 9.18 version train-> supported from9.18(4)40and newer versions within this specific train.
  • 9.19 version train-> supported from9.19(1).37 and newer versions within this specific train.
  • 9.20 version train-> supported from9.20(3)and newer versions within this specific train.
  • 9.22 version train-> supported from9.22(1.1)and any newer versions.

https://www.cisco.com/c/en/us/support/docs/security/secure-firewall-asa/222315-configure-threat-detection-services-for.html

 

View solution in original post

3 Replies 3

@fcs-lingle you can "shun" the source IP address directly on the ASA using the threat detection feature, which helps prevent DoS attacks from IPv4 addresses by automatically blocking the host IP address that exceeds the configured thresholds.

These threat detection features are supported in the next Cisco Secure Firewall ASA versions:

  • 9.16 version train-> supported from9.16(4)67and newer versions within this specific train.
  • 9.17 version train-> supported from9.17(1)45 and newer versions within this specific train.
  • 9.18 version train-> supported from9.18(4)40and newer versions within this specific train.
  • 9.19 version train-> supported from9.19(1).37 and newer versions within this specific train.
  • 9.20 version train-> supported from9.20(3)and newer versions within this specific train.
  • 9.22 version train-> supported from9.22(1.1)and any newer versions.

https://www.cisco.com/c/en/us/support/docs/security/secure-firewall-asa/222315-configure-threat-detection-services-for.html

 

Thanks for this.  I would much rather us implement something on the ASA and take these hits off our ISE environment.  We are running 9.16(4)71 on it already.  I will lookin to this.  Thanks again.

Marvin Rhoads
Hall of Fame
Hall of Fame

I have found the most effective countermeasure is to send the Defaultwebvpn connection profile to a blackhole authentication server (local, certificate or an invalid AAA server). Require legitimate users to use a group-url (like vpn.company.com/logon) that is not published as a dropdown but rather saved via the profile that you push to them upon first login. I have used that method an a half dozen customers (in addition to the threat-detection measures mentioned by @Rob Ingram ) and found that it blocks essentially all attempts from hitting your legitimate AAA server (ISE or AD).

The problem with threat-detection alone is that the attempts come in from many many different source addresses and often a given source does not exceed the threat-detection threshold.

Review Cisco Networking for a $25 gift card