Bug Rsyslogd Was Huped

Support Debian
#1

Bonjour,

J’ai un très gros problème avec rsyslog, plus rien n’est logué dans “messages” et c’est très embêtant pour moi vu que 2 des règles iptables que j’ai mis en place utilisent ce fichier log pour y écrire les IP des attaquants et que fail2ban puisse les ban.

Voilà le message que j’obtiens :

(Je n’en poste qu’un, mais j’en ai eu plusieurs, et malgré un restart du rsyslog, ce bug persiste).

J’ai fait des recherches sur google, et même sur ce forum (avec la fonction recherche) mais je n’ai rien trouvé ! A part des centaines de bugs trackers dont la moitié qui disait que le bug avait été résolu ._.

Je précise que la machine avec laquelle j’ai un problème est un serveur sous debian Squeeze, et que rsyslog n’a réussi qu’une fois à loguer correctement les informations depuis que j’ai le serveur (28 Mai) … depuis il affiche toujours le message “Rsyslogd was HUPed”.

Avez vous déjà eu ce bug ? / Savez-vous comment le résoudre ?

Merci d’avance pour votre aide.

#2

Salut,

Je me mêle d’une chose que je connais mal, mais j’ai déjà bloqué ma machine avec rsyslogd, pour un problème de trop plein de messages avec un pare feu. Une piste:

Dans le man de syslog, il est écrit:

[quote]HUP This lets rsyslogd perform close all open files. Also, in v3 a
full restart will be done in order to read changed configuration
files. Note that this means a full rsyslogd restart is done.
This has, among others, the consequence that TCP and other con‐
nections are torn down. Also, if any queues are not running in
disk assisted mode or are not set to persist data on shutdown,
queue data is lost. HUPing rsyslogd is an extremely expensive
operation and should only be done when actually necessary. Actu‐
ally, it is a rsyslgod stop immediately followed by a restart.
Future versions will remove this restart functionality of HUP
(it will go away in v5). So it is advised to use HUP only for
closing files, and a “real restart” (e.g. /etc/rc.d/rsyslogd
restart) to activate configuration changes.
[/quote]

Qu’il le fasse de manière automatique est peut être un bug, mais vu que le message dit “type lightweight”, tu peux peut être essayer (je n’ai pas testé) tout simplement un:

Sinon, aller voir:
/etc/sysctl.conf

Edit: rsyslogd lightweight ne fonctionne pas, désolé (le message propose d’autres trucs)

Edit2: par contre rsyslogd -lightweight fonctionne, et renvoie chez moi un already running.

Stef

#3

Je ne suis pas sûr que “rsyslogd -lightweight” ai un quelconque effet … (rsyslogd -abcdefgh me retourne aussi “Already Running.”)
J’ai quand même essayé, et ça ne fonctionne toujours pas …

Ce que je ne comprends pas c’est qu’il a fonctionné une fois (au premier lancement de la machine après son installation) et puis il a cesser de fonctionner, avant même que je mette des règles en place pour le firewall…

Un rsyslogd -d me donne :

