Around 50,000 Fortigate VPN accounts from around the globe were leaked to the public Internet last week. Not really news anymore, you can learn details elsewhere. What I asked myself about that was – is there anything to be done to prevent or lower the damage of such vulnerabilities? The remotely exploitable vulnerabilities after all are that – remote, if you have to provide remote services on your Fortigate (VPN/Port Forwarding, etc), and no one can predict what the next vulnerability is going to be – how can we possible prepare? The short answer we can’t, the long answer – depends.
Below are some ideas of mine to lower the risk/damage or even prevent remote exploitations by built-in Fortigate means. Would these measures prevent such leaks? Not sure, but believe for many of these 50,000 it would.
“Security through obscurity” was the label for such measures in the early 2000s, but not anymore, not at all. Let’s have a look at possible path to such public leaks/dumps. It starts with a script kid Joe hearing some vulnerabilities in Fortinet-something firewall/or “whatever they called the device on the Twitter”. He goes to shodan.io, puts “Fortinet” in the search box and voila – 79,171 devices found! Zero effort. Conveniently for Joe, Nessus has already published the plugin https://www.tenable.com/plugins/nessus/128552 for that (he couldn’t even know that all he needed was curl/wget in a loop), again, zero effort for Joe. He runs the automatic scan and gets the list of vulnerable Fortigates with no idea what to do with them. So, naturally he brags about “pwn1ng” lots of Pentagon firewalls on social networks. This list of devices gradually spreads, until someone bored enough to run a wget downloading VPN users caches from those Fortigates finds it amusing to post the dump online. Again – zero effort on the attacker part. The Fortigates haven’t been compromised yet, but now each and every vulnerable Fortigate, which could go unnoticed for years, is being probed/watched by tens, then hundreds, then thousands Joe/Jane on the Internet until someone sees a benefit and connects with the stolen VPN credentials for real and pivots into the LAN.
All this “chain of contagion” could have been prevented should the Fortigate admin had implemented the “masks protection”, of course first of all updates to the FortiOS, but even the measures below would do the trick.
Change the default listening ports of the Fortigate services.
Internet is being scanned all the time by multiple parties. The aforementioned search in Shodan.io, if you noticed, shows most popular services as well, and most of them are default ports for default Fortigate services. The same goes for other scanners – doing the wide scan on all 65K ports is very, very expensive. Only large organizations can afford it, but then, we will categorize them as an APT threat and beyond scope of this article. The majority, though, scan only well-known ports in general, and to a lesser degree well-known ports for a given vendor. By changing the listening ports of such services, you stop the “chain reaction” I depicted above because even being vulnerable, your Fortigate will not be discovered by such scans. Here is how to change some of the services:
Here I change admin HTTPS port to 12771 and SSH port to 5533:
config system globalset admin-sport 12771set admin-telnet disableset admin-ssh-port 5533Here I change VPN SSL listening port from the default 10443 to 13771:
config vpn ssl settingsset port 13771Any sensitive information stored on the perimeter is bad. Authorize/authenticate users remotely.
We cannot reliably predict which remotely exploitable vulnerability will affect what next time, service-wise. We can, nevertheless, say with certainty that the first (and probably the only) device to be affected by such a vulnerability will be the Fortigate itself and everything stored in its configuration. This includes any “secret” information like local users’ passwords, SNMP strings, pre-shared keys, Active Domain query domain user, etc. The only remedy here is to move as much of such secret data away from Fortigate as possible.
Local users (admin/VPN) options:
- Local users but LDAP authentication against Active Directory.
- (Ideal) No local users: everything is stored on Active Directory server.
- Local/remote user but with Two Factor Authentication enabled (free for 2 FortiTokens Mobile, unlimited free for email, and almost free for SMS authentication when purchased in bulk from your SMS Gateway provider, not to say Duo and others are there as well).
- Local user but with the user certificate authentication (free of charge).
Use Geo Location to limit remote access.
In most of the cases your remote workers work from the same country. So, if you are an Israeli company with all your Remote VPN connections coming from Israel – why allow the whole world to connect to the VPN Portal? Use Geo addresses to limit access to the VPN portal or any other service limitation. It can be circumvented by using local country proxy/VPN-for-hire servers, but we are talking about opportunistic attackers, not resolved ones.
Consider allowing access to SSL VPN only from static IPs.
If you, the IT admin, cannot say for sure to what device you are logging in, how can the your less technical users tell? They can’t. Unless you tell them to enter VPN SSL portal only via FQDN name (and please, refrain from vpn.example.com, vpnssl.example.com or remote.example.com) and present their browser/FortiClient with valid SSL certificate bought from a trusted provider for some 20$/year. I use valid SSL certificates even to connect to my labs, and paid some 8$ for it. People even made Fortigate work with Let’s encrypt free certificate, just Google it.
Also, nothing screams “I am Fortigate” to the network scan as the default SSL certificate issued by “Fortinet, CA, USA”.
Dormant remote access accounts are your “sleeper agents”, find and shut them.
An attacker needs no vulnerability if she has access to the VPN with local users and enough time to guess the user and its password. I’ve seen enough of local VPN accounts not used for YEARS, but still being active. Brute forcing takes time, but a dedicated attacker will continue guessing passwords for days/months and in the end she will succeed. With FortiAnalyzer you can have report auto-send to you on VPN users’ behavior and filter those that are not in use. But even plain System Events/User Events logs are good enough to weed out dormant VPN users.
Use password policy at least for admin users.
Unfortunately, Fortigate doesn’t provide currently for password policy for local SSL VPN users yet, but for admins they have existed for a long time. So, no real reason not to use them at least for admins who connect from the Internet to prevent password guessing.
Enable secure communication with Active Directory Domain Controller.
I see it, unfortunately, all the time in 2021 as well – Domain Admin user is configured in Fortigate for querying AD DC and … over the port 389 without “Secure connection” turned on. Fortunately for an attacker that manages to get CLI access to the firewall it means now he has password for Domain Admin ready and served. All he needs to do is to run a sniffer in Fortigate diagnose sniffer packet any ‘port 389’ 6 and see Domain Admin pass being sent in clear text for LDAP binding. Great (not).
Do not use Domain Admin account to query the Active Directory.
The untold truth is that you only need an AD user that can READ, not write, the Directory Tree where the VPN users are located. That is, a REGULAR AD user will do the job just well, no need for Domain Admin at all for VPN authentication.
Alert email on firewall configuration changes.
Production-level firewalls do not change every day, so every configuration change should be noticed and accounted for. In older FortiOS version we have Alert Email in Logs settings to be sent each time the configuration changes. The newer ones also have Automation stitches that can send email each time the configuration changed (and not only).
Port scan your Fortigate and close open ports in Local Policy.
Fortigate has quite a few ports open by default. They can only be seen in GUI after enabling “Local Policy” in Feature visibility, and changed only on CLI. Do not panic once you look there and see lots of open ports – not all of them/may be none of them are exploitable, but anyway as a hygiene rule – close everything on a need-to-work basis. You can read more about this on Fortigate Local in Policy what it does and how to change/configure it . Here is a typical list of open ports:
Follow me on https://www.linkedin.com/in/yurislobodyanyuk/ not to miss what I publish on Linkedin, Github, blog, and more.
