Understanding and building security rules

We now need to build some security rules to allow or deny traffic in and out of the network. The default rules will only allow intrazone traffic and will block everything else, as you can see here:

Figure 3.23 – Default security rules

We will first make sure "bad" traffic is dropped by creating two new rules—one for inbound and one for outbound traffic.

Dropping "bad" traffic

The inbound rule will have the external zone as a source and the three External Dynamic Lists (EDLs) containing known malicious addresses. These lists are updated via the threat prevention dynamic updates. The Source tab should look similar to the following:

Figure 3.24 – Reconfigured external dynamic lists

In the Destination tab, set the destination zones to both the external zone and any zone where you intend to host internal servers that you will allow inbound NAT to (for example, corporate mail or web servers) and set the destination addresses to Any, as in the following screenshot:

Figure: 3.25 – Security rule destination zones

In the Actions tab, set the action to Drop. This will silently discard any inbound packets:

Figure 3.26 – Security rule actions

Follow the next steps to create this rule:

1. Create a new security rule and give it a descriptive name.
2. Set the source zone to any zone that is connected to the internet (for example, Untrust).
3. Set the source addresses to the three predefined EDLs.
4. Set the destination zones to your internal zones that will accept inbound connections from the internet (for example, DMZ), also including the external zones.
5. Set the action to Drop.

   Important note

   You may have noticed that the Profile Setting fields and Log Forwarding are filled out with the default profiles that you created in the previous step. In all rules where sessions are blocked, content scanning will not take place, so having these profiles will not cause overhead.

Click OK, and then make the reverse rule, as in the following screenshot, setting the source zones to your internal zones, the destination to the external zone, and the predefined EDL as addresses. If you changed the DNS sinkhole IP address to one of your choosing, add this IP here as well:

Figure 3.27 – Outbound drop rules

Follow these steps to create the above rule:

1. Create a new security rule and give it a descriptive name.
2. Set the source zone to your internal zones.
3. Set the destination zone to any zone leading out to the internet (for example, Untrust).
4. Set three destination addresses and for each one, select one of the predefined EDLs.
5. Set Action to Drop.

A good practice is to add some catch all rules to the end of your rule base, as in the following screenshot, once all the required policies have been added to any catch connections that are not allowed. One catch all rule should be set to application-default and one to any; this will help identify standard applications that are not hitting a security policy and (more suspicious) non-standard applications that are not using a normal port (see the Allowing applications section to learn about the application-default service):

Figure 3.28 – The catch all rules at the end of the rule base

You now have some rules actively dropping connections you do not want to get past the firewall, but there are more options available than to just silently discard packets. We'll review the other options next.

Action options

There are multiple actions that handle inbound connections, some of which are stealthy and some of which are noisy and informative, depending on your needs:

• Deny: This action will drop the session and enforce the default Deny action associated with an application. Some applications may silently drop while others send an RST packet.
• Allow: This allows the session to go through.
• Drop: This silently discards packets.
• Reset Client: This sends a TCP RST to the client.
• Reset Server: This sends a TCP RST to the server.
• Reset Both: This sends a TCP RST to both the client and the server.

If you check the Send ICMP Unreachable checkbox and the ingress interface is Layer 3, an ICMP Unreachable packet is sent to the client for all of the dropped TCP or UDP sessions.

Allowing applications

There are generally two approaches to determining which applications you want to allow:

• Creating a group of known applications
• Creating an application filter to sort applications by their behavior

From Objects | Application Groups, you can create groups of known applications that can be used in security policies, as shown:

Important note

The security rule base is evaluated from top to bottom and the evaluation is stopped once a match is found, then the matching security rule is enforced. This means blocking rules need to be placed above the allowing rule if there could be an overlap.

Figure 3.29 – Application Group

With the widespread adoption of cloud-based hosting and cheap SaaS solutions, more traditional programs are turning into web-based applications that are accessible over a web browser. This makes it harder for an administrator to easily determine which applications need to be allowed as the needs of the business change quickly. Application filters created in Objects | Application Filters let you create a dynamic application group that adds applications by their attributes, rather than adding them one by one. These attributes can be selected for both "good" properties to be added to allow rules (as you can see in the following screenshot) or "bad" properties to drop rules:

Figure 3.30 – Application Filter with basic attributes

Alternatively, the filter can be based on the predefined and custom tags assigned to applications, as follows:

Figure 3.31 – Application Filter with tags

You can mix and match application groups and filters to build further security rules by adding them to the APPLICATIONS tab, as you can see here:

Figure: 3.32 – The APPLICATIONS tab

To create a new Allow rule using an application filter, do the following:

1. Create a new security rule and add a descriptive name.
2. Set the source zone to the internal zones that will connect to the internet.
3. Set the destination zone to external zone.
4. In APPLICATIONS, add a new line and select Application Filter.
5. Click on all of the desired attributes and review some of the applications at the bottom. Add a descriptive name and click OK on the filter, and again on the security rule.

You now have an allow rule based on an application filter!

Application dependencies

As you may have noticed in the previous screenshot, when you start adding applications to a security rule, there may be applications that have dependencies. These applications rely on an underlying protocol or build on an existing more basic application that needs to be added and allowed in the security rule base for this sub-application to work. They do not necessarily need to be added to the same security policy.

Starting from PAN-OS 9.1, these dependencies are displayed in the security rule. As you can see in the following screenshot, they appear when you are adding new applications and can immediately be added to the same security rule or to a different one in the security rule base. In older PAN-OS versions, users will only be warned about these dependencies once the configuration is committed. You can review application dependencies for individual applications via Objects | APPLICATIONS, too:

