CCNA Security Profiles Questions

The FortiGate cannot inspect email content that is encrypted with TLS unless SSL deep inspection is enabled on the security policy. Without it, the device only sees the encrypted SMTP session, so DLP pattern matching never reads the credit card numbers in the payload. This is why the DLP profile appears to detect nothing despite being correctly configured.

The IPS engine uses protocol decoders to parse and normalize traffic into a structured format for signature matching. Without the HTTP decoder, the engine processes raw TCP segments and cannot interpret HTTP headers, URLs, or payloads, so HTTP-specific signatures won't trigger correctly. Enabling this decoder is mandatory for any meaningful HTTP inspection.

Increasing the threshold value adjusts the anomaly's sensitivity so that a significantly larger rate of SYN packets per second is necessary to trigger the tcp_syn_flood anomaly. Legitimate connection bursts will now remain below the alarm level, avoiding false positives, while a genuine flood will still generate enough traffic to exceed the threshold and be blocked. This is the correct tune because it maintains an active defense while suppressing noise from normal traffic patterns.

Proxy-based inspection is the correct mode because it fully reassembles and buffers the entire file in memory before submitting it to the antivirus engine. This complete content capture enables sophisticated pattern matching and detection of threats that rely on whole-file context, at the expense of increased latency. For maximum virus detection assurance, FortiGate administrators use proxy-based inspection for antivirus profiles.

The proto_state=01 in the session table is interpreted as SYN_SENT, meaning the TCP handshake has not completed. The FortiGate has sent (or received) a SYN and is waiting for the corresponding SYN-ACK to move to ESTABLISHED (proto_state=02). Because the session remains in proto_state=01, it correctly indicates that the sessions are in the SYN_SENT state and have not completed the three-way handshake.

Creating an application control profile with 'P2P' set to 'block' and 'File Sharing' set to 'allow' is the fundamental step because FortiOS application control categorizes traffic into distinct signatures. This configuration explicitly permits file-sharing protocols like FTP or SMB while denying peer-to-peer applications such as BitTorrent or eMule. Without this profile, no other setting can differentiate between these two categories.

Enabling Google Safe Search in the web filter profile forces Google to return filtered results, blocking explicit content at the search engine itself. This satisfies the requirement to enforce filtered Google searches for students without inspecting every result page.

A Web Filtering profile with FortiGuard categories is purpose-built for this task: it leverages FortiGuard's extensive web rating database to classify URLs into categories such as 'Malicious Web Sites' and applies a configurable action (block, warn, or allow) for each category. This profile evaluates the full URL at proxy level, enabling precise blocking of pages that host malware or phishing content.

A DLP profile inspects email content for sensitive data patterns, such as credit card numbers, and blocks matching messages. This directly satisfies the stem's requirement to prevent data leakage via outbound email, since DLP is the only FortiGate profile that performs content-based pattern matching on data rather than application or protocol control.

During the TLS handshake, the server's certificate is sent in plaintext, and certificate inspection extracts the Common Name (CN) and Subject Alternative Name (SAN) to make web filtering decisions. The FortiGate can therefore block or allow an HTTPS request before any application data is exchanged, using the certificate's CN as the classification criterion even with no decryption.

The spam threshold score defines the rating at which a message is classified as spam. Raising it means messages must score higher before being blocked, so borderline legitimate emails pass through while clear spam is still caught, reducing false positives.

In flow-based inspection mode, the FortiGate offloads many sessions to the NPU for high-throughput processing. When a session is offloaded, packets traverse the NPU and are not sent to the CPU, so the IPS engine never inspects them; the session is then marked as 'bypass'. This is expected behavior for traffic that is not explicitly selected for deep inspection, and it explains why the IPS engine reports no inspection. Admins can confirm this by checking the session table via 'diagnose sys session list'.

