1. Panorama concepts, hardware, template and template stack
In this lecture we’ll talk about Panorama. And Panorama is the management platform for Palo Alto Firewalls and it allows you to do multiple things. First thing is centralized configuration and deployment and deployment. So instead of logging into each firewall and configuring the firewall itself, you can configure the firewalls from Panorama. And this allows you to centralize the configuration and deployment. So you don’t have to visit every device to configure the device. You can just configure it through Panorama and it’s going to provide you also the aggregate logging and reporting. So if you have a big environment where you have like ten firewalls or more, checking the logs from each firewall would be cumbersome, right? So anorama allows you to go to a central point of reference to do logs and this will facilitate forensic research and cybersecurity defense, cybersecurity response and incident response.
And the other function that Paloto Firewall allows you to do is distribute administration. And this distribute administration basically allows you to control who can manage the device based on their group membership and what they can view on Panorama. So for example, you have like panorama in different regions. For example, you have the West Coast multiple Panorama firewalls. And you have the East Coast multiple Panorama firewalls. And basically you want to give the east coast administration access to just the east coast firewall. And give the west coast administration just access to the west coast firewall. This will allow you to provide the sweet administration. And you have a global administrator here that controls all of them. But the West Coast. Firewall management administrators cannot manage the East Coast. And vice versa.
So you can have render control over who can manage the Palo Alto Firewall and what Palo Alto Firewall by going to a central management platform, a central management location, which is the Panorama. So the panorama comes in different flavors. You have the Panorama VM and the VM basically gives you the ability of running the panorama and it can provide management for different license levels. You can have 25 devices, 100 or 1000 devices managed by Pen Rama virtual machine. By default, the VM has eleven gig for log storage, which is not sufficient. You can add virtual disk and that virtual disk gives you the ability of adding up to eight terabytes for log storage. And then you have the physical appliances and those are called the M series appliance.
You have the M 100 and the M 500. Okay, so what’s the difference between the Panorama VM and M series? I mean, there’s limitation on the VM series. If you have 10,000 logs per second, it’s less than 10,000 logs per second, then the VM would be fine for you. If you have more than 10,000 logs per second coming into panorama, the VM will not be able to cut it. So in the case of environment where you have 10,000 logs per second or more, you need to use the physical hardware platform. The M 100 and M 500 has redundant disk. The M 100 doesn’t have hot swappable power supply. The M 500 gives you hot swappable power supply. You can run the M series appliance in one of two modes.
You can run in panorama mode, which allows you to do the administration and logging, or you can run it in lock collector mode. In the case of lock collector mode, this will allow you to have it run in lock collection only mode. And the reason why is if you have a lot of logging per second, you probably want to distribute your logging to multiple appliances to be able to handle the number of logs coming in and avoid logs getting dropped as they arrive to the M appliance. The M 100 provides you the ability of receiving 10,000 logs per second. And if you’re running it in lock collector mode, it can receive up to 30,000 logs per second. In the M 500, in regular panorama mode, it can receive up to 20,000 logs per second. And in panorama in lock collector mode, it can get up to 50,000 logs per second.
And the reason why the lock collector mode goes higher because there’s a function that’s not running by the M appliance, which is the administration piece of it. But the M 100 can have up to eight TURB, four Turbit drive, and then the M 600, M 500 can have up to eight Turbit drive. That basically is the difference between a different platform for running panorama. Panorama basically allows you to manage the Firewalls and it allows you to manage the Firewalls through panorama itself. And if you want to go to the device itself that’s connected to panorama, if I had devices connected, I’ll be able to click on the device and access the device itself. So it basically kind of proxies the web interface of the power to Firewall through the panorama.
So this is context switching which basically allows you to switch between panorama. If you had Firewall connected, you can go to the Firewall itself. When you add devices, you click on manage devices and basically you should be able to do this one. You should be able to see devices that are connected. If you have devices connected that are in active standby mode, you can group them into one device and group them as an H Shapir. So to add the device, what you need to do is add the serial number and basically this serial number in basically you can group the devices in group as an H, a PA pair, if they are connected. Once they connect, if they are in the same Ha group, then basically they would show up as a single device.
The Palo Alto panorama system allows you to manage pretty much all the configuration of the Palo Alto Firewalls. And there’s two types of configuration. There is a template and the template basically handles the two tabs. That the two tabs of configuration that you have when you log into the Palo Alto Firewall itself, you have the device tab and the Network tab. So this is what the template allows you to manage. So when you create a template basically, and you put that Firewall as managed by that template, you are able to manage the configuration of the Firewall that are device and network those two tabs. And then you have device group and the device group allows you to manage the objects and policies there.
Okay, in Panorama, when you add a device you should be able to see the manage those configuration within the panorama itself. And you basically don’t have to go through the Palo Alto Firewall itself but manager to Panorama. So let’s take an example here on Panorama itself and we can create a good template. And when you go to template, you can add a template. So let’s call this west coast region. Okay, you see here now as soon as I created that, it created the template that has the two tabs network and device. And this is basically what you can go to that context and change the context to the template to west coast region and configure settings that will get pushed to the Firewall in the West Coast region once the Firewall connects.
The West Coast region is basically one template, but there is flexibility as far as what you can configure, something called template stack. So let’s take an example of what template stack allows you to do. So let’s say I have the west coast region and this will be encompassing all the Firewalls in the west coast region which includes data center Firewalls and includes user location Firewalls. And inside the data center location you have different Firewalls. For example, California. DC. DC. Pair. So this is a template for the California Data Center pair. User location. You have Long Beach and this Long Beach has the firewall pair in Long Beach.
Okay, so to simplify the configuration, you can create something called template stack. And what a template stack allows you to do is set configuration at different levels. So I can say okay, west coast region the time zone is PST and in the data center my time servers are 170 216 one one and one two. And then in California DC pair, the network interface I have Ethernet one one as Untrust, Ethernet one two as Trust. As an example user location. Here I have time servers. For example, I have here DNS servers as Four as 172 17 one dot One. The Long Beach Firewall pair has Ethernet One one as Untrust. Ethernet One two as Trust and Ethernet One three as DMG.
In order for me to manage the Firewall and have it receive configuration from the top level, from different level of hierarchy, I can create something called template stack. So the template stack allows me to receive configuration from multiple templates. So in the case of the data center firewall I can configure it to receive the settings of the network from the California. I can configure it to receive the following templates california DC pair that’s first level data center and west coast region. So the configuration is applied top down and the top level text priority. So for example if I configure the time survey here to be 172 dot, 31 dot, one one dot and here it’s configured to be 170, 216, one one. The top level will take priority so that will erase this configuration.
But the nice thing about this is you can have some configuration at one level, other configuration at other level and this way you can control different type of configuration based on hierarchy of location of the firewall. In order to create a template tag we’re going to create the west coast region, we’re going to create the data center firewalls and then we are going to create the California data center and then now we’re going to create a template stack. This template stack consists of California Data center as the top level data center firewall is the second level west coast region at the bottom level. So here we go stack at the bottom and then call this California firewalls and put the firewalls that are in that location in this template and then create the template stack.
Template stack. So the top level will going to be California DC second down to it data center firewall. Bottom down to it is west coast region top down, this will take over. And nice thing about this is when you push the configuration, if in the west coast region something changed you don’t have to go to each individual firewall and change it. You basically go to the west coast region and change it here by adding whatever you want to add. So for example, you want to enable LDP in the west coast region. You can just enable it here across all firewalls in the west coast region. Okay, this would include the firewalls. Basically this would trickle down because the template set in California has California DC data center, west coast region so it’s going to basically receive the setting from the west coast region.
And when we look back at our setup here, now I have user data, user location so I’m going to create another template stack that basically I have user location. So the first stack here is called User location, the second one in the stack and then Long Beach location and then I’m going to create a stack called Long Beach Firewalls and basically add the template. First level is going to be the Long Beach location, second level is going to be user location, bottom level is going to be west coast region. Now my setting that enable LDP basically is going to be available across the California firewalls in the data center and the Long Beach location firewalls by just one changing the setting in one place.
If this was not the case. You would have to go and change the settings for all the firewalls in the West Coast region. So that’s basically what the nice thing that allows you to do. Template basically controls the device and network tab and once you’re ready to push the template you’re basically going to commit issues, commit template and then commit the change. No device commit template or commit to Panorama. Right, so we’re first going to commit to Panorama because that will save the configuration on Panorama. Now if I have devices connected I can go in and choose commit the template and commit the template is going to basically push those settings to the firewalls. So if I had firewalls connected to my Panorama, I will basically be able to click them and then push the commit in 80.
They made another button here that allows you to commit and push at the same time. The way of saving the settings is first you have to commit to Panorama, panorama and basically that saves the settings in Panorama. Save settings in Panorama. And then now you can push the template, commit the template, which basically pushes the configuration on the device tab and network tab in the template. It pushes it to the device and there’s basically a commit template. So sometimes the device has settings in it. Let’s say you want to overwrite the settings that’s on the device. When you push the template to the device you’ll click on Force template Values. This will force the template values on the device and then once you click Comment you will get the outcome of your operation.
2. Panorama Device Group Concepts Part 1
In this lecture we will talk about device groups. So same like we did in templates where we had a template stack hierarchical configuration that allows you to push a template stack that has multiple configuration from different template policies and push the configuration to the device to simplify the management. When you deploy deploy new firewalls in your environment. The same thing applies to the two other tabs in the Palo Alto Firewall which is going to be the Policy and Objects tab. So the Policies and Objects tabs are managed by the device groups. The device groups allows you to also manage policies and control the different policies that you have in your environment and different objects that you have configured.
Go back to our example where we had templates. We had an example we provided that was at the top level. We have the we’ll go back to up to one level company wide and then west region user sites and then we have data centers and under the user sites we have Long Beach and then here we have Data center, we have California data center. You can also have the west region, the east region and so on. You place the firewall and the lost branch. So if you place it under Long Beach it’s going to inherit the settings from user sites, west region and company wide. This basically consists of the device group, the policies and then also the object. By default there is shared object group and this shared object group is the top level.
So when you configure what you configure in the shared this will basically apply trickle down to all the other devices. So typically what you have is net policies. So you’d have the security policies that this could be global. So you can configure the security policies to be at the company wide level and then trickles down to all the way to the Long Beach and then you can have the net policies because that’s basically ad policies are tied into the actual location. So the net policy can configure at the actual data center, at the actual leaf branch. So you have leaf and spine that connects you back all the way to shared. How do you create device groups? You create device groups by going to the panorama and device groups and there is going to be a shared device group by default.
Let’s create shared company wide and then we’re going to add company wide. It came after shared so you probably could make the shared as your top level basically where you apply settings that’s applicable to the entire environment. And then we’re going to configure I’m going to delete that one since we’re getting shared and then we’re going to configure west region, okay, and then we’re going to configure under the west region. We’re going to configure user sites here. It fell under west region and then we’re going to configure data center and we’ll move this up one level so you see here the parent device group. We’re going to make it west region. Now the west regions and data centers inherited from west region and user sites inherit from west region. And then we’ll put under the west region, the data centers will put California Data Center.
So the parent device for this will be data centers under the west region. And then we’re going to add another one user sites called Long Beach. And we’re going to put the parent of west region user sites. Now you see this device group two tabs that got created. And if you go to Policies and Objects, you have multiple levels of configuration and the top level is the shared object. So when you look at device group here, you can configure objects that are in the west region if you configure something that’s in the west region because below it are multiple other device groups they’re going to inherit for the west region. Anything you put in shared, it’s going to get inherited by everybody, anything you put with the west region or it’s going to get inherited by user sites in Long Beach.
So let’s try that out. So I’m going to go to west region and I’m going to here create an object. And this object you can make it pertinent to when you create an object, you can make this object pertinent to that device group you’re creating or shared. Shared means it’s going to be global object that’s seen by all the firewalls. So for example, if I go here and say I create an object saying DC network SuperNet call this make this 100 one 72160 00:16. So this company uses the data center networks or in class B and they partition it to other different class CS based on the location. So here if I look at the west region, I created it here. If I go back down to the data centers, I see it also here and I see it created under the shared object. So it trickled down to data centers.
It trickled down to California DC. I see it there. So what if I create an object in west region? So if I create an object with west region, it’s still going to get inherited by the other side. Let’s create an object for the west region. We’ll call this California data center. And this is going to be 172 1620. Okay, so if I go to the vice group data center, I see this was created, you see here the location where it was created from the west region. This applies to all the configuration that’s under objects. You can create the objects that make it shared or make it based on device group. And everything under that device group. All the device groups under that device group would inherit the set. That’s great. So what about policies? Okay, so Policies have the concept of pre rules, post rules and default rules.
What are those means? Okay, so by default. The default rules is the default rules is the rule that will show up on all the firewalls no matter what. And this was introduced in PALotto 6. 0, is the intra zone permit and enter zone Deny. Okay? Then we have pre rules and post rules. Okay, so what are Pre rules and post rules? Picture this. You have the firewalls. The firewall has its own policy tab. And inside the policy tab, there are security policies, QS and so on. The firewall has policies that has the policies and then you have Panorama. So Panorama has two things. You have the pre rules. The Pre rules takes priority over what’s configured on the firewall itself. The Pre rules comes first, the firewall configuration comes next. The post rules comes following that.
When you configure something in Panorama as pre rules, it supersedes the policies that are local to that Palo Alto Firewall physically. So if you configure policies in the Palo Alto Firewall, they will come after Pre rules. So pre rules were superseded. So for example, if you allow traffic from traffic to Google. com here and then block them here, allow. So here you put deny and here you put allow. So top down is the Pre Rules and this will get denied and it stops there, stops processing there. So if I deny something at the Pre Rule level, it doesn’t matter what the administrator of that firewall puts in the policy, it basically will get superseded by the Pre Rules. Typically, the Panorama, we configure post rules and we configure Pre rules. Pre rules for stuff that you want to definitely deny.
So if you’re going to deny stuff across the board, pre rules makes sense because if you configure the Panorama Pre rules and he pushed it to all the firewalls and you have a local admin on the firewall, configure it to allow, for example, a category that you denied, that rule will not take effect. The Panorama pre rules will take effect. Post rules is the rules that will fall under the local following rules. So if I configure Panorama post rules and I put denygoogle. com here, let’s say@yahoo. com deny@yahoo. com, and then local admin went in and said allow. So if I put deny here and then the local admin specified that@yahoo. com is allow, this will supersede this.
So even though the Panorama pushed the deny rule, the Yahoo policy that the local admin created to allow Yahoo is going to be taken effect. The same thing applies for security policy. Everything under that. Under the policy step another level of hierarchy. If you configure something here as free rule. So if I let’s configure the rule here, I’m going to put it up at the shared level, top level, I’m going to say deny malicious traffic and I want to say source, untrust destination any, and then deny. I have a list of IPS, just put a bogus IP here, 1124. So if I determine that this I need to block this across my entire environment. So I put this in the prewalls. Reason why I put it in the prewalls is no matter what, this will take effect and supersede. So I put the Pivot rules under share.
This is going to fall trickle through all the other device group policies. If I go here, you’ll see here grayed out, meaning it’s not at that level. This is at the location Share. And then if I put the good data center, it’s still there. If I go to California data center, it’s still there. So if you configure something, it falls through to the next step.
3. Panorama Device Group and Object Iheritance
So the same rule apply in a device group. When you create a prerule at the top level, it takes president on the bottom level. So if I have a pre rule here in the west region, and then I have a pre rule in the data centers, the prerule at the data center at the west region takes precedence over the rule of the data center. Going through with our example here, california Data Center I have preroll. If I add a preroll here, this one takes precedence over this one. So the president’s level higher to lower. So for example, if I go back to our example here and I create so if I create a policy here at the west region, and I basically have a rule in the west region that says malicious IP malicious IP block West Region as an example, and I put here source untrust destination any and destination two 200:24. So this is a pre rule.
If I go down one level down data center, I see I’m inheriting those tools. But if I add a preroll here, it’s going to be lower in priority. So I cannot override the previous tools. So if I create a preroll, I cannot override the previous tools. So malicious IP exception as an example and go to source contrast destination any two 2132 one, and allow this. It basically is at a lower level compared to the pre worlds coming from the home higher level. That’s basically based on the prerolls follows the prerolls concepts, which is prerolls supersedes the local rule. So prerolls supersedes at the lower level is superseded by pre rules at the higher level. So that’s another concept. We have to be careful. So I need to change those to deny shared payrolls. This is deny.
That’s one thing you have to be aware of, right? In post rules, the opposite occurs. So when you have a post rule, the local post rule at your level, it supersedes the post rules from above. So I have, again west Region Data Center California so here I have a post rule, and here I have a post rule, and here I have a post rule. Okay, this is higher priority and this is lower priority, the opposite. Okay, let’s try that out. So I’m going to go to security policies in the west region. I’m going to create a post rule. And this will permit the nnx category. And I’m permitting the NNS category, I was permitting the Nfcategegory service URL search engines, and down below at that level, I want to make an exception for another, for one exception. So if I create a post rule here and say deny search engine yahoo untrust URL category, well, I need to create a special URL category.
So let’s create that one. So if I create an object here at this level, at the data center level, and I create a URL category, custom URL category, data center, search engine search engine exceptions, I’m going to add here astabilityaholo. com so I created it at that level. I should be available at the same level. So if I go to policy now, I can pick this from my category search engineer who excludes. I want to exclude search engine Yahoo. So I can now pick that category, search engine exceptions and then permit at that level. I’m sorry, I got a little bit confused here. Well, let’s make this deny in the next category. Oh, this was a higher level. You see a gray dot here that means it’s up higher.
I’ll make this deny. I switch from post pre rules to post rules permit and category. I’m going to make this deny internet category. So this way I could show you the exception. So I denied all the Internet category search engine, but at the data center level, I made an exception. You see here. So the exception, because it’s poster rule, it supersede, has a higher priority than the rules coming from the higher level, from the higher device groups. So this is an example. So here I added search engine Yahoo. Exclude and then going to go back to the California DC. See here the rule is inherited. So let’s say basically here it says in California data center, I’m receiving the rules, search engine exclude Yahoo. Let’s say if I change my mind, I want to change this.
I can create a local rule at post rule at that level. And that would supersede the other rules if I say here my search engine exceptions. So I made a decision at that level to deny. So here it took priority over what I inherited from the data center level, which took priority over what I had inherited over at the higher level. So post rules, the lower the hierarchy, the higher precedents prerolls. The higher the hierarchy, the higher the precedents. Okay? So that basically explain post rules payrolls. And this basically applies to everything, the Nets QoS policy based forwarding decryption, captive portal, duos protection.
That hierarchy pushes to your firewalls in the collective view, which is basically what you see here. So this is the collective view that’s going to get pushed to the firewall. If I go to post rules, I’m going to get post rule denying that category deny search engine Yahoo. Search engine Yahoo. Exception denying that category. And this is in the post rule level. The preroll level is going to be denying malicious traffic, malicious IP block exception, malicious block exception location that was applied was west region and data centers. And between the pre rules and post rules, there’s going to be the local power rules that’s configured on the actual firewall.
So that’s what it looks like. So this is as far as policies. If we look at the objects I created, URL category, that search engine category, data center, search engine exceptions, it was configured as data center. So basically because it was configured with this data center, it’s going to show up at California Data Center because the California Data Center inherits the objects from the higher level, which is data center, and then because it’s created at the data center level, you don’t see it in oyster. Okay? So the object inheritance is top down. The highest level is the shared object. So when you create a shared object, that basically supersedes all of them. So if I go to addresses, I see the DC network SuperNet that isn’t shared, that supersedes that basically is shared. So it supersedes everything.
If I go to user sites, I will see the same thing, DC network SuperNet. What if you have a situation where you want to change the object even though it’s inherited? So in that case, you can go to that object at the level you want to change and click on it and choose the override option. And that override option allows you to change the IP address or change the attributes of that object wise, what we have is object you have the shared, and that’s inherited by everything falls through to all the other device groups. So if I create an object here at device group two, it’s not going to show up at device group one. But if I get an object that’s shared, it’s going to show up in all of them. Same thing. If I create an object, device group three is not going to show up at the other level.
If I create another device group as under device group three, device group three one, the object will show up here, will fall through. So basically it’s inherited top down. And objects wise, you can override the object. So you can override the object at any level and change the information. So let’s go back here and I’m going to use your site and I’m going to override that object and make it 172 17. Let’s say we’re netting 172 16 to 172 17. So here I overwrote that object at the user size level, and if I go down to the levels below, it inherited that with the change. So you can override objects at multiple levels and basically the levels below inherit your change, your override change.
