Pass Your Palo Alto Networks PCNSE Certification Easy!

Prepare with top-notch Palo Alto Networks PCNSE certification practice test questions and answers, vce exam dumps, study guide, video training course from ExamCollection. All Palo Alto Networks PCNSE certification exam dumps & practice test questions and answers are uploaded by users who have passed the exam themselves and formatted them into vce file format.

Security Policy Configuration

1. Security Zones and Traffic Processing

In this lecture, we will talk about the fundamentals of the Palo Alto Firewall. For the Palo Alto Firewall, traffic must pass through the firewall in order for it to manage and control it physically. Traffic enters and exits the firewall through interfaces, right? So the firewall determines how to act on a packet based on whether the packet matches the security policy rule. At the most basic level, each security policy rule must identify where the traffic came from and where it's going to.So what is a zone? A zone is an interface or a collection of interfaces, physical or virtual, requiring the same security policy. So for example, in this diagram here, we have a firewall with two interfaces. Those two interfaces might be going to two different departments or two different locations on the network. However, both locations are considered trusted locations. So they are put in a trust security zone, and then you would have the untrust zone. The name doesn't really matter, but we generally like to use the concept of trust, untrust, and DMZ. The untrusted part is your connection to the public network. The DMZ is the zone where you serve services to public internet users, and the trust is where users are coming from. The zone itself doesn't have to be mapped one-to-one to an interface. You can have multiple interface mappings to the same zone. The basis of the decision that the Palo Alto firewall makes is based on the firewall settings and the security policies. The security policy is meant to protect network assets and prevent any threats and disruption on the network. the ball out of our wall. Security policy rules determine whether to block or allow the traffic based on different traffic attributes such as source and destination, security zone source and destination, IP application, user, and service. If the traffic does not match any rule, the default rule would apply. There are two different default rules in the firewall and the 6.1 release. There are two zones: intrazone and enterzone. The intrazone refers to traffic that occurs within the zone. So going back to the diagram here, if traffic comes in from one user on this interface in this trust zone and goes out to another user on a different interface in the same zone, the intra-zone rule will be applied. By default, it is configured to allow all traffic between interfaces to remain within the same zone, or intra zone. However, by default, traffic between different zones is denied. So you have to specifically allow that traffic. The way the path of our wall evaluates the policy is from left to right and top to bottom. We look at the security policy we created in the previous lectures. It's going to look at the traffic to determine what zone is the source zone and what zone is the destination zone the packet is going to.And then if this rule matches, it's going to stop processing at that point. However, if this rule does not match, it's going to process the next rule and so on, and then it's going to go to the default rules. Those are the default rules. We talked about the intra zone and inter zone, and as we see here, by default the intra zone is open to traffic. So traffic, if it comes in from the trust and goes to the trust, this will allow it by default. If traffic goes in from inside to outside, it's going to deny it by default. Do you see the difference in colour here? This is kind of greyed out a little bit. You can change some of the attributes, override it, and then change the action. You can change the action or log by clicking overwrite. If you want to log traffic, for example, going between interfaces in the same zone by default, that's not logged. You need to go here and specify the log with the enter zone default. You can override it and specify an action. You can override it and change the action from the night to "allow" and "do" the logging. So the security zone represents different areas in the network. Network interfaces with different security requirements go into different zones, right? Multiple interfaces can exist in the same security zone, and the zones are used by the security policy to match the traffic and determine what type of action to take on the traffic. Like we said, enter-zone traffic is denied by default. Intra-zone traffic is allowed by default. The implicit rules, which are the interzone and intrazone rules, do not have logging configured by default. But like we saw here, you can go and override it and change the action. You click on the rule and then click override, and then change the action to "logat," start logging at," and "do logging." So how do you configure the security zone? We saw this in a previous lecture when we configured the layer two interfaces, the virtual wire. You can create the zone as you are creating your interface configuration, or you can go to network zones and add the zone, specify the type, tap Virtual Wire, layer two, or layer three, and create a zone here. DMZ specifies the type of layer three. So that's basically how you create a zone. When you create an interface or configure the interface, you can attach it to that zone. So I can go here and specify what I want to attach this to. I have to specify layer three. You can use the zone that you created, right? So besides the interface types that we talk about, which are the physical interfaces on the firewall that you can change the mode to in the tab "virtual wire," layer two, layer three, you have the VLAN interfaces that you can attach to layer two mode. And then you have LUPEC interfaces, which come in handy for routing protocols. And then you have the tunnel interfaces that you use for IPsec termination and tunnel configuration. And we will talk about this when we get to the "global protect" section. This was covered in a previous lecture: thetap mode, virtual wire mode, and layer three modes. This is the processing of the packet that the powerwall does. When the packet first comes in, the initial packet gets processed to determine what the source zone and what the source address are. Then it's going to take a look and determine, based on the routing table, what the destination zone is. It looks at the packet IP destination and determines the destination zone with those two pieces of information. It needs to evaluate the net policy because when you do the netting, the destination address might change and the source address might change. So it goes to the net evaluated policy to verify what's going to be the actual destination zone, destination address zone, and source address. After this is done, the next step is to check the security-free policy that checks the allowed ports. Traffic is allowed, and it's going to create a session. then it's going to check the application inside the traffic. It's going to check for encrypted traffic. It's going to check the decryption policy and application override policy and then determine the application ID. And this typically takes two to three packets. Once the application is determined, it's going to check the security policy again to determine if this application, once it's identified, is allowed or not. If it's allowed, then it's going to check the security profile. And this is where you apply the antimalware, anti-spyware, vulnerability protection, and other features. Then the last step is going to be the post-policy processing SSL encryption. It's going to apply the net to the traffic, and then it's going to do the packet forwarding. We talked about Virtual Wire, and Virtual Wire is bumping the wire in line with no VPN, no routing, and no management on the interfaces that are participating in inline subinterfaces. You can create layer-two subinterfaces and layer-three subinterfaces, and you can also configure virtual wire subinterfaces. Besides the loop-back tunnel, VLAN interfaces, and Ethernet interfaces, you have aggregate interfaces. It will allow you to group multiple interfaces into the same logical interface. This is referred to as the port channel or the Ethernet channel. You can use multiple interfaces as a single logical interface. There's also a new interface called decryption mirror that is used to export decrypted traffic to another MacBook device. You can mirror any interface type tab, a virtual wire, layer two, and layer three. What this does is decrypt the traffic and send it to the port mayor. This requires a license. It's a free license, but it's required for export restrictions and other government compliance. And the goal of decryption is to send the decrypted traffic to an external appliance that performs loss prevention or other advanced security features. So that basically gives us an overview of how the firewall processes traffic and an understanding of what security zones are.

