- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
02-24-2017 04:23 PM
hi All,
I am bit confuse of the usage of rule no 2 and 3. Eventually they will deny the traffic. But which two benefits are gained from having both rule 2 and rule 3 presents? Any clarification please.
A. A report can be created that identifies unclassified traffic on the network.
B. Different security profiles can be applied to traffic matching rules 2 and 3.
C. Rule 2 and 3 apply to traffic on different ports.
D. Separate Log Forwarding profiles can be applied to rules 2 and 3.
02-25-2017 04:28 AM
I'll go out on a limb and attempt an answer and hopefully someone will correct me if I'm wrong, so take this with a grain of salt:
A. A report can be created that identifies unclassified traffic on the network.
Based on the rules, an app is going to fall under either: Known Good, Known Bad or 'any' which would fall under being unclassified. For example, if Twitter is in neither of those two object groups, then it is unclassified and you can run a report showing that it was attempted to be accessed based on rule #3 being hit (or more simply, just apply a filter in the traffic log).
B. Different security profiles can be applied to traffic matching rules 2 and 3.
While this is technically true, security profiles are only processed if the policy action is allow, so they will have no effect here. (i.e., it would be a waste of resources to run threat prevention against a session that won't be allowed anyway).
C. Rule 2 and 3 apply to traffic on different ports.
As both apply to all ('any') ports, this would not make sense.
D. Separate Log Forwarding profiles can be applied to rules 2 and 3.
As with B, this is true as well. Only in this case, it will be applied, so you can choose where the results of either policy will be forwarded to.
Therefore my answer would be A & D.
02-25-2017 06:11 PM
Thanks a lot mate for the great explanation
@bradk14 wrote:I'll go out on a limb and attempt an answer and hopefully someone will correct me if I'm wrong, so take this with a grain of salt:
A. A report can be created that identifies unclassified traffic on the network.
Based on the rules, an app is going to fall under either: Known Good, Known Bad or 'any' which would fall under being unclassified. For example, if Twitter is in neither of those two object groups, then it is unclassified and you can run a report showing that it was attempted to be accessed based on rule #3 being hit (or more simply, just apply a filter in the traffic log).
B. Different security profiles can be applied to traffic matching rules 2 and 3.While this is technically true, security profiles are only processed if the policy action is allow, so they will have no effect here. (i.e., it would be a waste of resources to run threat prevention against a session that won't be allowed anyway).
C. Rule 2 and 3 apply to traffic on different ports.As both apply to all ('any') ports, this would not make sense.
D. Separate Log Forwarding profiles can be applied to rules 2 and 3.As with B, this is true as well. Only in this case, it will be applied, so you can choose where the results of either policy will be forwarded to.
Therefore my answer would be A & D.
Thanks a lot mate for the great explanation.
02-26-2017 06:15 AM
The setup you see here, is used for port to App-ID migration. Customer migrating from other firewalls, port based, to Palo Alto Networks, will typically be done with no policy changes as the first step. Then App-ID adoption is the next step.
Other customers start from scratch, building an App-ID based ruleset from day 1. Then the 3 policy lines you see will be used. The last rule you could call a "clean up rule". Everything that are to match that rule, are for you to move into one of the two above. Me personally would have moved the known bad to the top. When you've cleaned up things, after verifying for days or weeks, depends on you gut feeling, and when you see close to nothing in the last rule, you could just disable/delete the any rule. Then you've created a Application based White List ruleset. And that's what Palo Alto Networks is all about, bringing back the default action of the firewall, by doing what the intention of the firewall has always been, to control what you allow.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!