NSE4 System and Network Administration Practice Question
A large enterprise is deploying a FortiGate 600F as the perimeter firewall. The security team requires that all administrative access (SSH, HTTPS, and Ping) to the FortiGate must be restricted to a dedicated management network (10.10.10.0/24). Additionally, any failed login attempt from outside the management network should be logged and the source IP should be blocked for 30 minutes. The administrator has configured a local-in policy to deny all administrative access from non-management networks and enabled logging. However, the administrator wants to automatically block the offending IPs. The FortiGate is not connected to any FortiAnalyzer or FortiManager. What should the administrator do to achieve this?
⚠ Common exam trap
Many candidates confuse 'block-session-ttl' (which only controls session timeout for already-blocked traffic) with automatic IP banning, or assume external devices like FortiAnalyzer are required when the FortiGate's automation stitch can handle the task locally.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Create an automation stitch that triggers on local-in policy logging and adds the source IP to a blocked list via CLI script.
An automation stitch can directly react to local-in policy log events by executing a CLI script that adds the offending source IP to a local banned user list (e.g., via `diagnose user banned-ip add`). This provides automatic, immediate blocking without requiring external devices like FortiAnalyzer, and the 30-minute duration can be set via the ban-time parameter in the script or the local-in policy's block-session-ttl.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Create an automation stitch that triggers on local-in policy logging and adds the source IP to a blocked list via CLI script.
Why this is correct
An automation stitch is the correct approach because it creates an event-triggered workflow: a local-in policy log entry (e.g., 'local-in denial') fires an automation trigger, which then executes a CLI script to add the offending source IP to a configured blocked address list. This provides immediate, autonomous enforcement without waiting for human intervention, and it directly addresses the source IP at the device level.
- ✗
Use a FortiAnalyzer to generate alerts and send to SIEM.
Why it's wrong here
FortiAnalyzer's role is to aggregate logs and generate alerts that can be forwarded to an external SIEM for monitoring and reporting, but it does not enforce security actions on the FortiGate. In this environment, no FortiAnalyzer is present, so the solution is architecturally invalid. Even when it is deployed, it only provides visibility—it cannot dynamically add IPs to a block list, leaving the response manual and non-automated.
- ✗
Configure a firewall policy to block the offending IPs manually based on logs.
Why it's wrong here
Manually configuring a firewall policy from logs is a reactive process that requires an administrator to detect the attack, interpret the logs, and create a rule to block the IP. This is not automated and introduces significant response time, during which the FortiGate management interface remains vulnerable. Furthermore, a regular firewall policy applies to transit traffic passing through the device, not to local-in traffic destined to the FortiGate itself; a local-in policy would be required, so a manually created firewall policy may not even block the hostile source.
- ✗
Enable 'set block-session-ttl' on the local-in policy.
Why it's wrong here
The `set block-session-ttl` option on a local-in policy only controls the time-to-live of a denied session's session table entry; it is a per-session parameter that does not create a persistent IP block. Once the session TTL expires, the next packet from that source creates a new session and is denied again, but the source IP is never added to an address or block list. Thus it fails to provide the ongoing, IP-based blocking needed to stop repeated attacks, unlike the automation stitch that adds the IP to a blocked list for a defined period.
Go deeper
Related to this question
About these practice questions
One of 773 original NSE4 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This NSE4 practice question is part of Courseiva's free Fortinet certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the NSE4 exam.