IT Knowledgebase
< All Topics
Print

Tips to Create a Firewall Policy. ( Fortigate )

Firewall Policies: The Basics

A firewall acts as a filter between your network and the outside world by scanning all network traffic and deciding what is allowed in or out. Firewalls are a well-known part of network security and in the last few years most operating systems include one as part of the system. Personal computer firewalls are usually fairly straightforward, as you can pretty much turn it on and let it do its thing.

Things get a bit complicated when a single box, like a FortiGate, is used to manage multiple network devices, especially if you want to restrict some traffic sources while allowing others. This is where firewall policies, also called security policies, come into play on your FortiGate.

The FortiGate Firewall

A FortiGate firewall operate on the basic idea that only traffic that is expressly permitted is allowed to come in and out of the network. That’s why all FortiGates start out with a default deny policy that cannot be deleted, which is used as a catch-all for traffic that is not specifically set up as allowed. Most FortiGates also have a default policy that allows traffic from the LAN to the Internet.

These two policies do allow basic access for your network, but for a more complex network you’ll need to know how to put together more specific policies.

Putting the Pieces Together

To make a firewall policy, go to Policy > Policy > Policy and select Create New.

At the top of the page, you’ll see several different types of policies. We’ll look at a few more of these policy types later. For now, let’s concentrate on how to make a basic firewall policy that is based on IP addresses, which is the default policy type.

To help you understand what each part of policy does, we’ll create an example policy that allows all devices on the local area network to have Internet access, but only using HTTP, HTTPS, and DNS, and only during regular workdays.

The Who, What, Where, and How of Firewall Policies

The first part of the policy’s configuration is setting a few important fields. These fields act as filters to make sure the policy handles only the intended traffic.

  • Incoming interface: FortiGate interfaces can be seen as one side of a bridge between two networks and each interface has its own MAC address and internal IP address. The incoming interface is either a single physical port or a switch, containing multiple ports, that listens for incoming traffic. In our example, this would be the default LAN or internal interface (the name differs depending on which FortiGate model you have).
  • Source address: This field sets which IP addresses traffic are allowed to send traffic through this policy. Addresses in this field must be predefined firewall objects. They can be specific IP addresses, ranges, subnets, Fully Qualified Domain Names (FQDNs) or geographical locations (countries). Firewall address can be created by going to Firewall Objects > Address > Addresses. In our example, this will be the range of addresses on the network’s subnet. You could also select the option all, but using a firewall address is the best practice, as it ensures that only traffic from your subnet is allowed.
  • Outgoing interface: This field determines the interface that the traffic for this policy is being sent out on. In our example, this will be WAN1, which is typically the interface used to connect to the Internet.
  • Destination address: This field controls the IP addresses that can be reached by traffic using this policy. In our example, this will be all, which will allow access to all websites on the Internet.
  • Schedule: This field deals with when traffic is allowed to use this policy. For our example, we’ll use a custom schedule that allows traffic on Monday, Tuesday, Wednesday, Thursday, and Friday, between 9AM and 5PM. Custom schedules can be created by going to Firewall Objects >Schedule > Schedules.
  • Service: This field controls the protocols which can be used, such as HTTP, FTP, and SIP. In the example, we’ll select HTTP, HTTPS, and DNS. It is important to remember to allow the DNS protocol since, as we saw last time, it is required for your computer to find websites.

To keep track of what you’ve learned so far, here’s a quick “cheat sheet” you can use:

Finally, make sure that the action is set to ACCEPT, which allows traffic to flow through the policy.

You can use the DENY option if there is traffic you want to prevent from getting through the firewall. For example, if you have identified the IP address of an attacker, you can drop any traffic from that IP.

If you are planning to create a number of firewall policies, you should know how the FortiGate matches traffic to a firewall policy. The FortiGate starts at the top of the policy list and works its way through each of the policies until it finds one that matches all six of the mentioned fields. When you are creating a policy, you need to keep in mind the policies that will come before and after it. For example, make sure that you don’t have one policy accepting traffic at the top that a different policy is meant to block.

You’ll find more information about ordering policies below.

Address Translation

You will want to enable Network Address Translation (NAT) in a number of scenarios. These may include:

  • You want to hide the addresses of your internal network from the Internet.
  • You have fewer public IP addresses than devices that need to use them.
  • You have two subnets that need to communicate that share an IP address range.

Using NAT allows your FortiGate to use a single public IP to represent enables a significantly larger number of private addresses.

Logging Options

Choosing a logging option is also part of the firewall policy. In most cases, just logging security events is sufficient, in order to avoid dedicating too much memory to logging.

Security Profiles

Finally, security profiles and sensors are selected for the policy’s traffic; however, we’ll save talking about these features until we get to the layer of the network that they are involved with.