2. Packet Flow

Before I get into how to configure the security policy and all the features that come with it, I need you to understand the packet flow on the firewall because understanding the packet flow is crucial in configuring the proper security policy. So this might be a heavy lecture, but it's really necessary for you to gain a deeper understanding of how the Palo Alto Firewall works. This packet flow diagram goes over the steps that the Palo Alto firewall takes to inspect the packet and process the packet.The first phase is the ingress phase. In the ingress phase, the file receives the packet,extracts the layer two, layer three, layer four. Information based on the ingress interface is going to determine the zone—the traffic source zone. It's going to do IP fragment reassembly if the packets are fragmented, and then following that, it's going to determine if there are any ingress process errors. If there is any packet abnormality, it's going to discard the packet. If the packet looks fine and there's no issue, it's going to determine if the firewall inspection is applicable or not. So maybe this traffic comes in on a zone trust and goes to a zone trust, and there's no inspection needed; it's going to forward the packet. Following that, it's going to determine if this packet is coming into an IPsec or SSL VPN tunnel. If yes, it's going to do the decryption for the tunnel and then determine what the source zone is based on the tunnel that the packet landed into, going through the second phase. What the second phase does is determine if this packet is part of an existing session. So I was going to look at the package source-destination, look at the source zone and destination zone, and determine if there is an existing session for this traffic. If there is no existing session for this traffic, then it's going to need to lookup and determine the next step, which is processing the packets against the security policy. It needs to determine the destination zone based on looking at the destination IP address and determining the eager interface that the packet needs to exit out of to reach the destination. So now it has the source and the destination zone. It must examine the net policy because it is possible that the destination net is present and the rule is correct, but the egress interface is different. So the egress interface and zone might be different. So it's going to look at the IP destination and then look at the net policy to determine if the eager zone changes at that point. Then it's going to determine thefirewall policy that it's applicable to. the first phase of determining the firewall application. The firewall security policy is to use the applicationany to see if there's any rule match that allows packets to the given destination and port. So by default, it allows the same zone and denies different zones. If no match is configured like we talked about in the previous lecture, Intrazone is by default allowed, and interzone is by default denied. It's going to parse the security policy at that point, top to bottom, like we saw in our previous lecture, and then it's going to determine if there is any rule match. If there is a rule match, it's going to determine what the action is. If the action is allowed, it's going to basically create a session, create and install a session, and go through the next phases. If the rule is deny, it's going to discard the package, so that's where the packet processing would stop at that point. So if the rule is allowed, then it's going to proceed to the next steps. It's going to update the session states. This is the second packet in the session or the third packet in the session. It's going to update the session state, and then it's going to determine if there is any SSL proxy decryption policy applied. Following that, it's going to determine if a session application was identified. Application identification is basically a crucial feature of the firewall because it allows us to make decisions based on applications. And we're going to see this when we start creating the security policy. If the session application has not been identified, it's going to start putting those packets in for that session. So the first two and third packets for that session are going to get processed against the application identification. The application identification looks at different patterns in the stream to determine what type of application. Once the application is determined, the rule might be different. Now this traffic that was originally allowed might be hitting a different rule when the first packet came in, determining the rule based on source port and destination port, like a legacy firewall would do now that it has seen two or three packets from the session. Now it will need to evaluate if there's a rule specifically for that application. and if that rule allows this application. It's going to let it through to do the next phases. That's content inspection, which we'll talk about if the action is denied. It's going to discard the first two or three packets. goes through the application identification process. It takes two or three packets for the Palo Alto Firewall to determine what type of application it is. Once it determines the type of application, the traffic that was allowed might now be denied because there is a rule that specifically denies that traffic. If this application is allowed, then it's going to need to look at content inspection. The content inspection looks at spyware, malware, file analysis, vulnerability identification, and so on. At that point, if there's an SSL decryption policy in place and this session is SSL encrypted, it's going to do the SSL proxy and mark the packet to be a proxy to decrypt this packet stream. This allows it to perform the content inspection. It will need to decrypt it to do content inspection. if you have a decryption policy. It will need to decrypt the traffic to be able to look at the content and determine if it has a vulnerability, if it has malware, if it has files that shouldn't be there, and so on. If the application is not SSL-decrypted, it's going to do the content inspection. That's basically all of the unified threat management portion. OK. The content inspection will do protocol parsing, decoding, and content matching to determine things like malware, URL filtering, and other content of the package that allows the firewall to determine if it's malicious or not malicious.The flow, the packet processing There are multiple packets that come into the session, right? So each packet goes through the same process based on the stage of the session. It will take different avenues. When it does the contact inspection, it really wants to determine if something changed. So maybe this application started by being web traffic, and now there's a proxy web inside the content. As the packet keeps coming into the session, it needs to verify that nothing changed in the application, nothing changed.It will carry out the security policy action. As a result, once the packet passes the content inspection, it is forwarded to the egress interface. It will forward the packet and send it out the egress interface. If this session or this traffic is part of an encrypted tunnel, it's going to do the packet encryption and send it back through the tunnel, then circle back and send it out to the physical interface. It's important to understand the ingress flow. One of the main highlights The main highlights are basically when it does the forwarding lookup, it determines the actual egress interface for the destination, but it also does the net policy lookup, and this net policy lookup can change the destination zone. So that will change the packet-processing flows in the next stages. Other things to be aware of are the application identifications as the session gets established and more packets come through and hit that same session. The application might not be identified at first, but after 1234 packets, it depends on the type of application. This will allow the palace to do the pattern matching and determine the application itself. And this might change the rule. It might have been here in the first stage of the session setup. It might have been allowed because the application hasn't been determined yet. However, once the application has been identified, it will discard it if it is blocked by any of your security policies.

