Just realized we’ve had somewhere in the ballpark of 240k SSL-VPN auth failures in the span of (the last time I looked at it).
GeoIP restrict allowed hosts by country? Seems like this will reduce much of it but not all.
What I’ve done (right or wrong) is look at the usernames they’re using. A lot of them are garbage - “root”, “vpn”, “system”, etc. If I see hits from any user with those usernames, I have an automation stitch to add their IP address to an address object, put it in a group, and reference that group in a policy (SSL-VPN is on a loopback address) to block them. There’s probably a cleaner way to manage it based on volume / # of failures from one IP but so far this seems to be working with my limited ability to write code. I just review logs and update the stitches as needed weekly.
Geofence what you can.
For the rest, we block entire companies by their ASN.
Our users will never connect from a VPN, or a server hosting company.
Edit:
For clarification, when we get a failed login, I go look at the username, if it’s not a legit user, I look up the ASN that owns the IP, and what company that owns it.
Then I create an external connector in the fortigate to the api at hackertarget.com to read the IPs associated with that ASN.
Then add the external connector object to our block rule.
The theory behind this being that most of those attacks are going to come from compromised web hosting and server hosting companies and VPN providers. Which our users will never try to sign in from.
By using their ASN, it blocks all IP addresses associated with that ASN, and any future ones that they may acquire.
Put your VPN on a loopback interface, create a policy to block a list of feeds (internally or externally hosted.) Then, since you should be using VIPs to get the traffic to that loopback interface, make sure to add ‘set match-vip enable’ on the policy and set the policy to Deny
Next policy in the list, set it up the same way but set it to allow and make the incoming address object a geoobject for the country you operate in.
Now - All incoming traffic to your VPN that matches the IPs or subnets in the feeds will be blocked. Any traffic that doesnt match the first policy will roll to the next and if its from your country, it will be allowed to try logging in. Finally anything that doesnt match the first two will fall to implicit deny.
I did this and the hit count on my deny policy was over 300k in three weeks.
Final question you might have is “What feeds do I use?” - Well, thats up to you. I posted about this a while back.
Some people automate blocking failed logins based on common bad usernames. I dont like to fill my firewall with millions of address objects. Feeds are cleaner.
- Put the SSLVPN on a loopback interface.
- Utilize geo blocking to block countries you don’t care about.
- Use threat feeds which publish IP addresses gathered from honeypots.
- Use threat feeds which publish malicious IP addresses.
- Build your own lists to block IP addresses of hosting companies and other non-residential type ASN’s as it’s highly unlikely users are connecting from such things.
- Use automation to build your own threat feeds / IP lists to block access to things that are still trying to brute force.
Disable SSL VPN interface and switch to IPSEC instead, certificates are a great alternative
My plan was to modify the sign in page to remove the login box. We only use SAML based auth via forticlient so supposedly this is a good option from what I’ve read. I haven’t done it yet though.
For remote access, I used to block IP ranges. But you would need to block so many it was a ridiculous chore as we have some global travelers.
So now I only allow specific IPs in. Those IPs are updated by a dynamic DNS client. The clients require a unique access code, and I can control their functionality and remove it.
Each client Dynamic IP gets a FQDN that the firewall can resolve. The published virtual server on the firewall denies all but the group of FQDN objects created for the Dynamic DNS client entries.
This should eliminate brute force attacks to your IP addresses. You then would need a strong user auth policy to use the service behind the IPs.
Now, it’s certainly a pain to get the Dynamic DNS clients deployed, but it’s the safest damn way to limit access while allowing for client mobility. If FortiClient would add dynamic DNS, would make life one less client easier.
I had the same issue.
SSLVPN is trash, gets hacked constantly. Ripped-off the bandaid and switched to IPSEC and disabled SSLVPN entirely.
No issues since.
Users are happier and performance has increased since IPSEC works at the network layer and not the Application layer. IPSEC has no vulnerabilities - its a win to switch.
ASIN blocking is tight if you can’t switch but so far no hotels have blocked IPSEC on any of our traveling sales force. They have been instructed to use mobile hotspot should they encounter a block - that was not a viable option not so long ago but it is now so we’re out of the woods on that one.
No practical reason to risk SSLVPN anymore considering Fortinet just can’t keep ahead of it and literally plans to discontinue it.
geofence to the USA only will probably help
my users are not working from a starbucks or convention center
we have moved our SSL VPN port to a high random port. that has stopped the script kiddies looking for 443. we don’t have time to read these logs either. from their homes they can hit ports like 22444 etc
I did all the above and it really slowed them down, but since I added realms and set the / default to a deny policy I haven’t had any failed attempts. We use EMS so client update happened immediately.
On mobile will post code later.
This article goes over several good ideas for hardening your VPN settings. The first thing you should do is change your listening port from 10443 to anything else not standard. This is the only thing that I changed in my configuration and I haven’t had a single failed login attempt since.
Your mileage may vary but you should know that changing this setting in the Forticlient VPN didn’t work for me on my clients until I uninstalled and reinstalled the client completely.
I’ve added local firewall polices as well as geo locations only allowing countries we expect VPN users to live in. Reduced our failed logins from a max of 500 per min to roughly 10 per min.
require cert + saml? That would effectively ignore every request without a client cert. That’s what I have on our PA and it is really succesful.
Alternatively setup a EDL filter for the AS numbers where most requests come from. Quite common to apply a bulletproof hosting EDL filter before the VPN (we have that too). Still had to block 2 hosting companies.
Something like this: https://iserv.nl/files/edl/feed.php?asn=394711 Although not sure if this format is compatible with Fortigate.
Mandatory MFA + dropping all local-in except for the countries we operate in. You will always have noise.
We use local in policies with geo ip filtering AND firewall policies with ip reputation source
As someone who is starting on Fortigate, Why do you put SSL on Loopback interface?
Can you share you automation rule?
In my experience each fraudulent logon attempt comes from a different IP. Mainly IPs that are registered to ISPs. Looks like home PCs that are in a botnet. Ive never seen more than 2-3 attempts from a single IP. After blocking non US IPs, and allowing on an as needed basis for vacation, the attempts stopped for about a month or two before resuming with US IPs showing the same behavior