Most firewall engineers using FortiGate will implement the SSL VPN function using the standard method as indicated in the documentation. Fortinet do provide additional information on securing SSL VPN but there’s even more you can do. I’ll go through a number of essential tasks to cover when implementing SSL VPN and some options to improve on the existing setup methodology.
What is SSL VPN?
A virtual private network (VPN) is a service that allows a user to establish a secure, encrypted connection between the public internet and a corporate or institutional network.
A quick summary of the standard setup
A typical FortiGate SSL VPN setup looks as follows:
- User & Authentication -> User Groups: Add 1 or more groups for authentication
- User & Authentication -> User definition: Add local or remote users, and add them to the above group(s)
- VPN -> SSL-VPN Settings: Configure your listening interfaces and port
- VPN -> SSL-VPN Settings: Configure a public certificate, the assigned client IP range and DNS servers
- VPN -> SSL-VPN Settings: Configure portal mappings
- VPN -> SSL-VPN Portals: Configure portals with split-tunneling, routing and web mode settings
- Network -> Static Routes: Add a route to the SSL-VPN client-assigned range through the SSL-VPN interface (not really required anymore but force of habit)
- Policies & Objects -> Firewall policy: Add a policy from the SSL-VPN interface through to internal networks or the internet with the above user group(s) as a delimiter on the source
Improvements on the standard setup
The standard setup works fairly well however there’s additional options you can add to increase security of the VPN solution. Those options are:
Limiting the sources by allowing addresses
You can limit source connections to specified addresses in the SSL-VPN settings – this can however be difficult as you may not know the addresses and/or locations that your clients are connecting from. You can use any kind of address object including GEO-address objects.
If you do know the sources/locations, and they’re fairly static, then you can use this option.
Limiting the sources by blocking addresses
If however, your sources are variable, then you can use the inverse method of this limit function – ie. you can add values and set them to “negate” in which case, the firewall will allow everything EXCEPT these addresses. This allows you to block incoming addresses, and even GEO address objects.
- Create the block group object along with the specific address objects
- Edit the VPN settings
- Set your source address value to the group object above
- Set the source negate option
config vpn ssl settings
set source-address “<group>”
set source-address-negate enable
The result is that the VPN will limit connections to anything EXCEPT what’s in the defined block group.
This is typically used with GEO-address objects to block connections from specific countries.
Changing the default SSL-VPN port
This is mostly a “security-by-obscurity” option but as it’s “free”, why not do it … Simply choose a new value in the port in SSL-VPN Settings. The disadvantage of this is that you need to configure a FortiClient VPN profile with the specific port which adds 1 extra step to the VPN client configuration.
This won’t get around attackers scanning for the port but it does get rid of the low hanging automated attacks on the default port 443.
Non-local users
It’s always best to use a centralised authentication source eg. via LDAP or RADIUS rather than local users.
RADIUS especially allows you tack on MFA and other options … discussed next.
MFA/2FA
What with brute-force and dictionary attacks via password sprays, it’s critical to make use of MFA. Fortinet themselves support FortiToken soft and hard tokens for local or remote users; in addition, the FortiGate supports 3rd party MFA solutions via a standard RADIUS redirect authentication.
In either case, that means you can use email, mobile or hardware tokens for MFA authentication.
As a final option in this category, PKI client certificates are also supported however this is a fairly complex option that requires specific infra that most users won’t have.
Local-in policies
Standard FortiGate policies affect user traffic passing THROUGH the firewall. However the FortiGate also has the concept of local-in policies which affect traffic TO the firewall. You can therefore make use of local-in policies to limit access to the SSL-VPN service port via address/groups.
Local-in policies are CLI-only so a little more complex to configure than a UI policy.
Public certificates
I mentioned public PKI certificates as part of the standard configuration however I’m mentioning it again here as a specific step seeing as this item is often ignored. A public certificate means that your clients will only accept connections to an SSL-VPN portal with a valid certificate where the client has a corresponding CA/root certificate.
If the certificate is not valid, then the client gets a certificate warning or you can outright prevent the client from connecting.
No-access portal
Your default portal in the portal mappings of SSL-VPN settings should always be a no-access portal with tunnel- and web-modes disabled.
Automated brute-force blocks
The SSL-VPN is set to block repeated failed attempts from the same source however the default time span from which it samples, is quite short. It’s recommended to increase this time.
config vpn ssl settings
set login-attempt-limit 3
set login-block-time 600
end
Adjust your TLS protocol levels
Removing access to older protocol levels means you remove a whole raft of attack methods.
config vpn ssl settings
set ssl-min-proto-ver tls1-2
end
Changing up the standard setup
Limitations in the standard setup mean you are limited in implementing certain types of controls to protect SSL-VPN. Including a loopback interface in your SSL-VPN setup can open up new options.
Loopback interface
- Setup your SSL-VPN using the standard method indicated above
- Create a loopback address (eg. called sslvpn-loop) and assign a unique IP address (from a unique range) to it
- Create a VIP with your wan interface as inbound and your loopback address as outbound, then specify the mapped SSL-VPN port to use
- Add a policy with your WAN (or SDWAN) interface as source and the loopback interface as destination, all for src address and the VIP from above for dst address
- Your normal SSL-VPN interface policies should be below the above policy
The VIP policy above now gives you the ability to use any address objects as a source limiter (deny or accept), along with the full set of security profiles. You can use threat feeds as a source to provide dynamic blocking of sources to the loopback interface.
Using ISDB limiters
Now that you have a more flexible setup, you can make use of ISDB address objects to block access from specific types of address groups. Example, you could block the IP Reputation DB entries which include:
- Crypto
- Botnets
- Malicious and phishing servers
- Proxy servers
- other
You can also use GEO-address objects to block access
IPS + SSL DPI
If you have a valid certificate for the SSL-VPN service, you can then use that certificate in a DPI profile which can be combined with IPS, to inspect SSL-encrypted traffic to the SSL-VPN portal.
Depending on the types of resources being access via SSL-VPN, you can then use application control, IPS and/or malware protection to check for malicious activity and potential lateral movement from an endpoint.
Conclusion
SSL VPN on it’s own, is a mechanism to secure access to corporate networks. However, standard configurations for SSL VPN do not necessarily provide optimal security.
There are still some additional protections to implement – the above set of recommendations is a good starting point for most people and provides significantly better protection for the SSL-VPN service as well as users of that service.
