How to disable DefaultWEBVPNGroup in ASA 5512-X?

[Scryden2]

Hi all,

We are running an ASA 5512-X firewall running firmware version 9.12.4(62) from September 2023. It is end-of-life and will be replaced in the next few months. Until then I have to make do with this firewall.

We are using AnyConnect, or in this case Secure Client version 5.1 for office staff to VPN in remotely. This VPN profile is setup with RADIUS to a DUO proxy for MFA. Authentication takes place based on Active Directory. So we got our MFA all setup and going for VPN.

However, there is this default DefaultWEBVPNGroup in the firewall that uses the LOCAL user database that I really want to get rid of. When I look in the logs of the firewall, I see a whole bunch of hooligans trying to make a WebVPN session on this profile and trying to brute-force their way in: 6 113015 AAA user authentication Rejected : reason = User was not found : local database : user = ***** : user IP = x.x.x.x.

There was another error that specifically showed me the DefaultWEBVPNGroup but I can't find that now. When I look at the AAA statistics in my ASA, I see about 1000 login attempts of which 99% of them were rejected due to invalid credentials. The 1% permitted was myself logging into the firewall. There is only one username in the LOCAL database which is impossible to guess (50 character long username with 50+ character long password) so I don't foresee any problems here. However, since we are using MFA for our VPN login, I don't want these shenanigans happen on my firewall in the first place. VPN authentication should go through the RADIUS MFA proxy exclusively.

How do I stop these bots from hitting the DefaultWEBVPNGroup and trying to authenticate against the firewall's LOCAL user database? I never set this profile up. It was there by default. And if its accessible from the internet then that poses an astronomical risk, especially for those of us that use something simple like admin/admin for a LOCAL login. So I really want to boot this out so nobody can ever hit this using WebVPN anymore.

[Rob Ingram]

@Scryden2 you cannot delete DefaultWEBVPNGroup but you can disable user logins. The DefaultWEBVPNGroup uses the default group policy called DfltGrpPolicy, in that group policy change the vpn-simultaneous-logins to 0.

group-policy DfltGrpPolicy attributes
 vpn-simultaneous-logins 0

If your custom tunnel-group/connection profile uses the default group policy then create a new group policy and reference that.

[Scryden2]

Hi Rob,

Thank you for this. I applied the vpn-simultaneous-logins 0 command on the DfltGrpPolicy but I still see the same messages in my ASA logs:

Group <DefaultWEBVPNGroup> User <*****> IP <x.x.x.x> Authentication: rejected, Session Type: WebVPN.
AAA user authentication Rejected : reason = User was not found : local database : user = ***** : user IP = x.x.x.x

Am I not supposed to see a different error message now that I disabled the logins and set it to 0? After I applied the command I reset the statistics for the LOCAL authentication attempts and within the first minute I already got 2 rejected attempts again. So it seems like the public internet is still able to hit the firewall on WebVPN.

group-policy DfltGrpPolicy attributes
vpn-simultaneous-logins 0

[Rob Ingram]

@Scryden2 sorry I didn't mean to imply those errors would not be generated, rather than no one can login to that tunnel-group.

You could look to disable ssl-client under the DfltGrpPolicy, no SSL connection could even be established to even prompt for authentication (and fail).

group-policy DfltGrpPolicy attributes
 no vpn-tunnel-protocol ssl-client

Important - before you make that change, ensure you explictly allow ssl-client under the group-policy assigned to your tunnel-group(s) and check the logged in users are using the custom group-policy (not DfltGrpPolicy).

[MHM Cisco World]

If this IP you see in log is same then 

Shun it' 

MHM

[zeech978]

To disable the DefaultWEBVPNGroup in Cisco ASA 5512-X, you'll need to navigate to the configuration mode of the ASA via the command-line interface (CLI). Here are the steps to do so:

1. **Access the ASA CLI**: You can access the CLI either via console connection or SSH/Telnet.

2. **Enter Configuration Mode**: Once logged in, enter privileged EXEC mode by typing:

```
enable
```

Then, enter global configuration mode:

```
configure terminal
```