Flow-based and proxy-based are the two security profile inspection modes supported on FortiGate for antivirus and other UTM features. Flow mode performs scanning in a single pass directly on packets transiting the kernel and can be accelerated by FortiASIC content processors (CP), lowering latency and supporting high-throughput links. Proxy mode terminates the TCP session in a dedicated proxy engine, reassembles and buffers the full content before scanning, enabling deeper inspection of files and more granular control at the cost of higher latency and resource consumption.

In FortiGate, IPS is enforced at the firewall policy level by assigning an IPS sensor to the policy's Security Profiles. This design lets each policy pass traffic through the sensor's configured signature rules, enabling selective inspection for different source/destination pairs. Because a sensor is a reusable object, the same sensor can be applied to any number of policies, and changes to the sensor immediately affect all policies referencing it.

Full SSL Deep Inspection is a valid and correct FortiGate SSL inspection type. It decrypts SSL/TLS traffic in real time, inspects the plaintext content against security policies such as antivirus, web filtering, and intrusion prevention, then re-encrypts it before forwarding. This provides complete visibility into encrypted traffic, making it the most thorough inspection option, but it requires clients to trust the FortiGate's CA certificate to avoid errors.

Newer game traffic, such as Fortnite, uses frequently changing update servers and protocols, so a FortiGate with an outdated FortiGuard signature database will fail to match those flows. Application control relies on regularly updated signatures to identify application-specific traffic patterns and unblocked domains. If the signature version predates a major Fortnite update, the traffic is passed as unknown. The solution is to update the FortiGuard application control signatures (either manually or via scheduled updates) and then retest the Guest policy.

For inbound SMTP, the correct procedure is to create a firewall policy for the SMTP service and attach an email filter profile to that policy; the FortiOS inspection engine then applies FortiGuard Antispam category lookups, IP/DNSBL checks, header and MIME analysis, and banned-word rules to every accepted email. The email filter profile is the sole UTM object that contains antispam capabilities, and it is designed to operate on mail protocols (SMTP, POP3, IMAP) in proxy-based inspection mode. This policy-level attachment is exactly how a FortiGate administrator activates spam blocking in production.

Deep inspection performs man-in-the-middle interception, presenting a dynamically generated certificate signed by the FortiGate's own CA to the client. If that CA is not in the client's trusted root store, the browser reports a certificate error. Installing the FortiGate's CA certificate on client devices establishes trust for all re-issued certificates, which resolves the error while preserving full inspection of the decrypted payload.

The FortiGate must be configured to operate as an SMTP proxy in the security policy to intercept and filter email traffic on port 25. In this proxy mode, the FortiGate acts as a relay that receives, inspects, and forwards email, allowing the UTM email filter and antivirus profiles to examine the message body, headers, and attachments. This is the standard method to apply email filtering on FortiGate; without proxy mode, the device would only see IP and port information, not the mail content.

For web filtering to function, the FortiGate must be able to contact the FortiGuard rating service to obtain URL category information. When the rating service is unreachable, the FortiGate may fall back to local cached ratings or fail open, allowing all URLs to pass if no local rating exists. Therefore, checking connectivity to FortiGuard servers is a primary diagnostic step. This is the correct explanation because without reachability, real-time URL categorization cannot occur.

Antivirus profile is the correct answer because FortiSandbox integration is a feature of the antivirus security profile in FortiOS. When an antivirus profile encounters an unknown file, it can send a copy to FortiSandbox for advanced static and dynamic analysis if the FortiSandbox license is available. This extends the signature-based antivirus capability to detect zero-day and advanced persistent threats. Without a license, the AV profile still scans using FortiGuard signatures, but cannot offload files to sandbox.

When an SSL inspection profile has the 'certificate-validation-failed' action set to 'block', the FortiGate actively terminates the TLS handshake whenever the server certificate fails validation, such as due to an expired certificate, an untrusted CA, or a hostname mismatch. This action is evaluated during the SSL inspection proxy phase, before any decrypted content is passed to the web filter for URL categorisation. Consequently, the user sees a connection reset or block page even though the web filter profile itself may have no rule blocking the URL. This direct cause-and-effect matches the scenario exactly.

