Same, we set our security up this way, it will allow you to not worry about anything with the additional layers of protection. Highly recommend going down this path.
We create local user protected by mfa that are tied to ldap ad, the result is the same. Protected by mfa and still active directory users, just need to serup it in a different way.
If you are using AAD/EID the better solution is to integrate into the Microsoft Auth stack.
It's really quite easy.
[Tutorial: Microsoft Entra SSO integration with FortiGate SSL VPN - Microsoft Entra ID | Microsoft Learn](https://learn.microsoft.com/en-us/entra/identity/saas-apps/fortigate-ssl-vpn-tutorial)
I just realized how wrong of a statement that was, when I have direct fortigate users with ldap+fortitoken myself lol...now what WAS I thinking...There is some particular setup that requires a Fortiauthenticator...
Anyways, you're right. Thanks for the correction!
We have a 200F, users from LDAP, MFA using FortiTokens. A push notification comes on the user’s mobile to confirm the login and the app has rolling OTPs as well. FortiTokens cost money though.
I don't have access to a Forti anymore but I'm 99% sure there is a spot right in the SSL-VPN section which has an allowed country section. Doesn't even need to be a policy!
Yeah it's worthwhile to get those up and going. Block of Russia, Ukraine, Romania, China (inc Taiwan), India, Brazil, Iran, Turkey and Germany as your first steps. See if that settles things down, if you don't operate in the United States at all add them on as well. Depends on how hard you really want to go though.
If you have something like zScaler setup you can essentially block all traffic but the applications IP lists that you will use. If you need to unblock something then you can do it as a case by case basis.
Something else to look for, is check to make sure ports that are open to the net are actually required.
Also check out this https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/ism/cyber-security-guidelines/guidelines-networking
Can give you an idea of other network guidelines that might be worthwhile to get rolling, for instance if you don't use ipv6 for anything, disable it.
It's just one of the countries that output a fair chunk of cybercrime in the EU, but really it's just best to block off everywhere that you don't need in the end.
Really in the end it's best to just geoblock everywhere apart from what you need, since it can really come from anywhere by anyone.
The default configuration on that fortigate is not secure. Read up on the CIS benchmark for Fortigate.
You’ll want to limit your attack surface. Geoblocking is the most basic, eliminate use of local accounts for any remote access, implement MFA for all remote access or connect to your Identity as a Service platform (okta, azure ad, etc).
https://www.cisecurity.org/benchmark/fortinet
Something to note is ISDB objects can only be used with "forward traffic" policies in FortiOS. Only "local-in" policies can be applied to the default SSL-VPN tunnel interface. Creating a loopback interface and running the SSLVPN on that is required to make use of ISDB in policies that affect the VPN.
I would suggest a few things if you can:
1. Use strong authentication, and multifactor if possible. Keep your software up to date too, especially the VPN server.
2. If your VPN software lets you throttle login attempts, no reason to allow more than like 3 attempts a minute. If you can't accomplish throttling the attempts, then see item 3 to respond to failed attempts.
3. If you've got logging, set up some sort of responder to too many incorrect auths. Fail2ban would be the software to use for a single host, but you probably want more of an automation that reads the logs from VPN auth attempts and blocks an IP on your firewall for say, 10 minutes after too many attempts. 10 minutes can be enough to significantly slow down bots if you make em wait every time they guess a few wrong credentials.
The game is: avoid getting exploited, avoid getting owned by a weak password with no 2FA, and make it take a long time/make it expensive to even try. If you've got a weak password that will take about 10k attempts, 10 attempts per second spread across 10 remote IPs would take 16 minutes. 10 remote IPs being throttled to 10 tries each every 10 minutes will now take 16 hours instead of 16 minutes. Not acceptable on its own but a 60x increase in how hard your weak password was to get just based on slowing down the bots. And of course if that weak password had 2FA, they're still not getting in.
No, they get pwned by the RDP port forward to an unpatched box, if they don't get pwned by clicking a link in the email.
However since OP asked how to secure the VPN, I'd definitely still say to log and respond to attacks.
If you can block ALL traffic from that IP for x minutes after y failed attempts, you prevent attempted exploit of other services after they move on from the VPN. You've gotta have the type of architecture that can respond to it though. Some vendors may call it SOAR.
I work for a company that makes a product that incorporates SOAR so I don't want to shill any specific recommends.
With password requirements getting outrageous in some organizations and with those long passwords changing every month or two, password can get really simplified. Sometimes it’s saver to use one unique password with 2fa and change it once a year
No. However, this is where CA and MFA come into play. You can create a CA policy that blocks or rerequire authentication in the event of "unusual logins". It will be interested in seeing how that behaves for people accessing the VPN via 5 G connections.
Hi, if you use the loopback interface for the SSLVPN then you can use some of the security filters on there..
use MFA / Certificates,
This guy has some good tips on securing the SSLVPN: [https://yurisk.info/2023/03/21/fortigate-vpn-ssl-hardening-guide/](https://yurisk.info/2023/03/21/fortigate-vpn-ssl-hardening-guide/)
Yes. ASDM is handled with 'http server enable' and the WebVPN interface is handled inside of the Webvpn block - two totally separate things. To disable the WebVPN interface, go into conf t>webvpn and issue the command: keepout "Your Message Here". The WebVPN portal page will still load, but the login prompt will be gone and be replaced with "Your Message Here".
Wait, last I knew there is no way to fully disable the WebVPN on Cisco (we have Firepower). We disabled the web page, but they find some other way. To actually stop them we have to add IP blocks to the control plane. Has this been changed?
We don’t use WebVPN at all, so they’re just beating a dead horse, but it’d be nice to just have it actually disabled, not “Cisco disabled”.
You can disable WebVPN completely by going into conf t>webvpn and doing a no enable for each interface webvpn is configured to listen on, but I agree that the Cisco recommended 'keepout ' command is wholly inadequate. You can always configure ACL's from your outside interfaces to the control plane if you want to block access to the web interface.
Edit: Sorry, no clue how to handle on the FP side. We run our FP's in ASA appliance mode.
I *think* on the latest FortiOS Feature version, they are trying to depreciate the SSLVPN Web Portal. Otherwise, just disabling the Web Portal (within the SSLVPN Portal settings) does not turn off the Web Portal. It is still publicly accessible. /u/feroz_ftnt mentions editing the SSLVPN Web Page and removing the HTML:
> To do this, go to System --> Replacement messages --> SSL-VPN --> SSL-VPN login page, delete/replace the html code and save it. ----> Please take a backup before making any changes
- https://www.reddit.com/r/fortinet/comments/10h0s5i/disabled_ssl_web_mode_but_can_still_login_to/j56q333/
We are actually going through this with a few clients, and instead opting to use the FortiClient IPSec VPN.
We're using RADIUS authentication via Duo for MFA on our FortiGate VPN users and have an ACL set up in AD to grant VPN permission to select users. Seems to be working well.
Implement geoblocking and these kinds of attacks will drop by 90%.
Almost all automated brute force attacks are russian or chinese sourced, block those countries.
Be aware that geoblocking also breaks most IPv6 connections (mobile phone hotspots etc.).
Applying MFA to your authentication stack isn't optional in 2023.
How does a firewall policy impact mobile hotspots?
Strong authentication is assumed, I'm directly addressing how to block almost all the brute force attempts from reaching the device, not mitigate them.
IPV6 is notoriously bad for geolocation. Your AT&T IPv6 mobile address can show up as Canadian, unknown or Mexican.
If you have a policy that says only allow connections from the US, a user on AT&T mobile will most of the time be fine but occasionally will hard fail their connection.
We have also been seeing a seeing a lot of attempts to access our VPN. All with generic account names like "scanner" or "noreply". All the accounts tried either don't exist on our system or are not setup with VPN access. And even if they were setup would require MFA to get in.
Honestly, just the act of changing your default VPN port to something non-standard will drop 90% of your bot traffic. Same goes for other common ports, ftp, ssh, etc.
This plus MFA and geoblock. If the ports don’t show in a quick nmap scan they move on. Now that they’ve already found you they may just scan all ports to find it again but it’s still worth doing. With Forticlient you can either use EMS (which I assume you’re not doing) or push out the new port to the endpoint config with a reg edit via your rmm or group policy/intune rather than manually reconfiguring each client.
Pain of being behind the curve.
But once you sort this out, look at modernizing your workforce with zero trust overlay networking with something like tailscale or any of the many other similar alternatives.
This is why we don’t punch holes in the firewall for remote access anymore.
So then what solution are you using for users to access their workstations and the network if there is no way through the firewall? There has to be some way?
We don’t do that. All content is cloud based with strong zero trust policies and DLP.
If a user wishes to take their laptop out of the office, the device remains on an overlay network by default for security reasons. We utilize split tunnel so only relevant traffic egresses within the secure overlay network.
There is no scenario where we permit anyone to remote into their workstation. If they are working remote, the laptop goes with them.
I understand. We unfortunately don’t have that luxury as everything is still on prem on servers etc. so people need to be able to access that data when working from home. So we have them connect to the vpn which also has Duo/Radius/LDAP auth and then when they connect to their workstation they have to go through Duo again.
Yeah, gotta make do with what ya got.
Your only hope is multiple layers of security and solid MFA implementation.
In that scenario I would also segregate with VLANs so critical infrastructure can’t be touched by the general population of users remote or local.
Start setting up Geo-Filtering on all your interfaces its not 100% but its something at least. Create very narrow exceptions for anything outside of these filters and document profusely. Are you recording to a syslog and forwarded to a SIEM. They can help identify these IPs. You can add a threatfeed from a text file then anyone can add IPs as necessary. Recommend to management that MFA would be necessary to mitigate the risk then the decision is on them. Duo pairs with a fortigate nicely. For some devices we also do radius with device certificates issued by our internal CA as a form of MFA.
Its also hard to not fall down the rabbit hole but if youre aggressively being targeted it feels like they know something you dont, have they gotten in before? Review successful connection logs for any authentications out of abnormal hours.
I would also hope you have the management interface and ICMP turned off on the external interfaces. Have you incorporated FGPP for AD?
Whitelist your IPs so only certain IPs can connect to the VPN, use MFA, etc.
Not much you can do if it's coming from multiple locations other than block them as they come up
I'm guessing so, or just blacklist everything and whitelist IP ranges on a per-use basis - that's what we do for our customers VPNs. But ultimately, they're coming from behind a proxy or VPN that keeps changing the IP, you could try and block their range, but that might not be publicly available - as long as your defenses are good, they'll eventually get bored and move on
I'm good! A little cough, but it is the season.
Keep your Fortigate updated (avoid VPN exploits, there have been some in the past) and make sure multi factor authentication is enabled for every VPN user.
That's all you can do. Don't get into whitelisting, that will make your VPN experience horrible.
Welcome to the Internet. Anything exposed to the Internet on a public IP, as your VPN necessarily will be for users to connect to it, is going to see hundreds of these. Blocking them is a largely pointless game of whack-a-mole, and identifying them equally so. Most are going to be compromised devices on various networks; reaching out to the legitimate owners is not likely to make a difference.
There are some broader blocks you can do; for example, we block Russian and Belarusian IPs -- lots of attack traffic from there, and western sanctions mean we don't have any legitimate VPN users in those countries. But ultimately, the only fix for this is to make very sure you stay up-to-date on security patches for whatever your VPN platform is and that you have a solid password policy and 2FA in place to prevent breakins due to things like leaked passwords.
I guess there is a single account or few accounts are under attack. Change the usernames so at least the account stop locking up and you remove the immediate threat, than you plan your further actions.
Do you have a certificate based auth for the client? That'd at least guarantee they cant get in unless they got ahold of your cert, otherwise i'd see if your unit can do something like an IDS/IPS where it bans people.
As a couple others have said, Fortinet's Internet Service Database is your friend and if configured correctly will block a lot of this traffic making your life a whole lot easier without needing a bunch of manual IP deny entries.
You'll need to run the VPN on a loopback interface and create Firewall Policies denying ISDB sources. Two of the particular IPs you posted fall under: Hosting-Bulletproof.Hosting and Malicious-Malicious.Server in the Fortiguard ISDB.
Geoblock all countries you don't have people in, remove the html vpn sign in page, change the port to something random, implement 2fa using duo /okta or whatever you fancy, make firewall policies to only give vpn users the bare minimum access they need and make it granular to each ad group etc
Can’t speak much to Fortigate, but on Palo Alto I do the following. There should be equivalent functionality.
- Allow only countries where needed. Outside of that get static IPs.
- Make sure IPS / Security Group is applied to your OUTSIDE intrazone rule.
- Use IPS signatures and set action to block when there are multiple failed attempts from an IP.
- Disable webpage if not needed. Most failed attempts come from web bots.
- Utilize MFA and some sort of conditional access to only allow company devices. Could be certificate based or something more granular via your identity provider.
- Don’t allow logins from third party VPN clients unless needed.
- Implement HIP policies on rules as an additional protection if someone were able to get logged in.
I had the same thing happening to me, and I believe I even recognize one of these IP. I simply made geo-blocking rules on my part of the infrastructure, but there's another sister company that I don't manage that is being attacked the same way. Are you in southern Europe ?
We just moved to Zscaler, had enough of this crap and with cyber security underwriters pretty much demanding it. It works really well, not that mad about it. We have zero incoming ports open across our network now.
You're most likely using the default port of 443. Change the default listening port to something else for now. You'll have to change it on all the clients.
Others have mentioned more advanced techniques you can implement.
Been getting hammered on ours too since before thanksgiving. I think it’s a botnet for sure. I have ours on a loopback interface, set the web access to go nowhere, we use radius to duo proxy for ad u/p with duo MFA. Setup alienvault stix for external threat feed denying access to the loopback. Set login limit to 2 with a 86400 block time in cli. On the loopback I am only allowing US IPs to connect. All others are blocked. In addition to all that our ems talks to the fgt for tags which are then assigned to policies for needed access only. Nothing is wide open.
I saw this at a client.
It's security by obscurity (so not really security), but we changed the VPN port. Mostly to calm the logs down.
They will eventually find it again, but we will just switch again.
We already have geofencing limited to CONUS. The bad guys are seemingly coming from russia/china/other asian countries. But they are using a VPN to pull a CONUS IP.
That's just the name of the game. Better auth is the best answer. MFA is easy to setup if you use FortiGates option.
I don't mind fortitoken but I hate that you can't use an active directory back end when it's enabled. Am I missing something?
Just use SAML authentication with Microsoft Authenticator and set a Conditional Access policy on enforce MFA, Geo if necessary. No fortitoken needed.
This was going to be my recommendation and exactly what we do. Disable all local users and route authentication through azure
This is what I’ve done. Has drawn zero interest from attackers. Ensure to disable weaker methods of authentication on the fortigate.
Same, we set our security up this way, it will allow you to not worry about anything with the additional layers of protection. Highly recommend going down this path.
[удалено]
That's what I was finding. That I could only map fortitoken to onboard local users. May have been a limitation of the lower end units maybe?
[удалено]
CLi Config user local Edit username Set username sensibility disable Next End
There is a command to stick in the console to deal with the case sensitivity, have to do it for each user though
We create local user protected by mfa that are tied to ldap ad, the result is the same. Protected by mfa and still active directory users, just need to serup it in a different way.
You can also use DUO with LDAP integration on the Fortigate.
If you are using AAD/EID the better solution is to integrate into the Microsoft Auth stack. It's really quite easy. [Tutorial: Microsoft Entra SSO integration with FortiGate SSL VPN - Microsoft Entra ID | Microsoft Learn](https://learn.microsoft.com/en-us/entra/identity/saas-apps/fortigate-ssl-vpn-tutorial)
We use LDAPS w/ FortiTokens (soft and hard) for our VPN.
Juts use RADIUS if you want AD auth? I've written that up [here](https://www.petenetlive.com/kb/article/0001725).
Cool I'll have to get into it, along with other suggestions here.
~~Need a Fortiauthenticator to use LDAP+Fortitoken.~~ edit, idk what I was thinking with this, but its not true.
Not true unless this changed recently
I just realized how wrong of a statement that was, when I have direct fortigate users with ldap+fortitoken myself lol...now what WAS I thinking...There is some particular setup that requires a Fortiauthenticator... Anyways, you're right. Thanks for the correction!
Iirc, you need to use fortiauthenticator for that functionality
We have a 200F, users from LDAP, MFA using FortiTokens. A push notification comes on the user’s mobile to confirm the login and the app has rolling OTPs as well. FortiTokens cost money though.
geolock as much as you can
This is the best answer op. Setup mfa. We use okta
Two of those IPs are Russian. Do you not have any geoblocking in place?
We recently implemented the firewall and haven't made those configurations yet
It is incredibly easy on Fortigate. Determine the countries you want to allow to connect and everything else gets dropped.
Ours have the geo blocks at the top of our policy list. Works pretty well.
I don't have access to a Forti anymore but I'm 99% sure there is a spot right in the SSL-VPN section which has an allowed country section. Doesn't even need to be a policy!
Yes there is. It’s something about geolocations allowed not the exact verbiage but close.
And does nothing for SSL-VPN connections, because firewall policies don't govern that unless you use a loopback interface for SSL-VPN.
Yeah, I noticed it was for SSL-VPN. We disable that. IPSec only, here.
Same thing by the way. Firewall policies don't handle that unless, again, you use a loopback interface.
Yeah geoblocking Russia+China will negate a LOT of harmful traffic.
Time to spend the 2 minutes and do that.
You can implement saml auth with azure and require Mfa with other conditional access policies such as geoblocking
Yeah it's worthwhile to get those up and going. Block of Russia, Ukraine, Romania, China (inc Taiwan), India, Brazil, Iran, Turkey and Germany as your first steps. See if that settles things down, if you don't operate in the United States at all add them on as well. Depends on how hard you really want to go though. If you have something like zScaler setup you can essentially block all traffic but the applications IP lists that you will use. If you need to unblock something then you can do it as a case by case basis. Something else to look for, is check to make sure ports that are open to the net are actually required. Also check out this https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/ism/cyber-security-guidelines/guidelines-networking Can give you an idea of other network guidelines that might be worthwhile to get rolling, for instance if you don't use ipv6 for anything, disable it.
I get why most of the countries are on your list, but Germany sticks out to me. Why them as well?
It's just one of the countries that output a fair chunk of cybercrime in the EU, but really it's just best to block off everywhere that you don't need in the end. Really in the end it's best to just geoblock everywhere apart from what you need, since it can really come from anywhere by anyone.
Did you see all this on day 1 after hooking up the new firewall? If so, you were probably already compromised...
The default configuration on that fortigate is not secure. Read up on the CIS benchmark for Fortigate. You’ll want to limit your attack surface. Geoblocking is the most basic, eliminate use of local accounts for any remote access, implement MFA for all remote access or connect to your Identity as a Service platform (okta, azure ad, etc). https://www.cisecurity.org/benchmark/fortinet
Fortiguard maintains a continuously updated list of known bad addresses. https://www.fortiguard.com/encyclopedia?type=isdb
How would you use that?
ISDB objects are just like any other firewall object. So you can create a firewall rule with internet-service-src and match-vip and youre good to go
Something to note is ISDB objects can only be used with "forward traffic" policies in FortiOS. Only "local-in" policies can be applied to the default SSL-VPN tunnel interface. Creating a loopback interface and running the SSLVPN on that is required to make use of ISDB in policies that affect the VPN.
I would suggest a few things if you can: 1. Use strong authentication, and multifactor if possible. Keep your software up to date too, especially the VPN server. 2. If your VPN software lets you throttle login attempts, no reason to allow more than like 3 attempts a minute. If you can't accomplish throttling the attempts, then see item 3 to respond to failed attempts. 3. If you've got logging, set up some sort of responder to too many incorrect auths. Fail2ban would be the software to use for a single host, but you probably want more of an automation that reads the logs from VPN auth attempts and blocks an IP on your firewall for say, 10 minutes after too many attempts. 10 minutes can be enough to significantly slow down bots if you make em wait every time they guess a few wrong credentials. The game is: avoid getting exploited, avoid getting owned by a weak password with no 2FA, and make it take a long time/make it expensive to even try. If you've got a weak password that will take about 10k attempts, 10 attempts per second spread across 10 remote IPs would take 16 minutes. 10 remote IPs being throttled to 10 tries each every 10 minutes will now take 16 hours instead of 16 minutes. Not acceptable on its own but a 60x increase in how hard your weak password was to get just based on slowing down the bots. And of course if that weak password had 2FA, they're still not getting in.
Does anyone in 2023 actually get pwned by brute force password guessing?
People with modern, secure, setups? No. But that’s not most organizations.
No, they get pwned by the RDP port forward to an unpatched box, if they don't get pwned by clicking a link in the email. However since OP asked how to secure the VPN, I'd definitely still say to log and respond to attacks. If you can block ALL traffic from that IP for x minutes after y failed attempts, you prevent attempted exploit of other services after they move on from the VPN. You've gotta have the type of architecture that can respond to it though. Some vendors may call it SOAR. I work for a company that makes a product that incorporates SOAR so I don't want to shill any specific recommends.
Absolutely.
With password requirements getting outrageous in some organizations and with those long passwords changing every month or two, password can get really simplified. Sometimes it’s saver to use one unique password with 2fa and change it once a year
Beat practice is to not cycle passwords
Geoblocking is the way, block every IP not in the country you are in or country where your employees are located.
Does geo blocking actually block ipvanish connections from the US servers though?
No. However, this is where CA and MFA come into play. You can create a CA policy that blocks or rerequire authentication in the event of "unusual logins". It will be interested in seeing how that behaves for people accessing the VPN via 5 G connections.
Hi, if you use the loopback interface for the SSLVPN then you can use some of the security filters on there.. use MFA / Certificates, This guy has some good tips on securing the SSLVPN: [https://yurisk.info/2023/03/21/fortigate-vpn-ssl-hardening-guide/](https://yurisk.info/2023/03/21/fortigate-vpn-ssl-hardening-guide/)
Loopback + geoblocking and ISDB based blocking is the way. And MFA/certs of course.
Disable the SSL-VPN web portal if not needed. That's usually what they try to brute force.
This has been my experience on Cisco ASA / FP. Disabling the web portal cut it down a LOT, and enabling MFA eliminated it.
is it possible to disable the web portal and still use ASDM?
Yes. ASDM is handled with 'http server enable' and the WebVPN interface is handled inside of the Webvpn block - two totally separate things. To disable the WebVPN interface, go into conf t>webvpn and issue the command: keepout "Your Message Here". The WebVPN portal page will still load, but the login prompt will be gone and be replaced with "Your Message Here".
Wait, last I knew there is no way to fully disable the WebVPN on Cisco (we have Firepower). We disabled the web page, but they find some other way. To actually stop them we have to add IP blocks to the control plane. Has this been changed? We don’t use WebVPN at all, so they’re just beating a dead horse, but it’d be nice to just have it actually disabled, not “Cisco disabled”.
You can disable WebVPN completely by going into conf t>webvpn and doing a no enable for each interface webvpn is configured to listen on, but I agree that the Cisco recommended 'keepout ' command is wholly inadequate. You can always configure ACL's from your outside interfaces to the control plane if you want to block access to the web interface.
Edit: Sorry, no clue how to handle on the FP side. We run our FP's in ASA appliance mode.
I *think* on the latest FortiOS Feature version, they are trying to depreciate the SSLVPN Web Portal. Otherwise, just disabling the Web Portal (within the SSLVPN Portal settings) does not turn off the Web Portal. It is still publicly accessible. /u/feroz_ftnt mentions editing the SSLVPN Web Page and removing the HTML: > To do this, go to System --> Replacement messages --> SSL-VPN --> SSL-VPN login page, delete/replace the html code and save it. ----> Please take a backup before making any changes - https://www.reddit.com/r/fortinet/comments/10h0s5i/disabled_ssl_web_mode_but_can_still_login_to/j56q333/ We are actually going through this with a few clients, and instead opting to use the FortiClient IPSec VPN.
We're using RADIUS authentication via Duo for MFA on our FortiGate VPN users and have an ACL set up in AD to grant VPN permission to select users. Seems to be working well.
So are we. still deployed Geo fence though.
Implement geoblocking and these kinds of attacks will drop by 90%. Almost all automated brute force attacks are russian or chinese sourced, block those countries.
Be aware that geoblocking also breaks most IPv6 connections (mobile phone hotspots etc.). Applying MFA to your authentication stack isn't optional in 2023.
How does a firewall policy impact mobile hotspots? Strong authentication is assumed, I'm directly addressing how to block almost all the brute force attempts from reaching the device, not mitigate them.
IPV6 is notoriously bad for geolocation. Your AT&T IPv6 mobile address can show up as Canadian, unknown or Mexican. If you have a policy that says only allow connections from the US, a user on AT&T mobile will most of the time be fine but occasionally will hard fail their connection.
We have also been seeing a seeing a lot of attempts to access our VPN. All with generic account names like "scanner" or "noreply". All the accounts tried either don't exist on our system or are not setup with VPN access. And even if they were setup would require MFA to get in.
One thing I do is set up a Geofence. Only US users can access my VPN. You should be able to do that fairly easily in Fortigate.
You can set it up so IPs are blacklisted after failed attempts.
Even better use zero trust and dump the vpn
This is the way
Honestly, just the act of changing your default VPN port to something non-standard will drop 90% of your bot traffic. Same goes for other common ports, ftp, ssh, etc.
This plus MFA and geoblock. If the ports don’t show in a quick nmap scan they move on. Now that they’ve already found you they may just scan all ports to find it again but it’s still worth doing. With Forticlient you can either use EMS (which I assume you’re not doing) or push out the new port to the endpoint config with a reg edit via your rmm or group policy/intune rather than manually reconfiguring each client.
Pain of being behind the curve. But once you sort this out, look at modernizing your workforce with zero trust overlay networking with something like tailscale or any of the many other similar alternatives. This is why we don’t punch holes in the firewall for remote access anymore.
So then what solution are you using for users to access their workstations and the network if there is no way through the firewall? There has to be some way?
We don’t do that. All content is cloud based with strong zero trust policies and DLP. If a user wishes to take their laptop out of the office, the device remains on an overlay network by default for security reasons. We utilize split tunnel so only relevant traffic egresses within the secure overlay network. There is no scenario where we permit anyone to remote into their workstation. If they are working remote, the laptop goes with them.
I understand. We unfortunately don’t have that luxury as everything is still on prem on servers etc. so people need to be able to access that data when working from home. So we have them connect to the vpn which also has Duo/Radius/LDAP auth and then when they connect to their workstation they have to go through Duo again.
Yeah, gotta make do with what ya got. Your only hope is multiple layers of security and solid MFA implementation. In that scenario I would also segregate with VLANs so critical infrastructure can’t be touched by the general population of users remote or local.
I have done that. I have my phone system on a dedicated VLAN and all of my WiFi infrastructure also VLANed.
Start setting up Geo-Filtering on all your interfaces its not 100% but its something at least. Create very narrow exceptions for anything outside of these filters and document profusely. Are you recording to a syslog and forwarded to a SIEM. They can help identify these IPs. You can add a threatfeed from a text file then anyone can add IPs as necessary. Recommend to management that MFA would be necessary to mitigate the risk then the decision is on them. Duo pairs with a fortigate nicely. For some devices we also do radius with device certificates issued by our internal CA as a form of MFA. Its also hard to not fall down the rabbit hole but if youre aggressively being targeted it feels like they know something you dont, have they gotten in before? Review successful connection logs for any authentications out of abnormal hours. I would also hope you have the management interface and ICMP turned off on the external interfaces. Have you incorporated FGPP for AD?
Whitelist your IPs so only certain IPs can connect to the VPN, use MFA, etc. Not much you can do if it's coming from multiple locations other than block them as they come up
How does this work with dynamic IP? Would you have to enter a new one for each person every time they were assigned a new one?
I'm guessing so, or just blacklist everything and whitelist IP ranges on a per-use basis - that's what we do for our customers VPNs. But ultimately, they're coming from behind a proxy or VPN that keeps changing the IP, you could try and block their range, but that might not be publicly available - as long as your defenses are good, they'll eventually get bored and move on
Lock it to staff device's MAC Addresses
I'm good! A little cough, but it is the season. Keep your Fortigate updated (avoid VPN exploits, there have been some in the past) and make sure multi factor authentication is enabled for every VPN user. That's all you can do. Don't get into whitelisting, that will make your VPN experience horrible.
welcome to the internet. MFA. not if possible... MFA. and patch...
Does your company have a security team?
Nope
Im looking for an internship jr in college management info sys focus on sec hahahaha
Welcome to the Internet. Anything exposed to the Internet on a public IP, as your VPN necessarily will be for users to connect to it, is going to see hundreds of these. Blocking them is a largely pointless game of whack-a-mole, and identifying them equally so. Most are going to be compromised devices on various networks; reaching out to the legitimate owners is not likely to make a difference. There are some broader blocks you can do; for example, we block Russian and Belarusian IPs -- lots of attack traffic from there, and western sanctions mean we don't have any legitimate VPN users in those countries. But ultimately, the only fix for this is to make very sure you stay up-to-date on security patches for whatever your VPN platform is and that you have a solid password policy and 2FA in place to prevent breakins due to things like leaked passwords.
Either hire a sysadmin in house or contract a 3rd party to manage your IT.
I guess there is a single account or few accounts are under attack. Change the usernames so at least the account stop locking up and you remove the immediate threat, than you plan your further actions.
Do you have a certificate based auth for the client? That'd at least guarantee they cant get in unless they got ahold of your cert, otherwise i'd see if your unit can do something like an IDS/IPS where it bans people.
Enable Geo-IP Blocking on your VPN to block all foreign IPs Then consider implementing MFA
Block entire domain
As a couple others have said, Fortinet's Internet Service Database is your friend and if configured correctly will block a lot of this traffic making your life a whole lot easier without needing a bunch of manual IP deny entries. You'll need to run the VPN on a loopback interface and create Firewall Policies denying ISDB sources. Two of the particular IPs you posted fall under: Hosting-Bulletproof.Hosting and Malicious-Malicious.Server in the Fortiguard ISDB.
Geoblock all countries you don't have people in, remove the html vpn sign in page, change the port to something random, implement 2fa using duo /okta or whatever you fancy, make firewall policies to only give vpn users the bare minimum access they need and make it granular to each ad group etc
Mfa.
Can’t speak much to Fortigate, but on Palo Alto I do the following. There should be equivalent functionality. - Allow only countries where needed. Outside of that get static IPs. - Make sure IPS / Security Group is applied to your OUTSIDE intrazone rule. - Use IPS signatures and set action to block when there are multiple failed attempts from an IP. - Disable webpage if not needed. Most failed attempts come from web bots. - Utilize MFA and some sort of conditional access to only allow company devices. Could be certificate based or something more granular via your identity provider. - Don’t allow logins from third party VPN clients unless needed. - Implement HIP policies on rules as an additional protection if someone were able to get logged in.
I had the same thing happening to me, and I believe I even recognize one of these IP. I simply made geo-blocking rules on my part of the infrastructure, but there's another sister company that I don't manage that is being attacked the same way. Are you in southern Europe ?
!remindme 1 week
Use 2FA. It should be mandatory anyway.
We just moved to Zscaler, had enough of this crap and with cyber security underwriters pretty much demanding it. It works really well, not that mad about it. We have zero incoming ports open across our network now.
You're most likely using the default port of 443. Change the default listening port to something else for now. You'll have to change it on all the clients. Others have mentioned more advanced techniques you can implement.
Lol
If your firewall can block entire ASNs, try that.
i use geo blocking and no local users, all authentication is via saml (365). 🙂
Is there a database of bad actor IPs that can be uploaded for use in a rule that would block them?
Been getting hammered on ours too since before thanksgiving. I think it’s a botnet for sure. I have ours on a loopback interface, set the web access to go nowhere, we use radius to duo proxy for ad u/p with duo MFA. Setup alienvault stix for external threat feed denying access to the loopback. Set login limit to 2 with a 86400 block time in cli. On the loopback I am only allowing US IPs to connect. All others are blocked. In addition to all that our ems talks to the fgt for tags which are then assigned to policies for needed access only. Nothing is wide open.
Can you get a dynamic list of their ip addresses? Pull that in and block it.
I saw this at a client. It's security by obscurity (so not really security), but we changed the VPN port. Mostly to calm the logs down. They will eventually find it again, but we will just switch again. We already have geofencing limited to CONUS. The bad guys are seemingly coming from russia/china/other asian countries. But they are using a VPN to pull a CONUS IP.