Ordering Policies

Once you’ve created your firewall policy, the final step before you can start using it is to make sure that the correct policy is used for all traffic that goes in or out of your FortiGate. When ordering policies, it is best to do the following:

  • Custom DENY policies should be placed first so there is no chance that matching traffic will get through.
  • VPN and other user identity-specific policies should be before policies that are not identity-specific.
  • For all other policies, keep the more specific policies before general policies, so that traffic matching the specific policy is not accepted by the general one accidentally.

As mentioned before, the FortiGate starts at the top of the policy list and works its way through each of the policies until it finds the best match. By properly ordering your policies, you can make sure that every policy is being used as you intend it to be.

Firewall Policies: How to Build a Better Policy

As networks become more advanced, so do the demands placed upon your firewall. As such, it is equally important to know how to make a firewall policy work, and to make it work well.

Improve Your Design

Just because a firewall policy works doesn’t mean that it’s design is perfect. Since firewalls play such a key role in keeping your network secure, it’s important to ensure that there are no holes in the configuration. Keeping that in mind, here are a couple of best practices that could help you, both with new policies as well as any older policies you may have kicking around:

  • When you create a new policy, start with the basics (as discussed above) ensuring that the policy works before adding the more complicated parts, like security features. While it may take more time to configure, starting with the basics makes it easier to pinpoint any problems that occur down the line, as it less likely you will encounter multiple issues at the same time.
  • Avoid using the “ANY” setting as a service. Instead, only allow the services that your network users will require. Be sure to always allow DNS for any Internet access policy.
  • Likewise, avoid using the default “all” setting for source addresses, unless you are creating a policy for incoming requests from the Internet. Instead, create a firewall address (a type of firewall object) that matches the addresses that are allowed to send traffic.
  • When creating firewall addresses or other objects, give them a specific name that helps to identify the object in the future. For policies, use the Comment field to for the same purpose. This will make it easier to tell, at a glance, the purpose of each policy.
  • When creating a policy that has user authentication, select a user group in the policy instead of a specific user account, so that if a new user is added to the group they will automatically be included in the policy without having to edit the policy directly.
  • For the same reason, groups should also be used for firewall addresses, virtual IPs, and services if more than one is used in the policy.
  • Only use logging as necessary – it is usually recommended to just log security events and use FortiCloud to store your logs. If you have to troubleshoot issues later, you can easily increase logging temporarily until the problem is found.

Policy Housekeeping

It’s very common for policies to be added as a network evolves; it is less common for policies to be removed as they become unused or irrelevant.

If you are using numerous firewall policies, ensure that you don’t have older policies kicking around that aren’t in use. Not only could they cause unintended issues with valid traffic, they could also potentially become security vulnerabilities. It’s easy to clear unnecessary policies if you’ve followed the best practices listed above, since you’ll be able to see, at a glance, the purpose of each policy. However, even if you haven’t, there are still a few things you can do to make it easier to decide if a policy should stay or go.

Before you delete any policies or make any major changes, create a backup of your current FortiGate configuration. Store and label the configuration in such a way that you can find it again easily if needed.

1) Use the Section view in the policy list to show which policies have the same source and destination interface. If two interfaces have a large number of policies connecting them, there is a good chance that some are no longer necessary. If you have a FortiManager, you can use its Policy Check feature to look for duplicate policies, duplicate objects, or partially overlapping/shadowed policies, which are all candidates for deletion.

2) Examine any policies that aren’t currently processing traffic to determine if they are still in use. You can do this a number of ways. In the policy list, you can use the Sessions column to show any active sessions that are currently being processed, and you can use the Count column to show you the total amount of traffic that hit this policy since the last reboot. You can also use the historical traffic logs to see when the policy was last used, or if it has ever been used at all.

3) Look at any policies located at the bottom of the list. A FortiGate starts at the top of the policy list and works its way through each of the policies until it finds the best match for the incoming traffic. Because of this, any policies at the bottom of a long policy list are less likely to be handling traffic than those at the top.

4) Test the policies you want to keep by generating some traffic and verifying in the logs that the intended policy processed that traffic. Just because traffic reaches its destination doesn’t mean it gets there using the intended policy.

Other Tips

  • When you upgrade your firmware from a previous version, read the Release Notes for the new version to find out if the policy process has changed. If there are changes (as with upgrades to the newly released FortiOS 5.2), be sure to review your policies to make sure they will still work as intended.
  • Remember that users are unlikely to complain when they are getting more access than they should, but will definitely let you know when they are getting less access than they should.
  • A simple solution is better than having a bunch of pieces cobbled together, even if the end result is the same. Take the extra time and effort to find these solutions, as they can simplify your configuration, saving you potential headaches in the future.