How bans reach the kernel
Enforcement
Enforcement is optional and off by default. When enabled, banned IPv4 addresses are dropped by an nftables table that DAV owns, with an optional XDP layer in front. The engine itself never touches the firewall.
DAV's own nftables table
DAV loads a single table, ip davco4, atomically from a package file. It contains:
- a protected set, always checked first, so listed addresses are never affected;
- a banned addresses set with a 48-hour timeout per entry;
- a banned subnets set, currently log-only;
- an input chain at priority
filter - 10that logs matches at a limited rate and, in drop mode, drops them.
An nftables drop is final across tables, so a DAV ban takes effect even though firewalld accepts established connections in its own tables. DAV never accepts traffic on firewalld's behalf and never edits firewalld's rules: everything DAV doesn't drop is still evaluated by the host firewall.
kernel-modules-extra, which the certification scan reports as unmaintained, and Red Hat recommends nftables or firewalld instead.
The native nftables table uses only supported RHEL components.Log mode and drop mode
A validated mode setting selects log (matches are logged, nothing is dropped) or drop. Log mode lets an administrator watch what would be blocked before enforcing.
The ban action
The engine reaches enforcement only through the root helper /usr/libexec/dav-ngwaf/davco-ip-enforce, which accepts a fixed set of
actions (test, ban, unban, connection cleanup). For every request it:
- validates the argument as a single IPv4 address, refusing protected and private addresses unless policy allows them;
- uses fixed set names, never taken from arguments, and runs its tools directly without a shell;
- serializes changes with a file lock and writes an audit line to the system journal;
- removes the banned source's existing connection-tracking entries, so open connections end immediately.
The engine tracks addresses it has already banned and does not call the helper again for them, which keeps floods from generating repeated privileged calls.
Optional XDP layer
An XDP program can drop banned addresses at the network interface, before netfilter. It is installed disabled and enabled only by the administrator. Native XDP requires driver support; generic mode works on any interface. A reconciliation timer keeps the XDP map consistent with the nftables set.
Measured timing
| Measurement (RHEL 10.2 lab, XDP detached) | Result |
|---|---|
| Detector journal entry to successful nftables insertion | Median 349 ms, range 126–404 ms, 10 trials |
| First timed-out client request, at one request every 250 ms | Launched 500 ms after the probe in 9 trials, 750 ms in 1 |
| Request on an already-open HTTP connection after the ban | Blocked by nftables alone (test server in an isolated network namespace) |
| XDP attached versus detached | With XDP, packets were dropped before nftables saw them; without it, nftables dropped them |
Detection is log-based, so the first requests of a fast burst are answered before the ban lands. Full method and timestamps: lab report.
Scope
Enforcement currently covers IPv4. IPv6 is planned as a separate table so the two can be loaded and rolled back independently.