Fortinet FortiGate Firewall Policies Best Practices

FortiGate Firewall Policies

Fortinet FortiGate firewalls are powerful network security devices, but without well-designed policies, your network remains vulnerable. Implementing firewall policies correctly enhances security, optimizes performance, and ensures compliance. This guide covers best practices for designing, implementing, and managing FortiGate firewall policies effectively.

Fortigate Firewall Policies Design

Rule 1: Place Specific Deny Policies Above General Allow Rules

When configuring firewall policies on a FortiGate firewall, the order of rules is critical. FortiGate processes firewall policies from top to bottom in a sequential manner. If a general allow rule is placed before a more specific deny rule, unwanted traffic might pass through before the firewall reaches the deny policy. To prevent this, you should always place specific deny rules above general allow rules.

Remember that only the first matching policy is applied and because of that arranging policy in the correct position is very important! If you move policies in the policy list, the policy ID remains the same.

Why Is Rule Order Important?

The FortiGate firewall evaluates policies in a sequential manner, stopping at the first match. If a broad allow rule is placed before a specific deny rule, the firewall will process the allow rule first, letting through traffic that should have been denied.

Example of Incorrect Rule Order (Security Risk)

Policy ID	Policy Name	Source	Destination	Action
10	Allow_All_Users	LAN	Internet	Allow
20	Deny_Suspicious_IP	Suspicious_IP	Any	Deny

Problem: Since the “Allow_All_Users” policy is evaluated first, even traffic from the Suspicious_IP will be allowed before reaching the deny rule.

Correct Rule Placement: Specific Deny Above General Allow

To ensure security policies work as intended, place specific deny rules first.

✅ Example of Correct Rule Order

Policy ID	Policy Name	Source	Destination	Action
10	Deny_Suspicious_IP	Suspicious_IP	Any	Deny
20	Allow_All_Users	LAN	Internet	Allow

✅ Result: The firewall first blocks suspicious traffic, then allows general traffic.

If you need to block specific traffic (e.g., countries, IPs, or services), place deny rules before the general allow rules.
Example: Block SSH access from the internet before allowing internal SSH connections.

config firewall policy
    edit 10
        set name "Block_SSH_Internet"
        set srcintf "wan1"
        set dstintf "internal"
        set srcaddr "all"
        set dstaddr "all"
        set action deny
        set service "SSH"
        set schedule "always"
    next
end

Rule 2: Implicit Deny Policy (Default)

The Implicit Deny Policy is a fundamental security principle in FortiGate firewalls and most network security devices. It ensures that any traffic not explicitly allowed is automatically blocked. This rule minimizes risk by preventing accidental exposure of services, reducing attack surfaces, and enforcing strict access control.

FortiGate has a default implicit deny rule at the bottom of the policy list. Any traffic that is not explicitly allowed gets blocked.
You don’t need to manually create a final deny all policy unless you want to log the denied traffic.

Why the Implicit Deny Policy Is Crucial

Prevents Unauthorized Access
- If a policy is missing or misconfigured, implicit deny blocks the traffic by default.
- No traffic is allowed unless explicitly permitted, ensuring a secure baseline.
Minimizes Misconfiguration Risks
- Administrators might forget to remove old rules, leading to open access.
- Without an implicit deny, unintentional traffic might flow unchecked.
Stops Unwanted Traffic by Default
- Traffic from unknown sources or untrusted networks is automatically denied.
- No need to manually configure a catch-all deny rule at the bottom of the policy list.
Enhances Network Security
- Blocks unauthorized inbound or outbound connections by default.
- Helps protect against zero-day threats and unpatched vulnerabilities.

config firewall policy
    edit 99
        set name "Explicit_Deny_All"
        set srcintf "any"
        set dstintf "any"
        set srcaddr "all"
        set dstaddr "all"
        set action deny
        set schedule "always"
        set logtraffic all
    next
end

Rule 3: Deny Policies for Specific Threats

A deny policy is one of the most effective ways to protect a network from malicious activity. By proactively blocking specific threats, FortiGate firewalls prevent unauthorized access, malware propagation, and data breaches. However, deny policies must be well-planned to ensure they don’t disrupt legitimate traffic.

Best Practices for Deny Policies

Block Known Malicious IPs and Threat Sources

Attackers often reuse IP addresses, domains, and networks for their operations. FortiGate firewalls can blocklists known malicious sources using Threat Intelligence Feeds.

Restrict Traffic to Specific Countries

Cyberattacks often originate from specific regions. If your organization does not need to communicate with certain countries, geo-blocking can enhance security.

✅ Example: Block Traffic from High-Risk Countries

Place Geo-IP blocking, malicious IP blocks, or service restrictions before general allow rules.
Example: Block traffic from specific country (in my case China) before processing other rules.

config firewall address
    edit "Blocked_Countries"
        set type geography
        set country "CN"
    next
end

config firewall policy
    edit 15
        set name "Block_Countries"
        set srcintf "wan1"
        set dstintf "internal"
        set srcaddr "Blocked_Countries"
        set dstaddr "all"
        set action deny
    next
