Global

The Service Global page includes the following sections. Click on the link to go to the corresponding section to learn more:

• Global
  • L7 source-based blocking
  • Advanced signature model
  • Response logging
  • Response inspection
  • Server ID
  • HTTP request throttling
    • Max HTTP request rate throttling zones
    • Website settings
  • HTTP connection limiting
    • Max HTTP connections limiting zones
    • Web site settings
  • Distributed Denial of Service protection
    • How it works
      • Hourly Traffic Profiling
      • Anomaly Detection
      • Coordinated Response
    • Protect all Websites
    • DDoS Protection Configuration
      • IP address limits in AWS
      • IP address limits in Azure
    • Baseline monitoring
  • SSL
  • HTTP global request limits
  • HTTP global settings
    • Core worker shutdown timeout
    • Core worker CPU affinity
  • HTTP error log level
  • HTTP global access logging
  • Syslog violation alert format
    • Log Format
    • Extend with headers
  • Proxy protocol
  • HTTP global security options
    • Enable Emerging Threats virtual patches for all websites
  • GeoIP lookup order preference
    • Available Lookup Orders
  • Custom IP lists
    • Uploading a List
    • Best Practices

To go to the documentation for the previous section of Services, see Websites. To go to the documentation for next subsection in the Services section, see Network .

To manage website security profiles, under Services on the left panel, click Websites to go to the Website Overview page, and then click the Global tab.

To save configuration changes or edits you make to any features and options, you must click Save on the lower-right of the section or page where you are making changes. Click apply changes on the upper-left corner of the page, and then click OK. Your changes will not be stored if you do not properly save your changes.

Global HTTP settings that affect all websites.

L7 source-based blocking

When a client source IP is deployed behind a layer 7 proxy (for instance, a load balancer), the original client source IP becomes lost. This happens because the proxy (or proxies) terminates the requests that pass through before reaching Alert Logic Managed Web Application Firewall (WAF) and then reconnects to WAF on behalf of the client. The connection source IP, as seen from WAF, will then be the source IP of the proxy. Since all requests appear as if they come from the proxy before they reach WAF, source IP based blocking controls apply to the proxy, and consequently all traffic is blocked.

If you want to use source IP based blocking controls, you can configure WAF to enforce the controls at the application layer instead of at the network layer. When an IP is blocked, WAF does not send a response to a request. This is the equivalent of "silent drop" at the network level.

The controls are enabled or disabled by a global master switch. When enabled, blocking is either enabled for single websites or enforced for all websites with a global master switch.

Advanced signature model

The global Advanced signature model options affect all websites and control the version in use and the version update policy. Also, to test the potential impact of using a more recent version, these options can show differences between the version in use and the more recent version can be logged without blocking.

Response logging

Enable the response logging option for individual websites. Response logging is a requirement for response inspection.

When response logging is enabled, the server response will be included with the deny log record for violations that were detected but not blocked.

Enable response logging for all websites will enable response logging for all websites.

Response inspection

Response inspection in Fortra WAF is a post-processing security feature that analyzes server responses for anomalies, data leakage, or signs of compromise. However, it is important to understand its operational boundary:

Key Characteristics:

• Selective Activation: Response inspection is only triggered for requests that are allowed through the WAF and subsequently generate a response. If a request is blocked by a policy, no response is returned from the backend, and thus no inspection occurs.
• Violation-Driven: Even among allowed requests, only those that trigger a violation (e.g., a rule match in log-only mode) are subject to response inspection. This means the feature is not universally applied to all responses, but rather selectively engaged based on policy configuration.
• Best Used in Detect Mode: Because response inspection depends on violations being logged (not blocked), it is most effective in Detect mode. In Protect mode, where violations result in blocked requests, the response never materializes and cannot be inspected.
• Baseline Comparison: WSM builds a baseline of normal responses for specific request types. When a response is inspected, it is compared against this baseline to detect anomalies such as:
  • Unexpected content (e.g., injected scripts)
  • Sensitive data exposure (e.g., debug info, stack traces)
  • Structural deviations (e.g., altered headers or formats)

