SSL-VPN Security Best Practices

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.

Disable webmode

Disable weak cypher’s

GEO block all countries but the ones your company needs to connect from.

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.

Here’s a good guide I got some of the above info from. Fortigate VPN SSL Hardening Guide – Yuri Slobodyanyuk's blog on IT Security and Networking

Requiring MFA goes a long way. We switched to azure ad via saml as the only way to login so we get a lot of nice policies automatically via aad.

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.

AAD conditional access, MFA for all users, GeoIP, good firewall rules with ZTNA tags.

Move VPN SSL listening interface to a Loopback interface.

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.

unique port away from 443 … on top of everything else people have commented on

I’ll get a lot of hate but emerging industry best practice is to not use VPN to begin with.

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.

These are good suggestions. I agree though time to move away from fortigate ssl vpns

Hello, why is the web mode not safe?

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.

How is GeoIP based blocking noted in logs, if at all?

Keep in mind that only NP7 platforms can accelerate traffic terminating on a loopback.

cc /u/gwynethsdad

Move VPN SSL listening interface to a Loopback interface.

Can you share more details on this please?

I do get it. Fortunately, I can replace most of of our SSLVPN connectivity with IPSec.

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.