Problème de logs iptables (redirigées à 2 endroits)

Support Debian
#1

Hello, j’ai un petit souci que je n’arrive pas à résoudre, quand j’active les logs :

iptables -A INPUT -j LOG 
iptables -A FORWARD -j LOG

Je me retrouve avec de la log dans kern.log (ce qui est normal), mais également la même dans syslog.log. Ce qui d’une part n’est pas propre, mais en plus sature mon /var (du moins mes alertes braillent tout le temps).

J’ai bien fouillé sous /etc/rsyslog.d/* pour voir où était configuré la sortie de ces logs, mais je ne le vois nulle-part.

Quelqu’un aurait-il une idée ? Idéalement, je voudrais avoir mes logs iptables juste dans 1 fichier de logs spécifique et détaché du reste.

Ce problème se pose seulement sur deux Ubuntu 14.04.

Mon 50-default.conf :

auth,authpriv.*                 /var/log/auth.log
*.*;auth,authpriv.none          -/var/log/syslog
kern.*                          -/var/log/kern.log
mail.*                          -/var/log/mail.log
mail.err                        /var/log/mail.err
news.crit                       /var/log/news/news.crit
news.err                        /var/log/news/news.err
news.notice                     -/var/log/news/news.notice
*.emerg                                :omusrmsg:*
daemon.*;mail.*;\
        news.err;\
        *.=debug;*.=info;\
        *.=notice;*.=warn       |/dev/xconsole
#2

La cible LOG écrit dans les logs du noyau. Par défaut les logs du noyau sont écrits à la fois dans kern.log et dans syslog.
On doit pouvoir configurer le syslog pour n’envoyer les logs du noyau que dans l’un ou dans l’autre, mais je ne sais pas faire.

Le syslog a peut-être des options pour envoyer certains logs dans un fichier particulier en function d’un en-tête ou autre critère distinctifs.

Ou bien tu peux utiliser la cible NFLOG au lieu de LOG et enregistrer les logs avec le démon ulogd2.

#3

Merci pour ton retour, du coup ça me rassure. Je trouve ça quand même limite que par défaut il y est cette contrainte d’enregistrer une même info dans deux endroits…

J’ai essayé ce qui est expliqué ici, mais sans succès, tout est toujours envoyé aux 2 même endroits.

Disons que le log prefix apparait bien dans la ligne de log iptables, mais la redirection vers le fichier ne fonctionne pas. J’analyse et fais un retour quand j’ai trouvé, ça peut être l’objet d’une astuce.

…

Bon, je sèche, voici ma conf :

root@vpsxxxx:/etc/rsyslog.d# cat 10-iptables.conf
:msg, startswith, "IPTables : " -/var/log/iptables.log
& ~

root@vpsxxxx:/etc/rsyslog.d# ls -altrh /var/log/iptables.log
-rw-r–r-- 1 syslog root 0 juin 12 09:45 /var/log/iptables.log

Mais à l’envoi de la commande suivante : iptables -A INPUT -j LOG --log-prefix "IPTables : "

Tout part toujours dans kern.log et syslog.

Chose étrange, j’ai lu que normalement le redémarrage de rsyslog créé le fichier iptables.log, or chez moi, si je supprime ce dernier et redémarre rsyslog, il ne recréé rien du tout.

La seule façon d’avoir un résultat qui va, c’est d’aller modifier le 50-default.conf (voir le mien plus haut) en virant tous les messages * de kern et syslog pour envoyer uniquement les kern.warn dans iptables.log.

Alors, oui, ça marche, mais c’est pas correct car ça ne me dit pas pourquoi la syntaxe utilisée dans mon 10-iptables.conf n’est pas prise en compte ! Par ailleurs, avec la méthode citée plus haut (redirection kern.warn dans iptables.log), je vais me retrouver avec des trucs qui n’ont rien à voir avec de la log firewall.

…

J’ai essayé cette solution là :

.;auth,authpriv.none;kern.=!kern.warning -/var/log/syslog
kern.;kern.*=!kern.warning -/var/log/kern.log
kern.=warning -/var/log/iptables.log

Mais pas mieux. Disons que que là, iptables.log se remplit bien, mais les 2 autres aussi, comme si l’exception ajoutée ;kern.*=!kern.warning n’était pas prise en compte.

#4

Il est pourtant courant que les mêmes messages se retrouvent dans plusieurs logs, comme syslog, daemon.log, messages… Je suppose qu’il y a des raisons historiques à cela.

Je ne peux pas t’aider avec la configuration de rsyslogd, ce n’est pas mon rayon.

#5

J’utilise shorewall couplé a ulogd2, c’est beaucoup plus simple.

#6

Pas besoin de shorewall, on peut utiliser ses propres règles avec la cible NFLOG.