DEV Community

Lia
Lia

Posted on

How to Check WAF Attack Details After a Blocking Page Appears

#waf #security #troubleshooting #deployment

A blocking page tells you that a request was stopped. Investigating what happened requires a second step: finding the corresponding attack in the administration console. SafeLine's application setup guide explicitly documents this workflow: open the web console, inspect the attack list, and click "detail" to view a specific attack. Official application guide

This guide explains how to set up that investigation workflow, confirm that your application traffic passes through SafeLine, and review a block without jumping straight to a configuration change.

1. Prepare access to the administration console

If SafeLine is already installed, start with its existing administration console. For a new deployment, first verify the documented prerequisites: Linux, a supported x86_64 or arm64 architecture, Docker 20.10.14 or later, Docker Compose 2.0.0 or later, and at least one CPU core, 1 GB of memory, and 5 GB of disk space. The deployment guide also lists an ssse3 CPU requirement. ARM installations require a Pro license; the Personal Edition is not supported on ARM. Official installation guide

Follow the official installation procedure for your environment. The documented web console address is https://<safeline-ip>:9443/. For initial administrator access, the guide provides this command:

docker exec safeline-mgt resetadmin
Enter fullscreen mode Exit fullscreen mode

Use the administrator credentials returned by that command to sign in. If you already have working administrator access, proceed with that account. Official installation guide

2. Configure the application and its traffic path

In the SafeLine Web Admin Console, open "Applications" and select "Add Application". Enter the application's domain, the port SafeLine should listen on, and the upstream address of the original application. For an HTTPS application, select the SSL option. Then resolve the configured domain to the IP address of the SafeLine server. These are the application setup steps documented by SafeLine. Official application guide

This traffic path matters during troubleshooting. SafeLine acts as an HTTP/HTTPS reverse proxy: it receives requests, filters malicious traffic, and forwards acceptable traffic to the upstream application. An investigation should therefore begin by checking which hostname and route the browser actually used. Official application guide

3. Capture the circumstances of the block

When the blocking page appears, record the approximate time, hostname, requested path, and action that triggered it. For example, note whether you submitted a form, opened a saved URL, or performed an authorized security test.

Keep this as an investigation note. Avoid copying passwords, session cookies, or sensitive form contents into a shared ticket. The purpose is to preserve enough context to identify the request and explain the user's intent.

For a controlled setup check, use only an application you own or are authorized to test. SafeLine's application guide supplies example attack requests and explains that seeing its blocking page during those tests indicates that SafeLine defended against the request. Official application guide

4. Open the attack list and select "detail"

Return to the SafeLine web console and inspect the attack list. Find the entry corresponding to the blocked request, using your recorded context and whatever information the console presents. Click "detail" to open the specific attack details. This is the exact investigation entry point described in the supplied documentation. Official application guide

The supplied guide does not enumerate the fields displayed in that view. Treat the actual record as your evidence, and avoid assuming that a particular request identifier, payload field, export option, or search filter is available.

5. Review the evidence before changing protection

Compare the selected entry with the action that produced the blocking page. Establish whether you are investigating an expected security test, an unexpected request, or a legitimate application operation that needs further review.

If you cannot confidently connect an entry to the browser event, verify the application configuration and traffic path again. Do not change protection settings simply to make the blocking page disappear. First document the observed behavior and the evidence supporting your conclusion.

FAQ

Where do I find attack details after a SafeLine blocking page?

Open the SafeLine web console, inspect the attack list, and click "detail" for the relevant attack. Official application guide

Does a blocking page prove that the request was malicious?

It establishes that the request was blocked. Determining whether it was an expected test, unwanted traffic, or a legitimate operation requires reviewing the request context and available evidence.

Can I look up an attack using an identifier from the blocking page?

The supplied documentation does not describe an identifier-based lookup procedure. Use the documented attack-list and "detail" workflow without assuming that capability exists.

What should I check if I cannot find the corresponding attack?

Recheck the hostname, approximate time, configured application, DNS destination, and upstream settings. SafeLine's documented setup requires the application domain to resolve to the SafeLine server, which then proxies traffic to the upstream application. Official application guide

SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.

Top comments (0)