I’m seeing tons of login failures in our globalprotect logs, we are being bruteforced by many IPs. We’ve disabled the portal page, which makes me think the threat actors are scripting the globalprotect client itself. We turned on Palo Alto Networks GlobalProtect Authentication Brute Force Attempt in our security profile, but that only gives us the option to block for up to 3600 seconds, I want to block forever.
I reached out to PAN support and their only suggestion was to use an external dynamic list, which is pretty lame.
It depends where you are and what your business case is, but we block Global Protect traffic from outside our country and since then I haven’t seen signs on brute force attempts. Before that, they were constant.
This one is simple to implement and lets you block a source IP for up to an hour to slow things down. The auto-tag suggestion is a better option for long-term.
It looks like disabling the portal login page works and still allows users with the global protect client to connect fine. You would just need to provide users an alternative location to download the client from.
GP gateways seem to have Web GUI inadvertently exposed in both 10.2.8 and 10.2.9 PAN-OS versions. 10.2.7 doesn’t seem to have that problem. Didn’t try 11.x
Just did some frequency analysis on the IPs. While there are some obviously abusive IPs, many of the IPs with login failures only occur one time over the course of weeks. About 950 different IPs.
Been having this issue. I tried the url filter and have even worked live with support a couple times but something keeps breaking VPN for us. We can authenticate and get MFA but connection breaks after that. Might be specific to our config but support hasn’t been able to figure it out. You have any luck implementing the URL filter?
Have a tutorial on how to do this for brute force attack? The articles/examples everybody keeps posting are useless and only apply to the web portal, which most already have disabled. Plus, the Global Protect client makes 10 attempts/actions to auth when connecting once with a legit user. Thus, it locks them out when a legit user successfully logins in. Dumpster fire.
This doesn’t work, only works for the web page login. Not Global Protect client itself. So if somebody is spraying user/pass from a single IP, which is rare, but does happen, it doesn’t happen enough or that IP is feeding users too slowly to trigger the rule. Or, the other problem is, the Global Protect client makes like 10 auth attempts each time a legit user logs in…so actual Global Protect users end up getting failed connections, they login, it triggers the 10/60 trigger and blocks them. Even if you bump it up to 15 attempts from an IP, that is way too fast for what really happens in reality when people are hitting the firewall. They use vpn and auto scripts to random hit from multiple IPs so it won’t trigger. If you have the portal enabled, which most don’t, it works just by a single IP failing 4 logins it blocks them for 2 minutes. There doesn’t seem to be a good answer except maybe the above automation rule that when the Brute Force attack is triggered, you can add that to a dynamic group list and block them for 60 minutes or something. But I have no idea how to even do this since all the articles like the one posted above are kind of useless and don’t explain anything. Thanks
what I meant is global protect *gateway* GUI is, for some reason, exposed. tested both on 10.2.8-hx and 10.2.9-hx. same thing. just https to the public ip associated with your GP GW. funny thing, AFAIK, there is no way to turn it off or on. different look and feel than GP portal landing page.
what poulito is saying is another thing, global protect portal.
No the GP portal. Some companies have a central portal with gateway-only devices spread out. The patch turns on the web page for the portal when no portal is configured.