AnyConnect - Brute Force Attempts

[JRHTC]

Firepower 2110 managed by FMC - Device is only used as a VPN device and has AnyConnectPlus licensing only.

Since the announcement of the CVE related to AnyConnect I have been monitoring logs, and using FlexConfig to block traffic from IP blocks when I saw attempts come in. This morning logs show a new methodology where they are using a VPN tool, or botnet to make 3-4 login attempts then switch source IPs and try again, this makes IP blocking impossible to implement. All of these attempts are showing as coming from WebVPN.

I have added a FlexConfig to Disable WebVPN (webvpn portal-access-rule 1 deny any) and I get a "forbidden" message if I try to access the WebVPN UI via web browser

However, I still see the below rejected authentication messages showing up in logs.
Group <DfltGrpPolicy> User <*****> IP <107.144.237.108> Authentication: rejected, Session Type: WebVPN.

Am I missing something to completely close down WebVPN as an attack vector since I am still seeing these attempts in logs? Or is the rule working properly and rejecting all logins attempted through WebVPN, but not preventing the attempts entirely based on a limitation of how the rule functions?

[JRHTC]

Update: It looks like the attempts have stopped, or are now being fully blocked. and are no longer showing up in the logs. Stopped about 10 minutes after I pushed the config update.

[tvotna]

DfltGrpPolicy is attached to tunnel-groups DefaultWEBVPNGroup and DefaultRAGroup by default. The DefaultWEBVPNGroup can accept AnyConnections too, not just clientless requests from a browser. And actually, even if you configure "vpn-simultaneous-logins 0" or "vpn-tunnel-protocol ikev1" in the DfltGrpPolicy this doesn't stop password guessing attacks due to the nature of the vulnerability. This only blocks connection attempts *after* login/password prompt, if correct username and password were submitted by the attacker. To stop the password guessing attack (or at least make it more difficult) you need to use cert+aaa authentication, so that attacker needs to provide valid certificate first before password prompt appears. Also, it's recommended not to use default tunnel-groups (if possible, which depends on many factors) and block AAA in them completely with "authentication certificate" in webvpn-attributes.

HTH

[sysad43]

I see the same thing on my ASA. We are not using the default connection profiles, so if I change the auth on them to certificate only, that would prevent the password guessing? Other than default our only tunnel group uses SAML to enforce MFA.