Is anyone else having their RADIUS servers inundated with VPN authentication attempts? Recently a Palo Alto vulnerability was recognized and actors are attempting to exploit it. They don’t seem to know what environments have what equipment so they’re spraying everywhere.
I’ve already modified our NPS logs, it was growing exponentially trying to keep up. Next step is to setup NPS IP filters and block the IPs from being allowed to even attempt to authenticate to our RADIUS servers. Thoughts?
Attacking VPN servers is becoming increasingly common
Cisco, Palo, Fortinet, and Sonicwall (just for examples) have all had VPN related vulnerabilities discovered and patched fairly recently (last 6 months)
Credential theft and phishing is also extremely common place
Review the logs and see if specific usernames are being used, or if it’s random. If the same usernames come up over and over again, there’s a good chance that user has been compromised at some point and you should investigate further.
You should be enforcing MFA on your VPN logins if you aren’t
Since you likely integrate AD into your VPN using RADIUS disable any non-user accounts from logging into VPN (like the built-in administrator or service accounts, anything with a common or easy to figure out username)
Ensure that IT people in the company have separate unique administrator accounts, don’t use the same login that you use for your email + VPN for IT Administrative use.
Pay attention and IP block any IPs brute forcing you
Enable GEO-IP fencing to block VPN logins outside of countries that your operate
Have good password policies, etc
And patch patch patch everything
To be honest I don’t review my vpn logs as often as I should. Ever since I turned off the SSL vpn it hasn’t really been an issue.
I find I spend more time reviewing the RDP Gateway logs.
Like everyone else said any external connection “MUST” be mfa. It’s simply not safe enough on the edge without a 2nd factor. If you publicly announce a vpn portal with a records ya you will get hit. Once they find an access denied message they then brute it badly while attempting to get different results.
You can block ip’s as soon as you do they cet connection error and try from different ip or proxy.
I would also suggest geo blocks.
If you don’t do business from certain parts of the world geo block the countries or subnets of the isp’s.
Unfortunately they getting smarter now and some purchase Amazon hosts and attack from cloud platforms because most of us allow cloud platforms also.
Personally I’d consider using something like Netskope Private Access to remove the need for VPN entirely. If you still wanted VPN as a failsafe for a limited number of users, ensure they’re using fixed IP’s and then lock that down to those source IP’s. Netskope is way more convenient than VPN also.
Yep. They hit our fortigate all the time. Been going on since mid last year.
Geofencing and then ASN lookups on offending IPs, and blocking whole ASNs keeps it in check.
You should be enforcing MFA on your VPN logins if you aren’t
Fortunately we are. It’s still blowing up the RADIUS authentication logs.
Review the logs and see if specific usernames are being used, or if it’s random.
They’re random usernames.
Pay attention and IP block any IPs brute forcing you
This is what I’m considering implementing in NPS IP filters.
Apply a conditional access policy to only allow trusted devices to connect to your VPN client. This should reduce the fuck off logs.
Pay attention and IP block any IPs brute forcing you
I’ve found blocking individual IPs to be extremely labor intensive. Most of the offending IPs come from server hosting providers that are being used to get around geo-fencing.
Thos companies own hundreds of thousands of IPs and the IP it will come from changes.
So I just started blocking entire ASNs and all the IPs they own.
The logic being that, we’ll never have a authentic VPN connection coming from a hosting provider company, or a VPN service.
CA from azure doesn’t work with radius.
You should implement vpn login via azure enterprise app, than ca and bf protection will work.
I blocked a huge set of Networks and Ranges that were hitting us. It’s slowed down.
Thank you for the tip, Bane8080
Now I learned I how to apply GEO-IP blocking on this one rule (I do understand location can be faked).
Did I do this right or do you recommend otherwise? Screenshot.
I figured out some things, so I’m deleting prior comment.