Stackvora.tech

FortiGate Initial Setup: Best-Practice Checklist

Successfully deploying a FortiGate firewall as a perimeter defense or internal segment requires meticulous initial configuration to establish a secure and…

Successfully deploying a FortiGate firewall as a perimeter defense or internal segment requires meticulous initial configuration to establish a secure and efficient operational baseline. This guide details a best-practice checklist for the initial setup phase, focusing on security hardening, essential network services, and foundational logging, applicable to FortiOS versions 6.4 through 7.2.

Adhering to these steps ensures the device is robust, manageable, and prepared for integrating into a larger enterprise network. We will cover critical administrative access controls, core network service configurations, security profile applications, and essential monitoring prerequisites.

1. Initial Access and Administrative Hardening

a. Secure Initial Access

Upon initial boot, access the FortiGate via its default IP (typically 192.168.1.99) on the internal interface (port1). Use the default username admin with a blank password. The system will prompt for a new password immediately.

  • Strong Password Policy: Enforce complex passwords (minimum 12 characters, mix of upper/lower case, numbers, and symbols).
  • Restrict Admin Access: Limit administrative access protocols (HTTPS/SSH preferred, disable HTTP/Telnet).
config system interface
    edit "port1"
        set allowaccess ping https ssh http telnet fgfm capwap fortiac
        unset allowaccess http telnet  <-- Remove insecure protocols
    next
end

b. Create Dedicated Administrator Accounts

Avoid using the default admin account for day-to-day operations. Create role-based administrator accounts with specific profiles.

config system admin
    edit "net_ops_admin"
        set accprofile "prof_net_ops"
        set password ENC <strong_password>
        set vdom "root"
        set trusthost1 10.0.0.0 255.255.255.0
        set trusthost2 172.16.0.0 255.255.255.0
    next
    edit "sec_ops_admin"
        set accprofile "prof_sec_ops"
        set password ENC <strong_password>
        set vdom "root"
        set trusthost1 10.0.0.0 255.255.255.0
    next
end

Create custom admin profiles with granular permissions based on roles. For example, a prof_net_ops might have read-write access to network configurations but read-only access to security profiles.

c. Enable Two-Factor Authentication (2FA) for Administrators

FortiToken or FortiAuthenticator provide robust 2FA. This is critical for administrative account security.

config system admin
    edit "net_ops_admin"
        set password ENC <strong_password>
        set fortitoken "FTK-XXXX-YYYY" <-- Assign a FortiToken serial
        set two-factor fortitoken
    next
end

2. Network Configuration Essentials

a. Configure Management Interface (if different from LAN)

If using a dedicated management interface, configure its IP address, subnet mask, and allowed access protocols. Ensure it is distinct from data-plane interfaces.

b. Configure WAN Interfaces and Default Route

Set up WAN interfaces (e.g., port1, port2) with static IPs, DHCP, or PPPoE as required. Define the default route to the ISP gateway.

config system interface
    edit "wan1"
        set vdom "root"
        set ip 203.0.113.10/24 <-- Example static IP
        set allowaccess ping https ssh
        set type physical
    next
end

config router static
    edit 1
        set gateway 203.0.113.1 <-- ISP gateway
        set device "wan1"
    next
end

c. Configure Internal Interfaces (LAN/DMZ)

Assign IPs and define access for internal segments. Consider creating VLAN sub-interfaces.

config system interface
    edit "vlan10_users"
        set vdom "root"
        set ip 10.10.10.1/24
        set allowaccess ping https ssh
        set interface "port3" <-- Parent interface
        set vlanid 10
    next
end



d. DNS Configuration


Configure reliable DNS servers for the FortiGate itself (e.g., FortiGuard DNS, public DNS like Google 8.8.8.8, or internal DNS servers).


config system dns
    set primary 8.8.8.8
    set secondary 8.8.4.4
    set dns-server-override enable <-- FortiGate uses these, not DHCP-assigned
end



3. Time Synchronization and FortiGuard Updates


a. Configure Network Time Protocol (NTP)


Accurate time is crucial for logging, certificate validity, and security. Use reliable NTP servers.


config system ntp
    set ntpsync enable
    set type custom
    config ntpserver
        edit 1
            set server "0.fortiguard.pool.ntp.org"
        next
        edit 2
            set server "1.fortiguard.pool.ntp.org"
        next
    end
    set syncinterval 60 <-- Sync every 60 minutes
    set status enable
end



b. Configure Timezone


Set the correct local timezone.


config system global
    set timezone 04 <-- Example: (GMT-5:00) Eastern Time (US & Canada)
end



c. Enable FortiGuard Updates


Ensure the FortiGate can reach FortiGuard services for critical security updates (IPS signatures, antivirus definitions, web filtering categories, etc.).


