We have an FTD 2110 with software 7.2.5.1 (build 29). We use AnyConnect for our employees to VPN, but we deploy that in our computer image, we don’t allow employees to download and configure it themselves.
We’ve been getting increased Active Directory lockouts on some of our users recently, and failed authentications in our domain controller logs, coming from the firewall. Logs show:
Group <SSL-Split/Full-Tunnel> User <various usernames> IP <various IP's> Authentication: rejected, Session Type: WebVPN
When I go to the https://vpn.ourdomain.org address from outside our network, I’m presented with a Cisco VPN login screen, with username, password, and 2nd password (just like the AnyConnect Windows client). It looks like people are trying to brute force our user accounts through here.
We don’t want this web login at all. Our employees exclusively use the desktop client.
This article describes how to block it: https://www.linkedin.com/pulse/shutting-down-webvpn-portal-ftd-flexconfig-matt-albrecht/
But this page says the feature is deprecated, and the commands no longer exist https://community.cisco.com/t5/network-security/how-to-disable-webvpn-from-fmc/td-p/4605975
And this page https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asaftd-ravpn-auth-8LyfCkeC suggested by this post https://www.reddit.com/r/Cisco/comments/17lqfye/cisco_asa_webvpn_authentication_attempts/ says the issue should be resolved in the 7.2.5.1 we have installed.
Our vendor who provides us support for the network says this page can’t be turned off.
What can we do to block this page, or block logins at this page from hitting our Active Directory?
If you just wish to disable the clientless webvpn you need to deploy a flexconfig object that displays the keepout message.
e.g.
webvpn
keepout “None shall pass!”
Also make sure the default group policy is set to use certificate.
They default policy may not be in use but setting it to cert ensures you do not get password attempts.
Also use certificates for auth if possible, SAML with MFA is your using O365 is even better.
Don’t use the default url like https://vpn.ourdomain.org but use something like https://vpn.ourdomain.org/vpn
Set the default profiles to certificate authentication. Since we did this the brute force attacks stopped.
Ofcourse if they know the url with /vpn for example they can still try to brute force but for us it stopped the attacks.
You can also use the shun command from the FTD CLISH to ban the offending IP addresses brute forcing your users.
In FMC under platform settings, disable HTTP server. Also, I highly recommend you use client certificates along with radius so that the brute force logins don’t even make it to AD without a cert. Also ensure that your defaultwebvpn group is set to client certificate only. They can DDoS your AD if you don’t.
Certificate is one way, tying it into AzureAD(two factor) now entra is another. Full instruction set online
Certificates will help mitigate this. I like having the web portal because users will be able to download the latest version in case for some reason they don’t have it in their machine.
We tried a lot, there is a control plane acl that you can deploy to block the addresses (obviously they can change so may not help too much).
The best thing we did was change to a non standard port instead of 443.
We also use ikev2 so disabled the login via the Web page too.
Did you end up with a solution for this? Also coming across the same issue with FTD 7.4.2.1, the FlexConfig option doesn’t work as it appears to be deprecated and all I’m seeing is:
ERROR: % Invalid input detected at ‘^’ marker.
Config Error – webvpn keepout “None shall pass!”
Other logs
Any other alternative to disabling this page entirely?
This. Just did this with TAC and aliased the connection URL. So far so good.
I fought for months to get this done on my sites VPN. We were getting hammered. My ISE server was going nuts with all the login attempts. CISO kept asking why it was happening. Multiple times to which I eventually started giving him the ‘first time on the net bro’ answers cause he wouldn’t accept the fact that the VPN used the public IP and therefore was reachable.
Put in Cert Auth onto it and nuked the bruteforce instantly cause no cert == no login.
HTTP Server configuration in the platform settings is not related to AnyConnect.
“When you manage the Firepower Threat Defense using the FMC, HTTPS access to the Firepower Threat Defense is only for viewing packet capture files. The Firepower Threat Defense does not have a web interface for configuration in this management mode.”
Our sysadmin checked, says it’s already disabled.
Our SysAdmin that was working on this issue quit, and the other one is too busy to address the problem. Our organization is ending at the end of the year, so we are just unlocking accounts constantly until then.
Ya, control-plane ACL works in FTD. I prefer shun because I don’t need to do a deploy (But it is ephemeral in that is resets on reboot) while shun take effect immediately. The other advantage to shun is that it will clear that IP from the connection table as well, where as ACL will not impact existing sessions. I do all my shunning via script so it’s no worry on the reset…
And if you pull up https with the IP address what do you see?