Configuration

Network

Basic network configuration is performed in this section. Any changes made to this section are applied and saved by clicking on the Save" button.

Hostname Input field	Domain name of the Web Security Manager Alert Logic Managed Web Application Firewall (WAF). Valid input Fully qualified domain name. Input example `proxy.mydomain.com` Default value `None`
Default gateway Input field	IP address of the default gateway. Valid input IP address assigned must be in the same network subnet as the IP address of one of the physical network interfaces. Input example `192.168.0.1` Default value `None`
DNS server(s) Input field	IP address of one or more DNS servers. Valid input IP addresses Use space to separate multiple hosts (only one required). Input example `192.168.0.2` Default value `None`
SMTP server Input field	SMTP server hostname or IP address. SMTP server is used for sending alert e-mails to the contact e-mail address specified. Valid input IP address or fully qualified domain name Input example `smtp.mydomain.com` Default value `None`

Static routes

Define static routes.

Click Add new route and enter route information for each route you want to add.

When routes are entered click Save settings in lower button bar to save.

Destination

Input field

The route destination.

Enter first IP address of destination network.

Valid input

A valid ip address.

Input example

192.168.5.0
192.168.6.8
192.168.7.10

Default value

None

Subnet

Input field

Network mask of the destination IP address.

Valid input

A valid network mask

Input example

255.255.255.0
255.255.255.248
255.255.255.255

Default value

None

Gateway

Input field

IP address of the gateway through which the destination can be reached.

Valid input

An IP address of a gateway which is directly reachable by the Web Security Manager node.

Input example

192.168.0.4
192.168.0.5
192.168.0.6

Default value

None

The examples above would result in:

Access to IP addresses 192.168.5.0-255 (192.168.5.0/24) is routed through the gateway 192.168.0.4.
Access to IP addresses 192.168.6.8-16 (192.168.6.8/29) is routed through the gateway 192.168.0.5.
Access to IP address 192.168.7.10 (192.168.7.10/32) is routed through the gateway 192.168.0.6.

Date and Time

This section is used for configuration of time synchronization via NTP (Network Time Protocol).

It is strongly advised to configure an NTP server in order to have the correct date and time set on the system.

It is recommended to configure an internal NTP interface. If one is not available, a well-known NTP server time.nist.gov can be used.

Timezone

Drop down list

Timezone information.

Select the systems timezone from the drop down menu.

Valid input: A timezone option from the drop down list.
Default value: Europe/Copenhagen

Date format

Drop down list

Display dates in logs and reports in Month-Day-Year or Day-Month-Year format.

Select the date format from the drop down menu.

Valid input: An option from the drop down list.
Default value: Month-Day-Year

SNMP

Configure threshold level and address of external Syslog server.

Enable SNMP queries Check box	Enable or disable SNMP daemon. If checked, Web Security Manager will accept SNMP queries on the first of the IP addresses to which management is bound.
Public community Input field	Public community password. The read-only community password. Valid input Any string Input example `wdbhhaiedb` Default value `public`
System location Input field	Information about the system. Valid input Any string Input example `Facility 1, Server room 1` Default value `none`
Listening on Read only	If SNMP is enabled will display the IP address the SNMP daemon is listening on.

Admin contact

Update notifications, attack alerts and system errors can be sent by email to the admin contact email address.

Contact

Input field

E-mail address of the administrative contact.

All alert e-mails and notifications are sent to this address.

You need to define an SMTP server before any e-mails are sent.

Valid input: E-mail address
Input example: admin@mydomain.com
Default value: admin@mydomain.com

Sender domain

Input field

The e-mail address domain.

If not configured it will be extracted from the contact e-mail.

Valid input: a valid domain
Input example: mydomain.com
Default value: extracted from contact

Email system alerts

Critical events or conditions are logged both locally and to external syslog server (if enabled). However if an external syslog server is not available (or is not monitored) a subset of (potentially) critical alerts can be sent to the designated admin contact email.

Email system error messages to admin contact Check box	Enable or disable sending of error messages altogether. If checked, selected alert types will be sent.
Disk and memory Check box	If checked, disk and memory related errors at log level ERROR and CRITICAL will be sent.
Cluster interface events Check box	If checked, cluster interface related errors at log level ERROR and CRITICAL will be sent. The most common cluster interface event is STATE TRANSITION which, when sent by the worker node in a cluster, indicates that the master node is either down (backup > master) or has resumed operation (master > backup). When the nodes in a cluster are powered on/off or rebooted state transition messages are also logged to the syslog error log and may generate email alerts.
Administrative daemons Check box	If checked, any error at log level ERROR and CRITICAL from administrative daemons will be sent.

Forward HTTP proxy

Configure forward proxy to be used by the update system when connecting to the update server.