5815.609011377:7f785fec1700: rsyslogd 4.6.4 startup, compatibility mode 0, module path '' 5815.609203966:7f785fec1700: caller requested object 'net', not found (iRet -3003) 5815.609215399:7f785fec1700: Requested to load module 'lmnet' 5815.609221731:7f785fec1700: loading module '/usr/lib/rsyslog/lmnet.so' 5815.609285596:7f785fec1700: module of type 2 being loaded. 5815.609290595:7f785fec1700: source file conf.c requested reference for module 'lmnet', reference count now 1 5815.609295750:7f785fec1700: rsyslog runtime initialized, version 4.6.4, current users 1 5815.609305631:7f785fec1700: source file syslogd.c requested reference for module 'lmnet', reference count now 2 5815.609324683:7f785fec1700: module of type 1 being loaded. 5815.609333518:7f785fec1700: module of type 1 being loaded. 5815.609340540:7f785fec1700: source file omfwd.c requested reference for module 'lmnet', reference count now 3 5815.609348607:7f785fec1700: module of type 1 being loaded. 5815.609353071:7f785fec1700: entry point 'doHUP' not present in module 5815.609358401:7f785fec1700: module of type 1 being loaded. 5815.609362962:7f785fec1700: entry point 'doHUP' not present in module 5815.609366795:7f785fec1700: module of type 1 being loaded. 5815.609371172:7f785fec1700: entry point 'doHUP' not present in module 5815.609375111:7f785fec1700: module of type 1 being loaded. 5815.609379562:7f785fec1700: entry point 'doHUP' not present in module 5815.609445601:7f785fec1700: Called LogError, msg: WARNING: rsyslogd is running in compatibility mode. Automatically generated config directives may interfer with your rsyslog.conf settings. We suggest upgrading your config and adding -c4 as the first rsyslogd option. rsyslogd: WARNING: rsyslogd is running in compatibility mode. Automatically generated config directives may interfer with your rsyslog.conf settings. We suggest upgrading your config and adding -c4 as the first rsyslogd option. 5815.609526970:7f785fec1700: Writing pidfile /var/run/rsyslogd.pid. Pidfile (and pid) already exist.

Je précise que j’ai déjà essayé avec rsyslogd -c4, mais toujours ce satané bug …

#4

Il faudrait nous transmettre ton /etc/rsyslogd.conf, et nous dire si le répertoire /etc/rsyslog.d contient des fichiers de configuration.

Pour le HUP à 6h25, c’est normal, tu as cron qui exécute logrotate à 6h25, et c’est logrotate qui relance la lecture des fichiers de configs des différents services qui en ont besoin.

Faire un kill -HUP sur rsyslog lui demande de relire sa config et de recréer ses fichiers de log. C’est de là que vient le ‘lightweight’ car c’est un ‘redémarrage’ léger, et non un Stop/Start complet.

Tu peux faire l’essai :

Et dans une autre console :

[code]service rsyslogd restart

