Inline protection puts Filter on the path of every visitor request. The Filter proxies a permitted request to the application and answers a blocked request itself. This is the placement that can stop an attack, in the same role as an IPS.
Complete Deploy the agents first. The direct test request to the Filter must already return 403.
The visitor opens the site name. DNS points that name at the Filter. The Filter analyzes the request and either returns the block page or proxies the request to the application and analyzes the response.
During the first cutover, detection mode keeps the request moving to the application and records the attack in WMC. Leave the site in waf_host_dm until the attacks page shows no mass false blocks on real traffic. Then remove the site from that option. While the site stays in waf_host_dm, the Filter only monitors and does not block.
In WMC, open WAF settings → Common, select the CID open Detection mode for the host. Add example.com. * applies detection mode to every host. The same option is waf_host_dm.
Detection mode writes the event to PostgreSQL and does not block the request. The other detection options, including per-URL and machine-learning switches, are in Detection mode.
In WMC, open Web server for the same CID. Replace 10.10.10.1 with the application address. The fields are described in Web server settings.
SSL → Add SSL Certificate. Name example.com. Paste the certificate and the private key.
Virtual hosts → Add a virtual host named example.com-http:
| Field | Value |
|---|---|
| server_name | example.com |
| listen | 80 |
| return | 301 https://$server_name$request_uri |
| Active | on |
Do not add a location. Save.
Add a virtual host named example.com:
| Field | Value |
|---|---|
| server_name | example.com |
| listen | 443 ssl |
| SSL certificate | example.com |
| Active | on |
Add location /:
| Field | Value |
|---|---|
| pass_type | proxy_pass |
| proxy_pass | http://10.10.10.1 |
proxy_set_header:
| Header | Value |
|---|---|
| Host | $http_host |
Save.
WebSocket and gRPC locations are in Configuring Filter as a reverse proxy.
When visitors connect to the Filter directly, skip this step: the Filter already sees their address. When a load balancer stands in front of the Filter, open Web server → Global settings → Header settings. Set real_ip_header to the header the balancer sends, usually X-Real-IP. Add the balancer address to set_real_ip_from. Save.
10.10.10.1 in that list is the load balancer. The details are in Displaying the real IP address of the visitor or the API client.
Change the DNS record of example.com so visitors reach the Filter. Requests to the application server that bypass the Filter are not analyzed.
Send the test signature through the site name:
curl -i https://example.com/mikiri-waf-test
While example.com is in waf_host_dm, the Filter does not answer 403. The event appears on the attacks page in WMC /var/log/mikiri-waf/filter/filter.log records signature ID 1.
Watch the attacks page on the site's real traffic. When there are no mass false blocks, remove example.com from waf_host_dm and send the test request again. The Filter answers 403 the request does not reach the application. If the host is left in waf_host_dm, later attacks are only recorded.
The machine-learning detection option is separate from waf_host_dm. Leave that option on until a behavioral model has been trained, then turn it off the same way. That sequence is in Activating AI protection.