Palo Alto networks also makes bossware so intrusive that it's basically malware. Their VPN software on MacOS, for example, collects tons of system data and starts itself persistently on reboot + cannot be quit unless the user happens to have much-more-technical-than-most-users levels of knowledge about things like sudo and the various plist files work.
Tl;dr: I installed their VPN software on my personal computer in order to get remote library database access during COVID. It turns out that it wanted to know everything about my system and I had to rip holes into configuration files 99% of users couldn't even find in order to stop it.
If anyone is required to use Palo Alto or any other closed source VPN, try using Openconnect [1]. It is an open source client for Palo Alto, Cisco, Juniper, etc. VPNs which typically are just cruft on top of IPSEC tunnels. While some of the features these VPNs offer sound cool but at the end of the day they use client side validation in the from of a 'trojan' binary that is downloaded and collects a bunch of metadata about your system. Obviously this can be spoofed pretty easily if you have full control of the machine. I know it works on Linux and it should work on Mac, and Windows.
With some tweaking you can also use it to configure a split tunnel (at least on Linux) VPN so that your employer can't spy on all of your web activity. (Really for any VPN you just need to update the routing table after the VPN software is running).
Oh, how interesting! Thanks for linking this. I'd love to hear if anyone has experience with it---slightly anxious about using unknown software for sensitive tasks like VPN, but it does look like a pretty robust project...
I’ve been using it for years now. I have a Debian vm that is configured as a NATing router so I can flexibly send traffic wherever I want. Also use unbound to use the company dns for company internal queries only.
With the particular Palo Alto config the company uses I need to peel a cert off of a windows domain member as well as my creds, but that’s not hard to manage
It also uses High-Performance graphics for whatever reason when connected and can completely drain a full MacBook Pro battery in under an hour. Disconnecting does not free the GPU.
On a positive note, I now have a reason to use to MacBook touchbar. Setup an Automator action to kill the PIDs to release the GPU when I no longer need to use VPN.
> It also uses High-Performance graphics for whatever reason when connected and can completely drain a full MacBook Pro battery in under an hour. Disconnecting does not free the GPU.
Which is ultimately a bug, or a missing feature, in MacOS -- it shouldn't be possible for a random broken app to make your 10h battery only last 1h -- change my mind.
Coincidentally, even though MacBook Pro 16" has a much larger battery than MacBook Air -- ~100Wh vs. ~50Wh -- MBP is also capable of consuming said battery at a much faster rate -- 100W vs. 30W. So, if you need an average web-browsing machine with the best battery runtime in the presence of silly apps that consume all available resources, it's actually a much better choice to get MBA vs. MBP.
Why Apple doesn't introduce a setting to optimise the runtime for battery, or a lap-use mode, is beyond me. I had to install Turbo Boost Switcher to make my 2020 MBP16" usable as a laptop -- it runs out of battery, and is too hot to use on a lap, otherwise. Sadly, there's not even any tool to reliable turn off the graphics card, either -- I had to find a setting to switch it off in Firefox manually.
I've determined based on trial and error that the High-Performance graphics usage only happens after the animation during the Okta Verify window in their embedded browser. Unfortunately, there's no way for me to disable that and still authenticate into the VPN.
Hmm. I don't know about Windows, but when I've used Linux in the last few years, my impression of systemd is that somebody looked over at Apple's launchd and inexplicably said "yes, that's a great idea, let's do that," then did it just a little bit worse.
I mean, the general design is fine, the UX kind of sucks though. systemctl stop/start/restart/reload/enable/disable is a lot easier to grok than launchctl.
All of these things are actually configured by the company/library you are connecting to. They are configuration options for the firewall that are enforced by global protect. Blame your library IT, not Palo Alto.
It isn’t. You will have to speak with the IT staff to understand how they have it configured. If you have an issue with this use a third party open source client.
The point is, any enterprise client is expected to have these features. Don’t install them on your personal laptop if you have a problem with what is expected behavior.
Let's lay this out. Let's say you are a government IT shop (it doesn't matter what level, state, nation whatever), or a bank, or a hospital, you are required by law to control how data is processed on your network. Therefore you must monitor compliance for devices connecting to your network. This is what GlobalProtect was designed for. It can be used in less restrictive environments, but the IT shop should make sure to audit the rules and policies of the client to not be overly burdensome on users. Palo Alto has numerous courses to train IT professionals to configure their products. It is on the IT professionals to configure the services correctly.
Right, Global Protect is great in regulated environments. You can turn on its always on functionality and devices can then be used while connected to VPN or not at all. If that setting is configured in an environment where users are connecting their personal devices, it's misconfigured, pure and simple.
As much as I despise this kind of software as an end-user the data collection can be for above-board purposes and is required in certain regulatory domains. Zero excuse for being a shitty application though.
In our case we were required to verify that any machine that connected to our VPN was sufficiently updated, had a backup taken, was running AV and was recently scanned for malware, and had disk encryption enabled with our recovery key.
Anyone who requires this level of security for regulatory purposes should not have a BYOD policy at all. "Only fully-managed, organization-owned devices get to touch this data" is the only fair way to both maintain data security in highly regulated environments and not effectively take ownership over employees (and, in a university context, student) computers).
All of these things are actually configured by your university. They are configuration options for the firewall that enforces the portal. Blame your university IT, not Palo Alto.
The policies are really not excessive, Palo Alto is designing for enterprises which would want many of these restrictions on their assets. It just so happens the software is flexible enough to be used in BYOD settings. The IT professionals in those settings need to do their due diligence and apply appropriate policies. This is a PICNIC/PEBKAC.
Regulations (I'm familiar with HIPAA/SOX/PCI) do not require specific technical implementations like this. These are just things that have been negotiated between IT and their auditor. Saying shitty IT policies are due to "regulation" is almost always a cop-out.
My own experience, in a couple Twitter threads:
https://mobile.twitter.com/PaulGowder/status/129693268470763...
https://mobile.twitter.com/PaulGowder/status/129686524552122...
Tl;dr: I installed their VPN software on my personal computer in order to get remote library database access during COVID. It turns out that it wanted to know everything about my system and I had to rip holes into configuration files 99% of users couldn't even find in order to stop it.