3. Rules based on application using App-ID

In this lecture, we will talk about applicationID and how this application ID comes into play with the Palo Alto Firewall. And basically, application ID is the core functionality of the Palo Alto Firewall. The Palo Alto Firewall is the first firewall platform that came out with an application concept. The security policy makes decisions based on applications versus TCP, UDP ports, and protocol like the legacy firewall does. So applications are categorised into different categories. If you look here at the categories, you have business system collaboration, general Internet, media networking, and unknown. Then, on the left side, there is a column that shows the number of applications, and there are subcategories. Also, you have an audio streaming authentication database; there are multiple subcategories, and then applications are categorised by technology. For example browser based, you have a big chunk ofapplications are 824 client server, you have a lot ofapplications or client service servers, network protocols, some of thenetwork protocols for example are DHCP, Dhcpv six peer topeer or peer to peer applications which probably want toblock off the bat because you want any peer topeer application in a business environment. Another important categorization factor is the risk. The risks of the applications are numbered from one to five, five being the highest risk. And then also there's characteristics evasive, excessive bandwidth,prone to misuse software as a service, transferfiles, tunnel, other apps and used by Malwareand a vulnerability and widely used. So, for example, the application used by malware here is a good example of an application that you should block right away. Vulnerability applications that have vulnerabilities—one of them is Tip Trunking—have vulnerabilities as well. You have a lot of flexibility as far as selecting what applications you want to use in your policy. There are two different tools that you have that allow you to make application decisions or make simplified application groupings or decisions. One of them is application filters, and the other one is application grouping. So an application filter allows you to filter applications based on the different characteristics that we talked about, whether they were category, subcategory, technology, or other characteristics and risk level. One example that you would see in a lot of deployments is blocking based on risk level five. Some of the risk level five applications are business-related; one of them is Google Drive. So you have to be careful when youblock applications to go browse through those applicationsand make sure that they are not goingto break any of your legitimate applications. so browse through them before you block stuff. When Palo Alto sends you an update or a Firewall update, it sends you app ID updates; if they come up with new applications and you have an application filter security rule that, for example, blocks risk level 5, you're protected from that newly identified application that's at risk level 5. So we're going to start by creating a risk level five block. We call this app filter level five. And we would basically use this in our policy to block application level five. If we look through application level five, one of the applications that I know causes issues is Google Drive, Google Drive, Web, and then Google Talk. So maybe those are applications in your environment that you want to use. So you should create security rules to allow those business-related applications and your policy. So in our case, we're going to use application groups to do that. We're going to create an application group called Business Apps Whitelist, and for those we're going to use Google Drive, Google Drive, Web, and Whitelist. For those, we go back to our security policy here. I have pretty much allowed everything. I'm going to create a policy here that blocks risk level five, blocks risk level five, and allows source trust to entrust an application. That's why I called the DEP filter first—so that I knew what to search for. And then I'm going to specify deny and log here. Since I'm denying access, I need to log in at session start. Okay, remember, the firewall process is top down.So you have to have this up top. Under the service section, there's an application default. What the application default does is basically look at the application default. Is the application's default set of standard ports, UDP ports, and protocols There are some applications thatdon't have standard ports. like dynamic, for example. This one is dynamic (TCP).That means it can run on any TCP port. That's so big. The differentiator between the legacy firewall and the next-generation firewall is that they can identify the application on any port, not necessarily a specific TCP or UDP port. However, when you create a rule, the rule specifies the application default as a service. This basically utilises the application standard ports that you have here that were specifically created. So, if I do a search on Gmail, which runs on TCP port 4380, and Gmail video chat, which has dynamic TCP and UDP, when you create the policy and the policy would have application default, this looks at the ports that are defined within the app's definition. So blockers global five So right now, I'm going to go ahead and push that policy. And let's see if I can get through if Itry wants to drive Google.com before I push the policy. So if I push the policy now and it hasn't made the exclusion yet, which is the business app application group that I created, if I push the policy now, I'm not going to be able to get to that Google Drive. So I'm going to close the tab and now try to go to drive Google.com.probably cached. Open your browser. You should see it getting blocked. When I go to the log viewer filter, log viewer service here, the policy is denied and reset. That's why I created this application group and the application group. Now I need to put it up top. In this application group, I'm defining the business applications that I'm going to exclude, and one of them is Google Drive Web. So, on top of that policy, I'm going to add another rule that says "business app exclusion." The source is trust, and the destination is entrust. Then we'll specify applications and business apps, as well as business app whitelists. And then we're going to add this up top. And once I push that policy, I should be able to get to that Google Drive. So now I have a Google Drive app. requires a Google Doc page to be allowed. I'm going to need to add that to my application group. If I look at objects, And I'm going to need to add Google Doc faces. All I need to do is just add it to the application group. I don't need to touch the policy because the policy is already created. You need to whitelist an application. You just put it in that application group. Okay, I still get a Google Drive web page that requires GoogleDoc uploading, so that needs to be allowed as well. Google Docs uploading, uploading Okay, give me one last time. So if there's a dependency, it will tell you that there is a dependency. So you can actually also look at the application itself and at the dependencies. We'll go ahead and look at that. If you go to the application, you see here that it depends on Google Base, Google Doc Base, Google Doc Editing, and Google Doc Uploading. So technically, you should allow all those. It didn't complain. You click on the commit log and commit it successfully. So I'm going to go ahead and try it. I'm able to get it. It's allowed now, according to the policy and the logged viewer I see here. And the rule is "business app exclusion." This lecture shows you the different application groups of the application filter. And we're going to talk about additional stuff relating to application in the following lectures.