end

Block Unnecessary and Risky Services

Certain protocols are commonly exploited for attacks. If they are not required in your environment, it’s best to deny them.

Risky Services to Block:

Telnet (TCP 23): Unencrypted remote access, vulnerable to credential theft.
SMBv1 (TCP 445): Used by ransomware like WannaCry.
FTP (TCP 21): Often targeted for credential brute-force attacks.
RDP (TCP 3389): Commonly exploited for remote access attacks.

Where to Place Deny Policies?

Deny policies should be placed strategically to avoid performance issues and ensure security:

At the top of the policy list (for well-defined threats, like specific malicious IPs).
Before any “Allow All” or default rules to prevent unauthorized access.
At the end of policy rules as a “catch-all” to drop any unwanted traffic.

Policy ID	Policy Name	Action
10	Deny_Malicious_IPs	Deny
20	Deny_HighRisk_Countries	Deny
30	Allow_Web_Traffic	Allow
40	Allow_VPN_Access	Allow
50	Deny_All_Other_Traffic	Deny

Rule 4: Use a Clear Naming Convention

A well-structured naming convention makes it easier to understand, manage, and troubleshoot firewall policies. Without proper naming, administrators can waste time trying to identify rules, leading to configuration errors, security risks, and unnecessary complexity.

Why a Clear Naming Convention Matters?

Easier troubleshooting: Quickly identify policies related to specific traffic flows.
Simplified policy auditing: Helps in security reviews and compliance checks.
Consistent management: Avoids confusion between administrators in large environments.
Reduced risk of misconfiguration: Prevents mistakes like applying the wrong rule to critical traffic.

Best Practices for Firewall Policy Naming

Name Policies Based on Function

Each firewall policy should clearly describe its purpose. Use a structured format like:
<Source>_<Destination>_<Action>_<Service>

✅ Example of Good Naming Conventions:

LAN_to_WAN_Allow_HTTP -> Allows HTTP from LAN to the Internet
DMZ_to_LAN_Allow_SQL -> Allows SQL traffic from DMZ to LAN
VPN_to_Internal_Deny_All -> Blocks all VPN users from accessing internal resources
External_to_DMZ_Allow_Web -> Allows external traffic to reach the web server in the DMZ

Bad Naming Examples:

Rule1 → Meaningless and hard to understand.
Test123 → Indicates an incomplete or temporary rule, which might never be removed.
Policy_A → Lacks details about the function.

Use Prefixes for Easier Identification

Using consistent prefixes helps categorize rules and makes searches easier in large rule sets.

Prefix	Usage	Example
SEC_	Security-related policies	SEC_Block_Malicious_IPs
DMZ_	DMZ traffic policies	`DMZ_Web_Access`
VPN_	VPN-related rules	`VPN_to_LAN_Allow`
MGT_	Management access policies	`MGT_SSH_Admins`

Avoid Using Spaces and Special Characters

Use underscores (_) instead of spaces.Avoid special characters (/, @, #, -, etc.)` as they may cause issues in automation or scripts.Keep names concise yet informative.

Use Consistent Capitalization

Stick to either camel case (e.g., LanToWan_Allow_HTTP) or uppercase with underscores (LAN_TO_WAN_ALLOW_HTTP) for uniformity.

Rule 5: Minimize the Number of Rules

Having too many firewall rules can negatively impact performance and increase troubleshooting complexity. FortiGate processes policies sequentially, meaning it checks each rule one by one until it finds a match. The more rules it needs to evaluate, the longer it takes to process traffic. This can cause delays in packet forwarding, especially in large-scale deployments with thousands of rules.

How Excessive Rules Affect Performance

Increased CPU and Memory Usage
- Each packet must be evaluated against all active policies.
- More rules require additional memory and processing power.
- High CPU utilization can slow down critical firewall functions, including deep packet inspection and security profiles (IPS, Antivirus, Web Filtering).
Slower Traffic Processing
- Large rule sets increase the time needed for the firewall to determine which policy applies to a given packet.
- In high-traffic environments, excessive policy checks increase latency and reduce throughput.
Troubleshooting Becomes Difficult
- Managing a complex rule set makes it harder to find misconfigurations.
- Overlapping or conflicting rules may cause unexpected behavior.

Best Practices to Minimize Numnber of Rules

Consolidate similar rules: Instead of creating separate rules for each IP or service, use address groups and service groups.
Use the most specific rules first: Avoid broad ANY rules and ensure policies are optimized.
Periodically audit firewall rules: Remove unused or redundant policies to keep the rule set manageable.

Final FortiGate Policy Design Placement Strategy

Top: Specific Deny Policies (e.g., blocking specific IPs, countries, or services)
Middle: Allow Policies (LAN-to-WAN, VPN access, etc.)
Bottom: Implicit Deny (Default, or an explicit Deny All for logging)

If you are interesting in the Routing Best Practice check this post.