Figure: 3.33 – Application dependencies

Now that the applications have been set, let's look at how service ports are controlled.

Application-default versus manual service ports

Each application will use a certain service port to establish a connection. By default, each service is set to application-default, which forces each application to use its default ports (for example, web-browsing uses ports 80 (unsecured) and 443 (SSL) secured, FTP uses ports 21 (unsecured plaintext) and 990 (secured), and so on).

Important note

Protocols that use pinholing, such as FTP, are automatically taken care of via the Application Layer Gateway (ALG), which is a part of the content decoder that is specific to this protocol.

If an application needs a custom port, you can add a manual service object, but this would prevent the use of application-default. So, any exceptions should preferably be made in individual rules to prevent applications from "escaping" via an unusual port:

Figure 3.34 – Service ports

Adding a URL category can be used to allow or block URL categories at the TCP layer. For drop or deny actions, this will mean that the session is dropped, rather than returning a friendly blocked page to the user.

Controlling logging and schedules

By default, each security rule is set to Log at Session End. This means that a log is only written to the traffic log once a session is broken down. For some sessions, it may be interesting to log more interactions, and so Log at Session Start could be enabled. This does cause quite a lot of overhead, however, as there will be a log for each new stage of a session when the SYN packet is received and for every application switch. So, there could be two to five additional log entries for a single session.

Other applications that are very chatty or less relevant may not need to be logged at all, such as DNS.

Important note

Even with both start or end log disabled in the security rule action tab, any threats detected in a session will still be logged to the threat log.

Log forwarding can be used to forward logs to Panorama or a syslog server or to send out an email. As you can see in the following screenshot, if you call one of the log forwarding profiles default, it will be used in all the new rules, so logs are automatically forwarded:

Figure 3.35 – Log options and schedules

Schedule can be used to create timeframes when this security rule will be active if certain applications are only allowed at specific times of the day (for example, Facebook can be allowed during lunch and after hours):

Figure 3.36 – Schedules

Before you continue putting this new knowledge to work and start creating more rules, let's review how you can prepare address objects.

Address objects

To make managing destinations in your security and NAT policy a little easier, you can create address objects by going to Objects | Addresses. When you create a new object here, you can reuse the same object in different rules, and if something changes, you only need to change the address object for all the security and NAT rules to be automatically updated:

1. Click on Add and provide a descriptive name for the address. It is good practice to set up a naming convention so that you can repeat this process for all other address objects. A good example is to prefix all server names with S_ and all networks with N_ so that they're easily identifiable.
2. Set a description if needed.
3. Select the type of object that this will be.

   --IP Netmask lets you set an IP with a subnet mask down to /32 or /64 for a single IPv4 or Ipv6 address (no need to add /32).

   --IP Range lets you define a range that includes all the IP addresses between the first and last IP set in the range, separated with a dash (-).

   --IP Wildcard Mask lets you set a subnet masking that covers binary matches, where a zero bit requires an exact match in the IP bit, and 1 is a wildcard. So, for example, a wildcard subnet of 0.0.0.254 translates to 000000000.0000000.0000000.11111110. the first three bytes are set and in the last byte, all but the first bit are wildcards. This means that if the associated IP address is set to 10.0.0.2 (00001010.0000000.000000.00000010), all of the IPs in the subnet that end in 0 will be matched (that is, all of the even IP addresses). If the IP is set to 10.0.0.1, all of the odd IPs would match. This type of object can only be used in security rules.

   --FQDN lets you set a domain name that the firewall will periodically resolve according to the Time To Live (TTL) and cache. Up to 10 A or AAAA records are supported for each FQDN object. Use the Resolve link to verify that the domain can be resolved.

4. Add a tag to easily identify and filter policies for this object.
5. Click OK.

Once you have sets of objects that are similar, you can also create groups by going to Objects | Address Groups. These groups can be used to bundle objects for use in security or other policies.

Tags

Tags can be leveraged to group, filter, or easily identify many other objects. Security zones, policy rules, or address objects can all be tagged with up to 64 tags per object. By going to Objects | Tags, you can create new tags:

1. Click on Add and create a descriptive and preferably short name for the tag (up to 127 characters). You can also use the dropdown to select one of the already-created security zones, which will cause the tags to be automatically assigned to this zone.
2. Select a color or leave it as None.
3. Add a comment.
4. Click OK.

As you can see in the following screenshot, tags can then be used to visually enhance your rule base or to filter for specific types of rules:

Figure: 3.37 – Tags in the security policy

Important note

While building security rules, objects (such as addresses, applications, services, and so on) can be clicked and dragged from the object browser on the left into any rule, and from one rule to another. There is no need to open a rule and navigate to the appropriate tab to add objects.

While you're on the Security policy tab, there's a tool called Policy Optimizer on the bottom left-hand side that can help improve your security rules by keeping track of rule usage.

Policy Optimizer

After a while, you will want to review the security rule base you've built to make sure you haven't missed any applications, left rules too open, or have any duplicates that leave rules unused. Policy Optimizer records statistics relating to your rules and can report the following:

• Rules that have been unused for 30 days, 90 days, or for all time so that you can delete them
• Rules that are set up with no applications defined and the applications that were accepted by those rules
• Rules that have applications that are not being used so that you can remove these excess applications

Now that you are able to build a complete security rule base, there may need to be Network Address Translation for sessions coming in from the internet.