Advanced Firewall Support

[troglobit]

Description

Umbrella task and brainstorming topic for advanced firewall features, including outstanding TODO's from #448

• Support ipsets, with RPC support for dynamic blocking/allowing IPs in an ipset

• Integrate fail2ban, see below design proposal

• Investigate fail2ban integration with firewalld, for more info, see:
  Firewalld ignoring rich-rule against port forwarding firewalld/firewalld#1466 (comment)

• firewalld helpers -- possibly for conntrack, e.g., ftp

• With modprobe br_netfilter firewalld would see all traffic, but there are issues,
  It is impossible to add a rule accepting bridge traffic with FirewallBackend=nftables firewalld/firewalld#1236,
  and limits to what seem to be possible atm. You may also need to enable these callbacks:

  echo 1 | sudo tee /proc/sys/net/bridge/bridge-nf-call-iptables
  echo 1 | sudo tee /proc/sys/net/bridge/bridge-nf-call-ip6tables
  echo 1 | sudo tee /proc/sys/net/bridge/bridge-nf-call-arptables
  

• Investigate filtering out firewall log messages from other log files

  • Possible with the upcoming sysklogd 3.0 release

• Podman published ports, https://firewalld.org/2024/11/strict-forward-ports

• Software fastpath https://firewalld.org/2023/05/nftables-flowtable

Additional Information

No response

General Information

Anyone can help out by sponsoring development of new features or contributing pull requests.
Please use this issue for discussions related to the feature.

[troglobit]

Building fail2ban-style banning on top of address-sets

With address-set support merged, the enforcement half of fail2ban already exists. This note sketches how a log-driven banning mechanism plugs into it, what falls out for free, and what a full integration would still need.

Enforcement is already in place

A ban is a single NACM-checked action invocation:

rpc "/infix-firewall:firewall/address-set[name='banned-ssh']/add" entry 203.0.113.99

This is the same rpc tool the CLI firewall address-set command uses, so any local watcher gets the full stack for free: the entry lands in the kernel set, the drop zone kills the traffic, the kernel expires the ban after the set's timeout, and the ban is visible with a countdown in show firewall address-set, in NETCONF/RESTCONF operational data, and on the WebUI firewall status page.

Factory wiring is one set per jail plus a block zone:

firewall {
  address-set banned-ssh { timeout 600; }
  address-set banned-web { timeout 3600; }
  zone blocked {
    action drop;
    address-set banned-ssh;
    address-set banned-web;
  }
}

Bantime is set-level, so per-jail bantimes fall out naturally as per-jail sets. Since source matching takes precedence over interface matching, a banned IP is dropped no matter which interface zone it would otherwise land in.

Crucially, unban logic does not exist -- that is the kernel's job. A watcher that crashes, restarts, or loses its database cannot leak permanent bans, because nothing it creates outlives the timeout. That property is what makes the design a good fit for embedded systems.

What is missing: the detection side

Three realistic shapes, in increasing weight:

1. Homegrown log tailer. A small Finit-supervised script tails auth.log (or the dedicated firewall log sysklogd 3 can split out), counts matches per source IP in a sliding window, and calls the rpc add when the threshold trips. ~100 lines, no new packages, and the only state is counters -- losing them is harmless. Covers the common "ban SSH brute-forcers" case.

2. sshguard. A small C daemon built for exactly this, with firewall backends that are plain sshg-fw-* shell commands -- wrapping one around the rpc call is a ten-line script. An order of magnitude lighter than fail2ban, parses sshd and friends out of the box.

3. fail2ban proper. The action layer is pluggable: a custom action with actionban = rpc .../add entry <ip> and actionunban = /bin/true, with the jail bantime set equal to the set timeout so fail2ban's bookkeeping and the kernel agree on when bans end. This is essentially what Firewalld ignoring rich-rule against port forwarding firewalld/firewalld#1466 converges toward -- except the Infix action layer already solves the "reload wipes runtime bans" problem those users are fighting. The cost is a Python daemon on an embedded box; only worth it for the jail/filter ecosystem.

Whichever detector is used, it should run as a dedicated user whose NACM rules grant exec on the add action and nothing else.

Eventual YANG-facing configuration

If this graduates to a product feature, a small container ties it together, with the detector's config generated from the datastore the same way the firewall config is:

firewall {
  intrusion-prevention {
    jail ssh {
      match-service ssh;
      max-retry 5;
      find-time 600;
      address-set banned-ssh;
    }
  }
}

Detection config in the datastore, ban state in operational, nothing new to invent.

Caveats to design around

• No early unban. Timeout sets refuse remove and flush (the entries are tracked only by the kernel), so "unban this customer now" means waiting out the bantime -- or touching the firewall config, which flushes all timeout sets: a crude all-or-nothing amnesty button. If per-IP early unban matters, keep bantimes short and let re-offense re-ban.

• Whitelisting belongs in the detector, not the firewall. Racing an accept-zone source against a drop-zone source turns on zone-ordering subtleties; the robust pattern is an ignoreip-style list in the watcher -- never ban the management network in the first place.

• Config changes flush timeout sets. Documented behavior of the address-set implementation. Acceptable for banning: offenders re-ban themselves on the next attempt.