Traces : logrotate - Nettoyage partition /var/log saturée Le sujet est résolu

[dezix]

Bonjour,


j'ai un VPS laissé en "jachère" avec juste micro-httpd
qui sert une simple page d'accueil en attendant mieux,
- donc pas d'urgence ni de nécessité de service -
qui a du être l'objet d'une attaque par déni de service.


Je ne vois pas trop l'intérêt de l'attaque (sauf si de multiples instances du même fournisseur au même moment ???),
mais ce n'est pas l'objet de ma question.


La partition de /var/log est saturée :

Code : Tout sélectionner

# df -h /var/log
Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/vg0-var_log  1.9G  1.9G     0 100% /var/log

# find /var/log -size +100M -print
/var/log/syslog
/var/log/daemon.log

# du -sh `find /var/log -size +100M -print`
847M	/var/log/syslog
847M	/var/log/daemon.log

# du -sh /var/log/journal
208M	/var/log/journal

Dans syslog (idem daemon.log) j'ai des tonnes de :

Code : Tout sélectionner

Aug 20 16:12:31 server1 systemd[1]: micro-httpd@8740-51.178.81.74:80-139.144.73.81:51474.service: Succeeded.
Aug 20 16:12:31 server1 systemd[1]: micro-httpd@8741-51.178.81.74:80-139.144.73.81:51496.service: Succeeded.
Aug 20 16:12:31 server1 systemd[1]: micro-httpd@8742-51.178.81.74:80-139.144.73.81:51486.service: Succeeded.
Aug 20 16:12:31 server1 systemd[1]: micro-httpd@8743-51.178.81.74:80-139.144.73.81:51520.service: Succeeded.
Aug 20 16:12:31 server1 systemd[1]: micro-httpd@8744-51.178.81.74:80-139.144.73.81:51514.service: Succeeded.
Aug 20 16:12:31 server1 systemd[1]: micro-httpd@8745-51.178.81.74:80-139.144.73.81:51512.service: Succeeded.
Aug 20 16:12:31 server1 systemd[1]: micro-httpd@8746-51.178.81.74:80-139.144.73.81:51524.service: Succeeded.
Aug 20 16:12:31 server1 systemd[1]: micro-httpd@8747-51.178.81.74:80-139.144.73.81:51526.service: Succeeded.
Aug 20 16:12:31 server1 systemd[1]: micro-httpd@8748-51.178.81.74:80-139.144.73.81:51528.service: Succeeded.
Aug 20 16:12:31 server1 systemd[1]: micro-httpd@8749-51.178.81.74:80-139.144.73.81:51540.service: Succeeded.
Aug 20 16:12:31 server1 systemd[1]: micro-httpd@8750-51.178.81.74:80-139.144.73.81:51556.service: Succeeded.
Aug 20 16:12:31 server1 systemd[1]: micro-httpd@8751-51.178.81.74:80-139.144.73.81:51560.service: Succeeded

J'ai tenté :

Code : Tout sélectionner

# logrotate -vdf  /var/log/syslog
WARNING: logrotate in debug mode does nothing except printing debug messages!  Consider using verbose mode (-v) instead if this is not what you want.

error: file /var/log/syslog too large, probably not a config file.
Reading state from file: /var/lib/logrotate/status
Allocating hash table for state file, size 64 entries
Creating new state
...
...
Creating new state

Handling 0 logs

... apparemment ça ne va pas le faire car le fichier syslog a une taille trop importante
et/ou manque d'espace pour traiter cela ???


Je n'ai pas dans /etc/logrotate.conf ni dans /etc/logrotate.d
de size ou maxsize configurés

Code : Tout sélectionner

# cat /etc/logrotate.{conf,d/*} | grep size
    minsize 1M

J'ai vu dans le manuel l'option copytruncate,
mais je ne vois pas exactement comment en faire usage dans ma situation.


Mon questionnement :


Comment nettoyer "proprement" /var/log ?

Comment (hors solutions de "mitigation") configurer intelligemment la rotation des logs
pour éviter la saturation de l'espace qui leur est alloué ?



Merci pour votre attention.

[piratebab]

Perso je ne force pas de rotation, je purge.
J'ai un script basique qui supprime tous les fichiers .gz.
Je le lance manuellement, après m'être assuré que tout va bien.

[vv222]

Vu la taille de ta partition /var/log, ça ne me semble pas être une bonne idée de dupliquer les journaux entre journald et rsyslog. À ta place j’en retirerais un des deux.

Sur une Debian fraîchement installée, c’est rsyslog qui est absent : Problèmes à connaître pour Bookworm - Modifications de la journalisation du système.

[dezix]

Je vous remercie pour vos retours.
J'attendais avant de réinstaller en stable actualisée, pour me faire la main sur cette histoire.

Du coup je vais réinstallé une stable neuve sans rsyslog
et je vais m'appliquer à prévenir ce genre de petit désagrément.

[vv222]

Il n’y pas pas besoin de Bookworm pour se passer de rsyslog, ça doit être possible depuis Debian Jessie.