Enabling Safe Search on a FortiGate instructs the device to enforce the SafeSearch parameter on supported platforms like Google, Bing, and Yahoo, forcing those engines to exclude adult and explicit material from query results. This is accomplished through URL parameter injection or API calls when the user's request is inspected, typically requiring HTTPS inspection to see and modify the query. It ensures that even if a user manually attempts to disable safe search in the browser, the security policy overrides the setting. This filtering shields users from pornography and violent content appearing directly in search result listings.

The email filter profile is the dedicated antispam engine within FortiGate, combining sender IP/domain blacklists, DNS-based blocklists, and real-time content analysis with ML-based classification. It inspects SMTP sessions by examining the message envelope, MIME headers, and body against a library of spam signatures and heuristics, while also performing Sender Policy Framework, DKIM, and DMARC verification. This profile can automatically quarantine, tag, or drop unwanted messages, making it the correct choice for spam detection.

In FortiOS, an application control profile defines per-category actions such as Monitor, Allow, or Block. If the Peer-to-Peer category is left as 'Monitor', the FortiGate identifies BitTorrent, writes a log entry, but still forwards the packets, so employees can keep using it. Only changing the action to 'Block' (or adding a specific BitTorrent rule with block) will actually deny the traffic. Thus, the correct fix is to edit the profile's Peer-to-Peer setting to enforce blocking rather than merely monitoring.

On FortiGate, web filtering and application control profiles are complementary UTM features that can both be inserted into the same firewall policy. A web filtering profile evaluates HTTP/HTTPS requests against URL categories and FortiGuard ratings, while an application control profile identifies and controls the applications traversing the network, regardless of the URL used. This allows you to block, for example, a URL category while simultaneously allowing or restricting the specific applications that the traffic uses.

In FortiGate SSL inspection profiles, the 'untrusted-caname' parameter specifies a CA certificate used to re-sign server certificates that are not already trusted by the FortiGate, such as self-signed or internally issued certificates. If this field is left blank or points to an untrusted CA, the FortiGate will fall back to a default CA that clients do not recognize, causing certificate validation warnings and potential connection failures in web browsers. To ensure seamless inspection of sites with untrusted server certificates, the administrator must assign a trusted CA—typically the FortiGate's built-in CA or a corporate CA—so clients accept the re-signed certificates without alerts.

Application control must inspect the contents of an HTTP conversation to identify the application; but when the session is HTTPS, the payload is encrypted and opaque to the security engine. Without an SSL/SSH inspection profile applied to the firewall policy, FortiGate sees only the TLS handshake and the SNI field, so the protocol decoders cannot match application signatures. Enabling SSL inspection decrypts the HTTPS stream and makes the full payload available to application control. Therefore, the correct fix is to add and apply an SSL inspection profile on the same firewall policy that carries the application control profile.

A DNS filter profile is a set of blocking rules and categories, but it is inert until it is attached to a firewall policy. When the policy matches DNS traffic, FortiGate applies the profile's rules — such as blocking malicious domains — and returns a 'blocked' response to the client. This is the enforcement point that makes DNS filtering actually work for traffic traversing the FortiGate.

To protect a web server, the IPS profile must be attached to the firewall policy that controls access to that server, and that policy must actually match the traffic's source, destination, port, and interface. Without this attachment, the FortiGate forwards traffic based on the policy's action alone and never passes the packets to the IPS engine for inspection. Verify that the policy order places this rule before any catch-all policy, and confirm that the 'Security Profiles' section lists the desired IPS sensor; otherwise, the sensor is effectively dormant.

SSL deep inspection re-signs each server certificate with the FortiGate's forward trust CA. Browsers only accept that forged certificate if the CA is trusted locally, so without the certificate installed in each device's trust store, every HTTPS site triggers a warning.

