Drowning in VPN bot attacks, I had an idea

VPN
1

First off, I’m not a network/firewall engineer. I’ve inherited a terrible MSP that can’t seem to help.

Here’s my situation. I have a Forticlient VPN. It has a host of sslvpn.acme.com with a public A record pointing to the public IP of my firewall. I have a remote gateway of https://sslvpn.acme.com:443/Okta. We have a server hosting an Okta radius agent that we use for MFA on the VPN. We are getting flooded with brute force password attacks. I’ve created a workflow in Okta that if an invalid user requests login to the VPN from an IP outside of the US or from an anonymizing proxy then the IP is added to the Okta blocklist. It’s a hammer approach but it’s mostly working.

I would like to block this traffic before it gets to the firewall. I have Imperva as a WAF solution. I figured I had nothing to lose by trying to use it to filter traffic. I changed my hosts file to point to sslvpn.acme.com to Imperva and pointed Imperva to my firewall. Initially, I couldn’t establish a VPN connection because Imperva saw the Forticlient agent (FortiSSLVPN) as a bot making an illegal resource request. I whitelisted the agent and attempted to connect. I got my MFA prompt, responded, and it connected…and then disconnected two seconds later.

I ran wireshark to see if I could see anything around the drop. I see a SYN & FIN flags from the VPN to my client. I see my client poll the internal domain controller. Then I see yellow text on a red background with an RST & ACK.

This might be a terrible idea. While I’d like to WAF the public 443 connection, I certainly don’t want to route all my traffic through the WAF. Clearly, I know just enough to be dangerous. My hope is to get enough info to take back to my MSP and have them *do something*. Any help or ideas are appreciated.

2

Firstly, you’ll need to move your SSLVPN to a loopback interface.

How to use a Threat Feed with SSL VPN - Fortinet Community

Use geo-fencing to block countries you don’t need connecting to your VPN.

Then for the rest…

Get a cheap account for www.hackertarget.com (you’ll see why in a bit)

Take an IP address that is trying to brute force you. I’ll use 62.72.23.46 in my example, as that’s one that has tried hitting us.

Use the hacker target ASN lookup tool. Autonomous System Lookup (AS / ASN / IP) | HackerTarget.com

62.72.23.46 in my example, is owned by ASN 47583, company Hostinger, CY

Hostinger, CY is a web hosting company, and has no reason to ever connect to my VPN.

They also own a shit ton of IPs.

Use the hackertarget APIs that you get with your account to create a threat feed in your fortigate, using that ASN number you looked up. You’ll probably want to change the refresh time from 5 minutes to something longer.

Create wan policy to block all traffic from newly created threat feed. (This blocks all IPs that company owns, or will ever own as that threat feed updates it’s self)

Add new ASN threat feeds as needed. I think I’ve had to add about 30 or so.

Edit: Looking at my list now, it has grown to 49 companies in the US and EU that are either selling their servers to hackers, or have been infiltrated by said hackers.

3

A fun thing I did was simply remove the login functions on the SSLVPN portal page. Bad logins dropped off massively.

4

In addition to geo-fencing your VIP (to the loop back device, once you have it) and all the other things that have been mentioned already, you can also use ISDB objects to block connections.

There are some ISDB objects that might be interesting - like “malicious server” or “anonymous VPN” and such. They might help as well. Depending on your research as of what IPs are attacking you, you might also use the ISDB objects (rather than making your own objects), but that depends very much on your findings.

EDIT:
If you change to a loop back device and a VIP for your SSL VPN connection - all your firewall policies for that VIP (to protect it) need the parameter “set match-vip enable” in order to actually help (I am sure most of you know this, but I keep forgetiting it…)

5

Just setup local-in policies that has geo location configured. We have one for esp and ike with srcaddr as US, one for sslvpn from us

6

Move SSL VPN to a loopback interface, then create a vip to NAT the port to the loopback interface, create firewall policies to block traffic between the wan/outside interface and the loopback interface.

If you search this subreddit or the Fortinet community you’ll see plenty of posts about how to do this in more detail too.

7

I got my MFA prompt, responded, and it connected…and then disconnected two seconds later.

