Skip to main content
Atul_S
Staff & Editor
Staff & Editor
June 2, 2026

Technical Tip: FortiGate  Best Practices for conducting compliance and penetration, testing activities

  • June 2, 2026
  • 0 replies
  • 76 views

Description

This article describes the steps when a user (or a third‑party auditor) runs compliance scans (PCI‑DSS, ISO 27001, NIST, etc.) or penetration testing (external/internal, web‑app, network, wireless, social‑engineering), the FortiGate firewall sits at the front line of the environment.

Scope

FortiGate.

Solution

During a pen test activity, if the device is not prepared, the test can:

  • Trigger false‑positive IDS/IPS alerts that block the tester’s traffic.

  • Flood the data plane with high‑rate probes, exhausting session or CPU resources, and forcing the firewall into Conserve mode.

  • Cause log or event loss, making it impossible to produce the required audit trail.

  • Overwrite or delete security policies required for production.


The following best‑practice testing checklist helps protect the production environment, ensure accurate test results, and maintain evidence of compliance while allowing the tester to exercise the full scope of the assessment.


Step 1: Create a dedicated testing VDOM:

config system vdom
edit test_vdom
end


Step 2: Export current policies for backup:

execute backup config flash


Or use the GUI 'Backup' feature and store the file off‑box.


Step 3: Duplicate the production policy set into the test VDOM:

  • Export the production policies.

  • Copy the output into a text editor (like Notepad++ or VS Code).

  • Change edit <Production_VDOM_Name> to edit <Test_VDOM_Name>.

  • Change the production interface names (e.g., set srcintf "port1") to the test interface names (e.g., set srcintf 'port2').

  • Paste the modified text back into the FortiGate CLI global context.


Step 4: Create a test‑specific UTM profile like IPS:


config ips sensor
edit "pen‑test‑sensor"
set default-action pass
set log enable
next
end

Assign the sensor to the test policy.


Step 5: Enable logging for the test scope:

config log setting
set logtraffic all
set severity information
end


Or, send logs to a dedicated syslog server:

config log syslogd setting
set status enable
set server <IP>
set port 514
end


Step 6: Allocate extra session and CPU resources:

config system global
set session-ttl 86400 (or increase max‑sessions via set max-session <value>
end


Step 7: Rate‑limit the test traffic.

If the tester uses a traffic generator, limit the packet rate to less than 5 kpps per interface, or enable set max-pps <value> on the interface.


Step 8: Run a 'pre‑test' health check:


diagnose hardware sysinfo → verify CPU/Memory headroom.

diagnose sys session list → ensure session table is not near capacity.