SSL/TLS deep inspection is mandatory for DLP to detect sensitive data in HTTPS traffic. When enabled, FortiGate terminates the TLS session using its certificate as a trusted CA, decrypts the payload, and hands the plaintext to security profiles—including the DLP sensor—for inspection. Without deep inspection, only non-encrypted traffic or traffic subject to certificate inspection (which examines only certificate metadata) can be evaluated, making DLP blind to the content of an encrypted web session.

In FortiGate session output, proto_state=01 maps to TCP SYN_SENT in the TCP state machine. This means the session originated with a SYN packet and is currently awaiting a SYN-ACK from the server; the three-way handshake has not yet completed. Therefore, the session is not fully established and should not be treated as an active, fully formed session. This is the correct interpretation of the diagnostic data.

Enabling SSL deep inspection on the firewall policy is a prerequisite for any content-aware inspection of HTTPS traffic. It forces the firewall to decrypt outbound SSL/TLS sessions so that security profiles, including DLP, can examine the actual file contents being uploaded. By itself it does not block uploads; rather, it provides the visibility needed for a DLP sensor to detect and enforce a block on credit card data. This step is essential because without decryption, the firewall would merely see encrypted bytes and cannot apply data-loss prevention rules.

When the FortiGate's internal CA certificate is past its validity period, the FortiGate can no longer sign or re-sign the server certificates it presents to clients. Even if the generated leaf certificate has a future validity window, the browser will validate the entire chain and immediately flag the root/intermediate CA as expired, breaking trust and causing an 'untrusted authority' error during SSL inspection.

When SSL inspection is enabled on the FortiGate, it terminates the client's TLS connection and re-signs a new certificate for the requested website using its own local Certificate Authority. The browser will only trust this dynamically generated certificate if the FortiGate's CA certificate has been installed in the client's trusted root certificate store. If that CA is missing or untrusted, the browser warns that the certificate was not issued by a trusted authority, which is exactly the warning the user sees — this is the correct cause of the issue.

When a FortiGate performs deep inspection, it terminates the client's TLS connection and then initiates a second TLS connection to the web server to re-encrypt traffic. If the web server negotiates a cipher suite, key exchange method, or TLS version that the FortiGate's SSL engine does not support or is not configured to allow, the outbound handshake fails. This manifests as a 'Cannot communicate securely' or certificate-related error for that specific server, while other sites that use supported ciphers continue to work. The administrator should review the SSL inspection profile's cipher list and ensure it aligns with the server's capabilities.

The FortiGate's CA certificate is not installed in the Trusted Root Certification Authorities store on the clients. Deep SSL inspection works by having the FortiGate intercept TLS traffic and present a real-time generated certificate signed by a FortiGate-owned CA. If that CA is not present in the client's trusted root store, the browser cannot verify the chain of trust and will display a certificate error or block the connection entirely. Installing the FortiGate CA in the Trusted Root Certification Authorities store on all clients is a mandatory prerequisite for seamless deep inspection.

In proxy-based inspection, each protocol must be explicitly enabled in the proxy options of the security profile. If SMTP is left unchecked, the FortiGate will not decode or scan SMTP traffic, causing the antivirus profile to appear non-functional for email. Navigate to the AV profile's protocol options and ensure SMTP is enabled, then apply the profile to the firewall policy that carries SMTP traffic.

Application Control is the correct security feature because it uses deep packet inspection and application signatures to identify P2P traffic regardless of port or protocol. It can block specific applications like BitTorrent, eMule, or LimeWire by matching their unique traffic patterns, even when they use non-standard ports or encryption. This is the only option that directly governs application usage rather than relying on ancillary factors such as URLs or hostnames.

