dmesg mit Firewall-Protokollen überflutet


8

In meinen iptables habe ich eine Regel, die verworfene Pakete protokolliert:

-A INPUT -i eth0       -j   LOG  --log-prefix "FW: " --log-level 7
-A INPUT -i eth0       -j   DROP

Und in habe /etc/rsyslog.confich eine andere Regel, die diese Protokolle an eine dedizierte Datei sendet /var/log/firewall.log.

:msg, contains, "FW: "                    -/var/log/firewall.log
& ~

Das & ~löscht die Protokolle sofort, damit sie nicht überflutet werden syslogoder andere Protokolldateien.

Dies funktioniert gut, außer dass es dmesgmit diesen Firewall-Protokollen überflutet wird (nicht /var/log/dmesgaber die Ausgabe des Befehls dmesg).

Gibt es eine Möglichkeit zu verhindern, dass diese Protokolle angezeigt werden dmesg?


Was bringt es überhaupt, alles zu protokollieren?
0xC0000022L

1
Es ist wirklich keine gute Idee, alle verworfenen Pakete zu protokollieren . Besser als die Beseitigung der Symptome wäre es, mit Ihrer Protokollierungsregel spezifischer zu sein. Zum Beispiel ist es nicht sehr ratsam, Pakete zu protokollieren, die sich nicht auf eine Verbindung beziehen, und nichts »Besonderes« zu tun (wie die Verbindungsinitiierung). Es wäre viel besser, dies auf relevante Dinge wie »Host A wollte eine Verbindung zu Port B herstellen« zu reduzieren. Möglicherweise ist die Anzahl der Gründe, aus denen ein Paket verworfen wird, massiv größer als die Anzahl der Gründe, aus denen Sie es aus einem relevanten Grund verwerfen würden .
Andreas Wiese

1
@Andreas Wiese - Ich habe meine Regel wegen dieser Frage vereinfacht. Meine Regeln sind ausgefeilter und spezifischer. Die Frage ist jedoch, wie eine dmesgÜberflutung verhindert werden kann, nicht die Firewall-Regeln.
Martin Vegter

Siehe auch diese Antwort zum Netfilter-Protokollierungsdämon ulogd2. So habe ich das Problem gelöst.
Mivk

Antworten:


4

Sie könnten das NFLOGZiel anstelle von verwenden LOG:

NFLOG
    This target provides logging of matching packets. When this  target  is  set  for  a
    rule, the Linux kernel will pass the packet to the loaded logging backend to log the
    packet. This is usually used in combination with nfnetlink_log as  logging  backend,
    which  will multicast the packet through a netlink socket to the specified multicast
    group. One or more userspace processes may subscribe to the  group  to  receive  the
    packets.  Like  LOG, this is a non-terminating target, i.e. rule traversal continues
    at the next rule.

Sie benötigen lediglich ein nfnetlink_logleistungsfähiges Protokollierungsprogramm. Nachrichten würden dorthin gehen und der Userspace-Prozess würde entscheiden, ob das Paket protokolliert werden soll oder nicht.

Sie könnten auch versuchen, die LOGRegel auf einen bestimmten Schwellenwert zu beschränken:

-A INPUT -i eth0 -m limit --limit 10/minutes -j LOG --log-prefix "FW: " --log-level 7
-A INPUT -i eth0 -j DROP

Dies würde im Durchschnitt 10 Pakete pro Minute protokollieren. Sie können dies natürlich an Ihre Bedürfnisse anpassen.


Ich konnte keine Informationen zum Konfigurieren rsyslogder Protokollierung von NFLOGPaketen finden. Ich brauche eine Lösung, die funktioniert rsyslog.
Martin Vegter

2
@MartinVegter - NFLOG funktioniert mit rsyslog. Für NFLOG würden Sie ulogd (ich denke, ulogd2 wird benötigt) als Vermittler verwenden. Es überwacht den Netlink-Socket, um die Protokolle abzurufen und sie (wie konfiguriert) an syslog zu senden. Wenn ulogd2 nicht verfügbar ist, verwenden Sie ulogd (1.x) und das ULOG-Ziel.
Christopher Cashell

0

Dies hängt möglicherweise mit der Protokollebene zusammen, die Sie in iptables verwenden. So wie ich es aus der rsyslog-Dokumentation verstehe, lauten die Protokollebenen: "Die Priorität ist eines der folgenden Schlüsselwörter in aufsteigender Reihenfolge: Debug, Info, Hinweis, Warnung, Warnung (wie Warnung), Fehler, Fehler (wie Fehler), kritisch, wachsam, emerg, Panik (wie emerg). " Wie wäre es mit dem Versuch, die Protokollebene in iptables mithilfe des Namens anzugeben, dh "Hinweis". Gut dient mir zum Posten ohne Überprüfung, da ich jetzt denke, dass das überhaupt nicht das Problem ist. Ich habe ein ähnliches Schema wie oben beschrieben implementiert und bekomme das gleiche Problem. Mein Centos 7-Kernel ist v3.10.0 und anscheinend seit v3.5 scheint die Kernel-Protokollierung mit / dev / kmsg durchgeführt zu werden, und ich gehe davon aus, dass dmesg irgendwie seine Eingabe von dort erhält.


0

Wenn Sie die Protokollstufe mit dem folgenden Befehl auf 7 gesetzt haben:

-A INPUT -i eth0       -j   LOG  --log-prefix "FW: " --log-level 7

Anschließend können Sie diese Nachrichten einfach herausfiltern, indem Sie den Pegelschwellenwert an dmesg übergeben:

dmesg --level=err,warn

-7

Wieso kümmert es dich? dmesgist ein einfaches Tool zum Drucken der letzten Kernel-Nachrichten, und Sie haben den Kernel gebeten, verworfene Pakete zu protokollieren.

Konfigurieren Sie das Syslog-System Ihres Systems so, dass iptables-Nachrichten in einer von anderen Kernel-Nachrichten getrennten Protokolldatei protokolliert werden, und verwenden Sie stattdessen die Protokolldateien, die es schreibt dmesg.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.