We have been the victim of an attack on our SSL VPN since this morning. There are many of failed login attempts with real user names/e-mail addresses. They can be found on our website. So I’m not worried about a data leak. An attack is probably being attempted out of a botnet (many different ips, same user names) with word lists.
But my main problem is: The users are deactivated in the windows active directory (temporarly/30min)
and they can no longer log in themselves. Not even in our local network services. Can I prevent this somehow?
I now activated country-blocking and increased the login-block-time from 60 to 600 seconds. That should at least help a little. But for me, it is not a permanent condition that users can be blocked as a result of this.
SSL-VPN has configurable max attempt limit and configurable block time.
You probably want the attempt limit to be lower than the lockout limit in AD to prevent the AD-side lockouts.
config vpn ssl settings
set login-attempt-limit <0-10; default 2>
set login-block-time <0-86400 seconds; default 60>
end
Note: These lockous cannot be manually cleared. So configure them carefully.
You can also try an automated IP ban/quarantine for failed logons. There’s a couple CLI snippets/cookbooks floating around the community (typically using some automation stitches). Just keep in mind that genuine users can get trapped in this as well if they fat-finger their username/pwd too many times.
Lastly, if you want a nuclear forever solution, switch to certificate-based authentication.
I see nobody has asked about EMS availability yet. You can then combine the idea of using a loop back, with using the registered_devices group. This way it has to be a device registered in EMS for the sslvpn login page to be presented. Better than GeoIP even.
We have an internet facing Citrix solution, and the Citrix admins changed the login page to be Username and MFA code, and on the second page, the password. I don’t know if you can do something like that, but it certainly made a lot of these types of issues go away.
Have you thought about changing the port the ssl vpn listens on? Sure you need to make a change in the client, but it was simple, and now I get no brute force attempts, where it was non stop in the past. (Hi AJ)
Deploy vpn with certificates? I’ve been trying to think up a solution to the ssl spam. Haven’t had anyone get locked out yet, but I’m sure it’s coming. I know forticlient supports requiring a cert, but certificate services aren’t in my wheelhouse yet. Time to start learning.
Maybe SAML-SSO with 365 would mitigate? The modern auth login process on the firewall seems harder to hit with automation and you’d have MFA and CA to help protect.
Another thought is changing the port. I know, I know security by obscurity doesn’t work, but I’m seeing Fortigates and Sonicwalls getting hammered over the last month, however the ones on non-standard ports are thus far unaffected.
In my case we opted to use our blacklisted countries as a denied source for solving connections and we reduced 70% of our attacks against real accounts.
Change the port you’re using from the default port to an open uncommon port. We had a similar chain of incidents occur and that resolved the issue. Probably should also consider using certificates so they are blocked before trying to authenticate.
I use the local-policy-in to block countries and complete subnets in the same ASN. I also block all the TOR exit nodes and VPN (Nord, Surf, IPVanish, etc…). I started reporting them to the ASN owner, it would stop for a bit but then would start again.
i used to get 3-4 attempts per day, now i have not had an invalid attempt in several weeks.
i have added my VPN to a loop back as you said, and use the ISDB objects, but i also use external threat feeds which i use to block a whole lot of ASNs for large server hosting companies
and i made a script that downloads all of the different ASN lists and aggregates them into one .txt file for me which as of about 1 month ago has these entries in it
i also have a manual block list for IPs that are on major ISPs that i do not want to block the entire ASN for, or are on services that i could not determine the ASN
login-attempt-limit 2 (AD 5) login-block-time 600 (AD 30min)
But there were so many failed logins from many different IPs on the same logon-users, that they got blocked anyway.
I will take a look an fail2ban method. But yes. There are some users with fat-fingers. And without a “quick-unlock” i will have more work to do with it than I do now.
That would be my premium solution. But I would have to get new licenses first. And at the moment we still have Sophos as a client-av solution. If we were to rely on Fortinet there too, I would prefer the EMS solution. That would be a round thing.
Does this actually work? Can forticlient understand being presented with the ztna client cert check presented by adding the ztna tag req on the FGT policy?