Use proxy for outbound HTTP Check box	Enable or disable the configured forward proxy.
Proxy address Input field	The address of the forward proxy Valid input A valid ip address. Input example `10.10.10.5` Default value `None`
Proxy port Input field	Proxy port number Valid input An TCP/IP port number Input example `8080` Default value `none`
Forward proxy authentication required Check box	Enable if forward proxy requires authentication.
Username Input field	User name used for authenticating to the Proxy. Valid input A valid username Input example `wsm1` Default value `none`
password Input field	Password to authenticate the proxy user.

Backup configuration

This section is used to configure an FTP/SCP server used for automated configuration backup/restore of Web Security Manager configuration.

FTP configuration

FTP server Input field	FTP hostname or IP address. Valid input IP address or fully qualified domain name Input example `ftp.mydomain.com` Default value `None`
FTP port Input field	FTP server port number Valid input An TCP/IP port number Input example `21` Default value `21`
Login Input field	Username used for login. FTP account used must be able to store files on the remote FTP server. Valid input A valid username Input example `wsm_backup` Default value `none`
Password Input field	Password used for SCP login. Valid input Any string. A long password is recommended as it do not have to be memorable by humans. Input example `s984ROf.dds&fdsfs)afa8343287` Default value `none`
Remote directory Input field	Full path to directory on FTP server used for storing Web Security Manager related files. Valid input A directory path ending with / Input example `/ftp/wsm/` Default value `none`

SCP configuration

SCP server Input field	SCP hostname or IP address. Valid input IP address or fully qualified domain name Input example `ftp.mydomain.com` Default value `None`
SCP port Input field	SCP server port number Valid input An TCP/IP port number Input example `21` Default value `21`
Login Input field	Username used for login. SCP account used must be able to store files on the remote SCP server. Valid input A valid username Input example `wsm_backup` Default value `none`
SCP key Button	Click Download Web Security Manager Public SCP Key to download key used for authentication. Make sure to add this key to the authorized keys list on the remote server.
Remote directory Input field	Full path to directory on SCP server used for storing Web Security Manager related files. Valid input A directory path ending with / Input example `/scp/wsm/` Default value `none`

Auto-backup

Auto-backup, if enabled, is performed daily at 03:00 AM based on your current timezone settings.

Enable FTP auto-backup

Check box

Enable or disable FTP auto-backup.

If checked, automated FTP configuration backup will be active.

Enable SCP auto-backup

Check box

Enable or disable SCP auto-backup.

If checked, automated SCP configuration backup will be active.

Management user password requirements

Manage password requirements, session and login restrictions and SSL certificate.

Minimum length Input field	Minimum password length in number of characters Valid input Number in the interval 6 to 64 Default value `8`
Letter characters required Check box	Require one or more letter character, a-z + international.
One or more digits (0-9) required Check box	Require one or more digits.
Combination of upper and lower case required Check box	Require a combination of upper and lower case characters.
Non alphanumeric characters required Check box	Require one or more special (non-alphanumeric) characters.

Management GUI login restrictions

Idle timeout Input field	Number of seconds the management GUI can be idle before the user is logged out. Valid input timeout in seconds 20 to 86400. Input example `900 - 15 minutes` Default value `600`
Failed login delay Input field	Number of seconds to wait after a failed login attempt before a new attempt can be made. Valid input timeout in seconds 0 to 60. Default value `3`
Failed logins limit Input field	Number of failed login attempts allowed before the failed login action is taken. Valid input Number of attempts 1 to 100. Default value `5`
Failed logins action Dropdown	What to do if a user exceeds the failed logins limit. Options: None No action Lockout The user account is locked for the configured duration. After the configured the duration the user account is unlocked and the user can log in. Suspend The user account is suspended and cannot be used until is the account status has been set to OK by an administrator. User account status can be set in System : Users or in the console (see CLI reference manual for more information). Valid input `None, Lockout, Suspend` Input example `Lockout` Default value `None`
Notify user on lockout and suspend Check box	If enabled, user will receive an error message in the login page if the account has been locked or suspended.
Suspend inactive accounts Check box	Enable suspending of accounts that has not been active for a specified duration.
Account inactivity threshold Input field	Number of days a user account can be inactive before it is automatically suspended. Valid input Duration in days 1 to 1000. Default value `90`

Management GUI certificate

Management GUI SSL certificates can either be self signed or imported certificates.

In the SSL certificate section the current SSL certificate in use is displayed. To upload a new certificate click the Manage GUI certificates button.

Generate self-signed SSL certificate

To generate a self signed certificate, enter the certificate information in the input fields.

Click Save settings in the lower button pane.

Importing the PKCS12 format

If the certificate is in the PKCS12 format follow the guidelines below:

Enter the path to the certificate file in the PKCS12 file input field.
Enter Passphrase in the Passphrase input field.
Click Save settings in the lower button pane.

