As the title suggests, I’m looking for a better way to secure 443 traffic to my GlobalProtect portal.
In Security Policy, there is a rule allowing any IP address from the Untrust (Internet Zone) to the Untrust address of my GP portal.
This makes sense, since you don’t know what IP address remote users will come from, or their home IP could change.
The problem is, that rule allowing 443 traffic to my public IP address is allowing lots of traffic. Granted, I keep the Portal Login Page disabled, so the page itself doesn’t even load - but still - I don’t like having something like that completely open to any IP address.
From what I can see in my logs it looks like my remote users do still use this rule to communicate daily - so I think it’s a requirement for legitimate production GP traffic to flow.
I just don’t want random IP addresses from across the country doing broad scans and hitting this rule.
Is there anything else I can do to lock this down? How is your policy for this GP traffic (443 specifically) secured?
I was considering implementing machine certificates for another layer of security but I don’t believe that will help this particular rule.
Right now I’ve tried to limit the source address to known employee public IP’s, but it’s becoming a management nightmare with people moving locations, IP address changes, etc.
443 is critical to the running of GP so it needs to be available. Best practise is to make sure you’re blocking the known bad IP’s from the included EDL’s and otherwise publish the portal and gateway.
You could setup up some Geoblocking on the rule to only allow certain countries if thats an option for your users workflow but as long as you keep on top of patching I think it’s fairly safe to assume it’s secure.
Fortigate’s have had a number of vulnerabilities in their SSLVPN with the expected results but even then if you’re patching regularly and keeping on top of release notes when releases come out your exposure was pretty damn small
Adding the extra step with verifying the connecting host has an internal certificate will give you some additional protection incase user credentials got on the loose and is definitely a good thing to do.
If you want to add protection against scans there are some options mentioned already with geo block, known bad IP block and you also have zone protection which can be configured on the incoming interface.
Another one that I would recommend is to use is to use a dynamic block policy using a dynamic address group to list tagged IPs. Then you configure your threat detection logging to also set a tag on any IP address that triggers a threat of ex medium-critical. Then this IP will be blocked for further connections.
We have had good experience with such policy so I can really recommend it. Let me know if you want additional information about how to do it!
So other than the suggestions here about geo blocking one of the things you could do is allow the range for the provider of the current IPs.
Take one of the users public IPs and search it on IP info to get the range, then allow that specific range for the provider, yes other addresses in that range can connect but it’s a start and if the users public IP changes it will likely be to another IP in that same range.
Your other option is try seeing if the public IP of the users that are allowed resolves to a DNS name, it’s common in the UK at least for the public IP to resolve to what I think is some kind of ID like user ID for the connection.
For example a customers public IP for sky in the UK could be: ab65agbfisb.sky.com or something similar.
Try doing FQDN objects for that and see how that goes, if the Iap changes it should just resolve to the current name.
You could try to only allow certain countries to communicate; only allowing the countries in which your company operates or from where you expect to receive VPN connections.
Other way is to block inbound traffic using the built-in EDLs from palo alto (known malicious, bulletproof, tor nodes, etc)
If this is a top concern, I would apply two rules, one for each method that I mention
You can use security profiles to enhance security. You could also try using zone/dos protection policies to further limit ability to take it down. I have seen configurations with no default web page so nothing pops up, also in my opinion doing certificate based authentication is correct approach.
Aside from geo filtering and Palo and third party malicious IP EDL/feeds and securing your GP auth with MFA + the other comments: you have to accept that you’re running a hardned security appliance. As long as you’re updating it when CVEs come out, your are deferring risk to Palo Alto to have their product hardened.
This will prevent unauthorized attempts to the portal .
I agree with all the other stuff about edl/geo block/zone protection/ ip restrictions
I warn you if you keep it enabled… do one think for me.
Set up alerts for authentication attempts… Watch them alerts come in… after a while.
Palo had a vulnerability in 8.0 I believe that warned everyone to disable portal. After this I kept it off even after they fixed the cross script issue.
Mainly just worried about having it secured. It’s my only rule that is “open” to the internet (as in “Any” source address from the Untrust Zone is allowed through).
I just see it as a potential vector in, when none other exists. Like I stated, my current baindaid is restricting the source IP to my users known public IP addresses from their home - but it’s a pain in the damn ass to update almost daily.
You’re suggesting try and work out which isps the staff are using and then work out the ranges they have and wishlist them!? What about when they’re mobile?
Set up your own dynamic DNS server and have your users register to it. Then set up a dynamic access list with tagging to include everything in that dynamic DNS zone.
You gotta trust your firewall. It’s basically designed to do exactly this. If you don’t trust it then you need to get one you do trust.
Sure the internet is a hostile place, but this is literally designed for just the purpose you’re using it for.
Like I said, make sure you’re getting notifications for new updates and are reading the release notes and generally keep up with some security news and you’ll be aware of any exploits that need to be patched