Use Auto-Tagging to block failed Global Protect login attempts

[Fluck]

hi,

we use SAML for our Global Protect Portal and Gateway Authentication, so all logins are automatically forwarded to our IdP and are being processed there.

But for whatever reason we sometimes face Brute Force attacks on our portal, where all kinds of generic users are being tried to authenticate against the Portal:

for my understanding this login attempts will never be sucessful, as its not even forwarded to our IdP.

I guess it's a curl that is doing these login attempts.

but however, I take failed logins serious and have a Policy that blocks all traffic from these source IPs.

This list already got very long and I want to avoid doing this in a manual way.

I found there is a way of using auto-tags for automated security actions:
Use Auto-Tagging to Automate Security Actions (paloaltonetworks.com)

unfortunately this manual explains it very well for Authentication, Data, Threat, Traffic, Tunnel Inspection, URL, and WildFire logs, where rules work perfectly, but my required Global Protect Logs are only mentioned to be configured at Device - Log settings, where I can not configure a build-in Action, like automatic Tagging.

So I wonder how I can automate my policy with the mentioned Global Protect Logs?

[Claw4609]

Hello,

Assuming you have a vulnerability profile applied on your GP interface, is it triggering the brute force vulnerability? You can make various changes to this ID to fit your needs. Where you can set the action to block IP. 

At the end of the day, while certain actions can be taken, its a public facing site, you're going to have people trying to get into it. Depending on your SAML auth you could always set certain restrictions on that side as well. Presumably its not being forwarded to your IdP because they arent specifying the domain.

[Fluck]

Hi,

yes, a vulerability profile is applied on the GP interface, but it is not triggered, because there are only 2 logins within a 7 minute timerange.

of course i can configure the vulnerability protection for up to 2 logins within a 10 minute timerange, but i though there was a better way to archive this, as it was also mentioned in a reddit post, that auto tag is the better option:

Block GlobalProtect brute force attack? : r/paloaltonetworks (reddit.com)

but they are also only referring to the Auto tagging article of Palo Alto which doesn't really explain how to do it in on the log settings.

[Raido_Rattameister]

Be careful with brute force signature 40017.

It counts how many 32256 events happen during configured amount of time.

Issue is that both successful and failed logins generate 32256.

So if you have multiple users connecting to GlobalProtect from same source IP it is easy to trigger 40017 and block source IP of legit users.

[Fluck]

has noone any idea how to block these Brute Force attacks?

we currently get about 5.000 attempts per day, each of them creates a ticket through our system log that creates an email.

So right now I check the IP in the email and put it manually in a policy of blocked IPs.

Then I have to close each ticket, which almost costs me half of the day.

Of course i can filter out the logon attempts, but that would just mean I don't see it anymore, not that I block these attacks.

I don't get why the Palo Alto documentation is sometimes so extremely bad.

[Steven Tan]

I am also in the same situation as Fluck and would appreciate if someone can offer guidance on this!

[blaiotta]

Hi @Fluck !
I’m exactly in your same situation. Since the vulnerability protection signature is triggered with both successful and failed logins, I was looking forward to making an auto-tagging rule, but the existing documentation didn’t lead me to a solution. Did you manage to solve it?

[KhaleelE]

Have you discovered any solution?

[TomYoung]

Hi @Fluck , @KhaleelE , @blaiotta , and @Steven Tan ,

You cannot auto-tag failed attempts, because tagging is not an option for GlobalProtect Log Settings.  I am not sure how useful that feature would be since I have seen the failed logins continuously come from different IP addresses.  By the time you block one, they have already moved onto another one.

Before I get into blocking the attempts, always enable MFA on your RA VPN since we see in the logs how pervasive the attacks are, and always inspect your inbound GP traffic with a security profile.

Here are some things that I have done to significantly decrease the failed logins from unauthorized users on my NGFWs.  If any one else has other ideas, I would love to hear it.

1. Block all traffic to your GP public IP address except the source country or countries you need.  This stopped a significant amount of failed attempts.
2. Always block the built-in PAN-OS EDLs inbound (and outbound), and any additional ones you prefer.
3. Allow only panos-global-protect and ipsec-esp-udp applications to connect to your GP public IP address with service application-default.  This works fine for me.
4. Disable the GP portal page.  It is not needed for GP to work and GP can even upgrade the client with the portal page disabled.  There are multiple workarounds for new client software deployment that can be discussed later.  This action stopped 90+% of the attempts that appeared to be web-based.  The remaining attempts appear to a GP-based script that connects to the gateway.
5. If you want to stop all brute force attempts, consider using a whitelist of IP addresses.  If you have a small user base or all of your users live in one geographical region, developing an EDL for the ISP CIDR blocks is easier than you would think.  This step would also do a great deal to block Day 0 attacks.  All of the hacking attempts I have seen use hosting provider IP addresses and not residential/business IP addresses.

Thanks,

Tom

[Fluck · Accepted solution]

hey,

I totally agree with all points of TomYoung. He is completely right, but that doesn't work in our case, as we have employees all over the world with always changing public IP addresses, so a whitelisting or country blocking won't work for us.

But of course we already set up the PAN-OS EDLs and we also only allowed the applications on our Policy Rules.

Anyways, I found a solution, that is not the nicest but works for massive brute force attacks.

1. you need to create a new Tag, I called it blocked-ips in my case. I also colored it red

2. create a vulnerability protection profile (or use one you already have), add at Exceptions the ID 40017

I used as Actions Block IP for 600 seconds. (only Source):

3. attach that profile to your Global Protect inbound Rule.
I have one for the Portal and one for the Gateway and attached it to both.

you can not use auto-tagging for failed Global Protect events, but you can create a log forwarding profile, once this vulnerability protection rule is triggered.

4.

(don't worry about the censored filter, we just have an exception for our company Public IPs, that these don't get blocked)

as Action tag the source IP with the Tag you created earlier:

5. now all you need to do is create a dynamic address group, that matches the tag:

6. now create a new Policy Rule and block all traffic, coming from this dynamic group.

Be aware: if you don't attach the dynamic group to a policy rule, it won't get filled even when the event is triggered, it cost me alot of time to find that out.

and please also be aware that the event 40017 is also triggered on successful logins, so choose your Time Attributes in the vulnerability protection profile wisely. We choose 9 failed logons, as each login costs us 2 triggered events (portal + gateway), we can login 4 times without being blocked within 900 seconds. 5 Logins even when successful and the user is blocked until unblocked manually.

you can unblock IPs on the dynamic address Group, if you click on more... at addresses:

and then unregister tag:

and then add the tag:

that doesn't require a commit.

I hope I could help anyone, I'm personally not really happy with this solution, but better than nothing.