Failed GlobalProtect login confusion

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Failed GlobalProtect login confusion

L2 Linker

We're experiencing a very slow "brute force" login to our VPN but I'm having issues understanding how they're trying to log in.

 

We currently use okta. None of their failed attempts are showing up in okta but they are showing up in the GlobalProtect monitoring tab of the firewall. Where could they be trying to log in (and failing) to make these logs show up? I am not able to recreate it by failing to log in.

Untitled.png

 

1 accepted solution

Accepted Solutions

Cyber Elite
Cyber Elite

Thank you for testing.

 

I was getting LOTS of the slow, brute force logins, and disabling the portal web page stopped almost all of them.

 

TomYoung_0-1695070923977.png

 

I was expecting the failed attempt with the browser was causing it.

 

Thanks,

 

Tom

 

Help the community: Like helpful comments and mark solutions.

View solution in original post

12 REPLIES 12

Cyber Elite
Cyber Elite

Hi @DopedWafer ,

 

Try logging into the portal web page with bad credentials.

 

Thanks,

 

Tom

Help the community: Like helpful comments and mark solutions.

When I hit our VPN page we get redirected to the Okta login, failing our logins here does not log it on the palo alto side but only in Okta. Is there a different logon page they could be getting to? It's weird to me because their failed attempts only show up on the firewall and not okta.

Cyber Elite
Cyber Elite

Are you connecting to the portal page with a browser or GlobalProtect client?

Help the community: Like helpful comments and mark solutions.

I am authenticating through the embedded browser in the globalprotect client which takes us to an okta log in.

Cyber Elite
Cyber Elite

Got it.  Thank you.

 

Open a browser on your computer and browse to your GlobalProtect portal FQDN. e.g., https://xxx.yourdoamin.com.

Help the community: Like helpful comments and mark solutions.

This also takes me to okta to authenticate, failing to log in here also does not get logged to the firewall, only the okta logs.

Cyber Elite
Cyber Elite

Thank you for testing.

 

I was getting LOTS of the slow, brute force logins, and disabling the portal web page stopped almost all of them.

 

TomYoung_0-1695070923977.png

 

I was expecting the failed attempt with the browser was causing it.

 

Thanks,

 

Tom

 

Help the community: Like helpful comments and mark solutions.

Thanks, I disabled it and so far so good. Very bizarre to me that I could not recreate the failed login issues.

 

This brings up another question, with the portal page disable I'm not sure how to get the latest globalprotect client, normally users would navigate to the portal and log in to get it. Is there another way of getting it?

Cyber Elite
Cyber Elite

Hi @DopedWafer ,

 

Users that already have the GP client can be upgraded without the page enabled.  For new GP users, you can temporarily enable the portal page, or you could push out the client through MS Intune, Jamf Pro, or similar software.

 

Thanks,

 

Tom

Help the community: Like helpful comments and mark solutions.

L0 Member

Hey @DopedWafer @TomYoung you can also access the Globalprotect client with the direct URL, such as https://portal[.]example[.]com/global-protect/getsoftwarepage[.]esp

Cyber Elite
Cyber Elite

Hi @Steve_E ,

 

You are correct!  I learned also after I posted.

 

Thanks!

 

Tom

Help the community: Like helpful comments and mark solutions.


@DopedWafer wrote:

This also takes me to okta to authenticate, failing to log in here also does not get logged to the firewall, only the okta logs.


When you say you get redirected to Okta to authenticate, I assume you are running SAML authentication through Okta?

 

I see continuing slow brute-force login attempts on our Portal and Gateway interfaces (that require client cert and SAML authentication respectively). What I have found is that the login attempts are scripted and are just pushing POST login/password variables or sending a HTTP authentication header with user/password. So they ignore/don't understand the initial PA server response to provide a cert/SAML token and instead blindly pushes credentials. The error login therefore shows up on the PA and not your SAML provider as the script never redirects there.

  • 1 accepted solution
  • 4297 Views
  • 12 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!