Brute Force? Failed authentication - User is not in allowlist

VPN
1

Under Monitoring > System logs, It appears that they have a Brute force attack that has been ongoing on our portal for some time. Logs are not consistent… slow hits… 1 maybe 2 times per minute, but then there are others that are 1 every 2-3 minutes.

This appears to be the GlobalProtect portal page, which is for when you have a new remote laptop. You punch in the FQDN, and then you can download the VPN client.

I’m not sure how they’re doing this, but you see random names attempting to access our firewall portal. We do have OKTA, but. The Palo Engineer mentioned that the firewall is doing its job.

Solutions? I was thinking of doing either or leaving it as is.
Customize the Action and Trigger Conditions for a Brute Force Signature
Auto-Tagging to Automate Security Actions

One of many Logs
( description contains ‘failed authentication for user 'nat'. Reason: User is not in allowlist. auth profile 'Aut-Prf-OKTA', vsys 'vsys1', From: 179.43.148.58.’ )

2

This is part of being on the Internet and having a login page. Use mitigating protections like account lockouts, two factor, and, for optimal security, machine certificates on top of user authentication.

3

Host the GP Client Files anywhere else and disable the Login Page on the Portal. https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClbpCAC

4

This happens to us too.

We had rules in place to drop Brute Force attempts on GP Portals, but that lead to other issues.

We have now just accepted it as a part of normal operations, since you cannot turn off the Portal if you want to use GP that isn’t going through Prisma Access.

5

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClJ2CAK
This article explains how to block the IP after a certain number of attempts in a specific time period. You can then set a duration for the length of time you want to block it. While this doesn’t prevent the attackers from trying, it does cut down on the rapid attacks. I will say, this is all fine and dandy for the portal, but I’ve also seen attacks on the gateway - almost as if they engineered the requests to appear to come from a GP client. Those unfortunately do not fall under this detection, and you have to add a sec policy to block the IP as you see it, or just deal with it.

Happy blocking!

6

Interesting our palo is getting hit by the same source address. According to ARIN it’s from a DC in Panama.

7

Ok got it…We do have two factor and AD LDAP authentication

8

Same… we turned off the public login and will distribute GP files differently.

This seems to have ramped in the last month, maybe globally. I blocked a few IP’s, but they keep changing a few minutes later. Clearly automated.

Seems they scanned the internet for GP Portals and they’re hitting all of them.