ASA webvpn brute force attack

[nkmz]

We use cisco anyconnect vpn on ASA 5525-x.
Two days ago we found out in ASA logs something like a brute force attack:

---

6|May 31 2021|08:35:34|725007|193.27.228.247|60734|||SSL session with client outside:193.27.228.247/60734 to a.a.a.a/443 terminated
6|May 31 2021|08:35:34|716039|||||Group <DfltGrpPolicy> User <*****> IP <193.27.228.247> Authentication: rejected, Session Type: WebVPN.
6|May 31 2021|08:35:34|113015|||||AAA user authentication Rejected : reason = User was not found : local database : user = ***** : user IP = 193.27.228.247

---

Are there any ways to protect our device?

[licensing · Accepted solution]

I had the same host attempt on a few off my appliances as well.  

I was able to block this traffic.

Here's what I did:

object-group network BLOCKED-NETWORKS

network-object host 193.27.228.247

access-list anyconnect_deny extended deny ip object-group BLOCKED-NETWORKS any

access-list anyconnect_deny extended permit ip any any

access-group anyconnect_deny in interface outside control-plane

I don't know if this is the best way to block this traffic, but it's how I stopped these brute force attempts. 

Thanks

[jfnk]

I was alerted to this yesterday, and quickly put a similar access-list in place.  

However, when I did a bit more reading up on it, I found that control-plane access lists do not have an implied deny rule so the "permit ip any any" is not needed.  In fact it may (although I'm not 100% on this) inadvertently result in greater management access being granted. 

To be safe I went back in an took that line out.  This still worked (ie it blocks 193.27.228.247 address but allows others to make vpn connections)

[jfnk]

This is what I was reading: CLI Book 2: Cisco ASA Series Firewall CLI Configuration Guide, 9.6 - Access Rules [Cisco ASA 5500-X Series Firewalls] - Cisco

Management Access Rules

You can configure access rules that control management traffic destined to the ASA. Access control rules for to-the-box management traffic (defined by such commands as http , ssh , or telnet ) have higher precedence than a management access rule applied with the control-plane option. Therefore, such permitted management traffic will be allowed to come in even if explicitly denied by the to-the-box ACL.

Unlike regular access rules, there is no implicit deny at the end of a set of management rules for an interface. Instead, any connection that does not match a management access rule is then evaluated by regular access control rules.

[nkmz]

We successfully have blocked brute force traffic:
---
object-group network brute_force
network-object host 193.27.228.247

access-list brute_force_attack extended deny ip object-group brute_force any

access-group brute_force_attack in interface outside control-plane
---

You can see/add/edit this Management Access Rule in ASDM:
Configuration> Device Management> Management Access Rules

In logs:
---
4 Jun 04 2021 11:05:47 106023 193.27.228.247 56816 a.a.a.a 443 Deny tcp src outside:193.27.228.247/56816 dst identity: a.a.a.a/443 by access-group "brute_force_attack"...
---

[iscinteianu]

We detected a similar attempt from the same IP: 193.27.228.247.

We took another approach, by using uRPF to block the packets sourced from that IP.

We added a static route via inside interface to 193.27.228.247 host, so that when the packet reaches outside interface, URPF compares the source ip address to the routing table and will see the route for that ip is via different interface (inside). Due to that fact, ASA drops the packet as considered a spoofed packet.

Ionut

[Da ICS16]

How to prevent AD user locked out when user under VPN brute force? thanks.

[Ken Stieers]

If you're using ASA, you want to be on an up to date version.
Newer versions have facilities that can block IPs based on failed logins.
You'll have to tune them against what your AD is set to do... if AD locks a user after 3 failed attempts, and the ASA blocks the IP after 10 attempts, you'll always have locked out users... so both of those numbers need adjusting based on what you're comfortable with.
https://www.cisco.com/c/en/us/support/docs/security/secure-firewall-asa/222315-configure-threat-detection-services-for.html
The above only works if the attempts are coming from the same IPs... if they're using a bunch of different IPs, and they're spread out over time enough, those rules may not fire.
You may also want to look at other hardening options, like moving your users to a group-url. See the ASA configuration section of this page:
https://www.cisco.com/c/en/us/support/docs/security/secure-client/221880-implement-hardening-measures-for-secure.html

[Da ICS16]

Hello @Ken Stieers We use FTD. Is it possible to prevent AD locked?

If yes, please kindly share your commend and how to do it.

Best Regards.

[Ken Stieers]

Both of the links I posted have sections that apply to FTD as well.

If you're using AD as the final login source, it's going to lock users out if someone attempts more than you're allowing.  Hardening your FTD with a group-url, and switching the DefaultWEBVPNGroup connection profile to NOT use AD is the best way.