When the FortiGate is integrated with FortiSandbox, the administrator can configure the sandbox profile to 'block' while the file is being analyzed, meaning the FortiGate holds or buffers the file and does not deliver it to the client until a verdict is received from FortiSandbox. This approach ensures that unknown files are not released to the endpoint unless the sandbox deems them clean, with a fallback action applied if the verdict times out. This is the correct behavior for a blocking integration, as it prevents potential malware from reaching the user during the analysis window.

When users connect to Facebook over HTTPS, FortiGate must decrypt the TLS session (or at least inspect the Server Name Indication) to determine the destination domain and apply URL category filtering. If the SSL inspection profile configured on the policy includes a certificate exemption for Facebook (often added to avoid certificate pinning errors or breakage), the firewall skips decryption entirely and cannot see the SNI or the full URL. As a result, the web filter is effectively blind to the HTTPS session, and the Social Networking category is never matched, allowing the traffic even though the profile is set to Block.

In flow-based inspection, FortiOS scans traffic in a single pass by inspecting packets as they traverse the interface without buffering the entire file. Because it does not reassemble the full content or unpack compressed archives (e.g., ZIP, RAR, or base64-encoded files), malware hidden inside these containers can evade detection. Proxy-based inspection, in contrast, buffers the whole object, unpacks archives, and scans each component individually, offering deeper and more thorough virus detection than flow mode.

In a FortiGate IPS sensor, each signature can be configured with an action and logging. Setting the action to 'Block' drops the matching traffic, and enabling logging ensures an event is recorded. This directly meets the requirement to block the attack and generate a log entry for each detection.

Applying no SSL inspection to the policy means the FortiGate does not decrypt or examine HTTPS traffic; it simply passes it through based on the destination port (443). This is the appropriate and efficient choice when the requirement is to block HTTP (port 80) while allowing HTTPS, because the firewall can enforce that distinction entirely through policy rules without the overhead or privacy implications of encryption decryption.

Anomaly signatures in FortiOS are rate-based detectors that only generate an event when traffic exceeds a configured threshold, such as packets per second or concurrent connections. The command output lists only triggered anomalies, not configured ones. If no traffic has exceeded the threshold, the list remains completely empty, which is a normal operational state.

In FortiOS, web filtering is enforced only when a web filter profile is explicitly attached to the firewall policy that matches the traffic. If the policy used by the affected users does not have the profile selected, the FortiGate will not inspect URLs and will allow all web traffic, creating a bypass. The administrator should examine the policy's Security Profiles section to confirm the web filter profile is applied. This is the most direct and common cause of a partial web filter bypass.

Application control is the correct approach because it classifies traffic based on application signatures and behaviors rather than static port numbers or URL strings. A properly configured application control profile can identify and block specific social media applications—even when they run over HTTPS or use non-standard ports—while explicitly allowing Office 365 applications, including Outlook, Teams, and SharePoint Online. This granularity meets the exact requirement without disrupting business-critical services, and with SSL inspection enabled, it remains effective against encrypted social media traffic.

Setting critical and high severity signatures to block ensures that the most dangerous attacks are stopped. These signatures are typically well-tested and have low false positive rates. This balances security with minimizing false positives, as lower severity signatures might be more prone to false positives.

Safe search enforcement rewrites search-engine traffic so the engine itself filters explicit results, independent of browser preferences. This satisfies the requirement to force filtering regardless of user browser settings, since the FortiGate modifies the request rather than relying on client-side configuration.

Certificate inspection is correct because this SSL/TLS inspection mode only validates the server certificate and does not perform any decryption of the encrypted session. FortiGate forwards the client hello, receives the server certificate, and verifies its validity (e.g., signing chain, issuer, trust, and possible revocation) while leaving the payload encrypted and untouched. This mode is lightweight, preserves performance, and is typically used when you only need to enforce certificate-based policies or ensure clients do not connect to untrusted servers. It does not inspect application content, making it the only mode that strictly only validates the server certificate.

