About paul.dinapoli

Yep - you bring up good questions - same issues/pain we've had - so rest assured you're not alone! 1. After the new one is created, how are you removing the old rule + auditing that deletion? Me:  for us - still keeping this manual.  Once the new IaC rule is live I just use panorama UI to disable the existing hand-built rule.  We hang onto it for 30 days - then finally just delete/commit/push. Say I had a rule that was named "Access to TCP 443 from Internet for DMZ Web Servers", but then you realized you actually meant HTTPS and wanted to update the rule name to now say "Access to HTTPS from Internet for DMZ Web Servers".  What is your process from doing this as the moment you change the rule name, you will now have 2 rules that IAC created. Me:  this is the beauty of running the playbook targeting your device-group in Panorama first.  If you noticed something you don't like - delete the rule from Panorama via the UI (quickest/easiest). Tweak the playbook and rerun it.  You sorta have to iterate over that a few times until you get it right - then finally you do the push to the firewall.   2. How are you modifying your rules.  Example, you find you need to move a rule up or down in the rule base for whatever reason say you have a rule that allows HTTPS from the internet to 100 address objects.  Then one of those address objects is being retired, how are you removing only that 1 address object from both the rule and from Panorama as to keep the rule clean and panorama clean of stale objects?   Me: pretty straight-forward - if you are talking about a rule you have already codified - later you need to tweak it - ansible won't create the rule that already exists...it will only change the value that you tweaked.  add a source or dest address...it doesnt recreate another duplicate rule - it just adds the diff. 3. Just because your rules are in IAC, doesn't mean a human couldn't log into panorama and create a rule (think like when ansible is down or something, or a human just not doing things they are supposed to do) and thus negate your IAC and auditing.  How are you accounting for this?  True, in my organization - for better or worse it's just me and my partner, there's only 2 of us that have full god-rights to the network and firewall infrastructure...so we are 100% in sync as parters in this journey.  No exceptions...all firewall rule work goes through this jira/git/PR approval workflow.   (think like when ansible is down or something,) this isn't really a thing...Ansible runs from your laptop - or a jump host - unless it was a true emergency and you need to do something "RIGHT NOW" i would say - once you start your journey to all-rules-are-ansible - dont deviate.  it will be a mess.  if you have folks on your team that won't play nice...demote their account to read-only.     4. How are you creating/maintaining all the things  (Objects, security profiles, custom apps, administrators access configs, EDLs, UserID configs, ldap/kerb configs... etc).  Without these objects and configs the firewall and it's rules wont work properly. True, there's a lot of dependencies.  We made the decision to only focus on the access rules and associated objects...but address objects / tags / etc... you can build a playbook with tasks - and you just create the dependencies first - then finally the firewall rule - that uses those objects   5. How are you accounting for commit errors?  Are you still going into Panorama and validate the commit happened?     correct - we run the playbooks against panorama - then we use the validate tools for sanity check.  there's not really that many commit errors honestly - if the playbook has syntax issues it wont run...so by the time you have your playbook built correctly - it will execute against panorama without any issues. Are you still going into Panorama and validate the commit happened?   <--- most definitely!   6. If you need to back out of a change how do you quickly revert to the last config?  Within Panorama it's easy, via IAC, i can't wrap my head around it as you can't just delete the rule (should you need to remove the rule) in IAC and say push.  Ansible in this case wont remove the rule. (might be easier to show you this via zoom - too much typing!) 7. You mention you have an HA pair of Panorama.  How are you checking which Panorama is the active Panorama with IAC before pushing the code? we only have 1 instance of panorama so this is not an issue for us.  we have HA firewalls...but for us panorama is just a single VM.   8. As for your rebuilding everything from zero, why would you not just use the panorama backups as it has EVERYTHING where as your IAC only has the stuff that you've put into IAC.   yep - fair point.  many ways to skin the cat.  we bought into panorama after we'd already deployed several firewalls.  i would say this was a general PITA disaster.  some stuff panorama managed - other stuff it didn't.  The general concept of panorama is pretty good...but in day to day use it has a lot of very confusing layers  / hard to navigate.  its an operational mistake to have feet in both worlds where some stuff is configured local - vs some stuff from panorama.   ... View more