-> rsyslogd: [origin software=“rsyslogd” swVersion=“4.6.4” x-pid=“12296” x-info=“http://www.rsyslog.com”] (re)start

killall -HUP rsyslogd

-> rsyslogd: [origin software=“rsyslogd” swVersion=“4.6.4” x-pid=“12296” x-info=“http://www.rsyslog.com”] rsyslogd was HUPed, type ‘lightweight’.
[/code]

Tu pourras remarquer qu’a chaque ‘restart’, le x-pid change, alors qu’il ne change pas quand tu fais un HUP.

Il faudrait aussi, si possible, nous dire à quel niveau tu loggue dans iptables (Debug, User, Error, Warning ???), parce que suivant les niveau choisi, tes logs n’iront pas dans le même fichier. L’idéal serait de mettre ici aussi ton script iptables.

Pour les histoires de log, as tu regardé dans kern.log, warn.log et autres si ton iptables ne log pas dedans ?

#5

Il n’y a rien dans le répertoire rsyslog.d, et voici le contenu du fichier de configuration de rsyslog :

[code]# /etc/rsyslog.conf Configuration file for rsyslog.

For more information see

/usr/share/doc/rsyslog-doc/html/rsyslog_conf.html

#################

MODULES

#################

$ModLoad imuxsock # provides support for local system logging
$ModLoad imklog # provides kernel logging support (previously done by rklogd)
#$ModLoad immark # provides --MARK-- message capability

provides UDP syslog reception

#$ModLoad imudp
#$UDPServerRun 514

provides TCP syslog reception

#$ModLoad imtcp
#$InputTCPServerRun 514

###########################

GLOBAL DIRECTIVES

###########################

Use traditional timestamp format.

To enable high precision timestamps, comment out the following line.

$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

Set the default permissions for all log files.

$FileOwner root
$FileGroup adm
$FileCreateMode 0640
$DirCreateMode 0755
$Umask 0022

Include all config files in /etc/rsyslog.d/

$IncludeConfig /etc/rsyslog.d/*.conf

###############

RULES

###############

First some standard log files. Log by facility.

auth,authpriv.* /var/log/auth.log
.;auth,authpriv.none -/var/log/syslog
#cron.* /var/log/cron.log
daemon.* -/var/log/daemon.log
kern.* -/var/log/kern.log
lpr.* -/var/log/lpr.log
mail.* -/var/log/mail.log
user.* -/var/log/user.log

Logging for the mail system. Split it up so that

it is easy to write scripts to parse these files.

mail.info -/var/log/mail.info
mail.warn -/var/log/mail.warn
mail.err /var/log/mail.err

Logging for INN news system.

news.crit /var/log/news/news.crit
news.err /var/log/news/news.err
news.notice -/var/log/news/news.notice

Some “catch-all” log files.

.=debug;
auth,authpriv.none;
news.none;mail.none -/var/log/debug
.=info;.=notice;.=warn;
auth,authpriv.none;
cron,daemon.none;
mail,news.none -/var/log/messages

Emergencies are sent to everybody logged in.

*.emerg *

I like to have messages displayed on the console, but only on a virtual

console I usually leave idle.

#daemon,mail.*;\

news.=crit;news.=err;news.=notice;\

.=debug;.=info;\

.=notice;.=warn /dev/tty8

The named pipe /dev/xconsole is for the `xconsole’ utility. To use it,

you must invoke xconsole' with the-file’ option:

$ xconsole -file /dev/xconsole […]

NOTE: adjust the list below, or you’ll go crazy if you have a reasonably

busy site…

daemon.;mail.;
news.err;
.=debug;.=info;
.=notice;.=warn |/dev/xconsole[/code]

#6

Rien à signaler dans celui la, c’est la configuration par défaut.

Peux tu nous faire parvenir ton script iptables (Prends soin de virer toutes les adresses que tu ne voudrais montrer).

#7

Le problème était là 3-4 jours avant que je mette les règles dont je parle en place (Et j’utilisais les mêmes règles sur une autre machine sous debian lenny sans problème).
Les seules règles Iptables qui étaient en place lors des premiers messages “HUPed” étaient celles de fail-2-ban (6 jails proposées par fail 2 ban)

target prot opt source destination fail2ban-apache tcp -- anywhere anywhere multiport dports www,https fail2ban-ssh tcp -- anywhere anywhere multiport dports ssh fail2ban-apache-overflows tcp -- anywhere anywhere multiport dports www,https fail2ban-default tcp -- anywhere anywhere fail2ban-ssh-ddos tcp -- anywhere anywhere multiport dports ssh fail2ban-apache-noscript tcp -- anywhere anywhere multiport dports www,https

#8

Là, je ne vais rien pouvoir faire avec ça : Tu ne m’as donné que les tables créées automatiquement par fail2ban.
Tu as bien des règles iptables qui logguent ? C’est ça que je souhaite voir. Parce que si tu n’as pas explicitement spécifié à iptables de logguer les paquets, par défaut il ne loggue rien.

Regarde par exemple ce que j’ai donné à lol cet après-midi, tu auras un exemple de règles iptables + log + fichier de config rsyslog + logrotate :

iptables-ssh-et-x11forwarding-t33799.html

PS : Il n’y a surement pas de problème avec ton rsyslog. Il suffit pour t’en convaincre :

  1. De brancher une clé usb sur la machine, tu verras que les évènements seront loggués dans /var/log/messages
  2. De te connecter en ssh sur la machine, et cela apparaitra dans /var/log/auth.log

J’avais fait des modification dans mon premier post, peut être ne les as tu pas lues.

#9

J’ai peut-être manqué aussi de précision dans mon tout premier post, en fait tous les autres fichiers logs sont fonctionnels (auth.log, kern.log, syslog) C’est juste dans “messages” que rien n’est logué du tout.

Voici la partie qui concerne les logs dans le script iptables :

/sbin/iptables -N DDOS1 /sbin/iptables -A DDOS1 -j LOG --log-prefix 'DDOS 1 : ' --log-level info /sbin/iptables -A DDOS1 -j DROP

=> Le reste ne fait que rejeter des paquets arrivant sur des ports défini. J’ai utiliser ce script pendant plus d’un an sous lenny, et je n’ai jamais eu un problème, sans parler du fait que ce script n’était pas en place quand j’ai commencé à recevoir les messages “rsyslogd was HUPed”.

En plus de ça j’ai vérifier avec find dans les logs de mon ancien serveur sous lenny et je n’ai jamais eu de messages “rsyslogd was HUPed”.

Par contre sous Squeeze je suis servi !

May 30 06:25:01 hostname rsyslogd: [origin software="rsyslogd" swVersion="4.6.4" x-pid="2412" x-info="http://www.rsyslog.com"] rsyslogd was HUPed, type 'lightweight'.
May 31 06:25:01 hostname rsyslogd: [origin software="rsyslogd" swVersion="4.6.4" x-pid="2412" x-info="http://www.rsyslog.com"] rsyslogd was HUPed, type 'lightweight'.
Jun  1 06:25:01 hostname rsyslogd: [origin software="rsyslogd" swVersion="4.6.4" x-pid="2412" x-info="http://www.rsyslog.com"] rsyslogd was HUPed, type 'lightweight'.
Jun  2 06:25:01 hostname rsyslogd: [origin software="rsyslogd" swVersion="4.6.4" x-pid="2412" x-info="http://www.rsyslog.com"] rsyslogd was HUPed, type 'lightweight'.
Jun  3 06:25:01 hostname rsyslogd: [origin software="rsyslogd" swVersion="4.6.4" x-pid="2412" x-info="http://www.rsyslog.com"] rsyslogd was HUPed, type 'lightweight'.
Jun  4 06:25:01 hostname rsyslogd: [origin software="rsyslogd" swVersion="4.6.4" x-pid="2412" x-info="http://www.rsyslog.com"] rsyslogd was HUPed, type 'lightweight'.
Jun  4 07:13:25 hostname kernel: Kernel logging (proc) stopped.
Jun  4 07:13:25 hostname rsyslogd: [origin software="rsyslogd" swVersion="4.6.4" x-pid="2412" x-info="http://www.rsyslog.com"] exiting on signal 15.
Jun  4 07:13:25 hostname kernel: imklog 4.6.4, log source = /proc/kmsg started.
Jun  4 07:13:25 hostname rsyslogd: [origin software="rsyslogd" swVersion="4.6.4" x-pid="5143" x-info="http://www.rsyslog.com"] (re)start
Jun  5 06:25:02 hostname rsyslogd: [origin software="rsyslogd" swVersion="4.6.4" x-pid="5143" x-info="http://www.rsyslog.com"] rsyslogd was HUPed, type 'lightweight'.
Jun  5 06:25:02 hostname rsyslogd: [origin software="rsyslogd" swVersion="4.6.4" x-pid="5143" x-info="http://www.rsyslog.com"] rsyslogd was HUPed, type 'lightweight'.
Jun  6 06:25:01 hostname rsyslogd: [origin software="rsyslogd" swVersion="4.6.4" x-pid="5143" x-info="http://www.rsyslog.com"] rsyslogd was HUPed, type 'lightweight'.
Jun  6 09:52:37 hostname kernel: Kernel logging (proc) stopped.
Jun  6 09:52:37 hostname rsyslogd: [origin software="rsyslogd" swVersion="4.6.4" x-pid="5143" x-info="http://www.rsyslog.com"] exiting on signal 15.
Jun  6 09:52:37 hostname kernel: imklog 4.6.4, log source = /proc/kmsg started.
Jun  6 09:52:37 hostname rsyslogd: [origin software="rsyslogd" swVersion="4.6.4" x-pid="26372" x-info="http://www.rsyslog.com"] (re)start

Edit :

Et toujours avec find j’ai recherché pour ‘DDOS1’ et rien n’a été logué.

#10

1) /sbin/iptables -N DDOS1 2) /sbin/iptables -A DDOS1 -j LOG --log-prefix 'DDOS 1 : ' --log-level info 3) /sbin/iptables -A DDOS1 -j DROP

Alors, je vois comme un soucis qui expliquerais pourquoi rien n’est loggué. Je vais te détailler les commandes iptables que tu m’as données :

  1. Créer une nouvelle règle perso qui se nomme DDOS1
  2. Ajouter à DDOS1 la fonction de LOG, avec préfixe DDOS1 et niveau info
  3. Ajouter à DDOS1 la directive ‘DROP’

C’est parfait, seulement, il faut que tu envoies des paquets dans ta règle perso. Par exemple :

Et là, les paquets en entrée, tu les envoie dans la règle perso DDOS1, qui va, dans l’ordre, logguer ‘DDOS1’, puis DROPPER le paquet.

/!\ Attention, ce n’est qu’un exemple qui bloquera TOUT en entrée si tu le tapes tel quel.

Pour le fait que rsyslogd reçoive le signal HUP, je t’ai expliqué plus haut que c’est normal, ce sont les tâches cron de maintenance qui s’exécutent.

Tu peux voir les tâches cron :

[code]# /etc/crontab: system-wide crontab

Unlike any other crontab you don’t have to run the `crontab’

command to install the new version when you edit this file

and files in /etc/cron.d. These files also have username fields,

that none of the other crontabs do.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

m h dom mon dow user command

17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

[/code]

On peux par exemple voir qu’à 6h25 tous les jours, est exécuté le script cron.daily.

Ensuite, tu te rends dans /etc/cron.daily/ et tu regardes, il y a les tâches qui sont exécutées chaque jour. Idem pour cron.weekly et cron.monthly.

Et pour le fait que tu n’avais pas ces messages dans Lenny : Est tu sur que c’était rsyslogd qui était installé dans Lenny, et pas simplement syslog ?

Et pour finir : find permets de chercher des fichiers sur un disque, pas ce qu’il y a dans les fichiers.

Conviendrait mieux je pense.

Et pour finir une deuxième fois : Si tu te sers de ta règle DDOS1 pour que fail2ban connaisse les IP à bloquer, saches tout de même que dans ce cas, fail2ban ne te sers à rien. Je te laisse chercher pourquoi :wink:

#11

En fait j’utilise find avec grep ( find * -type f -exec grep ‘DDOS’ {} ; ).

Et pour mes règles IPtables elles sont bien conforme, les paquets devraient être logués (comme plus d’un an sous lenny avec rsyslogd).

Je ne possède plus ma machine sous lenny, mais j’ai sauvegardé les logs :

May 17 06:25:02 hostname kernel: imklog 3.18.6, log source = /proc/kmsg started. May 17 06:25:02 hostname rsyslogd: [origin software="rsyslogd" swVersion="3.18.6" x-pid="3463" x-info="http://www.rsyslog.com"] restart

Et comme je l’ai dis, jamais le message “rsyslogd was HUPed” n’est apparu dans les logs sous lenny, alors que là sous squeeze il ne me met que ça et me prive de précieuses informations qui étaient loguées sous lenny.

Quant à fail-2-ban je l’utilise pour bloquer totalement les IP une fois les paquets logués, ça évite le flood des logs, pourquoi ça serait inutile ? Sous lenny ça me servait à avoir 20 lignes de logs d’une attaque avec les informations nécessaire (IP source, IP destination, PORT de destination) ces attaques peuvent durer des heures, voir des jours, et ne nécessitent rien d’autre qu’une bande passante supérieure à 15KB/s couplé avec un petit programme de flood.

Et au niveau des cron il n’y a rien qui pourrait expliquer ça :

[code]

m h dom mon dow user command

17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

*/1 * * * * root /usr/local/rtm/bin/rtm 34 > /dev/null 2> /dev/null[/code]

#12 

Sauf une tâche qui s'exécute à 6h25 tous les jours ...

N'aurais-tu pas un 'logrotate' par hazard dans /etc/cron.daily ?

Tu t'acharnes sur rsyslog, alors que tu indiques que celui ci loggue bien tout le reste. S'il ne logue pas tes règles iptables, j'ai comme un doute sur tes règles iptables ... De plus, tu semble oublier que, bien que Lenny et Squeeze utilisent rsyslog, les versions ne sont plus les mêmes, donc les développeurs on peut être fait logguer lorsque rsyslog reçoit un HUP alors qu'il ne le logguait pas avant.

J'utilise iptables et rsyslog, et tout fonctionne bien. Comme te montre le lien que je t'ai fais passer plus haut, lol à mis en place des règles pour se dépanner, et il semble que tout fonctionnait bien pour lui aussi. Ta configuration de rsyslog étant celle installée par défaut, j'ai du mal à croire que le problème vienne de rsyslog.

PS : A moins que tu gères une machine dont dépends la survie de l’humanité, je pense que je ne vais pas arriver à te dépanner si tu ne fournis que des bribes d'informations à chaque fois, et cela va être encore plus dur si tu me dis faire un find quand tu fais un grep.

Au fait, j'avais pas fait gaffe, mais tu mets dans ton premier post :

[code]Linux ****.****.fr 2.6.38.2-xxxx-std-ipv6-64-hz1000 #1 SMP Wed Apr 13 08:40:44 UTC 2011 x86_64 GNU/Linux[/code]

C'est un noyau perso ? Si oui, fais le test avec le noyau standard, car tu peux très bien avoir compilé ton noyau sans le support iptables-log.

Je vois aussi que tu lances rtm toutes les minutes. N'y a-t-il pas de rapport entre la fréquence de lancement de rtm et celle des HUP ?

Sauf une tâche qui s’exécute à 6h25 tous les jours …

N’aurais-tu pas un ‘logrotate’ par hazard dans /etc/cron.daily ?

Tu t’acharnes sur rsyslog, alors que tu indiques que celui ci loggue bien tout le reste. S’il ne logue pas tes règles iptables, j’ai comme un doute sur tes règles iptables … De plus, tu semble oublier que, bien que Lenny et Squeeze utilisent rsyslog, les versions ne sont plus les mêmes, donc les développeurs on peut être fait logguer lorsque rsyslog reçoit un HUP alors qu’il ne le logguait pas avant.

J’utilise iptables et rsyslog, et tout fonctionne bien. Comme te montre le lien que je t’ai fais passer plus haut, lol à mis en place des règles pour se dépanner, et il semble que tout fonctionnait bien pour lui aussi. Ta configuration de rsyslog étant celle installée par défaut, j’ai du mal à croire que le problème vienne de rsyslog.

PS : A moins que tu gères une machine dont dépends la survie de l’humanité, je pense que je ne vais pas arriver à te dépanner si tu ne fournis que des bribes d’informations à chaque fois, et cela va être encore plus dur si tu me dis faire un find quand tu fais un grep.

Au fait, j’avais pas fait gaffe, mais tu mets dans ton premier post :

C’est un noyau perso ? Si oui, fais le test avec le noyau standard, car tu peux très bien avoir compilé ton noyau sans le support iptables-log.

Je vois aussi que tu lances rtm toutes les minutes. N’y a-t-il pas de rapport entre la fréquence de lancement de rtm et celle des HUP ?

#13

Désolé de mon manque de précision dans mes messages, je vais faire un message un peu plus complet.
Le noyau est un noyau 1000 HZ compilé par OVH et proposé en netboot, je tenterais avec le noyau standard cette nuit quand il n’y aura plus grand monde.

/sbin/iptables -N DDOS1 /sbin/iptables -A DDOS1 -j LOG --log-prefix 'DDOS1: ' --log-level info /sbin/iptables -A DDOS1 -j DROP /sbin/iptables -A INPUT -i eth0 -p udp --dport 27015 -m length --length 28 -j DDOS1 /sbin/iptables -A INPUT -i eth0 -p udp --dport 27016 -m length --length 28 -j DDOS1

Sur ma machine j’héberge des serveurs de jeux + serveur apache2 (mirroir de téléchargement) + un mumble.
Les règles DDoS sont fait pour palier à une vulnérabilité des serveurs Counter-Strike source qui peuvent être floodés avec certains paquets qui rendent le serveur inaccessible même avec une très faible bande passante.

Un iptables -L -nvx m’indique que 12000 paquets on été drop sur le port 27016, et que 5000 ont été drop sur le port 27015.
Du coup les paquets sont bien bloqués, l’attaque est inefficace, mais vu que je n’ai pas leur IP je n’ai pas de quoi identifier l’attaquant et le bannir des serveurs de jeux (grâce à leur STEAMID, une ID unique attribuée à un compte de joueur sur steam)

Cette commande m’indique aussi :

Le répertoire cron.daily contient logrotate :

[code]#!/bin/sh

test -x /usr/sbin/logrotate || exit 0
/usr/sbin/logrotate /etc/logrotate.conf[/code]

logrotate.conf contient :

[code]# see “man logrotate” for details

rotate log files weekly

weekly

keep 4 weeks worth of backlogs

rotate 4

create new (empty) log files after rotating old ones

create

uncomment this if you want your log files compressed

#compress

packages drop log rotation information into this directory

include /etc/logrotate.d

no packages own wtmp, or btmp – we’ll rotate them here

/var/log/wtmp {
missingok
monthly
create 0664 root utmp
rotate 1
}

/var/log/btmp {
missingok
monthly
create 0660 root utmp
rotate 1
}

system-specific logs may be configured here[/code]

Et les rtm toutes les minutes sont aussi config à la base par OVH, rtm veut dire Real Time Monitoring et ils s’en servent pour pouvoir afficher l’état de la machine sur le site. Toutes les machines chez OVH avec une distribution sous linux possèdent ce cron après l’installation de la machine, sous lenny il était aussi présent et sont logués dans /var/log/syslog .

#14

J’avoue ne pas bien saisir où se trouve le problème.

Pourrais tu tenter soit de modifier le niveau de LOG de tes règles iptables, en les passant à debug :

/sbin/iptables -N DDOS1 /sbin/iptables -A DDOS1 -j LOG --log-prefix 'DDOS1: ' --log-level debug /sbin/iptables -A DDOS1 -j DROP /sbin/iptables -A INPUT -i eth0 -p udp --dport 27015 -m length --length 28 -j DDOS1 /sbin/iptables -A INPUT -i eth0 -p udp --dport 27016 -m length --length 28 -j DDOS1

Et voir si tu trouves des informations dans /var/log/debug …

Soit de forcer le log des ‘info’ dans /etc/rsyslog.conf, en ajoutant à la fin :

Et voir si les evènements ‘info’ se logguent dans /var/log/iptables

Enfin, tu peux surveiller les messages grace à xconsole (Paquet x11-apps) de la sorte :

Je viens à l’instant de penser à un truc : Ton module ‘ipt_LOG’ est bien chargé ?

#15

Avec --log-level debug tout est bien logué dans /var/log/debug , je n’ai plus qu’a changer la config de la jail fail-2-ban pour lire les info depuis ce fichier, merci à toi !

Quant au module ipt_LOG, je ne l’ai pas apparemment :

lsmod Opening /proc/modules: No such file or directory

J’avais pensé à mettre en --log-level debug, mais je ne supprimais pas ma règle avant de mettre la nouvelle… Du coup les paquets ne passait que par la première règle qui avait le --log-level info.