Comment supprimer les messages net-fw des logs système ?

xuo Membre non connecté
-
- Voir le profil du membre xuo
- Inscrit le : 23/10/2011
- Groupes :
J'ai énormément de lignes du type :
Sep 8 16:43:37 ordi4 kernel: [153829.427314] net-fw DROP IN=enp4s0 OUT= MAC=80:ee:73:63:54:a6:68:a3:78:1b:f3:1e:86:dd SRC=2a04:4e42:001d:0000:0000:0000:0000:0729 DST=2a01:0e0a:0016:6150:82ee:73ff:fe63:54a6 LEN=103 TC=0 HOPLIMIT=55 FLOWLBL=831047 PROTO=TCP SPT=443 DPT=57766 WINDOW=59 RES=0x00 ACK PSH FIN URGP=0
dans les fichiers /var/log/messages et /var/log/syslog.
Savez-vous comment faire pour qu'elles ne soient pas écrites dans ces fichiers ? Elles ne m'apportent rien et me remplissent les logs.
Merci.
Xuo.

Jybz Membre non connecté
-
- Voir le profil du membre Jybz
- Inscrit le : 10/10/2018
- Groupes :
-
Administrateur
-
Forgeron
Téléverser une image : /wiki/hebergement-de-fichiers-sur-mlo
Arch | Machine | OS |
x86_64 | lenovo x250 | mga9 |
armv7hl | bananapro | mga9 |
aarch64 | Raspberry Pi 4B | mga9 |

xuo Membre non connecté
-
- Voir le profil du membre xuo
- Inscrit le : 23/10/2011
- Groupes :
Non, je ne pense pas, je ne sais pas ce que c'est. Je pense que ces messages sont liés au firewall de Mageia.
Xuo.

nic80 Membre non connecté
-
- Voir le profil du membre nic80
- Inscrit le : 06/08/2018
- Groupes :
-
Modérateur
@ Jybz: pourquoi jami en particulier ( je n' ai pas vu de port de destination dans les ports utilisés )
Comme il y a presence d' ipv6, je regarderais les options de demarrage de shorewall (ce qui n'empêche pas de regarder ce qui génère ce traffic. L'adresse IPV6 est sur le réseau local ? (freebox ?), voir des régles (mais j' ignore comment vérifier ceci)

