Scan response on RHEL 10.2
November 10–11, 2026 · Lab report
We tested DAV NGWAF on a RHEL 10.2 lab VM, with a Raspberry Pi on the same network generating scan and test traffic. The VM used nftables to enforce bans, with XDP attached for one run of the controlled comparison.
Probe traffic and firewall response
In the November 10 paced lab run, the Raspi launched nine HTTP requests at 250 ms intervals. The first three returned HTTP 404. The next six timed out. The kernel excerpt records five TCP SYN packets from the Raspi hitting the DAV ban rule on port 80.
| Probe side · Raspi client log | Defense side · kernel journal (UTC) |
|---|---|
| 0, 250 and 500 ms · HTTP 404 | No matching DAVCO_BAN entries in the kernel excerpt for this phase. |
| 750, 1,000, 1,250, 1,500, 1,750 and 2,000 ms · curl timed out | DAVCO_BAN at 12:19:47.793490, 12:19:48.043923, 12:19:48.293610, 12:19:48.543528 and 12:19:48.794105. |
Client times are relative to the first request. The ban rule allows a burst of up to five log entries and replenishes that allowance at three per minute. The drop rule runs independently of logging, so the five journal entries are a sample of packets that reached the ban rule. The kernel lines identify TCP connections by source port. These excerpts support a comparison by phase of the run. Matching individual requests to packets requires a shared connection identifier.
What the detector saw
| Probe side | Defense side |
|---|---|
Separate November 10 lab probe · GET /.env · HTTP 404 from the server | At 12:10:33.196167 UTC, the detector logged blocklist_regex. At 12:10:33.275930 UTC, the journal recorded the ban-ip invocation. The test first observed the ban at 12:10:33.465114 UTC. |
Ban membership was observed about 269 ms after the detector entry. That interval includes the wait for the next membership check.
How DAV NGWAF responded to scanning
| Lab test | Observed response | Evidence |
|---|---|---|
| Gobuster directory scan | Detector triggered a ban | All eight requests reached NGINX before the ban took effect. Ban membership was observed at 12:15:23 UTC on November 10. |
| Paced HTTP requests | Requests began timing out after the ban | First timed-out request launched at 500 ms in 9 trials and 750 ms in 1 |
| Open HTTP connection | Next request after the ban was blocked | nftables drop counter rose from 0 to 4. A fresh request returned HTTP 200 after unban. |
The Gobuster run and the paced series were separate tests. The ten-trial series ran with XDP detached. The open-connection test used nftables in an isolated network namespace.
How quickly the ban took effect
| Measurement | Result | Clock starts at |
|---|---|---|
| Successful nftables insertion acknowledgment | 349 ms median · 126–404 ms observed range · 10 trials | Detector journal entry |
| Launch of first request that timed out | 500 ms in 9 trials · 750 ms in 1 trial | Initial probe |
The client launched a request every 250 ms. The client measurement records the launch time of the first request that timed out, with a 250 ms sampling interval.
Where the packets were dropped with XDP on and off
On November 11, the Raspi requested the same benign page during a temporary source-IP ban in both runs. The firewall was in drop mode and the detector ran in monitor-only mode. The XDP program used generic mode on the lab interface.
| Run | Client result during ban | XDP drops | nftables drops |
|---|---|---|---|
| XDP attached | No HTTP response · 2.999997 s | 0 → 3 | 0 → 0 |
| XDP detached | No HTTP response · 3.001047 s | Detached | 0 → 3 (180 bytes) |
With XDP detached, the kernel logged three TCP SYN packets with the same source port, consistent with retries for a single connection. The XDP run recovered to HTTP 200 in 2.333 ms after cleanup. After the nftables-only ban expired, the same request returned HTTP 200 in 2.382 ms.
Each run used one request and a three-second curl timeout. The counter changes show where packets were dropped. Measuring enforcement latency requires timing the drops themselves.