FCP_FWB_AD-7-4 Practice Questions

FortiWeb provides a multi-layered approach to secure API connections. The three essential features are:

1. API Schema Validation: This enforces a positive security model by validating all incoming API requests against a predefined OpenAPI or Swagger schema. It ensures that requests adhere to the correct format, data types, and constraints, effectively blocking malformed or malicious payloads.

2. Machine Learning (ML)-based API Protection: FortiWeb uses machine learning to automatically build a model of normal API traffic. It then uses this model to detect anomalous behavior, business logic abuse, and zero-day attacks that static rules or signatures might miss.

3. API User Key Enforcement: This is a fundamental access control mechanism. By requiring and validating API keys, FortiWeb ensures that only authorized clients can access the API endpoints, preventing unauthorized usage.

A. Single sign-on (SSO) authentication with Active Directory (AD): This is an authentication method for human users accessing web applications via a browser, not a typical security control for machine-to-machine API communication.

D. API user authentication with SAML: SAML is primarily a standard for web browser single sign-on (SSO). While it can be adapted for APIs, it is not a common or foundational security feature for them, unlike API keys or OAuth.

1. FortiWeb 7.4.0 Administration Guide

Page 518

"API Protection": "FortiWeb's API protection feature allows you to import an OpenAPI file that defines the specifications of your APIs. FortiWeb then validates the API requests against the specifications defined in the OpenAPI file." (Supports option C)

2. FortiWeb 7.4.0 Administration Guide

Page 488

"Machine Learning": "FortiWeb uses machine learning to detect attacks based on abnormal user behavior... It can be applied to both regular web applications and APIs to detect threats." (Supports option B)

3. FortiWeb 7.4.0 Administration Guide

Page 520

"API Protection > API": The configuration for API protection includes settings for authentication and authorization

which are the mechanisms used to enforce access control

commonly through methods like API keys. The guide states

"FortiWeb validates the API requests against the specifications defined in the OpenAPI file

including the security schemes

such as API Key

HTTP authentication

and OAuth 2.0." (Supports option E)

In an Active-Passive High Availability (HA) cluster, only one FortiWeb unit (the primary) actively processes traffic, while the other (the secondary) remains in a standby state. When a failover is triggered, the standby unit assumes the primary role. To redirect traffic to itself, the newly promoted primary unit broadcasts gratuitous Address Resolution Protocol (ARP) packets. These packets advertise that the cluster's virtual IP (VIP) address is now associated with its own MAC address, prompting neighboring switches and routers to update their ARP tables and forward traffic to the new active unit.

A. Passive-Passive: This is not a standard or valid high availability mode, as it implies no device is actively processing traffic, which defeats the purpose of HA.

C. Active-Active: While an Active-Active cluster also uses gratuitous ARP during a failover (e.g., if the primary load-balancing unit fails), its primary purpose is load distribution across all nodes, not just failover. Active-Passive is the model most defined by this specific failover mechanism.

D. Passive-Active: This is not a distinct HA mode; it is simply another way of describing the Active-Passive configuration.

1. FortiWeb 7.0 Administration Guide

Page 478

Section: "How HA works".

The document states: "When a failover occurs

the new primary unit (the former standby) notifies the network that it is now the owner of the virtual MAC address and the IP addresses of the HA cluster. It sends gratuitous ARP packets that contain the virtual MAC address and the IP addresses of the cluster. Network devices (routers and switches) update their forwarding tables

and traffic begins to flow to the new primary unit." This description is the fundamental mechanism of an Active-Passive failover.

A primary reason to implement HTTP rewriting is to support SSL/TLS offloading and enforce secure connections. When FortiWeb terminates an HTTPS connection from a client and communicates with the back-end server over unencrypted HTTP, the server might generate responses containing absolute URLs with http://. A response rewriting rule can be configured to replace these http:// links with https:// in the response headers and body before forwarding the response to the client. This prevents mixed content warnings and ensures the user's session remains securely encrypted, which is a critical security function. This is often used in conjunction with a rule that redirects initial HTTP requests to HTTPS.

B. To implement load balancing.

Load balancing is a separate FortiWeb feature that distributes traffic across multiple back-end servers; it is not implemented using HTTP rewriting rules.

C. To replace a vulnerable element in a requested URL.

This task is primarily handled by FortiWeb's security inspection profiles, such as attack signatures or sanitization, which are designed to detect and block malicious patterns.

D. The original page has moved to a new URL.