4. Security Policy Rules for applications not running on application default ports

So in this lecture we will look when you'rerunning something not on the application default port. So for example, SSH runs a standardport is port 22 is 22 TCP. In my AWS setup, I have a DMZ server that's Ubuntu, and that DMZ server server.I'm running the SSH service. I want to offer it out to the public. I'm going to be running that on two ports, 22 and 22 22.The application's default service port is TCP 22. So how do we get around that situation? So we'll see how to take care of that. I am going to set up a policy for my Ubuntu server running on the DMG. There is currently an ad configured for port 22 and port 22 22.And this is the destination net. And we look@the.net in a differentsection, but basically from untrust unrust. If I connect to my firewall IP addressport 22, it's going to destination added tothe Ubuntu server and also port 22 22. It's going to forward it to the Ubuntu server. To protect my DMZ, I'm going to create a rule that basically allows the application SSH and nothing else. So under the security policy, we'll go ahead and add a policy here with a rule that specifies Dmzshaccess, and under the source, we're going to be untrusting of the rules, looking at the security rules, the source PostNet zone, the destination PostNet, and the IP address PreNet. So we're going to get into this deeper in the Internet section. But to be specific on that rule, the destination PostNet is the DMZ, and the destination PreNet is the IP address of the firewall outside interface, which is why I want to allow application SSH and I'm going to basically use the application default port, which for SSH is TCP 22. And then I'm going to specify what action to allow. And then, just to make sure nothing else gets allowed into the DMZ, I'm going to block anything else from entering the DMZ. So my next rule here will be to block DMZ access if the source is untrusted, the destination is DMG, and the action is deny. since it's a denied login session start.Okay, I'm officially denying everything else. So I'm allowing SSH to that server and nothing else. Let me go ahead and commit that rule and SSH into the firewall. Let me associate the firewall 172310 machine here. I'm going to go ahead and SSH into the firewall public IP address and load my keys. 9116-88, and I'm connected. If I show sessions, I will only see the SSH session. Here is an SSH session. And that SSH session is session 1763. shows session ID 1763. I'm looking here and see that the rule is "Dmzsh access the application that is identified as SSH." So I'm running on my Ubuntu server, and I'm running SSH on port 22 22.To run that, you basically edit this file, suodo sudi TCSs config, and you should basically add another port, port 22. So if I try to connect to port 22:22, I'm not going to be able to try this out. Load my keys and Uber to 52-9106, 88, 22 22.The reason for this is that the port is not a standard port. And my rule specified an application default, so it basically discarded that traffic. And if I go to the log here logDMZ axis, log viewer), I see here that 2222 is blocked even though this is SSH. So how to deal around that? So to deal with this, basically you need to remove the application default from your rule and specify the port specifically that SSH is running on. So if I go back to my policy here, and under that rule, instead of application default, I'm going to specify the actual service instead of service application default, I'm going to be specific and use the TCP port for both 22 and 22 22.So I'm not relying on application defaults anymore, even though I specified a different service port. The firewall is smart enough to know that this is SSH. So you have to have the two together, not just the service and the application, for you to have protection from running applications on a port that they are not intended to run on. So that's one of the main advantages of running the Palo Alto Firewall: the application visibility. So I'm going to go ahead and commit. And now I should be able toaccess if I look at the session. So I see the SSH session at 22 22.You can do "show session allmatch filter destination port 22 not on the application default port. So for example, SSH runs a standardport is port 22 is 22 TCP. In my AWS setup, I have a DMZ server that's Ubuntu, and that DMZ server. I'm running the SSH service. I want to offer it out to the public. I'm going to be running that on two ports, 22 and 22. The application default specifies service port TCP 22. So how do we get around that situation? So we'll see how to take care of that. I am going to set up a policy for my Ubuntu server running on the DMG. There is currently an ad configured for port 22 and port 22. And this is the destination net. And we look@the.net in a differentsection, but basically from untrust unrust. If I connect to my firewall IP addressport 22, it's going to destination added tothe Ubuntu server and also port 22 22. It's going to forward it to the Ubuntu server. To protect my DMZ, I'm going to create a rule that basically allows the application SSH and nothing else. So under the security policy, we'll go ahead and add a policy here with a rule that specifies Dmzshaccess, and under the source, we're going to be untrusting of the rules, looking at the security rules, the source PostNet zone, the destination PostNet, and the IP address PreNet. So we're going to get into this deeper in the Internet section. But to be specific on that rule, the destination PostNet is the DMZ, and the destination PreNet is the IP address of the firewall outside interface, which is why I want to allow application SSH and I'm going to basically use the application default port, which for SSH is TCP 22. And then I'm going to specify what action to allow. And then, just to make sure nothing else gets allowed into the DMZ, I'm going to block anything else from entering the DMZ. So my next rule here will be to block DMZ access if the source is untrusted, the destination is DMG, and the action is deny. since it's a denied login session. Okay, I'm doing an explicit denial for anything else. So I'm allowing SSH to that server and nothing else. Let me go ahead and commit that rule and SSH into the firewall. Let me associate the firewall 172310 machine here. I'm going to go ahead and SSH into the firewall public IP address and load my keys. 9116-88, and I'm connected. If I do show sessions, all I would see is the SSH session. Here is an SSH session. And that SSH session is session 1763. shows session ID 1763. I'm looking here and see that the rule is "Dmzsh access the application that is identified as SSH." So I'm running on my Ubuntu server, and I'm running SSH on port 22. And in order for you to run that, you basically edit this file, suodo sudi TCSs config, and you should basically add another port, port 22. So if I try to connect to port 22:22, I'm not going to be able to try this out. Load my keys and Uber to 52-9106, 88-2222. And the reason why is that port is not in the standard port. And my rule specified an application default, so it basically discarded that traffic. And if I go to the log here (logDMZ axis, log viewer), I see here that 2222 is blocked even though this is SSH. So how to deal around that? So to deal with this, basically you need to remove the application default from your rule and specify the port specifically that SSH is running on. So if I go back to my policy here, and under that rule, instead of application default, I'm going to specify the actual service instead of service application default, I'm going to be specific and use the TCP port for both 22 and 22. So I'm not relying on application defaults anymore, even though I specified a different service port. The firewall is smart enough to know that this is SSH. So you have to have the two together, not just the service and the application, for you to have protection from running applications on a port that they are not intended to run on. So that's one of the main advantages of running the Palo Alto Firewall: the application visibility. So I'm going to go ahead and commit. And now I should be able toaccess if I look at the session. So I see the SSH session at 22:22. You can do "show session allmatch filter destination port 22." There's no active session. Oh, I didn't change my port. Let me do this again. 22 are open. Okay, see, now it's connected. Let me do that show session.So if I look here, it's still identified the application as SSH, and I'm able to connect to it even though it's not running on the application default port, standardport, that is defined in the application SSH. If I do show the session ID, you would see that one of the main things to be aware of is that it's doing layer seven processing. And that basically means that it's analysing the traffic or threats, and it's identifying the application as SSH. So if you're running an application on a non-standard port, you need to be specific about the service port.