xuo Membre non connecté
-
- Voir le profil du membre xuo
- Inscrit le : 23/10/2011
- Groupes :
Oui, j'ai du ipv6 sur le réseau local. Pourquoi, je ne sais pas. Et je ne sais pas l'enlever. Si je passe la souris sur l'applet network, je vois mon adresse ipv4 et une adresse ipv6.
J'ai une Freebox.
J'ai supprimé la vérification du balayage de ports dans drakfirewall (ainsi qu'une autre option juste au-dessus mais je ne me rappelle plus son nom) mais chaque fois que je relance drakfirewall, les 2 options sont à nouveau sélectionnées.
Ce soir, je peux essayer de lancer le drakfirewall pour ipv6 (il me semble qu'il y a quelque chose comme ça dans le MCC) et voir s'il est possible de le désactiver.
Merci.
Xuo.

xuo Membre non connecté
-
- Voir le profil du membre xuo
- Inscrit le : 23/10/2011
- Groupes :
Je reviens sur ce post que j'avais un peu laissé tomber.
J'ai toujours dans mon fichier /var/log/messages un nombre incalculable de lignes du type :
Jan 4 14:12:14 ordi4 kernel: [237555.158330] net-fw DROP IN=enp4s0 OUT= MAC=80:ee:73:63:54:a6:b8:27:eb:f8:4e:ee:08:00 SRC=192.168.0.5 DST=192.168.0.14 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=45315 DF PROTO=TCP SPT=52634 DPT=8895 WINDOW=29200 RES=0x00 SYN URGP=0
Si je fais un :
iptables -L | grep LOG
Je vois que j'ai :
LOG all -- anywhere anywhere limit: up to 1/sec burst 10 mode srcip LOG level info prefix "net-fw DROP "
Dans le fichier /etc/shorewall.conf, j'ai essayé de changer la ligne :
LOG_LEVEL="info"
à successivement :
LOG_LEVEL="warning"
LOG_LEVEL="notice"
LOG_LEVEL=2
mais ça ne change strictement rien à ce qui s'écrit dans /var/log/messages (à chaque fois je faisais un systemctl restart shorewall).
Est-ce le bon fichier pour modifier le log level des iptables ?
Merci.
Xuo.

nic80 Membre non connecté
-
- Voir le profil du membre nic80
- Inscrit le : 06/08/2018
- Groupes :
-
Modérateur
J' ai remarqué également que j' ai des entrées dans la sortie de journalctl et /var/log/messages ( bien que mon fichier /etc/shorewall/shorewall.conf indique uniquement /var/log/messages).
Dans le fichier de service systemd (/usr/lib/systemd/system/shorewall.service) , il y a cette ligne:
Citation :
StandardOutput=syslog
Est ce que cela pourrait expliquer que le /var/log/messages continue à se remplir ?

xuo Membre non connecté
-
- Voir le profil du membre xuo
- Inscrit le : 23/10/2011
- Groupes :
C'est possible. Mais pour moi, que ça aille dans /var/log/messages ou dans /var/log/syslog ou dans les 2, ce n'est pas très grave (encore que je préfère tant qu'à faire qu'un seul fichier se remplisse plutôt que les 2).
Ce que je voudrais, c'est que les seules informations loguées soient celles de type warning, erreur, ... pas celles de type info ou notice qui n'apportent pas grand-chose.
Xuo.

xuo Membre non connecté
-
- Voir le profil du membre xuo
- Inscrit le : 23/10/2011
- Groupes :
J'ai essayé de commenter "StandardOutput=syslog" dans /usr/lib/systemd/system/shorewall.service ou "LOGFILE=/var/log/messages" dans /etc/shorewall/shorewall.conf mais ça ne change rien. Les lignes sont toujours écrites dans les 2 fichiers. Et j'avais LOG_LEVEL= "warning" dans /etc/shorewall/shorewall.conf.
Xuo.

nic80 Membre non connecté
-
- Voir le profil du membre nic80
- Inscrit le : 06/08/2018
- Groupes :
-
Modérateur
Dans le fichier /var/lib/shorewall/.iptables-restore-input, il y a présence de cette ligne ( je suppose que iptables-restore charge ce fichier) :
-A net-fw -m hashlimit --hashlimit-upto 1/sec --hashlimit-burst 10 --hashlimit-name lograte --hashlimit-mode srcip -j LOG --log-level 6 --log-prefix "net-fw DROP "
il faudrait trouver le fichier qui génère cette ligne dans la configuration de shorewall, afin de le changer. Peut être le fichier /etc/shorewall/policy ?

xuo Membre non connecté
-
- Voir le profil du membre xuo
- Inscrit le : 23/10/2011
- Groupes :
J'ai modifié le fichier /etc/shorewall/policy mais sans que ça change quoi que ce soit. Pas de chance ...
Xuo.

xuo Membre non connecté
-
- Voir le profil du membre xuo
- Inscrit le : 23/10/2011
- Groupes :
En fait en modifiant les fichiers /etc/shorewall/policy et /etc/shorewall.conf, ça ne change rien au contenu des fichiers /var/log/messages et /var/log/syslog.
Par contre, les fichiers /var/log/kernel/info.log et /var/log/kernel/warnings.log et /var/log/errors.log sont mis à jour en fonction du contenu des fichiers de /etc/shorewall.
Donc mon problème serait plutôt à chercher du côté de syslog de façon à ce que les messages du kernel ne soient pas écrits systématiquement dans /var/log/messages et /var/log/syslog. Parce que 3 fichiers, ça commence à faire beaucoup ...
Xuo.

nic80 Membre non connecté
-
- Voir le profil du membre nic80
- Inscrit le : 06/08/2018
- Groupes :
-
Modérateur
3 fichiers uniquement ?
C' est en comptant ce qui est listé dans la sortie de journalctl ?
Parce que si je lis la doc de systemd.exec, j' ai:
Citation :
StandardOutput=
Controls where file descriptor 1 (STDOUT) of the executed processes is connected to. Takes one of inherit, null, tty, journal, syslog, kmsg, journal+console, syslog+console, kmsg+console, file:path, append:path, socket or fd:name.
inherit duplicates the file descriptor of standard input for standard output.
null connects standard output to /dev/null, i.e. everything written to it will be lost.
tty connects standard output to a tty (as configured via TTYPath=, see below). If the TTY is used for output only, the executed process will not become the controlling process of the terminal, and will not fail or wait for other processes to release the
terminal.
journal connects standard output with the journal which is accessible via journalctl(1). Note that everything that is written to syslog or kmsg (see below) is implicitly stored in the journal as well, the specific two options listed below are hence
supersets of this one.
syslog connects standard output to the syslog(3) system syslog service, in addition to the journal. Note that the journal daemon is usually configured to forward everything it receives to syslog anyway, in which case this option is no different from
journal.
kmsg connects standard output with the kernel log buffer which is accessible via dmesg(1), in addition to the journal. The journal daemon might be configured to send all logs to kmsg anyway, in which case this option is no different from journal.
journal+console, syslog+console and kmsg+console work in a similar way as the three options above but copy the output to the system console as well.
The file:path option may be used to connect a specific file system object to standard output. The semantics are similar to the same option of StandardInput=, see above. If path refers to a regular file on the filesystem, it is opened (created if it
doesn't exist yet) for writing at the beginning of the file, but without truncating it. If standard input and output are directed to the same file path, it is opened only once, for reading as well as writing and duplicated. This is particularly useful
when the specified path refers to an AF_UNIX socket in the file system, as in that case only a single stream connection is created for both input and output.
append:path is similar to file:path above, but it opens the file in append mode.
socket connects standard output to a socket acquired via socket activation. The semantics are similar to the same option of StandardInput=, see above.
The fd:name option connects standard output to a specific, named file descriptor provided by a socket unit. A name may be specified as part of this option, following a ":" character (e.g. "fd:foobar"). If no name is specified, the name "stdout" is
implied (i.e. "fd" is equivalent to "fd:stdout"). At least one socket unit defining the specified name must be provided via the Sockets= option, and the file descriptor name may differ from the name of its containing socket unit. If multiple matches
are found, the first one will be used. See FileDescriptorName= in systemd.socket(5) for more details about named descriptors and their ordering.
If the standard output (or error output, see below) of a unit is connected to the journal, syslog or the kernel log buffer, the unit will implicitly gain a dependency of type After= on systemd-journald.socket (also see the "Implicit Dependencies"
section above). Also note that in this case stdout (or stderr, see below) will be an AF_UNIX stream socket, and not a pipe or FIFO that can be re-opened. This means when executing shell scripts the construct echo "hello" > /dev/stderr for writing text
to stderr will not work. To mitigate this use the construct echo "hello" >&2 instead, which is mostly equivalent and avoids this pitfall.
This setting defaults to the value set with DefaultStandardOutput= in systemd-system.conf(5), which defaults to journal. Note that setting this parameter might result in additional dependencies to be added to the unit (see above).
Controls where file descriptor 1 (STDOUT) of the executed processes is connected to. Takes one of inherit, null, tty, journal, syslog, kmsg, journal+console, syslog+console, kmsg+console, file:path, append:path, socket or fd:name.
inherit duplicates the file descriptor of standard input for standard output.
null connects standard output to /dev/null, i.e. everything written to it will be lost.
tty connects standard output to a tty (as configured via TTYPath=, see below). If the TTY is used for output only, the executed process will not become the controlling process of the terminal, and will not fail or wait for other processes to release the
terminal.
journal connects standard output with the journal which is accessible via journalctl(1). Note that everything that is written to syslog or kmsg (see below) is implicitly stored in the journal as well, the specific two options listed below are hence
supersets of this one.
syslog connects standard output to the syslog(3) system syslog service, in addition to the journal. Note that the journal daemon is usually configured to forward everything it receives to syslog anyway, in which case this option is no different from
journal.
kmsg connects standard output with the kernel log buffer which is accessible via dmesg(1), in addition to the journal. The journal daemon might be configured to send all logs to kmsg anyway, in which case this option is no different from journal.
journal+console, syslog+console and kmsg+console work in a similar way as the three options above but copy the output to the system console as well.
The file:path option may be used to connect a specific file system object to standard output. The semantics are similar to the same option of StandardInput=, see above. If path refers to a regular file on the filesystem, it is opened (created if it
doesn't exist yet) for writing at the beginning of the file, but without truncating it. If standard input and output are directed to the same file path, it is opened only once, for reading as well as writing and duplicated. This is particularly useful
when the specified path refers to an AF_UNIX socket in the file system, as in that case only a single stream connection is created for both input and output.
append:path is similar to file:path above, but it opens the file in append mode.
socket connects standard output to a socket acquired via socket activation. The semantics are similar to the same option of StandardInput=, see above.
The fd:name option connects standard output to a specific, named file descriptor provided by a socket unit. A name may be specified as part of this option, following a ":" character (e.g. "fd:foobar"). If no name is specified, the name "stdout" is
implied (i.e. "fd" is equivalent to "fd:stdout"). At least one socket unit defining the specified name must be provided via the Sockets= option, and the file descriptor name may differ from the name of its containing socket unit. If multiple matches
are found, the first one will be used. See FileDescriptorName= in systemd.socket(5) for more details about named descriptors and their ordering.
If the standard output (or error output, see below) of a unit is connected to the journal, syslog or the kernel log buffer, the unit will implicitly gain a dependency of type After= on systemd-journald.socket (also see the "Implicit Dependencies"
section above). Also note that in this case stdout (or stderr, see below) will be an AF_UNIX stream socket, and not a pipe or FIFO that can be re-opened. This means when executing shell scripts the construct echo "hello" > /dev/stderr for writing text
to stderr will not work. To mitigate this use the construct echo "hello" >&2 instead, which is mostly equivalent and avoids this pitfall.
This setting defaults to the value set with DefaultStandardOutput= in systemd-system.conf(5), which defaults to journal. Note that setting this parameter might result in additional dependencies to be added to the unit (see above).
Or le fichier unit de shorewall contient:
Citation :
StandardOutput=syslog

xuo Membre non connecté
-
- Voir le profil du membre xuo
- Inscrit le : 23/10/2011
- Groupes :
Je n'ai pas fait un 'grep -r' pour identifier tous les fichiers contenant ces lignes. Je n'en avais identifié que 3 et j'avais oublié la sortie de journalctl.
Je ne sais pas la différence entre le fichier messages et le fichier syslog. Il faudrait déjà que j'arrive à me débarrasser de l'un d'eux.
Je vais regarder le fichier /etc/syslog.conf pour voir s'il ne peut pas me servir à diminuer le nombre de fichiers écrits.
Et je vais aussi essayer :
StandardOutput = journal
Xuo.

xuo Membre non connecté
-
- Voir le profil du membre xuo
- Inscrit le : 23/10/2011
- Groupes :
Pour le moment, j'ai modifié le fichier /etc/syslog.conf.
Citation :
# *.info;mail,news,authpriv.none -/var/log/messages
# *.*;auth,authpriv.none -/var/log/syslog
*.info;mail,news,authpriv.none,kern.none -/var/log/messages
*.*;auth,authpriv.none,kern.none -/var/log/syslog
# *.*;auth,authpriv.none -/var/log/syslog
*.info;mail,news,authpriv.none,kern.none -/var/log/messages
*.*;auth,authpriv.none,kern.none -/var/log/syslog
Ce n'est pas parfait mais j'évite d'écrire dans 2 fichiers sur 4 (il reste les /var/log/kernel/kernel.info et le journalctl).
Il serait mieux d'empêcher le pare-feu d'écrire des événements de type info mais je ne sais toujours pas le faire.
Xuo.
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie