Hi there, does anyone have a good method to block password spray login attempts from various IPs to their GP portals?
We have 2FA, I setup a brute force IP blacklisting policy, I block by geo location so only US is allowed, I have disabled the HTTPS web portal, I have palos EDLs in a block policy, but I still get a ton of failed logins from some bad actors start password spraying our VPN.
In turn, I have blacklisted millions of IP’s, entire class A subnets to try and keep them at bay, but its a losing battle. I look up the IP WhoIs and more often than not it is something like the attached whois record.
I feel like better minds than mine must have come up with a more bullet proof way. IP allow listing isn’t really an option, I have remote staff all over the place. Thanks anyone who can help.
One of the things I have had success with in addition to the threat signature mentioned and disabling the portal is to apply a url filtering profile to a rule for the SSL access. That blocks attempts not using the FQDN.
We are getting hit with the same thing, same hostname too. We haven’t been able to stop it but the best mitigation is to enable 2fa and have a hip profile enabled if you have the license for global protect. I believe you can block the hostname too if you have the gp license.
Disabling the portal logon only helps to an extent because the web server and authentication is still there for the client to use. It’s just not easily accessible via web browser.
Yeah, I’ve already implemented that, the tactic of the bad actors though is to password spray from different multiple IPs subnets, they space out the attempts from the same IP across minutes to avoid this rule getting triggered.
Great topic and excellent link! Where would you guys recommend applying the vulnerability protection profile? Near the top of the security policy list? I was considering applying to the intrazone-default policy at the bottom, since all of my GP attempts seem to be from untrust to untrust.
Would performance be affected if the incoming traffic has to make its way all the way down the list to the intrazone-default policy instead of being squashed at the top?
Create a custom URL category list with vpnportal.yourdomain.com/, vpngw.yourdomain.com, x.x.x.x/ssl-vpn/hipreportcheck.esp, x.x.x.x/ssl-vpn/hipreport.esp, x.x.x.x/ssl-vpn/agentmessage.esp
Split your global protect security policy rule into two rules. One to handle app-ids palos-global-protect, ssl, and web-browsing. The other for IPsec and icmp if you allow that.
For the ssl rule add the url category object you created. (URL license not required for custom categories). After applying you will only be able to connect to your VPN with the FQDN. HIP and agent message still uses the direct IP from what I’ve seen.
I tried this, but it looks like it’s breaking SSL-VPN (connections from the Globalprotect app using SSL instead of IPSEC).
URL is: /ssl-tunnel-connect.sslvpn?user=&authcookie=
I added /ssl-tunnel-connect.sslvpn to the URL category and that seems to work. I use an Azure VM, I had to put in the “internal” Azure IP (not the external one).
When connecting through SSL, its states the gateway is unresponsive (which is correct, since I’m not allowing that traffic to that URL apparently).
I know this post is a little old now but am hoping someone is still checking it. I tried this solution but it seems to be blocking the hip checks. This is a problem, because I use a hip profile in one my security policies. After 3 hours, the policy with the hip profile in it stops working. Are you adding the URL category directly to the security policy or through a URL filtering profile?
Thanks we do have both, we have our 1st rule to drop geo IP and known malicious IPs, then we have them in the GP config rule to only allow specific regions
I am having this exact issue when implementing the URL filter. Our SSL connections break. We get through portal authentication and our MFA prompt but breaks after that. I’ve been working with Palo support for the last week and he hasn’t been able to figure it out what’s wrong. Seems like this could be what I’m missing. Going to try it out.
Hi, The firewall I was testing on was detecting the URLs as 64/ssl-vpn/hipreport.esp and 64/ssl-vpn/hipreportcheck.esp so that’s why it wasn’t working for me. I tried it on my production firewall and it worked as expected. Perhaps this is a bug with the firmware that I’m running. One other thing that I found is that you have to add a deny rule after these two rules that blocks any traffic that doesn’t match the other two rules. I just cloned the ssl rule and added ipsec, then removed the url category from the rule. This, along with disabling the portal page and 40017 vulnerability protection, has pretty much taken care of all the malicious login attempts that I used to see.
Thank you very much! Your post helped me as the original palo article was very vague and palo support wasn’t sure about adding the URL category directly to the rule.
Hello, I am also having an issue after implementing this with clients disconnecting/reconnecting every hour. How did you come to realize what URL’s the client was using? And is it literally “64” or is that abbreviated?
