Wer mit Linux Servern arbeitet, dem ist iptables mit hoher Wahrscheinlichkeit ein Begriff. Die auf vielen Distributionen standardmäßig installierte Firewall wird jedoch mehr und mehr durch nftables ersetzt. Es gibt viele Gründe, die für nftables sprechen, genug, dass es für einen eigenen Beitrag reicht. In diesem Artikel möchte ich jedoch zeigen, wie das Logging unter NFTables in Kooperation rsyslog funktioniert. Denn wer eine neue Firewall im Blindflug einrichtet, macht sich selbst das Leben unnötig schwer.
NFTables Logging In der Grundeinstellung schreibt nftables überhaupt keine Logs. Wie auch bei iptables bereits, werden Logs über Regeln in der Konfiguration hinterlegt. Ich verwende dafür übrigens eine nftables Konfig-Datei, die mit sudo nft -f /pfad/zur/datei
eingespielt wird. Im Vergleich dazu setzen viele aus Gewohnheit noch auf Skripte, welche die Regeln nacheinander durch entsprechende Befehle hinzufügen. Das ist jedoch mit nftables nicht mehr notwendig.
Das Grundgerüst meiner Konfiguration sieht folgendermaßen aus.
$ cat /etc/nftables.conf
# Regeln für IPV4
table ip filter {
# Regeln für eingehenden Traffic
chain input {
# Eigentliche Regeln kommen hier hin
# - entfernt -
# Standard Richtlinie (Accept / Drop)
policy drop;
}
# Regeln für eingehenden Forwarding
chain forward {
# Eigentliche Regeln kommen hier hin
# - entfernt -
# Standard Richtlinie (Accept / Drop)
policy drop;
}
# Regeln für ausgehenden Traffic
chain output {
# Eigentliche Regeln kommen hier hin
# - entfernt -
# Standard Richtlinie (Accept / Drop)
policy drop;
}
}
...
Sie eigentlichen Accept-Regeln wurden entfernt, da diese für den Artikel nicht relevant sind. Die Standard-Richtlinie für alle Bereiche ist DROP. Um Logging zu aktivieren, kann an eine beliebige Regel das Schlüsselwort log
hinzugefügt werden. Da ich jedoch alles verbiete und nur bestimmte Protokolle explizit erlaube, ist es für mich interessanter zu sehen, was alles geblockt wird. Statt die einzelnen Regeln mit dem Schlüsselwort zu versehen, soll es deshalb der Richtlinie hinzugefügt werden. Das geht direkt im Anschluss zur jeweiligen Policy.
$ cat /etc/nftables.conf
# Regeln für IPV4
table ip filter {
# Regeln für eingehenden Traffic
chain input {
# Eigentliche Regeln kommen hier hin
# - entfernt -
# Standard Richtlinie (Accept / Drop)
policy drop;
# Aktiviert Logging für alle eingehenden Pakete die verworfen wurden.
log;
}
...
Soweit so gut, allerdings laufen diese Logeinträge direkt nach /var/log/syslog
und das ohne Anmerkung, worum es sich bei dem Eintrag eigentlich handelt.
Jun 22 13:35:19 hostname kernel: [6647383.426215] IN=eth0 OUT= MAC=aa:bb:cc:dd:ee:ff:00:11:22:33:44:55:66:00 SRC=192.168.0.2 DST=127.0.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=118 ID=2415 DF PROTO=TCP SPT=53000 DPT=445 WINDOW=8192 RES=0x00 SYN URGP=0
Es wäre doch viel schöner, wenn der Logeintrag noch die entsprechende Regel beinhalten würde. Das lässt sich in nftables über die Option prefix
regeln.
# Standard Richtlinie (Accept / Drop)
policy drop;
# Aktiviert Logging für alle eingehenden Pakete die verworfen wurden.
log prefix "nft.ip4dropinput ";
Das Prefix wird zu allen geloggten Einträge hinzugefügt.
Jun 22 13:35:19 hostname kernel: [6647383.426215] nft.ip4dropinput IN=eth0 OUT= MAC=aa:bb:cc:dd:ee:ff:00:11:22:33:44:55:66:00 SRC=192.168.0.2 DST=127.0.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=118 ID=2415 DF PROTO=TCP SPT=53000 DPT=445 WINDOW=8192 RES=0x00 SYN URGP=0
RSyslog
Jetzt wissen wir zwar, um welche Regel es sich bei dem Eintrag handelt, allerdings müllt nftables immer noch die Syslog-Datei zu. Mit rsyslog lässt sich das aber bequem beheben.
$ sudo vi /etc/rsyslog.d/nftables.conf
:msg,regex,"nft.ip4dropinput" -/var/log/nftables/ip4-input.log
Nach einen Neustart des rsyslog-Dienstes laufen alle Meldungen von nftables mit dem Prefix „nft.ip4dropinput“ jetzt in ihre eigene Datei im Verzeichnis /var/log/nftables/
. Das Gleiche lässt sich für die anderen Chains genauso umsetzen. Damit laufen alle Meldungen in die entsprechenden Logfiles und können leichter untersucht werden. Außerdem bleibt die Syslog-Datei den eigentlichen Systemmeldungen vorbehalten.
$ ls -lah /var/log/nftables/
total 208
-rw-r----- 1 root adm 263 Jun 22 13:41 ip4-forward.log
-rw-r----- 1 root adm 200455 Jun 22 13:41 ip4-input.log
-rw-r----- 1 root adm 1221 Jun 22 13:41 ip6-input.log
Logrotate
Damit unsere Festplatte mit all den neuen Meldungen nicht voll läuft, sollte zusätzlich noch eine Logrotate Regel eingerichtet werden.
$ sudo vi /etc/logrotate.d/nftables
/var/log/nftables/*
{
rotate 5
daily
maxsize 50M
missingok
notifempty
delaycompress
compress
postrotate
invoke-rc.d rsyslog rotate > /dev/null
endscript
}