5. Application Override Policies - Custom Applications

In this lecture, we'll talk about application override. Application override is used for multiple purposes. It's used so you can identify applications that are specific to your environment. This way, you can create policies for those applications. So, for example, you might have a server running the SSH application, but this SSH application belongs to one of the business apps that you have. You might want to create a custom application and name this application in a way that you understand what it's actually for. And you can create policies specific for this application in your environment. And it can be used to identify specific characteristics for this custom application. Let's say you have a custom application that runs on port 80, and this application has a timeout that's greater than the timeout in the default policy. You can use application overrides to also deal with those types of issues. So in our lab environment and Amazon Web Services, I'm going to go back to the DMZ server running Ubuntu. I'm going to be running SSH on ports 22 and 23, and I'm going to be identifying this as a custom application. And I'm going to use "application override" to override this SSH, to use that as a definition for this custom application. So if I go here and go under object applications, I'm going to go ahead and create a custom app called Custom. I like to start the custom app with custom SSH 22 and 23. I'm going to give it the category, the specific category, the type of subcategory, the type of technology, and you can specify the parent app if you want to take some characteristics of the parent app. Or you can add your own characteristics here. So you can specify that it's capable of file transfer, excessive bandwidth use, and other characteristics used by malware evasive, pervasive), and you can check to continue scanning for other applications if you want under the advanced category. If you need to specify the port, you can do the port.If you don't specify the port, then it's going to rely on the application override to specify the port. So I'm going to not specify the port and choose none. You can check to make sure to scan this application for file types, to scan for files, to scan for viruses, and to scan for data patterns that are identified by a security profile. We also examine the security profiles and the various security profiles. If you don't check these, that means this application is not going to be inspected; it's not going to do any deep scanning for those applications at all. You can also specify different timeouts, default timeouts, and the actual firewall. If you choose session info on the firewall itself, you see a different timeout. So default TCP default timeout is3600 seconds, that's an hour. and the TCP session acknowledgement received, and so on. In such a situation, application override comes in handy. Also, if you have a custom application in your environment and it does, for example, have a slow timeout, that is higher. So for example, you have a custom application that basically sends traffic, then goes silent for a couple of hours, and then sends traffic again after a couple of hours. In this case, the session timeout will time out that session because it doesn't receive any traffic. If you want to increase that, you can increase this in your settings for the custom applications. In our case, we're showing this as an example to identify your custom app for the application override. Under signature, you can specify different signatures, and I'm going to show you guys examples of that to basically identify this application more specifically. So we're going to go in and click okay; that's the first step. The second step is to create an application override policy and tie in that application override to it. We're going to call this DMZSH port 22 or 23. We're going to specify a source as untrustworthy. I'm going to connect to it from the outside. So, following the same security rule, the source and destination zone or post-net source and destination IP is PreNet, as we'll see in the net lecture. So source and destination zones, and then PreNet IP destinations are 172-3125, 510, and 32, and then the protocol is going to be TCP 22/23, and the application is going to be the application that we created, which is custom SSH 22 23.Okay, I need to also create a net entry. So I'm going to duplicate this network to NAT port 22/23 when I clone it, and I'm going to specify 22/23 here and create a service port. So I'm going to add service TCP 22/3 and net it to the DMZ server as well. Now, for the security policy, I'll specify the following: SSH port 22; source is Entrust; destination is zone is DMZ; destination IP is the PreNet two-way 510; 32. And then application, I'll put the application custom, and another use for this is to move this above the block to put QoS policies for your applications to customer applications. So the application override helps you tie in the QS policies, which is going to be a different section we're going to have in this class. Go ahead and click "Submit" and commit. And then now I'm going to connect to it from outside the new session, load the key, and I'm connected. So now if I go to the session browser, monitor the session browser, and I can do a search on 22 and 23, I see here that it's identified as a custom SSH app, and we see the session is established. So this will allow you. The override will allow you to make your application visible inthe logs in a way that you can easily identify itand also allows you to down the road create Posies. Tie in user ID and restrict some users to this application, and do specific things that will be tied into the custom application you created for ease of visibility. and ease of security. Rules creation.

ExamCollection provides the complete prep materials in vce files format which include Palo Alto Networks PCNSE certification exam dumps, practice test questions and answers, video training course and study guide which help the exam candidates to pass the exams quickly. Fast updates to Palo Alto Networks PCNSE certification exam dumps, practice test questions and accurate answers vce verified by industry experts are taken from the latest pool of questions.