Hi @RyanH  We're in the middle of it now - iterating over our process - but overall I'd say the underlying technical aspects are going fine.  I will try to pull apart your comments above and at least try to answer each one how we did it.  Your concerns sound just like mine at the start of this! "This all gets really complicated when you start using application based rules vs port based rules, ssl decryption...etc" full disclosure - we don't terminate TLS on our palos - so I cant speak to this for you. but "app rules vs port rules".    from an ansible standpoint this is no biggie.   I would try to tackle in stages if you can. when you go to write the ansible playbook to convert a hand-built rule into ansible code...just craft it identical to how it exists today.  insert the new IaC rule right above the existing rule with all the same exact parameters (source/dest/app/logging/ etc... ) - just add. "-ansible" or whatever tag you like (-IaC) to the end of the name of the rule and use the 'location parameter' to have it land in the right location within your existing rule list. location: 'before' existing_rule: 'existing_rule_namet' This way when you or your larger team are looking at firewall configs...it's easy to see which rules are legacy hand-built rules - which are pushed via ansible. Once you commit this rule into the firewall - it will be 1 rule ahead of your existing rule and the new one will start taking the hits.  you can reset the counters on the old rule to make sure nothing is matching it - then you could disable the old one (for a period to make for safe roll-back) delete the disabled rules after a 30 day review period.  rinse/repeat.   I still don't know of a good way to rename a rule via code as you can't simply go into your text based rule base (stored somewhere likely github) and just rename the rule.  Ansible will just create a new rule.  yep - that's the point!     My jira workflow goes like this: we have 160+ firewall rules in our main east/west HA pair... they have all been hand built in panorama and pushed to a device group. to turn all our firewall rules into code with a good clean audit trail we did this: create a repo in bitbucket "network-ansible" build out inventory, vars, etc... (we use ansible for cisco/f5/palo) I wanted infosec to be default reviewers for anything related to firewall policy & security - but not general networking (cisco/f5) so we tag all our jira tickets with *net-seg* - so infosec can be alerted to commits and pull requests for palo stuff...but not all the other noise. build out the ansible playbook ( yep - 160 rules = 160 jira tickets) but this is perfect...tedious as all hell...but perfect for the audit trail - and great for DR / fault tolerance.  god forbid you ever have to rebuild from zero - your rule base is just an ansible command away. commit the code block peer review / pull request.  this whole git/jira/bitbucket workflow only takes care of the IaC part...you still have to go execute the playbook.  We do this by only running the playbook against Panorama (the ansible playbook for the rule will target the device group). This way we get the luxury of doing commit validation / and we then push to the firewall device group.  This gives us lots of opportunity for catching mistakes and easy roll back. rinse/repeat! you're right...it looks like you're creating duplicate rules. for my use case - that's how we wanted to do it... plug in the new rule with -ansible tag...position it right above the existing.  seems like extra work - but it's the safe method...if you miss some parameter in your IaC deployed rule and it doesn't match 100% to the existing rule... instead of breaking something - you're still gonna match on the existing rule and your app still works.   if it helps - i'd be willing to do a show & tell via zoom if you need more details. PD ... View more

ran this verbatim as shown above... no change 😞 paul.dinapoli@panorama.****> configure Entering configuration mode [edit] # load config from running-config.xml Config loaded from running-config.xml # commit force Commit job 179142 is in progress. Use Ctrl+C to return to command prompt .15%31%85%99%..... try to run my ansible playbook: {"changed": false, "msg": "Failed create: *** rule_name ***  -> hip-profiles unexpected here"}         ... View more

I too would love to know how to get help when all avenues of troubleshooting and documentation scouring has failed.  It kinda feels like Palo Alto doesn't give much care & feeding to their ansible support...when something doesnt work as advertised - we're on our own. https://github.com/PaloAltoNetworks/pan-os-ansible/blob/develop/SUPPORT.md ... View more

Hi Ivan, I went through your video - https://www.youtube.com/watch?v=0OnKIcUCKJg    I'm actively working on converting existing firewall rules into ansible code - and I have a feature/functionality inquiry.   Seems like all the documentation talks about how to start building security policies with ansible...and they all seem to be overly simplified and only apply to a basic new install.  What if you want to insert a new rule somewhere into the list...I have a hard time believing I'm the first person to see this - or need this functionality.   I have 130 existing firewall rules - I'd like to turn them into ansible code and manage them with git.  The only documentation I can find talks about "location"   location : 'before/after' existing_rule : 'xyz'   so this would mean you'd have to know the existing firewall rule list - and every code block for new policy - has to reference another rule/name.   example: - name : add SSH inbound rule to Panorama device group panos_security_rule : provider : '{{ provider }}' device_group : 'lab-pan01' rule_name : 'SSH permit' description : 'SSH rule test' source_zone : [ 'any' ] source_ip : [ 'any' ] destination_zone : [ 'any' ] destination_ip : [ '1.1.1.1' ] application : [ 'ssh' ] action : 'allow' - name : add a 2nd rule to Panorama device group panos_security_rule : provider : '{{ provider }}' device_group : 'lab-pan01' rule_name : 'SSH permit01' description : 'rule indexing test' source_zone : [ 'any' ] source_ip : [ 'any' ] destination_zone : [ 'any' ] destination_ip : [ '1.1.1.1' ] application : [ 'ssh' ] action : 'allow' location: 'before' existing_rule: 'SSH permit' the palo cli has the concept of "index" which is the position of the rule in the list...seems like if we could pass that into ansible - and ansible could index the new rule - the code would be a lot simpler.  having to know the name of the rule for before/after insertion makes for lots of useless extra text in the code. being able to index the rule right into the place you want it seems more efficient.  show running security-policy | match index <<-- gives nice output of all your firewall rules in their current ordering maybe this exists somewhere - but I can't find it in any palo/ansible documentation.   ... View more

fair question! My org has been spending an awful lot of time chasing soc2 compliance, CIS benchmarks, now NIST.  it's tedious work and I suspect will never end. Being a career "network guy" one thing that has always been a challenge is building an environment that can be easily audited.  So, the reason we're moving forward with ansible to automate some of our palo stuff is because then our config is in code..we have commit histories, change control, etc... it will be very handy to say "this is our baseline security config - here's our code - here's our proof we comply," etc..   so - to the question " Do you plan to use ansible instead of panorama to create firewall rules? Any special reason?" I think that's the direction we're headed...only because panorama is slow, lots of point & click, fairly cumbersome.  Don't get me wrong...Panorama does a lot of good stuff...but it's also cumbersome, and still hand built manual.   Since I'm still pretty new to this I'd love to hear your thoughts on what other low hanging fruit you think is better to pursue first. ... View more