Defense

If your VPN can be brute forced, I hate to break it to you, but it’s got a bit of a design/implementation problem! Now I’m not going to go into VPN RCE’s (we’ve seen a lot of them in recent times) but let’s look at what we can do to protect our remote access services!

Protections

Password Audits
Strong Password Policies (I said strong not complex and changing every 5 minutes)
Account Lockouts
Block Lists/Dynamic Block Lists
Shuns
Mult-factor authentication
Contextual Access (Network access protection/control/IP Reputation Checking)
Proactive Monitoring

Authentication

Ideally, we would want MFA enabled this could be in the form of:

Certificate based auth (with a password)
A multi-factor agent (such as DUO or RSA or Hardware Token)

However not everyone has the infra in place today so let’s look at what we can do short term

There’s a range of things we can do even on a basic firewall such as the CISCO ASA 5506 we can look at the following:

Now this device is using RADIUS authentication for its VPN users, and we can see that it has an account lockout policy enabled:

(you can also configure a lockout on local users as below)

However, I’ve not personally used this feature so just check you don’t self DoS!

So that’s going to give us some protection against brute force attacks. Again, configure that to suit your environment/risk appetite.

Check out vendor guidance for your specific device:

https://www.cisco.com/c/en/us/td/docs/security/asa/asa91/asdm71/general/asdm_71_general_config/aaa_radius.html

Monitoring

Now here’s where I see a lot of organisations fall down! You need to actually monitor your firewall! I know that’s crazy talk right! But it’s true… so get yourself a logging facility and get your logs shipped out!

Not only will it allow you to gain greater visibility in real time it also will let you look at historic data in case you need to validate an ingress/egress position later!

Intrusion Detection

Now CISCO devices may have if the right model and with the right licensing a FIREPOWER module/license. This is going to give you IDS/IPS capabilities. Now a lot of orgs pay for this but don’t use it… so get reviewing your capabilities and licensing and see if you are paying for something you aren’t using!

However, you might not have that or you or you might not be fortunate enough to have an NG firewall. That doesn’t mean you are left in the dark. You can implement a mirror port and use something like security onion to monitor traffic!

Setting up a TAP isn’t overly complex but too detailed for this blog.

Blocking

Blocking an IP is what we call playing whack-a-mole! You will simple spend all your time hunting new Ips, however that being said with a level of dynamic capability block lists aren’t all bad (depending on use case and scenario etc.)

Here we are showing using an external txt file as a block list on a Palo Alto firewall!

You can change the frequency of update, add authentication and ad exceptions etc. Now this can be really useful for removing some of that noise so you can focus on the signal (and also why let known bad actors touch your VPN to start with right?)

For info the block list I used is here (it’s from our honeypot)

https://raw.githubusercontent.com/PwnDefend/honeylove/main/iplist.txt

You’ll want to use a range of blocklists in my experience (if you want to go down the block list route, If I wanted to harden a sensitive remote access device, I’d definitely consider this).

Bear in mind they have an overhead and are not a silver bullet. For more info please check here for Palo Alto firewalls (or check with your vendor)

https://docs.paloaltonetworks.com/pan-os/9-0/pan-os-admin/policy/use-an-external-dynamic-list-in-policy/external-dynamic-list.html

But I don’t have time!

Honestly if this is the case (and it probably is in a lot of orgs) then it’s time to go and visit your manager/director and explain the risks that NOT having these capabilities creates but also to work out how you managed to get to a position whereby a remote access service was commissioned and put into operation without these things in place, because fundamentally that’s the issue here rather than the specific controls or technology!

Summary

Remote access services should be protected and there should be a good level of monitoring. Sadly, however this is often not the case, so harden what you can in the short term and look to change architecture and operating model to have a position that is robust and resilient. No one should be getting into a panic because an IP or range of IP addresses is “attacking” (unless they are using a 0-day RCE etc.)