SSL-VPN is HTTPS only initially, during authentication and config negotiation, but afterwards (the actual traffic tunnelling) it is not HTTP/S. Depending on how HTTP-centric your WAF is, maybe it doesn’t like or know what to do with the tunnel traffic?

8

Though you get results, this is a really over-complicated approach.

Put the vpn interface on a loopback and self-host or sub to threat feeds.

If you’re running FortiOS 7.4.x, you can also use threat feeds in local-in policies. This will net you better vpn performance depending on your setup.

9

Couple other things I would supplement to ask is what version of FortiOS are you using? Make sure you have disabled the web page to attempt to login to SSL vpn from your browser. You can set up via replacement messages to remove all the content from that and prevent the ability to login directly via the browser.

10

Is your MSP managing your firewalls? Curious that why they can’t solve this for you.

11

Also if you can geoblocking, I have a reverse rule in cloudflare in the security WAF settings as a custom and free rule!

It’s basically deny all except x, y, z countries

12

I just change the port whenever it gets spammy.

13

100%.

i have my entire SSL VPN loop back interface setup here

https://raw.githubusercontent.com/wallacebrf/dns/main/SSL_VPN%20Config%20with%20loopback%20and%20auto-block.txt?_sm_au_=i2sTVqkssR7ZqDPMTHcsHKQ7qMF83

it blocks lots of ASNs for hosting services. here is the list of ASNs i block: https://github.com/wallacebrf/dns/blob/main/ASN_LIST.txt

the block list that the fortigate uses is here: https://github.com/wallacebrf/dns/blob/main/asn_block1.1.txt

i also block by geography, and i have auto-blocks that will block attempts that use ~20 of the most common user name attempts.

take a look and let me know if you have any questions.

14

I believe I’ve found a free alternative to Hackertarget: GitHub - ipverse/asn-ip: Download IP address lists grouped by network provider (ASN)

I’ve just googled a bit while watching a movie. It seems to be working and it’s already aggregating the routes for you.

15

Brilliant idea. How much research do you do on the ASNs that popup? Frankly, I’d like to block anything that does something suspicious but then I’m blocking VZ because some idiot has a compromised lightbulb. If I had a nickel for every probe that’s hit my firewall looking for wordpress login pages, I’d have all the nickels that have ever existed.

16

I need to look into all this. I’m our Fortinet admin and recently got an email from our SOC about a password spraying incident. Looking through logs it’s our SSLVPN web portal. Our config requires user certs for a login, all of which are generated by our enterprise CA, so it all failed anyways, but it was still annoying

17

This is by far the best approach. I also leverage the isdb in the Fortigate to block tor, proxies, malicious stuff and various cdns and cloud providers. If you’re looking for a future ready answer you should be looking at ztna / sase. I’ve found the Cloudflare offering to be pretty remarkable and their free tier for up to 50 users is a great way to kick the tires. Fortinet has some ztna and sase capabilities too but I’ve found it to be incredibly buggy and am actually moving people off of it.

18

I did this but instead of my generating my own threat feeds I pull in multiple publicly available feeds. Failed login attempts have decreased dramatically.

Currently deploying this solution to our fleet of 50+ devices.

19

Just to add some context for this, the main reason that the loopback was originally recommended was that it allowed you to use threat feeds in source addresses so that you could allow/deny specific IP addresses. This is true if you are running 6.X or 7.0.

As of at least 7.4.0 (haven’t checked 7.2), you can use IP address threat feeds in local-in policies:
https://docs.fortinet.com/document/fortigate/7.4.0/administration-guide/891236

And as of 7.4.4 you can use ISDB entries as source address objects in local-in policies:
https://docs.fortinet.com/document/fortigate/7.4.0/new-features/896014/internet-service-as-source-addresses-in-the-local-in-policy-7-4-4

As traffic is determined to be a local-in policy, any inspection profiles you apply on the WAN->loopback policy are not applied by the firewall policy. Because of this the loopback method adds no real value anymore. If you want to have the SSL VPN traffic inspected, you’d have to put the loopback in a separate VDOM and inspect as it crosses from the outside VDOM to the inner VDOM.

You’re better off now just using a local-in policy, at least if you’re on 7.4 or above.

20

Should be careful with loopback interfaces as they might not be hardware accelerated and may cause some issues (I couldn’t make it work on a 60F Wifi, npu inter vdom link worked instantly…)