☰

RHEL/CentOS: Sollen jetzt beim Systemstart Nftable-Regeln zu Firewalld hinzugefügt werden?

tag-icon • tag-icon firewalld nftables
RHEL/CentOS: Sollen jetzt beim Systemstart Nftable-Regeln zu Firewalld hinzugefügt werden?

Ich verwende Firewalld auf RHEL 8 und muss auch einige Nftable-Regeln hinzufügen.

(Die nftable-Regeln basieren auf der Antwort aufCentOS 8 als NAT-Router mit nft und Firewalld – wie bringt man es dazu, TFTP zu bestehen?)

In einer laufenden Firewall funktioniert dies gut mit dem Befehl nft -f.

Bei einem Neustart gehen diese allerdings verloren.

DerRedHat-Dokumentation(hinter Paywall) schlägt vor, den Dienst nftables.service zu verwenden, um Regeln beim Neustart zu laden, aber das funktioniert nicht in Verbindung mit Firewalld. Die beiden Dienste werden als widersprüchlich aufgeführt, und selbst wenn dies nicht der Fall wäre, würde Firewalld wahrscheinlich die nftable-Regeln löschen.

Gibt es eine andere Möglichkeit, die Nftable-Regeln beim Neustart zu laden?

Antwort1

DerFirewallDienstprogramm, bei der Verwendung derNftablesBackend,wird keine Tabellen leeren, die nicht dazu gehören:

Leeren Sie nur die Regeln von Firewalld

Da nftables Namespaces zulässt (über Tabellen)Firewalld führt kein vollständiges Leeren der Firewall-Regeln mehr durch. Es werden nur Regeln im FirewallTabelle. Dadurch werden Szenarien vermieden, in denen benutzerdefinierte Benutzerregeln oder von anderen Tools installierte Regeln unerwartet gelöscht werden, wenn Firewalld neu gestartet oder neu geladen wird.

Das Gleiche muss bei der Verwaltung anderer Tabellen getan werden.

Tatsächlich ist es in der vorherigen Antwort bereits geschehen: dieNftablesRegeln löscht idempotentnurihre eigene Tabelle: handletftp.

Leider ist das nicht der Fall für nftables.servicediestoppenAktion:

ExecStop=/sbin/nft flush ruleset

Man muss nur sicherstellen, dass der Stop-Teil des systemd-Dienstes nicht direkt alle Regeln löscht, während er noch arbeitet. Dieser Job wird an dedizierteNftablesRegeln für diestoppenAktion.

Hier ist eine praktische Methode: Duplizieren Sie (zB: systemctl cat nftables.services) und ändern Sie es nftables.servicein eine instantiierte Version, [email protected]die in eingefügt werden soll :/etc/systemd/system/[email protected]

[Unit]
Description=Idempotent nftables rules for %I
Wants=network-pre.target
Before=network-pre.target

[Service]
Type=oneshot
ProtectSystem=full
ProtectHome=true
ExecStart=/sbin/nft -f /etc/nftables/idempotent/%I.nft
# As the rules are idempotent, ExecReload is same as ExecStart
ExecReload=/sbin/nft -f /etc/nftables/idempotent/%I.nft
# The stop rules should only have the first boilerplate parts
ExecStop=/sbin/nft -f /etc/nftables/idempotent/stop-%I.nft
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Erstellen Sie das oben verwendete dedizierte Konfigurationsverzeichnis:

mkdir -p /etc/nftables/idempotent

Platzieren Sie Regeln, die für jede definierte Tabelle immer so beginnen, so dass das Laden der Regeln unabhängig von anderen Tabellen ist undidempotent(Beispiel mit Tabellen ip foound bridge bar):

table ip foo
delete table ip foo

table bridge bar
delete table bridge bar

table ip foo {
    ...
}

table bridge bar {
    ....
}

oder verwenden Sie nur eine Tabelle pro Datei. Die flush rulesetAnweisung ist verboten, da sie global ist.

Der Grund, warum eine Tabelle erstellt, gelöscht und neu erstellt wird, ist, das Ergebnis idempotent zu erhalten: Während das Löschen einer nicht vorhandenen Tabelle ein Fehler ist und automatisch zum Fehlschlagen des gesamten Ladevorgangs führen würde, schlägt das Deklarieren einer vorhandenen Tabelle ohne sie zu definieren (durch Hinzufügen einer leeren Tabelle) nie fehl und bewirkt nichts.außer es leer zu erstellenwenn es vorher nicht existierte. In beiden Fällen (existierte beim Booten nicht, existiert beim Neuladen)löschenkann nun funktionieren, so dass der Platz frei wird, um die Tabelle direkt danach wirklich zu definieren. All dies geschieht in derselben Transaktion und ist immer noch atomar: Kein Paket wird jemals mit einem fehlendenIP-AdresseTabelle, falls sie zuvor vorhanden war.

Bereite ein ..... vorstoppenVersion von oben, die nur löscht (hier sind die leeren Deklarationen nicht unbedingt erforderlich und könnten entfernt werden, wenn es nur eine Tabelle gäbe, sollten aber beibehalten werden, wenn es mehr als eine Tabelle gibt: Ein Fehler betrifft die gesamte Transaktion):

table ip foo
delete table ip foo

table bridge bar
delete table bridge bar

und legen Sie alles an seinen Platz:

/etc/nftables/idempotent/foobar.nft
/etc/nftables/idempotent/stop-foobar.nft

Dieses lässt sich nun aktivieren mit:

systemctl enable --now local-idempotent-nft@foobar

Beispiel aus der Frage des vorherigen OP:

In /etc/nftables/idempotent/handletftp.nft:

table ip handletftp
delete table ip handletftp

table ip handletftp {
    ct helper helper-tftp {
        type "tftp" protocol udp
    }

    chain sethelper {
        type filter hook forward priority 0; policy accept;
        ip saddr 192.168.1.0/24 ip daddr 10.0.10.10 udp dport 69 ct helper set "helper-tftp"
    }
}

In/etc/nftables/idempotent/stop-handletftp.nft

table ip handletftp
delete table ip handletftp

Aktivieren und Starten:

systemctl enable --now local-idempotent-nft@handletftp

Stoppen:

systemctl stop local-idempotent-nft@handletftp

das wird verlassenFirewallRegeln vorhanden. Ebenso ist das Anhalten oder NeustartenFirewallwird diese Regeln in Kraft lassen.

Wahrscheinlich gibt es Verbesserungsbedarf:

  • Nftableshat eineenthaltenAnweisung, die irgendwie verwendet werden könnte, um eine Duplizierung von Standardtext zu vermeiden.
  • das spezielle Beispiel über TFTP beruht auf dem Laden von nf_nat_tftpwhich wird nicht automatisch durchgeführt (im Gegensatz zu nf_conntrack_tftpwhich wird automatisch aus der Referenz in den Regeln geladen oder im Gegensatz zuFirewalldie explizit geladen würde nf_nat_tftp). Also verwandt, aber nicht strengNftablesKonfigurationen sollten beachtet werden (diese eine Einstellung könnte einfach in eingegeben werden /etc/modules-load.d/).

verwandte Informationen