What are we missing? In nearly all FortiGate facilities we can leverage dynamic external block lists and other native Fortinet/FortiGuard protections in policies since 6.4 and in DNS resolution since 6.0 I think… But for SSL VPN, and the local in facilities we seem unable to add such options.
Has anyone found a good strategy to help knock down most of the inbound traffic noise while not causing major issues for the end users?
Typical deployment at our clients requires user SSL VPN access from multiple countries and this list changes frequently with their executive and vacation travel. Ideally, we should be able to block the geographies that generate the most brute force login noise. Currently this would be the Netherlands!
We also whitelist our clients’ and our management networks’ public IP addresses in a secured file that all the FortiGates subscribe.
Obviously our FortiGate admin interfaces are not exposed publicly, the biggest issue is for brute force SSL VPN and IPsec connections. IPsec protection with locol in policy typically works if we can hard code all the addresses in the FortiGate, since we cant use the external list.
I list here 18 ways to make SSL VPN secure https://yurisk.info/2023/03/21/fortigate-vpn-ssl-hardening-guide/ , but TLDR version - enable VPN SSL on Loopback and change the default port from 443/10443 and you have all the goods the FGT offers without any bads.
Put the SSL-VPN listen interface on a loopback interface, create a VIP that forwards the traffic to the loopback interface, create a policy that allows the traffic and then you can do whatever you want in that policy and leverage whatever security intelligence you have.
A lot of the issues we have been having lately with our clients with their split DNS, and what should or shouldn’t be public facing, etc is what we are looking to force them to retire SSL VPN for FortiSase or CATO.
and change the default port from 443/10443
Please don’t do this unless you have a very good reason for it.
We already do the VIP for 443 to 10443 translation and to get the SSL inbound traffic off the primary firewall public IP. But didn’t realize the second part of your statement, we just missed that opportunity. Will review it further. We may need to change the vpn native port to 443? OR use local in policy to block all outside 10443?
I don’t quite understand what you mean. Why do you do any kind of translation? What do you want to use a local-in policy for? Just forward 443 straight through and control access to the VIP via firewall policies. Don’t create useless complexity.
Security through obscurity is no security at all and by changing the port from 443 to something else you give up one greatest benefits of SSL-VPN over IPsec: TCP/443 is allowed pretty much everywhere. You are only creating a possible worse experience for your end users by changing the port.
Sorry, I now see what you were mentioning I was a little confused at first until I had a moment to actually think it through. Thank you! We have had to use VIPs to translate from 443 to 10443 where the VIP was a secondary public IP address out of say a /27 on the clients WAN. Most cases we are dealing with with FortiGate’s SD-WAN and two or more uplinks. We have been using loopbacks more and more, and this use case just never dawn on us! Testing right now in our lab and management network. again, thank you!
Please, this mental model has to be changed!
“Security through obscurity is no security at all” has became a mantra some will use without context.
Don’t believe a rando on Reddit, read this article by Daniel Miessler:https://danielmiessler.com/p/security-by-obscurity/
It is a valid method to consider moving those ports.
Real life proves otherwise - 3 years ago in a mass vpn usernames/passwords leak 50,000 VPN usernames and their passwords from Fortigates around the world were leaked last week – what we can learn and do
The only fortigates affected were those listening on port 443/10443.
In the next 0-day in ssl vpn daemon the only protection you may have until FTNT issue and you install the patch is this custom vpn ssl port.
Security through obscurity doesn’t work is righteous buzzwordiness from 90s, so when you read such recommendations, be aware - either it was written years ago or the writer is stuck in 90s, in both cases move on.
The only fortigates affected were those listening on port 443/10443.
Says who? Can you surely say that people on other ports weren’t affected?
But have fun with your users not being able to connect to your VPN in various guest networks I guess. I will continue to use a standard port and simply secure access to it.