Hardening ASA 5555X RAVPN against Brute-Force attacks

[r.fahey]

We recently noticed a sharp increase of brute-force activity against our Cisco 5555X Firewall, which provides our remote access VPN.

I inherited this firewall, so I want to ensure we are taking advantage of all available options to harden the ASA.

I see Cisco recently released some new options mitigating this activity here:
https://www.bleepingcomputer.com/news/security/new-cisco-asa-and-ftd-features-block-vpn-brute-force-password-attacks/

Unfortunately, the 5555x only supports software versions up to 9.14, and these options require version 9.16 or later
Hopefully Cisco will release something for older versions, but I'm not going to count on it.
We already use MFA, so we're not too concerned about a breach, but at least once already, a legitimate username was tried enough times by an attacker to repeatedly lock the account, effectively breaking access for that user.

In lieu of the above options, I want to make sure we are taking advantage of all available hardening practices.
I found an article outlining best practices for hardening here:
https://www.cisco.com/c/en/us/support/docs/security/secure-client/221880-implement-hardening-measures-for-secure.html

This article specifically lists Cisco Secure Client, and we are still using Cisco Anyconnect, (Not SecureClient), but it seems at least some of the hardening measures still apply.

One tactic is sending unauthorized users to the default group policy - "DefaultWEBVPNGroup" which has Certificates enforced and AAA disabled, but I am not seeing the "DefaultWEBVPNGroup" anywhere in our configuration.

We are running ASA version 9.12.
Does this group not normally appear in the configuration, or is this only in other ASA software versions?
I understand it is not possible to delete that group, so I am unsure why it doesn't appear in my configuration.

If there is a better article about ASA hardening specific to this model and Anyconnect, please let me know!

[MHM Cisco World]

Use this guide to harding the Anyconnect' 

The DefaultWEBVPNGroup and DefaultRAVPNGroup is hidden group' but still you can use these tunne-group to harden the RA VPN.

MHM

[MHM Cisco World]

Guide you share in your post work with your Asa ver. 

MHM

[MHM Cisco World · Accepted solution]

https://www.cisco.com/c/en/us/support/docs/security/secure-firewall-threat-defense/221806-password-spray-attacks-impacting-custome.html

This guide what I was looking for 

Op1 use threat detection which is seem not support for your Asa 

Op2 retrun use to link you share in your post

For default group use 

Show run all tunnel-group

MHM

[Rob Ingram · Accepted solution]

@r.fahey you are correct the newer RAVPN hardening functionality was only introduced on newer supported ASA versions. It's highly unlikely Cisco is going to introduce those features to any version the ASA 5555-X supports.

You would need to run "show run all tunnel-group" to display the default tunnel-groups (DefaultWEBVPNGroup).

Secure Client is just the new name for AnyConnect, so any recommendations for Secure Client should work for AnyConnect.

I would recommend you look to replace your ASA hardware with newer Firepower 1000,2100 or 3100 hardware with a supported newer ASA software version or even better use the NGFW image - FTD. Both software images will support the RAVPN hardening techniques.

[r.fahey]

Thank you!

Yes, upgrading would be the most straightforward solution, however we will no longer need a traditional RAVPN within the next year or so, and will be handling remote access via other mediums. So my aim is to harden the existing ASA as much as possible until it is decommissioned.

[ccieexpert]

they will never back port a new feature to a older release unless it is a big vulnerability sev1/sev2... Most people scanning the internet are using automated tools and are using publicly available DNS records that are published... So the suggestion to use a group url is a good one mydomain.com/vpn . put that in the anyconnect profile so users dont have to remember it. Which means if they go tot the default url it will fail. you may want to try that and see the effect.

[Aref Alsouqi]

I think replacing the username and password authentication with certificates authentication would be a solution here.

[r.fahey]

Appreciate everyone's help here.

Per the recommendations, I enforced certificate authentication on "DefaultWEBVPNGroup" and "DefaultRAVPNGroup", removed the existing group alias, and updated the group URL to enforce only the FQDN.
Our user profiles were already deployed with the FQDN, so this was straightforward and didn't change the user experience. 

I didn't yet perform the last measure - appending an obscure name to the end of the FQDN.
That would require modifying/updating user profiles, which would be more involved, but I'll keep that in my back pocket if it is needed.

Simply configuring the group-url as the FQDN ONLY, and removing the group-url configured for the IP address of the interface seemed to do the trick.
Nearly all of the activity we were seeing was attempts against the IP address, so this change seems adequate.

After these changes were made, we saw a dramatic drop-off of connection activity:



I have accomplished what I wanted, so thanks to those who responded!