TWAF stands for Transparent Web Application Firewall. The TWAF sits in front of the web server, inspects HTTP/HTTPS traffic, applies Modsecurity rules, and blocks or logs malicious requests before they reach the application and is primarily used to protect remote web servers, or special web applications that do not support modsecurity.
NOTE: Atomic Protector users do not need to setup the TWAF to protection a standard Apache installation on the system AP is installed on. On systems that meet this criteria the AP installer can install and manage modsecurity with Apache. The Atomic TWAF is only available to customers who have also purchased WAF licenses. To configure the TWAF, you must have Atomic Protector or Atomic WAF installed first. If you need assistance with this procedure, please contact Atomicorp support at support@atomicorp.com
In the Atomicorp UI, navigate to Integrations > TWAF Configuration
| Type | Where it runs | Best for | How it works |
|---|---|---|---|
| Remote Web Service | Customers that have remote web servers. | Traffic is inspected by the WAF engine, then forwarded to the remote web server. | |
| Local Web Service | Customers that are running web servers on the Atomic Protector system that do not support modsecurity | The WAF engine runs in front of the local web service. Note: this is not needed for Apache. Atomic Protector when installed on a system with a standard Apache installation can install and manage modsecurity. |
|
| Plesk | Protecting the Plesk web UI application | Protects the Plesk web UI from web attacks when used on the same system as Atomic Protector |
Local vs. Remote
| TWAF Type | Description | When to Use | Example |
|---|---|---|---|
| Remote Web Service | The web application is hosted on a different server than the TWAF. The TWAF acts as a reverse proxy, inspecting incoming requests before forwarding them to the remote backend server. | Choose this option when your web server or application resides on another physical server, virtual machine, or cloud instance. | A TWAF appliance at 10.0.0.10 protects a web application hosted on 10.0.0.25. |
| Local Service | The web application is hosted on the same server as the TWAF. Requests are inspected by the TWAF before being passed directly to the local web service. | Choose this option when the TWAF and the web application are installed on the same system. | A server running both TWAF and Apache or Nginx hosting www.example.com. |
Name Based vs. IP Based
-
Name Based (most common): Multiple websites share a single IP address. The TWAF uses the hostname (such as
www.example.com) to determine which backend application should receive the request. - IP Based: Each protected website has its own dedicated IP address. Requests are routed based on the destination IP rather than the hostname. This is typically used in environments where websites require separate IP addresses for networking or compatibility reasons.
| Field | Description |
|---|---|
| TWAF Type | Specifies the type of web application that the TWAF will protect. For example, Remote web service configures the TWAF to proxy requests to a web server hosted on another system. Other options (if available) may support different deployment scenarios. |
| Name or IP based | Determines how the virtual host is identified. Name based – Routes traffic based on the requested hostname (for example, www.sample.com). Multiple websites can share the same IP address.IP based – Routes traffic based on the destination IP address. This is typically used when each website has its own dedicated IP address. |
| Domain Name | The hostname that clients will use to access the protected website (for example, www.example.com). This field is required when using a Name based configuration and should match the site's DNS record. |
| Local URL | The local path on the TWAF that will receive incoming requests. In most deployments this is simply /, which forwards all requests to the backend application. A different path can be used if only a specific portion of the website should be proxied. |
| Remote Destination | The address of the backend web server that hosts the application. This can be a hostname or IP address, and may include a path if necessary. For example: http://192.168.1.10 or https://backend.example.com/app. |
| Remote Port | The TCP port on which the backend web server is listening. Common values are 80 for HTTP and 443 for HTTPS, but any valid web service port may be used. |
| Require SSL (Enable SSL) | When enabled, the TWAF accepts client connections over HTTPS instead of HTTP. This encrypts traffic between the client and the TWAF. If the backend server also uses HTTPS, the Remote Destination and Remote Port should be configured accordingly (typically port 443). |
Example Configuration
| Field | Example Value |
|---|---|
| TWAF Type | Remote web service |
| Name or IP based | Name based |
| Domain Name | www.atomicorp.com |
| Local URL | / |
| Remote Destination | http://192.168.1.50 |
| Remote Port | 80 |
| Require SSL | Enabled (if clients should connect using HTTPS) |