This scenario is best handled by a standard HTTP 301/302 redirect, which is a specific redirection feature, not the broader function of rewriting content or URLs transparently.

1. FortiWeb™ Administration Guide Version 7.0.0

Page 424

Section: "Response Rewriting Rule".

The guide states: "You can configure a response rewriting rule to replace content in the response body. For example

when FortiWeb performs SSL offloading

the back-end web servers may return a response body containing HTTP links. You can configure a response rewriting rule to replace the HTTP links with HTTPS links." This directly supports the explanation for answer A.

2. FortiWeb™ Administration Guide Version 7.0.0

Page 428

Section: "HTTP to HTTPS Redirect".

This section describes the feature to "automatically redirect HTTP requests to HTTPS

" which is a direct implementation of the reason stated in answer A.

3. FortiWeb™ Administration Guide Version 7.0.0

Page 313

Section: "Server Load Balancing".

This section details the configuration of server pools for load balancing

confirming it is a distinct function from rewriting.

The provided screenshot displays the Machine Learning (ML) configuration on a FortiWeb appliance. The Phase is explicitly set to Running, and the Sample Per IP parameter is set to Unlimited. This configuration instructs FortiWeb, during its operational Running phase, to continuously accept and process an unlimited number of traffic samples from any single source IP address. This allows the ML engine to perpetually refine its model of normal traffic behavior without being constrained by a sample limit per IP.

A. This is incorrect because the Sample Per IP setting is explicitly configured as Unlimited, not a fixed or "set number".

C. This is incorrect because the screenshot clearly shows the ML Phase is set to Running, not collecting.

D. This is incorrect as the Phase is Running, not collecting, and the configuration allows for Unlimited samples, not zero.

1. FortiWeb Administration Guide 7.4.1

Page 580

Section: "Configuring machine learning".

The guide details the configuration options for Machine Learning. It lists Running as a selectable Phase. It also describes the Sample Per IP setting

stating: "Select the maximum number of samples that FortiWeb collects from the same source IP address. The available options are 100

1000

10000

and Unlimited." The screenshot shows these two settings configured as Running and Unlimited

directly supporting the correct answer.

2. FortiWeb Cookbook 7.4.0

Page 113

Section: "Machine Learning for anomaly detection".

This document explains the ML process: "In the running phase

FortiWeb uses the data it has collected to build a mathematical model of your application's valid traffic. It then compares new traffic to the model to detect requests that are anomalous." The continuous learning in the running phase is governed by the sampling parameters

which in this case are set to unlimited per IP.

Based on the exhibit, the API Gateway Type is set to "URL". For this configuration to be functional and secure, two key elements are missing. First, you must define the specific API paths the gateway will manage. This is done in the URL Prefixes table, which is a mandatory requirement for the "URL" type gateway. Second, a primary function of an API gateway is to protect backend services from abuse, such as DoS or brute-force attacks. Defining rate limits is the fundamental mechanism for this protection. While the UI presents it as a toggle, a gateway without rate limiting is not fulfilling its core security purpose and is considered an incomplete configuration from a best-practice perspective.

C. You must select a setting in the Allow User Group field.

This is incorrect. Setting this to "None" is a valid configuration for public APIs that do not require user authentication.

D. You must enable and configure Host Status.

This is incorrect. Host Status is an optional health-check feature to monitor backend server availability, not a required element for the gateway's traffic routing or security logic.

1. FortiWeb 7.4.0 Administration Guide

Page 418

"Configuring an API gateway".

Regarding URL Prefixes (B): Step 4 states

"If you select URL as the API Gateway Type

you must also configure URL Prefixes. Click Create New to add URL prefixes to the API gateway. You must configure at least one URL prefix." This directly confirms that URL Prefixes are mandatory.

Regarding Rate Limits (A): Step 5 states

"Optionally

enable Rate Limit to apply rate limiting to the API gateway." While the guide uses the word "Optionally

" rate limiting is a foundational security control for API gateways

making it an essential configuration for a properly deployed and secure solution

which is a common expectation in certification exams. The purpose of the feature is to protect APIs

and rate limiting is a primary method for achieving this.

2. Fortinet Training Institute

NSE 6 FortiWeb 7.2 Study Guide

Page 201

"API Gateway".

The guide describes the API Gateway feature's purpose: "FortiWeb's API gateway feature provides you with a single point of entry for your APIs to enforce security policies

such as authentication/authorization and rate limiting." This highlights rate limiting as a core

defining function of the feature

reinforcing its practical necessity.

