Dmesg inondé de journaux de pare-feu

8

Dans mes iptables, j'ai une règle qui enregistre les paquets perdus:

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

Et dans /etc/rsyslog.conf, j'ai une autre règle qui envoie ces journaux à un fichier dédié /var/log/firewall.log.

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

Le & ~supprime les journaux immédiatement, afin qu'ils ne soient pas inondés syslogou autres fichiers journaux.

Cela fonctionne bien, sauf qu'il inonde dmesgavec ces journaux de pare-feu (pas /var/log/dmesgmais la sortie de la commande dmesg).

Existe-t-il un moyen d'empêcher l'affichage de ces journaux dmesg?

logs iptables rsyslog

— Martin Vegter
source

Quel est l'intérêt de tout enregistrer de toute façon?

— 0xC0000022L

1

Ce n'est vraiment pas une bonne idée de consigner tous les paquets perdus. Mieux que d'éliminer les symptômes serait plus précis avec votre règle de journalisation. Par exemple, il n'est pas très judicieux d'enregistrer des paquets qui ne sont liés à aucune connexion et de ne rien faire de «spécial» (comme l'initiation de la connexion). Ce serait bien mieux de réduire cela à des choses pertinentes comme »l'hôte A voulait se connecter au port B«. Le nombre de raisons pour lesquelles un paquet est abandonné est potentiellement supérieur au nombre de raisons pour lesquelles vous le supprimeriez pour une raison pertinente .

— Andreas Wiese

1

@Andreas Wiese - J'ai simplifié ma règle pour cette question. Mes règles sont plus sophistiquées et spécifiques. Mais de toute façon, la question est de savoir comment éviter d' dmesgêtre inondé, pas sur les règles de pare-feu.

— Martin Vegter

Voir aussi cette réponse sur le démon de journalisation Netfilter ulogd2. C'est ainsi que j'ai résolu le problème.

— mivk

4

Vous pouvez utiliser la NFLOGcible au lieu de 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.

Tout ce dont vous avez besoin est un nfnetlink_logprogramme de journalisation performant. Les messages y iraient et le processus de l'espace utilisateur déciderait de consigner ou non le paquet.

Une autre chose que vous pourriez essayer serait de limiter la LOGrègle à un seuil spécifique:

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

Cela représenterait en moyenne 10 paquets par minute. Vous pouvez bien sûr ajuster cela à vos besoins.

— Andreas Wiese
source

Je n'ai pas pu trouver d'informations sur la configuration rsyslogde l'enregistrement des NFLOGpaquets. J'ai besoin d'une solution qui fonctionnera avec rsyslog.

— Martin Vegter

2

@MartinVegter - NFLOG fonctionnera avec rsyslog. Pour NFLOG, vous utiliseriez ulogd (je pense que ulogd2 est nécessaire) comme intermédiaire. Il écoutera sur le socket netlink pour obtenir les journaux et les livrera (tels que configurés) à syslog. Si ulogd2 n'est pas disponible, utilisez ulogd (1.x) et la cible ULOG.

— Christopher Cashell

0

Cela peut être lié au niveau de journalisation que vous utilisez dans iptables. Si je comprends bien, les niveaux du journal de documentation de rsyslog sont: "La priorité est l'un des mots-clés suivants, dans l'ordre croissant: débogage, info, avis, avertissement, avertissement (identique à l'avertissement), err, erreur (identique à l'erreur), critique, alerte, émergence, panique (comme émergence). " Qu'en est-il d'essayer de spécifier le niveau de journalisation dans iptables en utilisant son nom, c'est-à-dire «avis». Me sert bien pour poster sans vérifier car je pense maintenant que ce n'est pas du tout le problème. J'ai implémenté un schéma similaire à celui décrit ci-dessus et j'obtiens le même problème. Mon noyau centos 7 est la v3.10.0 et apparemment depuis la v3.5, il semble que la journalisation du noyau se fasse en utilisant / dev / kmsg et je suppose que dmesg obtient en quelque sorte son entrée à partir de là.

— VaughanR
source

0

Lorsque vous avez défini le niveau de journalisation sur 7 avec la commande:

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

Ensuite, vous pouvez simplement filtrer ces messages en passant le seuil de niveau au dmesg:

dmesg --level=err,warn

— de pointe
source

-7

Pourquoi est-ce que tu t'en préoccupes? dmesgest un outil de bas niveau pour imprimer les messages récents du noyau, et vous avez demandé au noyau de consigner les paquets perdus.

Configurez le système syslog de votre système pour enregistrer les messages iptables dans un fichier journal distinct des autres messages du noyau et utilisez les fichiers journaux qu'il écrit à la place dmesg.

— Colin Phipps
source