How to remediate overly permissive any- any rule

[SaiTeja_1]

• We have an overly permissive rule with Source, destination and ports as Any. We are working to remove this rule but this  is widely used. Please suggest what's the best way to identify the traffic using this rule and to create rules with specific source, destination and ports.

[Brandon_Wertz]

---

@SaiTeja_1 wrote:

• We have an overly permissive rule with Source, destination and ports as Any. We are working to remove this rule but this  is widely used. Please suggest what's the best way to identify the traffic using this rule and to create rules with specific source, destination and ports.

---

The native UI won't give you exactly what you're looking for.  Native in the UI you can go to the rule, then the "Usage" tab then click on the "Compare Applications & Applications Seen

From here you can see the apps that have been seen/allowed on this rule.  You can then chose to add them to the rule.

If you're wanting to easily identify and allow/block source IP, destination IPs or destination ports/applications the native UI (GUI) doesn't have that feature.  To do that you will need to stand up a separate Palo Alto tool called expedition.  Expedition is kind of like a Panorama, it has a similar Palo Alto GUI, but can do what you're looking for.

Or you can purchase an entirely different tool such as FireMon or Tufin.  Both of these products are designed to do what you're looking to do.

[SaiTeja_1]

Hello Brandon,

We are not using Expedition/ FireMon/tufin etc in our lnfra. Is there any other way (Manual/ Automatic) to identify all the traffic hitting the rule using Palo Alto GUI through logs etc..

I really appreciate your suggestion on this.

[Brandon_Wertz]

---

@SaiTeja_1 wrote:

Hello Brandon,

We are not using Expedition/ FireMon/tufin etc in our lnfra. Is there any other way (Manual/ Automatic) to identify all the traffic hitting the rule using Palo Alto GUI through logs etc..

I really appreciate your suggestion on this.

---

Short of what was already described your only way would be to create a custom report of the traffic logs for the rule.  Dump that report into excel and do that for a month's worth of data probably and do the review manually.

[msenteza]

1. For a start, be sure that your overly permissive rule has "Log at Session End" checked/enabled in the "Actions" tab. This will let you see what traffic is flowing through your firewall in the "Monitor > Logs > Traffic" log. Its from here that you can identify what traffic should not be flowing through your firewall - and so write rules with "drop" action; and traffic that should be permitted - and so write rules with "allow" action.

If you have security feature licenses, such as the Advanced Threat Prevention, WildFire, etc, it's a good idea to apply relevant Security Profiles to your overly permissive rule. You can start with the inbuild "default" Security Profiles, then observe for matching threat traffic or false positives in the "Monitor " Logs > Threat" logs, and then tune appropriately.

2. For your new security rules, start with "application = any" plus the specific service/port observed in the traffic e.g. tcp = 443 (or the equivalent in-built "service-https"). Tighten with source/destination host(s) and/or subnet(s) so that you only allow what should be allowed.

3. Given time, once your new rule gets hits you can click on the number shown under the "Apps Seen" column for your rule, and it will display the apps that match that rule. Cross-check this with what's shown under the "Application" column for traffic that matches your rule in the "Monitor > Logs > Traffic" logs. You can then consider migrating that rule a from port/service-based rule to an App-ID based rule.

As you build more rules, make sure your more specific rules are further up the top from your less specific (more permissive) rules.

If you have multiple zones, I would recommend duplicating your overly permissive rule, creating one for each source zone, then edit the rule so that you have e.g. source zone = servers; and everything else = any; action = allow. That way you can identify traffic sourced from your "servers" security zone and write appropriate rules for traffic that needs to be allowed or dropped, above the more permissive "servers" rule.

Also, typically, if you have an internet-facing zone, you would want to start with dropping all traffic from the Internet, to any; and then write specific allow rules for traffic that you know needs to be permitted into your network from the Internet.

Migrating from an overly permissive rule will be a gradual change. The goal is to identify the traffic flowing through your firewall, and write specific rules to permit that traffic. These new more specific rules should be placed above your "permit any any" rule; and then eventually remove your overly permissive rule.