For a more thorough description of Response Inspection, metrics, and configuration options, see Response inspection.

Server ID

The server ID is the name of the server that is sent in the response header "Server," and is also called the server banner. Alert Logic recommends you hide, mask, or alter the server banner.

The server id can be set for each website proxy, or globally for all websites.

HTTP request throttling

HTTP request throttling tracks client request rate across all websites and enforces configured limits. When WAF is configured to be aware of receiving the request from proxies at the application layer (Trusted proxy), these controls are transparently enforced at the application layer.

Max HTTP request rate throttling zones

Client request rate is tracked across website proxies using four global databases, throttling zones. To account for different usage patterns, throttling limits are defined separately for each global throttling zone.

Website settings

HTTP connection limiting

HTTP connection limiting tracks client connection concurrency across all websites and enforces configured limits.

When WAF is configured to be aware of receiving the request from proxies at the application layer (Trusted proxy), these controls are transparently enforced at the application layer.

Client connection concurrency is tracked across website proxies using four global databases, connection limiting zones. To account for different usage patterns, connection limits are defined separately for each global limiting zone.

Distributed Denial of Service protection

Fortra’s WAF uses hourly traffic baselining over a trailing 7-day window to detect and mitigate distributed denial-of-service (DDoS) attacks with precision.

How it works

Hourly Traffic Profiling

The WAF continuously monitors incoming HTTP/S request volumes and builds a baseline of expected traffic levels for each hour of the day, based on the previous 7 days of observed traffic. This enables it to:

• Capture consistent hourly usage patterns.
• Adapt to evolving traffic trends over time.

Traffic data is collected from the CloudFront, ALB, or Azure load balancer that distributes traffic to the protected websites and the WAF’s instances. This is also the resource where ACLs will be enabled to fend off the attack.

Anomaly Detection

By comparing real-time traffic to these hourly baselines, the WAF can:

• Detect unexpected spikes or sustained increases in request volume.
• Trigger mitigation only when deviations exceed statistically significant thresholds, minimizing false positives.

Coordinated Response

When anomalies are detected, the WAF can:

• Apply IP filtering or challenge-response mechanisms to suspected sources.
• Push protection upstream by integrating with AWS or Azure DDoS mitigation services, ensuring volumetric attacks are intercepted before reaching the application layer.

Protect all Websites

If one protected website is in risk of a DDoS attack, we recommend enabling DDoS protection for all websites.

Since web traffic to protected websites passes through the same logical chokepoints (load balancer, WAF) and the same backend web servers may be serving requests for different protected domain names, an attack targeting one of the protected domain names can affect the others as well because it may take down chokepoints or the servers and thus, affect the others as well. Traffic load is therefore profiled and tracked at the resource level (i.e., ALB, CloudFront, LB), not individual websites.

To be effective, a DDoS response depends on what type of clients are allowed pass through the defenses. For websites intended for human users, CAPTCHA or JavaScript challenges are known to be effective. For APIs, IP filtering is recommended since API clients have no human “behind the wheel” to solve a CAPTCHA and are typically incapable of executing JavaScript.

To enable a differentiated response based on website type, DDoS protection is enabled globally (in this section) but the response is configured and enabled for individual websites in Website Global Policy.

DDoS Protection Configuration

IP address limits in AWS

In AWS a WebACL IP restriction rule references an IP Set. A WebACL can have multiple rules.

A total of 500,000 IP addresses is possible.

• IP Set Size Limit: Each IP set can contain up to 10,000 IP addresses.
• Web ACL Rule Limit: A Web ACL can have up to 50 rules that reference IP sets.
• Total IPs Across Rules: If each rule references a different IP set, the total number of IP addresses you can configure across all rules is up to 500,000.

