Best Way to block IP address from access Palo Alto VPN

[QuickShot]

I setup a small PA 440 firewall with GP VPN for my church. I am seeing a specific IP address constantly attempting to gain access via VPN using different login names, and wanted to reach out for the best methods to block vpn access for the offending IP address.  I searched online, there are tons of documentation on setting up GP VPN but not much available for applying security controls and blocking IP from access. Somewhat new to GP VPN, so looking for advice.  Thanks!

[Adrian_Jensen]

You are most likely going to want to add a Security Policy to allow only known inbound connections to the GP interface and block all others (how you do this will depend greatly on how accessible you want your GP to be... i.e. only connections from a few known home users?, or all users in your country?, or from around the world?). Unfortunately, I don't know of any way to have the PA auto-block sources which repeatedly fail to authenticate (would be nice if you could build selft-updating dynamic address lists).

First, you may want to create an initial Security Policy with a blacklist of addresses that should never connect for any reason. These can be addresses that are constantly scanning you, known region address groups, PaloAlto-provided dynamic lists, and/or external dynamic lists (EDLs):

Name = Blackhole_Source

SrcZone = Untrust

SrcAddr = "Kenny_is_not_allowed - 192.0.2.123",

                 RU,

                 "Palo Alto Networks - Known malicious IP address",

                 "Firehole EDL - bad IP list"

DstZone = Untrust

DstAddr = external_GP_address

Action = Drop

Then, depending on your GP user base, you may want to further allow only from certain address ranges, either IPs you know or IPs in a certain region. Depending on how your have your Security Policies setup**, this could be an allow rule for traffic meeting certain criteria (with further allow rules for other services) and a final Security Policy rule that drops all non-matching traffic (i.e. a permission-based ruleset), or you could block traffic that meets certain patterns outright (i.e. a rejection-based ruleset). The following is a permissive ruleset, but could be rejection-based by using only the first rule and negating the source address/dropping traffic.

Name = Allow US GlobalProtect connections

SrcZone = Untrust

SrcAddr = US

DstZone = Untrust

DstAddr = external_GP_address

Application = panos-global-protect,

                      ipsec-esp-udp

Action = Allow

...

Name = Drop all other traffic

SrcZone = any

SrcAddr = any

DstZone = any

DstAddr = any

Action = Drop

** Pay special attention to your existing Security Policies to know what type/where your current policies filter and how new rules would affect that. If you haven't already you will want to turn on logging for all your security rules (including the default "intrazone-default" and "interzone-default") so you know which connections are currently going through which policies (log on session end is typically enough to determine).

[QuickShot]

Adrian, thanks for the recommendations and detailed advice. What I did was similar to this, somewhat more basic as I am still coming up to speed on the Palo interface tools:

1. While I was waiting for a recommendation, I created a rule and blocked specific countries from accessing the PA440, and moved this policy to the top of the policy list. These were countries where I saw the majority of abuse, i.e. constantly attempting to access the VPN on the firewall with constant repeated attempted login names, suspect likely some type of script.

2. I then went to my system logs, sorted by auth failure and exported this to CSV file, then sorted by repeated offender IP's, and for the U.S. where I have staff depending on GP VPN, I created object addresses called "Block VPN IP's" and created objects for all of the repeat offenders IP's in the U.S. (total of 12), and then created an object group called "Block VPN auth abuse" and added these addresses to the object group. Using the Object group I then added a rule to the firewall to block the bad actors from accessing the PA440. This feels a bit inadequate as I will be playing defense manually by creating more object addresses to try and keep up with the abuse.

Based on your response I will take certainly check out this option as an alternative. I was trying to think of a way to capture the repeated failures and create a rule dynamically to add these address to the pool for the object group, not sure if that is possible? Still reading and learning, so thank you for taking the time to reply!

[TomYoung]

Hi @QuickShot ,

Disabling the portal login page eliminated all of the bogus logon attempts for me.  You can enable it only when needed.

Thanks,

Tom

[QuickShot]

Tom, thanks! I'll need to check with the leadership to see if everyone who needs it has downloaded the GP software, and follow that advice. Simple but effective! Can re-enable when they have new staff. Thank You!

[LCMember40912]

So, umm.... I give. How does one disable the portal login page in the SCM?

[TomYoung]

Hi @LCMember40912 ,

I do not know what SCM means, but you disable the GP portal login page under Network > GlobalProtect > Portals > [edit portal] > General.

Thanks,

Tom

[CosminM]

Hello,

You could try to configure a Brute Force protection mechanism.

More details can be found here: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClJ2CAK 

[LCMember40912]

SCM = Prisma Access's Strata Cloud Manager; PAN's SASE solution. Found that link on creating the brute force lockout mechanism (thanks for posting it though). Tried configuring it in the SCM, but couldn't get it going. Opened a case with the TAC, but after some back and forth, they politely told me it wouldn't work in the SCM. However, they also recommended disabling the login portal. I wrote back to them asking how but no response yet.

[TomYoung]

Thank you!

I have heard more about SCM in the past week.  It can also be used as a cloud version of Panorama without SASE.  I do not have any customers using it yet.

[LCMember40912]

Well, I did open a case with them and PAN's response was 'Oh, you can't do that with Prisma Access'. So there is no way to automatically block brute force attacks on the Prisma Access gateway. Manually banning the IP's after a log search is the only (extremely time-consuming) option. Not a good look for a security company like PAN. Nice going!