3. **Disable the DefaultWEBVPNGroup**: You'll need to navigate to the specific configuration related to the WebVPN group and disable it. The exact command may vary depending on your current configuration, but it typically involves removing the group configuration. Here's a general example:

```
no tunnel-group DefaultWEBVPNGroup general-attributes
```

This command removes the general attributes associated with the DefaultWEBVPNGroup.

4. **Commit Changes**: After making the necessary changes, remember to save the configuration:

```
write memory
```

or

```
copy running-config startup-config
```

This ensures that your changes are saved and will persist across reboots.

5. **Exit Configuration Mode and Verify **: Once you've disabled the DefaultWEBVPNGroup, exit configuration mode:

```
exit
```

You can verify that the group has been disabled by checking the running configuration or using show commands specific to WebVPN or tunnel groups:

```
show running-config tunnel-group
```

This command will display the current configuration for tunnel groups, allowing you to confirm that the DefaultWEBVPNGroup is no longer active.

Remember to exercise caution when making changes to your ASA configuration, especially in a production environment. It's recommended to have a backup of your configuration before making significant modifications, and to thoroughly test changes in a lab or staging environment whenever possible.

[Rob Ingram]

this looks like a ChatGPT response above. You cannot delete the DefaultWEBVPNGroup, it doesn't error if you do run "no tunnel-group DefaultWEBVPNGroup general-attributes" but it does not remove the configuration.

[Scryden2]

I noticed that after applying the vpn-simultaneous-logins 0 command on the DfltGrpPolicy policy, nobody was able to login to the VPN anymore. It was just result in a "Login failed". When setting it back to 3 (the original), people were able to login again.

Our MFA VPN is using a group policy called GroupPolicy_MFA. So we are not using the DfltGrpPolicy. Upon checking the GroupPolicy_MFA I did notice that "Inherit" was checked beside Simultaneous Logins in ASDM. Does that mean that even though its a custom policy it is inheriting settings from DfltGrpPolicy? So in other words, if I set DfltGrpPolicy to 0 and then uncheck the inherit checkbox in my custom policy and change that to say 3, will that resolve my issue and make VPN connections possible exclusively through my MFA RADIUS setup?

[Aref Alsouqi]

Yes that should work. Also, @Rob Ingram is right, you can't remove the default "DefaultWEBVPNGroup" nor the "DefaultRAGroup" nor "DefaultL2LGroup".

[Rob Ingram]

@Scryden2 no it's probably better to disable ssl-client under the default group policy, as per my second response. Setting the logins to 0 will just ensure no user can login. Take a note of my warning on disabling ssl-client, you should explictly permit it your MFA group-policy, so it does not inherit from the default.

[Scryden2]

Got it. Thanks all very much for the assistance. Really appreciate it.

Just to make sure I get this right, and not lock myself out, are the screenshots below the proper settings you were referencing to?:

Clientless SSL and SSL client disabled and simultaneous logins set to 0 under Default.Clientless disabled (we dont use webvpn) and SSL client enabled and simultaneous logins not inherited and set to 3 under my custom policy

[Rob Ingram]

@Scryden2 correct, before you make the change ensure the users receive the MFA group policy - from the CLI run "show vpn-sessiondb detail anyconnect" and confirm the group policy is the MFA policy and not the default policy.

[Scryden2]

Confirmed!

[Scryden2]

I applied the configuration changes as posted in my screenshots above, but I still see IP addresses hitting the DefaultWEBVPNGroup and trying to authenticate. I also see these failed attempts on the LOCAL user database statistics.

Group <DefaultWEBVPNGroup> User <*****> IP <x.x.x.x> Authentication: rejected, Session Type: WebVPN.
AAA user authentication Rejected : reason = User was not found : local database : user = ***** : user IP = x.x.x.x

The DfltGrpPolicy under the WEBVPNGroup now looks like this:

Am I missing something? Why are they still able to hit the webvpn and do a login attempt against the LOCAL user database?

[Rob Ingram]

@Scryden2 ok, do you use the Clientless Web Portal for users to access applications or download anyconnect?

If not you could shutdown the portal, this will remove the login prompt.

This will remove the login prompt, therefore no one can attempt to authenticate with incorrect credentials.