If Validate certificate chain is enabled Web Security Manager will validate and order the chain certificates.

Importing the PEM format

If the certificate is in the PEM format follow the guidelines below:

Open the .PEM file in a text-editor. Copy the public certificate section of the certificate.

The public key/certificate is the section of the certificate file between (and including) the certificate start and end tags. Example:
```
-----BEGIN CERTIFICATE-----
 Certificate characters
-----END CERTIFICATE----- 
```
Select Import SSL certificate In the Web Security Manager management interface

Paste the SSL public key/certificate into the SSL-certificate field.
Now copy the (SSL) private key section of the certificate. The (SSL) private key is the section of the certificate file between (and including) the private key start and end tags. Example:
```
-----BEGIN RSA PRIVATE KEY-----
 Private key characters 
-----END RSA PRIVATE KEY-----
```
Enter the passphrase for the private key in the passphrase field (if the original private key was encrypted).
If a certificate authority chain is provided with your certificate enter the entire list of certificates (more than one certificate may be provided) in the SSL authority certificate(s) chain field

If Validate certificate chain is enabled WAF will validate and order the chain certificates.

FIPS 140-2 validated mode

WAF provides the option for the appliance in the customer environment to be locked down to only run the OpenSSL FIPS Object Module in FIPS 140-2 validated mode (FIPS 140-2 certificate #1747).

The lockdown to FIPS 140-2 mode, including validation of the integrity of the FIPS validated crypto modules, is automated, irreversible, and locks down the operating system (CentOS) to run in FIPS 140-2 validated mode as originally specified in the OS provider’s (Red Hat Inc.) FIPS 140-2 certificate #1758.

When the option is selected, the applicable package and libraries are converted to FIPS mode, library pre-linking is disabled, and the WAF appliance reboots. After the appliance has rebooted, all communication occurs using only the FIPS-validated algorithms and the appliance will only accept and use FIPS validated encryption for all inbound and outbound communication to and from all services on the appliance. This includes the WAF HTTP proxy service, the appliance’s HTTPS web based UI, and SSH services used to remotely access the underlying appliance.

Validation of FIPS mode

When the WSM appliance is using only FIPS-validated encryption modules, the WSM User Interface running on the appliance displays the label FIPS mode. The FIPS mode label reflects the value of

/proc/sys/crypto/fips_enabled

Which is computed at startup when the system performs the self tests as required in the FIPS 140-2 certificate Security Policy.

If the self test validation at startup fails the system and crypto modules are not running as required for FIPS validated mode and the FIPS mode label is not displayed in the appliance UI.

Enabling FIPS 140-2 validated mode

When enabling FIPS mode:

The appliance is converted and locked down irreversibly to run in FIPS mode.
Depending on the disk size the conversion process will take between 2-10 minutes.
When the conversion process is finished the appliance will reboot.
During the process proxy services will be available and website availability will not be affected until the appliance reboots.

To enable FIPS 140-2 validated mode

Tick the box Enable FIPS mode
Click the button Convert appliance into FIPS mode

The system will now display a confirmation dialog that outlines the conversion process.
Confirm that the appliance is irreversibly converted to FIPS mode.

The conversion process begins.
Log out of the UI and log in again to have the FIPS mode validation label displayed.

The FIPS mode validation flag that is displayed in the appliance user interface is stored in the currently logged in session in the UI layer so to have the mode validation label displayed immediately after conversion is is necessary to log in again to read the setting from /proc/sys/crypto/fips_enabled.

In Amazon Web Services Auto Scaling deployments, the FIPS mode is embedded in the AMI that the auto scaling stack is built from. Consequently, the user interface option to convert the appliance to FIPS validated mode is not available. The configuration of FIPS validated mode and self test at startup to validate are no different from non-auto scaling WSM deployments.

Data Anonymization

The Fortra WAF Data Anonymization feature ensures that client-related log data is irreversibly obfuscated before being written to disk. This applies to all data, whether it is classified as Personally Identifiable Information (PII) or Protected Health Information (PHI), with specific exceptions. To protect the feature from accidental disabling, its configuration can be permanently locked.

Scope

The feature operates at a system-wide level, ensuring comprehensive anonymization across all instances. Sensitive data is anonymized before storage or transmission, enhancing security and compliance.

Anonymization applies to the entire logical WSM instance (master + worker instances).
All data is anonymized before being:
- Written to storage.
- Sent to the Alert Logic/Fortra backend.

Requirements Coverage

By complying with GDPR de-identification standards, the anonymization process fulfills some of the strictest global regulations for data protection. This ensures robust compliance and extends to jurisdictions with similar requirements.

The method satisfies GDPR de-identification requirements using the preferred method of data masking.
GDPR requirements are among the strictest globally; satisfying them also ensures compliance with PII data protection laws that mirror or are subsets of GDPR.
Because the data is irreversibly masked, GDPR does not apply to anonymized information.

Method

The anonymization process is designed to render data completely and irreversibly anonymous. This removes it from the scope of GDPR, as outlined in Recital 26, ensuring that anonymized data is no longer tied to identifiable individuals.

This process:

Renders complete and irreversible anonymization of value elements in data.
Moves data out of GDPR scope as per Recital 26:
- "The principles of data protection should therefore not apply to anonymous information, namely information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable." Reference: https://www.privacy-regulation.eu/en/recital-26-GDPR.htm

Reversibility

Anonymization is implemented as a one-way process, ensuring it cannot be undone. Once the feature is enabled and locked, the data cannot be restored or de-obfuscated through standard methods.

The operation is one-way and irreversible, applying to the entire WSM instance.
Once enabled and locked, the change cannot be undone using API or UI methods.

Risk coverage

The anonymization feature is designed to mitigate risks associated with standard operations and external data exposure. However, it does not protect against malicious actions by highly privileged users.

Risks covered:

Normal use
Data visibility ("eyes on")
Data leaving the appliance

Risks not covered:

Rogue admin with root privileges and skills to modify code or install unauthorized software on the instance.

Feature trade-offs

While the anonymization feature significantly enhances data protection and GDPR compliance, it introduces certain functional limitations. These limitations affect features that rely on detailed client data.

If source IP obfuscation is enabled (to comply with GDPR requirements):

Controls based on the client source IP will not work.
Application profiling/learning will be disabled if Data Anonymization is enabled.

Obfuscation method

The obfuscation process ensures that sensitive data is anonymized while preserving the semantic structure of requests. Specific data fields are exempted to maintain system functionality and efficiency.

Digits (\p[N]) replaced with digit 9.

Letter (\p[L]) replaced with letter A.
Combinations replaced with letter H.
Resulting string length is randomized.
Client source IP is reduced to a class C, B, or A network (/24, /16, /8).

The following request data is exempt from obfuscation:

Strings matching reserved words in signatures.
Request path.
Request element names such as the HTTP method (verb) and version.
Request parameter names/keys mapped for specific requests during parsing (but not their associated values).
Request header names mapped for specific requests during parsing.
Request header values exempt as per exemption list.

Log sources

Anonymization is applied across multiple log sources, each with tailored rules to ensure data protection. These rules limit the inclusion of sensitive data while maintaining necessary system logs.

Deny log:

Request data written to instance storage.
Response data written to instance storage.
Request data written to customer storage (e.g., S3 repository).
Response data written to customer storage.

Access log:

Custom access log data format is unavailable (to prevent fields containing PII from being included).
Source IP reduced to /24 network.
URL components (path + query string/'GET parameters') are replaced with the path only.

Learn data:

Learning is disabled and cannot be re-enabled.

Error log:

Client requests are not included in error messages.

Configuring Data Anonymization

Request data exempt from obfuscation:

Enable Data Anonymization Check box	Select this check box to enable data Anonymization. When enabled, log data will be irreversibly obfuscated before being written to disk.
Source IP Masking Dropdown	Source IPs are anonymized by applying a netmask. Options are: Off No source IP anonymization /24 Source IPs are reduced using a class C netmask – 10.11.12.13 becomes 10.11.12.0 /16 Source IPs are reduced using a class B netmask – 10.11.12.13 becomes 10.11.0.0 /8 Source IPs are reduced using a class A netmask – 10.11.12.13 becomes 10.0.0.0
Exceptions Input fields	By default, all input elements that contain information specific to the client request are anonymized – regardless of the information being confidential or not. To preserve the semantic structure of the request and not sacrifice exploit/attack related information, the header and input parameter names, URL path, and violation specific strings are exempt from anonymization (see “Obfuscation Method” above). If additional named request elements are required to be exempt from anonymization, these can be added as exceptions in the Exceptions table. Item Name of the input element Example: User-Agent Type Type of input element Example: Header
Log Data Export Check box	Allow unredacted log data export. When enabled, log data will be exported (eg. S3 log exports) in its original form and prior to anonymization.

Lock data anonymization

Once Data Anonymization is configured and enabled, it should be locked down to prevent an admin user from disabling or reconfiguring it, and consequently put WAF log data back in scope of privacy requirements.

Once enablement or configuration of Data Anonymization is locked, it cannot be disabled again through the console or API.

Prevent data anonymization from being disabled

Check box

Lock enablement of Data Anonymization.

Prevent data anonymization from being disabled

Check box

Prevent Data Anonymization from being changed.

It is strongly recommended that Data Anonymization configuration is validated before locking the configuration. For instance, enabling IP masking will disable source IP-based controls and should therefore only be considered if absolutely required. If configuration is locked, enabling source IP masking cannot be undone.