About BenKnorr2

BenKnorr2 · ‎06-24-2021

There is an Expedition v2.0 that is based on Ubuntu 18.04LTS. It has been easier to deploy from the previous iteration; cheers to the Palo Alto crew that put this together! https://panos.pan.dev/docs/expedition/expedition_qs

BenKnorr2 · ‎11-24-2020

Certificates are another thing that don't exist in Expedition and can't be migrated. For Palo to Palo, I would usually recommend just exporting full xml config and importing into target firewall. Before committing on target firewall, adjust physical devices as needed, especially management and dataplane interfaces. If you have Panorama, even better for the migration since you can leverage device groups and templates. If you need to mix-match stuff in those containers in panorama, expedition is a very helpful tool for that.

BenKnorr2 · ‎10-21-2020

Reading the Expedition Log Analysis Guide (1.0.2), it has a tiny blurb about the "flow" in the Learning Results: The Flow has been calculated after figure it out who are the servers on the networks. In the resulting potential rules, there are mixes of "Client_to_Server" and "Server_to_Server". I import rules to my project and when merging rules to group similar sources or destinations together with common apps, I'm at a loss to understand how Expedition or PanOS calculated the flows. Case in point, I have many rules that come up when merging that all have same src zone, same dst zone, same apps, only src or dst hosts are different. Without knowing more about actual clients that are listed, I would be inclined to group them all in the same policy. But if PanOS or Expedition is seeing an OS fingerprint or something in the traffic and throwing the "client_to_server" or "server_to_client" flow and then tag onto the rule, I would consider leaving them separate. Assuming same src/dst zones , what would make Expedition call one flow server to client or vice versa?

BenKnorr2 · ‎10-21-2020

Replied too fast just now! I typically go slowly when building filters and sorting the machine learning results in greenfield. Personally I like to add application column, group by dst-address or src-address, then sort on that field. Can use default view that groups by app to show some higher-risk apps like rdp or ssh and start breaking rules out like that, but I usually end up grouping by IP since customer has inventory that they are working from and we go down that list to make sure we cover everything. My case is assuming 5000+ hosts in the environment, so the recommendations get noisy. Once you're grouping by IP, can easily add filter there. FWIW, the filters aren't amazing (10.10.10.10 will match 10.10.10.100 too), but they help a ton if you can layer the filters on results.

BenKnorr2 · ‎10-21-2020

In your project, in the M.Learning tab, you can set your enabled networks to only include internal stuff that you want to make rules for. Once you have analyzed the enabled networks, doing m.learning on any policies should only reflect that new ip space.

Member Since	‎05-23-2019 08:29 AM
Date Last Visited	‎03-16-2023 11:29 AM
Posts	20
Total Likes Received	1

Online Status	Offline
Date Last Visited	‎03-16-2023 11:29 AM

About BenKnorr2

Re: Cloud Identity Engine Directory Sync

Re: Panorama log import

Prisma Access compatibility

Re: GlobalProtect - Autoblock/kick users when vulnerability exploit is detected?

Prisma Access rules : how to calculate when used?

Re: Palo to Palo migration

Re: forwarded logs not deleting after processing

Re: New Expedition Installation Procedure

Re: Palo to Palo migration

"flow" in Machine Learning

I've Re: ML Destination IP Filte

Re: ML Destination IP Filte