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