The problem is that FortiWeb sees all traffic originating from the FortiADC's IP address (192.0.2.1) due to the Source NAT (SNAT) configuration on FortiADC. When FortiWeb blocks this single IP, it inadvertently blocks all legitimate users. To fix this, FortiWeb must be able to identify the original client's IP address.

This can be achieved by either changing the network topology or by passing the original IP information at Layer 7. Placing FortiWeb in front of FortiADC ensures it sees the real client IP at Layer 3. Alternatively, in the current topology, FortiADC can be configured to insert the original client IP into an HTTP header (like X-Forwarded-For), and FortiWeb can be configured to trust this header for source identification.

A. "Preserve Client IP" is a setting configured on a proxy or load balancer (like FortiADC), not on the end-user's client machine.

B. Waiting for a block timeout is a reactive measure that accepts service disruption for all users and does not solve the underlying architectural problem.

1. FortiWeb 7.4.0 Administration Guide

Page 100

"Defining a server pool". The guide states: "If FortiWeb is installed behind a NAT device such as a FortiGate unit or a third-party router

enable this option to use the IP address in the X-Forwarded-For: HTTP header field as the source IP address." This directly supports option D.

2. FortiWeb 7.4.0 Administration Guide

Page 43

"How to position FortiWeb in your network". This section details deployment topologies. Placing FortiWeb at the network edge

before other devices like a load balancer

allows it to directly inspect traffic from its original source

which validates the architectural change proposed in option C.

3. FortiADC 7.4.0 Handbook

Page 138

"HTTP content rewriting and redirection". This section describes the capability of FortiADC to insert

modify

or delete HTTP headers

which is the required function on the FortiADC to implement the X-Forwarded-For solution described in option D.

An API gateway protection schema is configured by importing a formal specification, such as an OpenAPI file. This specification allows for the explicit definition and strict validation of diverse data types beyond simple strings, including integer, number, boolean, array, and object, along with specific formats (e.g., int32, date-time). This creates a rigid, contract-based validation.

In contrast, the machine learning (ML) schema learns from observing live traffic. While modern versions can infer basic types like "number", its core analysis is based on modeling patterns, character sets, and lengths of parameter values, which are fundamentally processed as strings. The gateway schema's reliance on a rich, predefined type system is a key architectural difference.

A. An API gateway protection schema does not preclude authentication; it is a validation layer that works alongside authentication and authorization policies to secure APIs.

B. Both API gateway and ML protection schemas in FortiWeb primarily focus on validating incoming API requests to protect the server, not on validating or handling response bodies.

D. Both schema types require administrator intervention to be updated. A gateway schema requires a new specification file to be uploaded, while an ML schema requires the administrator to initiate a relearning cycle.

1. FortiWeb 7.0 Administration Guide:

In the section "Configuring API protection using an OpenAPI file" (p. 478)

the guide states: "You can import an OpenAPI file to define the API to be protected... FortiWeb validates the API requests against the definitions in the OpenAPI file

including URL

parameters

data types

and so on." This confirms the use of explicit

predefined data types for gateway schemas.

In the section "Machine Learning for API Protection" (p. 492)

under "What FortiWeb learns for APIs

" the guide lists learned attributes like "Minimum and maximum length of the parameter value" and "Character set of the parameter value." This highlights its pattern-based analysis

which is fundamentally different from the strict type enforcement of a gateway schema.

2. OpenAPI Specification 3.0.3:

In the "Data Types" section

the specification details the primitive data types (string

number

integer

boolean

array

object) and format modifiers (float

double

int32

int64

date

date-time

etc.) that can be used. This demonstrates the rich

formal type system that an API gateway schema leverages for validation

