In general, for locations that implement SSL-VPN access using FortiGate devices, what are the recommended best practices to minimize the impact of bot or malicious users attempting to login via the SSLVPN portal?
Edit: Thank you all for the great responses. Most of the Fortinet FWs I deploy or support are in smaller businesses, so I’ll assess the various recommendations and apply them as is practical.
Require MFA. This is the most important imho. I wouldn’t even open up SSL-VPN anymore without this.
Block IP’s for a period of time after multiple failed logins
config vpn ssl settings
set login-attempt-limit 3
set login-block-time 600
end
Limit to a single login per user
config vpn ssl web portal
edit "full-access"
set limit-user-logins enable
end
This is my personal opinion but I’m getting more and more leery of the SSL-VPN over IPSec due to the amount of vulnerabilities that have impacted SSL-VPN. If you look back over the past few years a significant amount of the vulns are related to SSL-VPN.
GeoIP restrictions. MFA. It very frequently has bugs compared to IPsec so have a solid patching process that allows for emergency patches to be implemented as soon as they are made available.
Any other specifics (group restrictions, split vs full, etc) is up to your organizational needs / capabilities.
Create a no access portal profile and assign to guest users. Blank out the web page html with no login or download options, if web access is not to be used. Force port 10443, mfa, geo ip.
For the geo-blocking, isn’t it better to do this via local-in policies though?
I’ve seen multiple logins attempts from supposedly blocked countries when only setting it up with restricted hosts in vpn settings. Even though they were failing, I’m not sure in the case of a vulnerability they would have been successfully blocked.
Ive run into some issues with MFA in my environment. We had tried using email-OTP. On mobile, forticlient prompts for the OTP properly, enter it and you’re connected. On the desktop, Forticlient just errors out but the OTP is still received in the users inbox… so the fortigate is holding up its end of the bargain, but forticlient for some reason doesnt know to prompt the user.
I’ve not heard this stated quite so absolutely, but I understand the concept. Can you reference any publications that share this info specifically? I’m curious as to what they offer as alternatives when VPN-like solutions are needed.
I’m really not sure tbh. If it helps then I don’t see why not.
Also on the article I linked there’s a pretty good section at the bottom that goes over exactly what you experienced (geo block enabled but still seeing hits). I’d check those examples to see if you had something similar setup.
Past that, I also really like tying SSL-VPN to a loopback interface as its a very elegant way to get more direct control over hits to the SSL-VPN process itself. Since SSL-VPN isn’t offloaded as it is, there’s little downside to using this approach and then putting a normal IPv4 firewall policy restricting access to the SSL-VPN VIP. This is basically exactly what the local-in policy is doing but its just more visible in the system by default since its not local-in.
Geo block isn’t always reliable. We had a few from a EU country, but when you looked it up there was a mix of it being listed as EU and US, fortigate listed it as US and allowed it.
It’s an embedded version of apache Guacamole that’s had a significant amount of vulnerabilities over the years. It’s also not particularly great (copy paste restrictions etc) and opens up a pretty large attack surface.