Firewall Regeln mit NFTables und RSyslog loggen

von | Jun 22, 2019 | Allgemein | 0 Kommentare

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
}

Folge uns auf

Zum Newsletter Archiv

Beiträge durchsuchen

Was unsere Kunden sagen

LastBreach
5.0
Basierend auf 10 Bewertungen
powered by Google
Bettina BöhmBettina Böhm
18:24 22 Jul 21
Vielen Dank für den ausführlichen Support!!! LastBreach ist absolut kompetent und empfehlenswert.
John RizosJohn Rizos
14:43 23 Mar 21
Sehr gut, sehr schnell, sehr freundlich, sehr professionell
Manfred MackManfred Mack
20:05 27 Jan 21
Herr Mohr hat uns sehr kompetent und schnell bei unseren komplexen IT Problemen geholfen.Eine Zusammenarbeit kann ich ohne Einschränkung empfehlenM.Mack
Marc SchleichMarc Schleich
13:50 16 Sep 19
Wir arbeiten seit einigen Jahren mit LastBreach in unterschiedlichen Projekten zusammen. War immer sehr agil und von hoher Qualität. Daher können wir die Kollegen absolut empfehlen.
Chris LekChris Lek
07:54 15 Sep 19
Ich habe in den letzten zwei Jahren mehrmals mit LastBreach zusammengearbeitet und kann Herrn Mohr und seine Firma sehr empfehlen. Herr Mohr und sein Team arbeiten professionell und zuverlässig, was... ich auch von eigenen Kunden als Feedback zurückbekam, die ich an LastBreach verwiesen habe.weiterlesen
js_loader