A DLP (Data Leak Prevention) profile uses dictionaries of sensitive data types—such as credit card numbers, US Social Security numbers, dates of birth, and custom regex patterns—and inspects traffic content at the application layer to detect matches in files, HTTP posts, emails, or FTP transfers. When a match occurs, the DLP sensor can log, alert, quarantine, or block the transaction, and it can be applied in a FortiGate security policy together with antivirus and web-filter profiles. Its purpose is specifically to prevent or control the unauthorized transfer of sensitive data, making it the correct profile for this requirement.

Without SSL/TLS deep inspection enabled on the firewall policy, HTTPS sessions pass through still encrypted, and the antivirus engine can only see the outer TLS handshake, not the HTTP payload or files inside. Deep inspection forces the FortiGate to terminate the TLS connection, decrypt the content, scan it with the antivirus profile, then re-encrypt the session to the client. This is the most likely root cause when antivirus misses malware in HTTPS traffic, since the profile itself may be correctly configured but cannot see inside the tunnel.

A Web Filter profile is the correct mechanism because it applies FortiGuard URL category classification directly to HTTP/HTTPS traffic in the firewall policy. By referencing categories such as Malware and Phishing, the profile can immediately block all sessions to sites in those categories, regardless of the actual IP address, and it supports exemptions and overrides. The profile also integrates with antivirus inspection and SSL deep inspection for encrypted traffic, providing a holistic web access control.

The DNS filter profile inspects DNS queries and responses, blocking requests to known malicious domains using FortiGuard's domain threat intelligence. This satisfies the stem's requirement by preventing resolution before a connection occurs, stopping malware command-and-control and phishing at the DNS layer rather than at the subsequent HTTP session.

DNS Filter profile is purpose-built to inspect DNS query messages on port 53, comparing the queried domain against FortiGuard’s DNS category database and botnet indicators. It can take actions such as block, monitor, redirect, or allow based on domain category, and it supports sinkholing for botnet C2 domains. By operating below the web and application layers, DNS Filter can block malicious domains even for HTTPS, non-HTTP, or custom applications, making it the correct choice for DNS-level blocking.

This is necessary because even with SSL deep inspection enabled, the decrypted traffic is only inspected if an IPS profile is attached to the policy. The IPS engine then examines the plaintext HTTP/HTTPS payloads for signatures, vulnerabilities, and exploits. Without an IPS profile, deep inspection alone just decrypts/encrypts but doesn't provide intrusion prevention.

A web filter override is an explicit exemption configured inside the FortiGate profile that lets certain users, groups, or source IPs bypass the FortiGuard rating decision. When an override is in place, the FortiGuard rating may still be evaluated as 'not allow' (blocked), but the override action overrides that result and permits the session. This exactly matches the symptom where only some users, presumably those included in the override rule, can access sites that are otherwise blocked for everyone else.

Enabling 'Enforce Safe Search on Google, Bing, and Yahoo' is the correct FortiGate web filtering option because it actively forces these three search engines to use their safe search settings by rewriting URLs, setting cookies, or leveraging FortiGuard's search engine integration. Even if a user attempts to disable safe search in their browser, the FortiGate intercepts the request and ensures the search results are filtered at the network level, thereby meeting the company policy requirement.

Deep inspection is necessary because many P2P applications encrypt their sessions with TLS/SSL, which hides protocol fingerprints from normal flow-based inspection. By acting as a man-in-the-middle and terminating the TLS connection, the FortiGate can re-inspect the decrypted payload with its application control signatures and identify the P2P protocol. Note that deep inspection alone only makes the traffic visible; it must be paired with an application control profile that blocks the P2P category to actually deny it.

Certificate inspection only validates the server certificate's identity and trust chain; it does not terminate the TLS session or decrypt the stream. Consequently, the FortiGate forwards the encrypted HTTP payload unchanged, and the antivirus engine sees only ciphertext. Since malware signatures cannot be matched against encrypted bytes, the antivirus profile simply cannot inspect what it cannot see, which is exactly why HTTP traffic appears to bypass scanning.

