I have an issue with a single/multiple threat actors attempting to brute force or clientless vpn portal. They are switching IP's with each attempt and they occur 3-7 time per hour. They use the most ridiculous dictionaries for user names but regardless, they change periodically and I would like to put a stop to it but am finding it quite difficult.
Anyone have any advice for blocking these attempts? I've read so very much on this but cannot seem to find a solution for my particular situation. Any help or suggestions would be greatly appreciated.
Many thanks in advance!
How doe the Palo Alto see the traffic? Anything in the Threat logs? If you see something there, you can put policies in place to prevent this. A Zone Protection applied both internal and external (separate policies) might help. However if there is something in the traffic that can be recognized a custom AntiVirus or Vulnerability protection profile could help. Another way would be to send the logs to a SIEM and somehow block the IP's that are attempting to perform this.
Hope this helps.
Thank you for responding... I was actually updating our firewalls over the weekend and had little time to respond.
I am going through the threat logs now to see if there may be anything of interest. Also, creating a custom AntiVirus and Vulnerability protection profile may be the way to go. Let me dig into this over the day and I'll be back with some info which may be helpful.
Sadly, the rate at which the IP's are changing may prove to be difficult to deal with and this is one of the reasons I decided to create this thread. Again, however, let me dig into this and see what I can discover.
Thank you so much for your advice my friend!
Your advice is much appreciated my friend, I am about to read the KB you linked earlier...
Also, nothing coming up in the threat logs regarding the attempts but I have adopted the tedious task of filtering out the IP's the threat actor is using more than once or twice and adding them to our Explicit IP Drop Policy. I have done this in the past but it seemed hopeless.
This time, however, the attempts at brute forcing our clientless vpn portal have ceased as of 9/16. I'm hoping I covered most of the actors IP pool but I'm continuing to monitor the situation. I just updated our firewalls and may need to make some changes to send out telemetry data but that's a great suggestion which I will follow through with.
Again, thank you for your time and advice sir.
Hi @David_Burton ,
EDIT: You clearly said clientless! You can't disable the portal then.
If you do not need to roll out new GP clients, disabling the portal login page under Network > GlobalProtect > Portals > [edit portal] > General will stop 99% of those attempts.
Like @OtakarKlier , I also limit the countries that can connect to my portal via security policy rule.
@OtakarKlier we have an explicit drop policy and so far we can only block RU. If I had my way about it we would also block the region of China among others. Most of our malicious traffic seemingly originates in Russian for reasons without explanation. Of course, Russia, Iran, and China are our top threats from state sponsored APTs but no traffic from Iran as of yet.
@TomYoung Thanks for the input!!! That could actually be an option... Disabling the outward facing vpn portal... If the number of individuals who use clentless vpn access is minimal then that may be enough for me to work with to gain approval for blocking it. Ideally, having both would be optimal but it it could prevent initial access from a Threat Actor or APT then I am a supporter!!
So far, no futher brute force attempts on the clientless VPN portal but I am monitoring the situation. And will provide updates, there's always someone knocking on our firewall's door. Lol!
Interesting that the powers at be not allowing more blocking, etc. Maybe a SIEM alert for some of the following:
Things of this nature. I'm sure there are more that I didnt list that others are doing as well.
Agreed!!! Each of those points make perfect sense and I only wish we had that ability...
And fun fact: The threat actor(s) have started up again... Same ip hopping per login attempt and still only using 5-7 user names. Recon is one thing, but at this point, the threat actor likely knows what hardware we are using and seems to be making no further attempts to improve his odds at actually running a successful brute forcing campaign. It doesn't make one bit of sense at this point...
The biggest issue I've discovered when it comes to this/these types of threat actors which are using simplistic "brute forcing" methods. Almost on a "script kiddie" level taking me back to the days. of "NetBrute" if you will, but I digress
The thing is, PAN-OS allows for you to block authentication attempts via user name but ONLY when using LDAP. You cannot simply add a user name to an explicit ip drop (or other policy) that does not exist within your AD environment. Of course, you COULD create that user within your OU but noone wishes to create users accounts in AD such as sslvpn, admin, root, or testuser simply for the purposes of having the ability to block access attempts from individuals using these usernames.
Not to mention the additional security issues that are accompanied by doing such. But let us just say that if I could drop ip's explicitly and block them based on the user name that was used in the portal then problem solved!!! Why has Palo Alto refrained from incorporating such a feature?? 🤔
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!