a capability distinct from the inferential nature of ML-based protection. (Source: https://spec.openapis.org/oas/v3.0.3#data-types)

The exhibit shows an entry from the FortiWeb attack log. The log identifies the Source IP as 192.168.1.11 and the Attack ID as 20000010 (brute force logins). The Action taken by FortiWeb is "Alert," which means the device has detected and logged traffic matching a known attack signature. This log entry is direct evidence that the source IP (192.168.1.11) is originating traffic that FortiWeb, the inspecting device, has classified as suspicious. The traffic is directed towards the protected host, www.example.com.

A. The "Alert" action signifies detection and logging only; it does not confirm whether the brute force attempt was successful or if any credentials were compromised.

B. The log clearly indicates that 192.168.1.11 is the Source IP and the protected host is the destination, meaning the suspicious traffic flows from the client to the server.

C. While the Count field indicates the signature was triggered 10 times, this is a specific metric. Option D provides a more fundamental description of the overall event represented by the log entry.

1. FortiWeb 7.4 Administration Guide

Page 519

"Viewing log messages". The guide details the columns in the Attack Log. The Source IP column is defined as "The source IP address of the traffic

" and the Attack column shows "The name of the attack." The existence of an entry in this log for a specific source IP inherently means that the source is sending traffic flagged as an attack

which is suspicious.

2. FortiWeb 7.4 Administration Guide

Page 520

"Action". The guide explains that the "Alert" action means "FortiWeb generates a log message about the traffic

but otherwise takes no action." This confirms that the log entry is for detection and does not imply the attack was successful or blocked.

When a client's IP address is incorrectly blocked by FortiWeb's period block feature, the administrator can manually intervene. The FortiWeb GUI provides a monitoring page specifically for this purpose, typically called "Banned IP." From this page, an administrator can view the list of all currently blocked IP addresses, the reason for the block, and the remaining block duration. The administrator can then select the specific IP address that was incorrectly blocked and manually delete it from this list, immediately restoring access for the client without waiting for the block period to expire.

A. This is incorrect. FortiWeb provides a direct administrative function to view and manually release IPs from the temporary blocklist.

C. This is an improper and disruptive method. While it might clear the block, it would interrupt service for all legitimate users of the application protected by that policy.

D. FortiWeb is a security appliance and does not have the functionality to manage or assign IP addresses to clients on the network.

1. FortiWeb Administration Guide 7.0.3

Page 648

Section: "Monitoring system status > Banned IP".

The guide states: "The Banned IP page displays a list of IP addresses that are currently blocked by FortiWeb... To release a banned IP address

select it and click Delete." This directly confirms that an administrator can manually release a blocked IP.

2. FortiWeb Administration Guide 7.2.0

Page 721

Section: "Log & Report > Monitor > Banned IP".

This section details the "Banned IP" monitor

explaining its function is to display temporarily blocked IPs. The presence of a "Delete" option in the GUI screenshot and description confirms the ability to manually remove an entry.

A self-signed certificate, or more accurately, a certificate signed by a private Certificate Authority (CA), is appropriate for an internal enterprise environment where all client devices are managed. In such a scenario, the root certificate of the private CA can be distributed and installed as a trusted root authority on all company computers, often automatically via tools like Active Directory Group Policy. Once the clients trust the internal CA, any certificate it issues for internal servers (like those protected by FortiWeb) will be validated without security warnings, creating a secure and trusted internal Public Key Infrastructure (PKI).

A. The device type (mobile vs. desktop) is irrelevant; trust must be established on all clients, which is difficult in a mobile-only environment without a Mobile Device Management (MDM) solution that can push the trusted root certificate.

B. Business size is not the primary factor. A small business with a public-facing website would still need a commercial CA certificate to be trusted by external customers' browsers.

D. If resources do not require security or HTTPS, then no certificate of any kind is needed, which makes the choice between certificate types irrelevant.

1. FortiWeb Administration Guide 7.0.0 | Fortinet Docs: In the section "System > Certificates > Local

" the guide explains the process of uploading local CA certificates. This functionality is designed for scenarios where FortiWeb must trust or use certificates from an internal

private CA

which is the core concept described in the correct answer. The premise is that clients have already been configured to trust this private CA. (Reference: FortiWeb Administration Guide 7.0.0

"Certificates

" p. 438).

2. Microsoft Learn - Active Directory Certificate Services (AD CS) Overview: "AD CS provides customizable services for issuing and managing public key certificates used in software security systems that employ public key technologies... You can use AD CS to enhance security by binding the identity of a person

device

or service to a corresponding private key." This official documentation outlines the primary use case for a private CA within an enterprise

which is exactly the scenario in option C. (Reference: Microsoft Learn

"Active Directory Certificate Services Overview

" Document ID: 5f89555d-099c-4242-9b5a-c08748ac74c4).

3. NIST Special Publication 800-32 - Introduction to Public Key Technology and the Federal PKI Infrastructure: Section 2.2

"Public Key Certificate

" and Section 3

"PKI Components

" describe the role of a CA and the concept of a trust anchor. The document implicitly supports the model of a private

enterprise-specific PKI where the organization's CA serves as the trust anchor for all its managed entities. (Reference: NIST SP 800-32

Sections 2.2 and 3).