IP address limits in Azure

In Azure, Front Door rules consist of match conditions which reference IP address ranges. Match conditions are logically AND’ed, so each rule can only contain one IP address range since a request can only have one source IP.

A total of 60,000 IP addresses is possible

• IP Addresses per Match Condition: Up to 600 IP addresses per match condition.
• Custom Rules per Front Door WAF Policy: Up to 100 custom rules in a single Front Door WAF policy.
• Total IP Ranges per Policy: With 100 rules × 600 IP ranges each, you can configure up to 60,000 IP address ranges in total across a WAF policy.

Baseline monitoring

The Traffic baseline section and the IP whitelist meta data table display sampling progress. The latter can be used to determine the ideal limits on IP whitelists.

SSL operations consume extra CPU resources. The most CPU-intensive operation is the SSL handshake.

There are two ways to minimize the number of these operations per client:

This section applies to optimizing SSL by configuring SSL session timeouts and the SSL session cache.

HTTP global request limits

Request limits control the size of the HTTP request body (AKA, “POST payload”) and maximum deny log message size.

HTTP global settings

At its core, Fortra WAF is based on the NGINX proxy engine. NGINX uses a multi-process architecture consisting of:

• Master process: Manages configuration, spawns worker processes, and handles signals (e.g., for reloads or shutdowns).
• Worker processes: Handle actual client requests. Each worker is single-threaded and uses asynchronous, non-blocking I/O to handle many connections efficiently.

Core worker shutdown timeout

Controls the timeout for graceful configuration reload and restart of worker processes.

When changes are made to the policy or proxy configuration of a website, the master process spawns a new set of workers with the new configuration, and then sends a QUIT signal to each of the old workers. This tells the workers to:

• Stop accepting new connections.
• Finish processing existing connections.
• Exit once all work is done.

This reload process ensures zero downtime as existing connections can finish while new workers are brought up with the new configuration.

However, if old workers are prevented from quitting because of long running connections such as WebSocket or HTTP/2 stream, worker processes can potentially pile up and consume excess resources.

Therefore, workers are forcibly quit if existing connections are not completed within this configurable timeout (defaults to 60 seconds).

Core worker CPU affinity

To improve performance under load, worker processes are bound to specific CPU cores. This can improve performance by:

• Reducing CPU cache misses.
• Avoiding unnecessary context switching.
• Improving predictability under high load.

This option is enabled by default.

HTTP error log level

Sets the log level for proxy core engine error logging to the Proxy log, in Logs under System.

HTTP global access logging

Enable or disable debug access logging. When enabled, every website configured on an appliance keeps an access log that is rotated every three days. These logs are available in the WAF log directory prefixed with "debug." When normal access logging is enabled for a website, WAF does not log to the debug file.

Syslog violation alert format

Syslog violation alerts are excerpt log messages generated from the deny log of individual websites.

As with other syslog messages, violation alerts can be sent to an external syslog server. The alerts are sent to the Local3 facility.

Log Format

Select the format of the deny log violation alerts. The options are:

• Standard: Basic format containing core alert information:

  • risk: Risk level of the alert

  • event: Attack class classification

  • proxy: Proxy name

  • proxy_id: Numeric proxy identifier

  • log_id: Unique log entry identifier

  • source: Source IP address

  • violation: Type of security violation

  • path: Request path

  • method: HTTP method

  • node: WAF hostname

  • action: Action taken

  • time: Syslog timestamp

• Correlation: Extended format that includes additional fields beyond Standard:

  • ref_id: Reference identifier for correlation

  • cc: Country code of source IP

• Extended: Most comprehensive format that includes all fields from Correlation plus:

  • headers: Select request headers as configured in the Extend with headers input

    Headers are included as name=value pairs and empty header fields are included as empty quoted strings.

All formats output structured key-value pairs suitable for log parsing and analysis.

