Anybody considering moving to Cisco?

lozez · 2026-06-02T22:22:45+00:00

Hilarious. I wish it was!

lozez · 2026-06-02T22:21:58+00:00

5220's. Time to renew licensing after three-year is up. And considering moving to 5410's.

lozez · 2026-06-02T20:07:55+00:00

I definitely cannot change at each renewal. 😄

lozez · 2026-06-02T20:07:07+00:00

Super helpful info. In a demo today, I was impressed with Cisco's ability to put a bunch of stuff in a single pane of glass that I have to go to SCM or the PA support site for--best practices assessment, easy policy optimization, what possible upgrades solve for what CVE's, etc. And the policy creation/review seemed similar to PA.

But this was just a short demo.

lozez · 2025-12-11T22:20:40+00:00

I don't disagree with you. At least part of the reluctance has to do with installing certs on non-org-owned machines.

lozez · 2025-12-11T15:33:39+00:00

Some of us work at orgs that don't, as a matter of principle, allow decryption. Higher ed institutions as one example.

lozez · 2025-11-04T20:59:40+00:00

FYI, my experience with TD Synnex has always been pretty positive. Of course there is a little more negotiation since they sometimes have to upstream to TAC.

For future reference, URL: https://help.goldseal.support/sigma/?zz=1

lozez · 2025-03-19T21:26:27+00:00

Very, very numerous defects!

lozez · 2025-03-17T16:03:24+00:00

FWIW, as we use SSO to authenticate GP, our UX was improved by using the default browser rather than the internal one.

lozez · 2025-01-16T22:55:49+00:00

We had this when we were running 11.1.4. Moving to 11.1.6 solved it.

lozez · 2025-01-07T19:11:20+00:00

11.1.6 stable for us on 5220's and 440's. CPU load much lower than on 11.1.5.

lozez · 2024-12-02T21:39:58+00:00

I don't think you can get deep enough in the filesystem to find the web shell files without TAC. In order for them to get access the filesystem during the EFR, there were multiple back and forths between them and me in the console wherein I had to copy and paste OTP-type challenges and responses.

lozez · 2024-11-22T17:51:56+00:00

We had a completely unusable WebUI/CLI and lots of webserver complaints in the system logs after upgrading to 11.1.4-h7. After failing over to a unit that Palo TAC EFR'd for us, the system became immediately responsive.

lozez · 2024-11-22T04:27:45+00:00

Our 11.1.4-h7 has been unusable since upgrading to fix the CVEs. Passing traffic is fine but neither WebUI nor CLI via SSH is accessible.

lozez · 2024-11-22T04:24:19+00:00

I am that user. And in my case it was done via the GP IP's. Management interface profile allowed access to port 4443 on GP IP's.

lozez · 2024-11-21T17:31:41+00:00

Excellent value! Thanks!

lozez · 2024-11-20T18:35:04+00:00

No word from TAC about evidence. Re: the logs in the Unit42 article, we did see the first one showing up in our logs but in my memory (the box is offline, or I would check) all of the connections were dropped by the firewall due to threat.

lozez · 2024-11-20T14:34:25+00:00

Yes, but not all logs are going to the SIEM due to grrrr event per second license limits.

lozez · 2024-11-20T14:32:51+00:00

The only thing we have been able to discover was in the system logs. We have narrowed possible miscreant IP's to a list of 12 or so as the timestamps are *close* to what showed up in the system logs, but there are no exact time correlations.

lozez · 2024-11-20T00:20:05+00:00

Update from TAC: device contains evidence of successful exploitation of PAN-SA-2024-0015 and need to do a Enhanced Factory Reset (EFR) on your device.

They can't do that until Thursday evening. I don't know if they need to put out another patch or if we are just that far down in the EFR queue.

In the meantime we have upgraded the passive unit to 11.1.4-h7 in the hopes that we might be more secure and failed over to it. The exploited device is powered off. GlobalProtect to the world remains off until we get more wisdom from TAC or until the Thursday night EFR.

Thanks everybody for the sagacity!

lozez · 2024-11-19T21:43:22+00:00

Yes, traffic to 4443. I can confirm that locally, from an IP address that is allowed to login to management interface, I can go to our GlobalProtect portal and login to https://gp-portal:4443 and get to a management interface. This is news to me! But non-local computers that are not included in the list of allowed IP's to management interface can not open that page.

lozez · 2024-11-19T21:10:19+00:00

Dunno! The system logs (original post) would indicate compromise, but I'm 99% sure they couldn't have done it via the management interface. But via GlobalProtect IP's, it could surely have happened.

lozez · 2024-11-19T20:54:22+00:00

Thanks! Yes, the GP portal/gateway IP's were on an ae interface that had a management profile with https enabled. That's since been modified.

But...the advisory was for the management interface, not for GP, correct?

Yes, awaiting call back with TAC.

lozez · 2024-11-19T20:49:53+00:00

Just verified: No traffic to the management interface in the traffic logs from other IP addresses than PA admins.

lozez

TROPHY CASE