FortiGate Policy Mode vs Profile Mode

2023年8月12日 LOG admin

原文：FortiGate Policy Mode vs Profile Mode — theDXT (Daniel Keer)

By default all Fortinet FortiGates are in Profile-based NGFW mode. There is nothing wrong with the default mode. However, I personally prefer policy mode more.

Profile mode works like most firewalls like SonicWall, pfSense and UniFi for example. All your rules are based on ports.

Policy mode works like Palo Alto Networks firewalls. All your rules are only based on ports if you define them but where the real power comes in is application based rules.

To better show the differences here’s an example. I am using Central SNAT in profile mode to keep it as similar as possible to Policy mode.

The Setup

VLAN for the Guests network and the IoT network and they are on a tagged interface.
The Corp network is untagged on interface x1.
An object exists for the entire Guest LAN and the entire IoT LAN. I’ve colored them blue.
An object exists for the DHCP server on the Corp network. I’ve colored it green.
I will make a rule to allow the Guest and IoT network to talk to the DHCP server on the Corp network to get a DHCP address.

In profile mode I will build the Firewall Policy rule like this.

Name: Allow DHCP
Incoming Interface: Guests and IoT
Outgoing Interface: Corp
Source: Object for the Guest LAN and IoT LAN
Destination: Object for the DHCP server on the Corp LAN
Service: DHCP and DHCP6

Here is what that rule looks like.

Allow DHCP in Profile Mode

Those service objects are just ports. So effectively that rule allows anything from the Guests LAN and the IoT LAN to the Corp DHCP server if it uses the port for DHCP. That’s the part that I don’t like.

Explanation

There’s nothing stopping traffic from being allowed as long as the DHCP port is used. You can apply an Antivirus profile to the rule, but what if it’s a zero-day and your FortiGate doesn’t have that update yet, you could then technically be compromised from the Guest or IoT network as long as they used the port for DHCP and compromised your DHCP server and pivot from there.

While this is a very extreme situation it could happen, so why leave the risk?

FortiGate has Application Control but that isn’t perfect for all situations. For example if you have a network for servers and a network for users and you need to deploy User or Device certificates from a your internal CA via GPO or deploy a printer from a print server via GPO then you’d need to allow RPC. RPC is dynamic and this is exactly where the limitation of building rules based on ports starts to show it’s face.

You can build an application control for just RPC, but doing it that way forces you to make an application control for everything you want to allow, you would also need to set the service to all or allow the entire dynamic range that RPC uses. I don’t like that.

The Port-Matching Problem in Practice

The DHCP example looks small, but the same pattern repeats anywhere a protocol needs a dynamic or a very broad port range. Three cases turn up in almost every FortiGate deployment:

RPC and Group Policy — deploying user or device certificates from an internal CA via GPO, or pushing a printer from a print server via GPO, requires RPC. RPC negotiates dynamic ports (by default 49152–65535 in modern Windows, and the EPM endpoint mapper on TCP 135) plus SMB on 445. In profile mode the only options are to open the endpoint mapper and the whole dynamic range, or to open everything, and then hope that no attacker ever speaks RPC.
FTP and SIP — the control channel is on a well-known port, but the data channel and the media sessions are allocated dynamically. A port-based rule ends up permitting the whole dynamic range for those hosts.
Database and management protocols — a database listener on a non-standard port, or a web application on 8443, forces you to enumerate ports forever, and every new service means a new change request.

In every one of those cases a port-based rule is not really “allow RPC” — it is “allow anything that happens to arrive on a port in this range”. That is a much weaker statement than the rule name suggests, and it is the reason policy mode exists.

There has to be a better way. There is, it’s called policy mode.

Policy Mode

I will build the same DHCP rule as a Security Policy rule like this.

Name: Allow DHCP
Incoming Interface: Guests and IoT
Outgoing Interface: Corp
Source: Objects for the Guest LAN and IoT LAN
Destination: Object for the DHCP server on the Corp LAN
Service: App Default
Application: DHCP and DHCPv6

Here is what that rule looks like.

Allow DHCP in Policy Mode

By using policy mode the FortiGate can detect what the application is and only allow it if it is using the default ports for that application. My Favorite part of this is you don’t have to build multiple application controls, you can just do it in the rule itself and you don’t need to make service objects for the port ranges of anything that uses dynamic ports.

By using Policy mode you now have a rule that is much more locked down and is much harder for a zero-day to get past it. Because now the zero-day now needs to use the port for DHCP and spoof that it is the DHCP application.

What Changes Inside the Rule

The difference between the two modes is a difference in what the rule matches on, so it shows up in the fields you fill in:

Field	Profile mode (firewall policy)	Policy mode (security policy)
Match criteria	Source, destination, service (port)	Source, destination, application, URL category, user
Service	Port objects such as DHCP, RPC, ALL	App Default (the application determines its own ports)
Application object	Optional, via an Application Control profile	Required, selected directly in the rule
Security profiles	Attached to the policy	Attached to the policy as well
NAT	Policy NAT or Central NAT	Central NAT only

Selecting App Default as the service is the detail people stumble on. It does not mean “any port”: it tells the FortiGate to use the ports that the selected application normally uses, and to enforce that the traffic actually matches the application signature rather than merely arriving on the right port. If you select an application and set the service to ALL, you have thrown away most of the benefit of policy mode.

Security Profiles Still Exist in Policy Mode

An understandable misconception is that policy mode replaces antivirus, IPS, web filtering or SSL inspection. It does not. Those profiles still exist and are still attached to the rule; the rule simply gains application and URL-category awareness as matching criteria, and application control stops being a profile you remember to attach and becomes part of how the rule matches. Practical consequences:

You still need a deep inspection or SSL inspection profile for the FortiGate to see inside encrypted traffic. Without it, an application running over TLS 1.3 will be identified only as TLS or as the SNI, and the rule will fall back to whatever your unknown-application handling is.
You still need IPS for vulnerability detection and antivirus for file scanning. Application recognition is not a substitute for either of them.
Application control profiles can still be used in profile mode. Policy mode does not remove them, it just makes them implicit in the policy rule.

Where Application Recognition Falls Short

Policy mode is not magic, and pretending otherwise is how people end up with an outage. Three limitations matter operationally:

Unknown applications — a custom internal application, a home-grown protocol or a brand-new release of a known application may not be recognised yet. Decide up front whether unknown-application traffic is allowed, blocked or only logged; in a strict policy-mode design the usual answer is to block it and to open a ticket for the signature update.
Non-standard ports — an application moved to a non-standard port is still recognised by its signature, which is the whole point, but if it is also heavily obfuscated or encrypted without inspection, recognition can fail.
Custom applications — for internal protocols you can define the application manually, but the definition has to be maintained as the protocol evolves.

Operational Differences You Only Notice After the Change

Central NAT is mandatory. In profile mode SNAT can sit inside the policy as destination address translation. In policy mode the SNAT decision moves into a central SNAT map that is evaluated before the policy, so a mis-ordered central SNAT rule affects every policy behind it.
Explicit objects are the norm. Policy mode rewards a disciplined address-object model. Using “all” as source or destination defeats the purpose and makes the rulebase hard to audit.
Logs get more useful and more verbose. Log entries now name the application and the URL category, which is excellent for auditing but produces far more entries than a port-based rulebase.
Rule ordering matters more. Because rules are read top-down and the first match wins, a broad “allow popular applications” rule near the top will silently shadow the specific rules below it.

Which Mode Should You Choose

Choose profile mode if your rulebase is organised around network segments and ports, if you need policy NAT inside the rule, or if you are managing many devices with a well-established port-based template.
Choose policy mode if your security policy is written in terms of applications and users, if you need an explicit allow-list to satisfy an auditor, or if dynamic-port protocols such as RPC are a large part of your traffic.
In both cases the decision should be driven by how you want the rulebase to read three years from now, not by which one is faster to configure today.

Verifying the Result

Once the rules are in place, verify them by watching a real session, not by reading the policy list:

diagnose debug flow filter addr 10.10.20.50
diagnose debug flow show function-name enable
diagnose debug enable
diagnose debug flow trace start 20

# then check the resulting sessions
diagnose sys session filter dst 10.10.30.10
diagnose sys session list

The debug flow output prints, for each packet, the rule that matched and the application that was recognised. That is the fastest way to prove that a policy-mode rule is matching on the application and not merely on the port. Remember to run diagnose debug disable afterwards — leaving flow debugging on is a classic way to hammer the CPU on a busy gate.

Common Pitfalls When Moving to Policy Mode

Expecting the mode change to convert existing rules. It does not: objects and interfaces survive, the rulebase does not, and the FortiGate warns you about exactly that before applying the change.
Forgetting that Central NAT becomes mandatory, so the first thing to build after the change is the SNAT map.
Leaving a rule with service ALL and an application selected, which keeps the port-based hole open.
Not planning for encrypted traffic: without SSL inspection, a policy-mode design that depends on application recognition will silently degrade to allow-or-block-on-SNI.
Rebuilding rules one-for-one instead of rebuilding the intent. A one-to-one translation of a permissive port rule usually produces an even more permissive application rule.

Summary

I feel like you reduce the attack surface a lot more by using policy mode but I also think all in it comes down to personal preference and/or what makes the most sense in the setup.

If you want to make the switch to Policy mode here’s how to enable Policy Mode.

If you want to read more about policy mode you can do so by reading Fortinet’s documentation here.