config system fortiguard
    set sdns-server-ip 208.91.112.53 <-- FortiGuard DNS for domain lookups
    set webfilter-override disable
end
execute update-now <-- Manually trigger an update


Verify connectivity and update status in the GUI under System > FortiGuard or via CLI diagnose debug application update -1 and diagnose test application url-check-service 99.



4. Logging and Monitoring Configuration


a. Enable Local Logging


Ensure that critical security events are logged locally, even if remote logging is also configured.


config log memory setting
    set status enable
end
config log disk setting
    set status enable
end



b. Configure Remote Logging (FortiAnalyzer / Syslog)


For centralized logging and analysis, integrate with a FortiAnalyzer or a generic syslog server. FortiAnalyzer offers superior integration and threat correlation.


config log fortianalyzer setting
    set status enable
    set server "192.168.100.10" <-- FortiAnalyzer IP
    set upload-option real-time
    set reliable enable <-- Use reliable delivery (TCP)
    set enc-algorithm high
    set conn-timeout 30
end

config log syslogd setting
    set status enable
    set server "192.168.100.20" <-- Syslog server IP
    set port 514
    set facility local7
    set mode udp
end


Confirm log delivery using diagnose debug application miglogd -1 or checking the remote server logs.



5. Initial Security Policy and Profiles


a. Configure Essential Security Profiles


Apply these to firewall policies to inspect traffic. Start with default profiles and customize as needed. Minimum recommended profiles:


    
    
  • Antivirus (AV): Scan for malware.
    • 
    
  • Intrusion Prevention System (IPS): Block known exploits and attacks.
    • 
    
  • Web Filter: Block malicious websites, filter categories.
    • 
    
  • Application Control: Identify and control applications.
    • 
    
  • DNS Filter: Block malicious DNS lookups.
    • 



These are configured under Security Profiles in the GUI. For example, for an internet-bound policy:


config firewall policy
    edit 1
        set name "Internet_Access"
        set srcintf "internal"
        set dstintf "wan1"
        set srcaddr "all"
        set dstaddr "all"
        set service "ALL"
        set action accept
        set nat enable
        set profile-group "default" <-- Default security profile group
        set av-profile "default"
        set ips-sensor "default"
        set webfilter-profile "default"
        set application-list "default"
        set dnsfilter-profile "default"
        set logtraffic all
    next
end


It's best practice to create custom profiles tailored to organizational needs rather than relying solely on "default".



b. Create Basic Firewall Policies


Establish inbound/outbound policies for necessary traffic flows.
At a minimum:


    
    
  • Outbound policy for internal users to internet (NAT enabled, security profiles applied).
    • 
    
  • Inbound policy for permitted services (e.g., VPN, specific web servers in DMZ) with strict source/destination/service rules.
    • 
    
  • Deny all implicit rule (last rule, usually deny action).
    • 




6. Backup Configuration


After completing the initial configuration, immediately back up the FortiGate configuration. This is crucial for disaster recovery and rollback scenarios.


execute backup config usb <filename> <password>
execute backup config tftp <filename> <tftp_server_ip>
execute backup config ftp <filename> <ftp_server_ip> <username> <password>


Regularly schedule automated backups to a secure off-device location (e.g., FortiManager, SCP server).



Common Pitfalls and Troubleshooting


    
    
  • Default Password Persistence: Forgetting to change the admin password or leaving other default accounts active (e.g., fortigate for FortiManager enrollment) creates significant vulnerabilities.
    • 
    
  • Unrestricted Administrative Access: Allowing admin access from all interfaces or using insecure protocols (HTTP/Telnet) exposes the management plane. Always use set trusthost for specific management subnets.
    • 
    
  • NTP/DNS Misconfiguration: Incorrect NTP settings lead to logging discrepancies and certificate validation failures. Incorrect DNS prevents FortiGate from resolving FortiGuard domains or external services. Use diagnose debug application url-check-service 99 to test FortiGuard connectivity.
    • 
    
  • Logging to Non-Existent/Unreachable Server: Confirm FortiAnalyzer/syslog server IP and port, and ensure network reachability. Use diagnose debug application miglogd -1 to monitor log forwarding.
    
  • Generic Security Profiles: While "default" profiles provide basic protection, they are often not tuned for specific organizational needs, potentially leading to over-blocking or under-blocking. Customization is key.
    • 
    
  • Lack of Configuration Backup: Not backing up the initial, known-good configuration makes recovery from misconfigurations or hardware failures extremely difficult.
    • 
    
  • Interface Alias Overuse: While convenient, relying solely on interface aliases for policy source/destination rather than direct interface references can obscure actual traffic flow if aliases are later remapped.
    •

Back to the knowledge base · Ask the AI assistant