Extend with headers

List of request headers to include in the violation alert message.

The headers are extracted from the raw HTTP request, so case matters.

Proxy protocol

Alert Logic allows you to enable proxy protocol for all listen address, which is designed to safely transport connection information without losing any information. Enabling proxy protocol allows WAF to work with multiple layers of NAT or TCP proxy protocols, does not require infrastructure changes, has no impact on NAT firewalls, and is scalable.

Enabling proxy protocol is not necessary unless you are configuring both communicating endpoints. If you have configured the other communicating endpoint to proxy protocol, you can enable proxy protocol in the WAF.

HTTP global security options

Options to apply a virtual patch and other security configuration to all websites.

Enable Emerging Threats virtual patches for all websites

When enabled, the Emerging Threats virtual patch group will be enabled for all websites.

The Emerging Threat program at Fortra is a proactive, intelligence-driven initiative designed to identify, assess, and mitigate newly discovered or evolving cybersecurity threats. It spans multiple Fortra product lines, including Fortra WAF.

A key operational component is the Emerging Threats virtual patch group, which is enabled by default in Fortra WAF. These patches are crafted to respond to zero-day exploits and are released ASAP after threat identification, typically within five hours. Each patch is rule-based, combining “Discriminate” and “Detect” conditions to ensure high precision and minimal false positives.

GeoIP lookup order preference

The GeoIP Lookup Order Preference setting enables the sequence configuration in which the system resolves and prioritizes geographic location data for an IP address. This setting is essential for tailoring how location-based policies, analytics, and threat intelligence are applied.

This setting determines the order in which the system evaluates three distinct geographic attributes associated with an IP address:

• Represented Country: The country on whose behalf the IP is being used (e.g., via VPN or proxy).
• Registered Country: The country where the IP address is officially registered.
• Country (Located): The physical location of the IP address (based on geolocation data).

Available Lookup Orders

The following predefined sequences are available:

• Represented Country → Registered Country → Country (Located)
• Represented Country → Country (Located) → Registered Country
• Registered Country → Represented Country → Country (Located)
• Registered Country → Country (Located) → Represented Country
• Country (Located) → Represented Country → Registered Country
• Country (Located) → Registered Country → Represented Country

Default selection: Represented Country → Registered Country → Country (Located).

Custom IP lists

The Custom IP Lists feature in Fortra WAF enables configuration of organization-specific IP address lists. These lists can be referenced in L7 Source IP and Geolocation-based controls, which define how incoming connections are classified and managed based on their origin.

Custom IP lists support granular traffic management by enabling the classification of source IPs into Source Classes. These classes can then be mapped to Control Groups, which define specific handling behaviors such as:

• Allowing or denying access
• Applying rate limits
• Triggering CAPTCHA challenges

This mechanism is part of a broader two-step control model:

• Source Classification – IPs are grouped into Source Classes using uploaded custom lists.
• Control Application – Source Classes are mapped to Control Groups that define enforcement actions.

The Custom IP lists table shows information about uploaded lists:

• Name: Identifier for the uploaded list.
• IP Count: Number of IP addresses in the list.
• Last Update: Timestamp of the most recent upload or modification.
• Size: File size of the uploaded list.

If no lists have been uploaded, the table displays the message: “No custom IP lists found!”

Uploading a List

To upload a new IP list:

1. Click Upload IP list.
2. Choose a file containing the IP addresses. The file must be newline separated, one IP per line.
3. Confirm the upload. Once processed, the list will appear in the table and can be referenced in Source Class definitions.

Best Practices

• Use clear, descriptive names for each list (e.g., Partner_Networks_EU, HighRisk_ExitNodes).
• Validate the file format and IP syntax before uploading to avoid errors.
• Review and update lists regularly to reflect current operational and threat intelligence needs.
• Ensure that uploaded lists are correctly referenced in Source Class configurations to activate their effect in traffic control policies.