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.
Profile Mode
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.
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.
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.
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.
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.