Proxy-based inspection is the correct mode because it buffers the entire file in memory before scanning, allowing FortiOS to perform a thorough, full-file signature analysis. This enables detection of threats embedded deep within archives, compressed files, or multi-part executables that could evade streaming methods. As a result, it provides the highest fidelity for antivirus detection, albeit with added latency proportional to file size.

Creating an application control profile with a rule that blocks the 'Facebook' application signature and assigning that profile to the firewall policy for all users is the correct method. FortiOS application control uses deep packet inspection and regularly updated signatures to identify Facebook traffic even when it uses alternate domains or IP addresses. Because the profile is applied to the policy, every matching session that is detected as Facebook will be blocked for all users.

DLP inspection requires proxy-based inspection because the firewall must reassemble and scan the full payload; flow-based inspection forwards packets without buffering content, so credit card patterns pass undetected. This satisfies the stem's constraint that the policy uses flow-based inspection.

Importing the vendor's private CA certificate into the FortiGate's trusted root CA store is the correct fix because the FortiGate acts as a TLS man-in-the-middle and must validate the vendor's server certificate chain before it can generate an on-the-fly session certificate for the client. Once that CA is trusted, the FortiGate successfully validates the vendor's certificate, completes its upstream TLS connection, and issues a client-facing certificate signed by the FortiGate's own CA, restoring full inline inspection without any warning. This centralized approach also avoids needing to touch the 500 client machines.

Adding the websites to the SSL/SSH exemption list in the deep inspection profile is the correct method because it instructs the FortiGate to skip decryption for those exact destinations. The FortiGate then forwards the TLS handshake untouched, so the browser sees the original site certificate and no certificate validation error occurs. All other HTTPS traffic continues to be deeply inspected, preserving overall security while solving the compatibility problem.

A DNS filter enforces a security policy by matching DNS queries against a real-time feed of malicious domains, including those used for malware, ransomware, phishing, and botnet C2 infrastructure. When a client attempts to resolve such a domain, the filter returns a denial (either a block page IP or a sinkhole IP) instead of the real record, preventing the connection before it is established. This proactive approach stops threats at the earliest stage of the communication chain, even if the client has no other security controls.

DNS Filter on FortiGate intercepts DNS queries and evaluates the requested domain against FortiGuard's threat intelligence categories, as well as administrator-defined allow and block lists. If the domain is categorized as malicious or prohibited, the FortiGate drops the query or returns a spoofed response, preventing the client from resolving the domain to an IP address. This is a proactive security control because it stops the connection before any traffic reaches the malicious server, even if the client already knows the IP via DNS pinning or a hosts file.

The core purpose of safe search is to enforce content filtering on supported search engines such as Google and Bing by appending safe search parameters or using DNS-based enforcement. This compels the search engine to omit adult or explicit material from result pages, aligning with an organization's acceptable use policy. FortiGate applies this through firewall policy profiles, ensuring users cannot disable it client-side.

Anomaly detection is the IPS technique that builds a statistical or machine-learning baseline of 'normal' network behavior by observing traffic patterns over time, including metrics like packet sizes, protocols, and session flows. Once the baseline is established, any significant deviation from that learned profile is flagged as an anomaly, potentially indicating a zero-day exploit or insider threat. This is the only method listed that fundamentally depends on a baseline of normal traffic to operate.

FortiGuard web-filtering categories assign websites to taxonomy classes, such as 'Social Networking', 'Video/Audio', and 'Webmail', based on the site's actual content. This allows FortiGate administrators to construct IPv4/IPv6 firewall policies and proxy policies that permit or deny entire content categories, optionally with per-user or per-time overrides. Because the categorization is content-driven, it enables fine-grained access control that adapts to the constantly changing web rather than relying on a simple list of URLs.