Bonjour,
J’utilise VestaCP sur Debian 9. Après un petit souci de cron qui n’a pu s’exécuter à cause d’un problème de RAM, j’ai décidé d’en savoir plus.
Je me suis rendu compte que sur 5Go de RAM, systemd-journal utilise 23% !
Est-ce normal ?
Je vous remercie.
Bonjour cyclone200,
Et que donne un
sudo journalctl
il y a peut être quelque chose à voir ??
kawa
Bonjour kawa,
C’est intéressant, il y a des centaines de logs qui datent de cette nuit, à 4h du matin, pour ce qu’il me semble être des tentatives de connexion :
-- Logs begin at Wed 2020-06-03 04:46:34 CEST, end at Wed 2020-06-03 11:02:39 CEST. --
juin 03 04:46:34 sshd[17243]: input_userauth_request: invalid user uftp [preauth]
juin 03 04:46:34 sshd[17243]: pam_unix(sshd:auth): check pass; user unknown
juin 03 04:46:34 sshd[17243]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tt
juin 03 04:46:35 sshd[17240]: Failed password for root from 106.12.163.87 port 57580 ssh2
juin 03 04:46:35 sshd[17240]: Received disconnect from 106.12.163.87 port 57580:11: Bye Bye [preaut
juin 03 04:46:35 sshd[17240]: Disconnected from 106.12.163.87 port 57580 [preauth]
juin 03 04:46:36 sshd[17243]: Failed password for invalid user uftp from 201.163.56.82 port 46204 s
juin 03 04:46:37 sshd[17243]: Received disconnect from 201.163.56.82 port 46204:11: Normal Shutdown
juin 03 04:46:37 sshd[17243]: Disconnected from 201.163.56.82 port 46204 [preauth]
juin 03 04:46:37 sshd[17251]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tt
juin 03 04:46:38 sshd[17246]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tt
juin 03 04:46:38 sshd[17253]: Invalid user odoo from 51.89.40.99 port 51594
juin 03 04:46:38 sshd[17253]: input_userauth_request: invalid user odoo [preauth]
juin 03 04:46:38 sshd[17253]: pam_unix(sshd:auth): check pass; user unknown
juin 03 04:46:38 sshd[17253]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tt
juin 03 04:46:38 sshd[17249]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tt
juin 03 04:46:40 sshd[17251]: Failed password for root from 188.166.109.87 port 34800 ssh2
juin 03 04:46:40 sshd[17251]: Received disconnect from 188.166.109.87 port 34800:11: Bye Bye [preau
juin 03 04:46:40 sshd[17251]: Disconnected from 188.166.109.87 port 34800 [preauth]
juin 03 04:46:40 sshd[17246]: Failed password for root from 210.123.141.241 port 40534 ssh2
juin 03 04:46:40 sshd[17253]: Failed password for invalid user odoo from 51.89.40.99 port 51594 ssh
juin 03 04:46:40 sshd[17246]: Received disconnect from 210.123.141.241 port 40534:11: Bye Bye [prea
juin 03 04:46:40 sshd[17246]: Disconnected from 210.123.141.241 port 40534 [preauth]
juin 03 04:46:40 sshd[17253]: Received disconnect from 51.89.40.99 port 51594:11: Normal Shutdown,
juin 03 04:46:40 sshd[17253]: Disconnected from 51.89.40.99 port 51594 [preauth]
juin 03 04:46:40 sshd[17249]: Failed password for root from 222.186.190.17 port 25345 ssh2
juin 03 04:46:40 sshd[17258]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tt
juin 03 04:46:41 sshd[17256]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tt
juin 03 04:46:42 sshd[17258]: Failed password for root from 54.37.66.73 port 49768 ssh2
juin 03 04:46:42 sshd[17258]: Received disconnect from 54.37.66.73 port 49768:11: Bye Bye [preauth]
juin 03 04:46:42 sshd[17258]: Disconnected from 54.37.66.73 port 49768 [preauth]
juin 03 04:46:43 sshd[17256]: Failed password for root from 210.56.23.100 port 41848 ssh2
juin 03 04:46:43 sshd[17249]: Failed password for root from 222.186.190.17 port 25345 ssh2
juin 03 04:46:43 sshd[17256]: Received disconnect from 210.56.23.100 port 41848:11: Bye Bye [preaut
juin 03 04:46:43 sshd[17256]: Disconnected from 210.56.23.100 port 41848 [preauth]
juin 03 04:46:46 sshd[17249]: Failed password for root from 222.186.190.17 port 25345 ssh2
juin 03 04:46:46 sshd[17261]: Invalid user uftp from 201.163.56.82 port 34860
juin 03 04:46:46 sshd[17261]: input_userauth_request: invalid user uftp [preauth]
juin 03 04:46:46 sshd[17261]: pam_unix(sshd:auth): check pass; user unknown
juin 03 04:46:46 sshd[17261]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tt
juin 03 04:46:46 sshd[17249]: Received disconnect from 222.186.190.17 port 25345:11: [preauth]
juin 03 04:46:46 sshd[17249]: Disconnected from 222.186.190.17 port 25345 [preauth]
juin 03 04:46:46 sshd[17249]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh rus
juin 03 04:46:48 sshd[17261]: Failed password for invalid user uftp from 201.163.56.82 port 34860 s
juin 03 04:46:49 sshd[17261]: Received disconnect from 201.163.56.82 port 34860:11: Normal Shutdown
juin 03 04:46:49 sshd[17261]: Disconnected from 201.163.56.82 port 34860 [preauth]
juin 03 04:46:52 sshd[17263]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tt
juin 03 04:46:53 sshd[17263]: Failed password for root from 218.98.26.102 port 53236 ssh2
juin 03 04:46:54 sshd[17263]: Received disconnect from 218.98.26.102 port 53236:11: Bye Bye [preaut
juin 03 04:46:54 sshd[17263]: Disconnected from 218.98.26.102 port 53236 [preauth]
juin 03 04:46:57 sshd[17267]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tt
juin 03 04:46:57 sshd[17274]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tt
juin 03 04:46:58 sshd[17276]: Invalid user uftp from 201.163.56.82 port 51748
juin 03 04:46:58 sshd[17276]: input_userauth_request: invalid user uftp [preauth]
juin 03 04:46:58 sshd[17276]: pam_unix(sshd:auth): check pass; user unknown
juin 03 04:46:58 sshd[17276]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tt
juin 03 04:46:59 sshd[17267]: Failed password for root from 196.203.53.20 port 55776 ssh2
juin 03 04:47:00 sshd[17274]: Failed password for root from 118.163.176.97 port 51158 ssh2
juin 03 04:47:00 sshd[17274]: Received disconnect from 118.163.176.97 port 51158:11: Bye Bye [preau
juin 03 04:47:00 sshd[17274]: Disconnected from 118.163.176.97 port 51158 [preauth]
J’ai regardé pour les IPs, ce sont des tentatives venant de Chine, du Mexique, du Pakistan etc.
Je viens de faire un grep "Failed password" /var/log/auth.log pour voir le nombre de tentatives similaires et il y en a des MILLIONS ; ça a presque fait crasher ma console.
J’imagine que ce sont ces tentatives intempestives qui augmentent l’utilisation de la RAM. Que me conseillez-vous de faire ?
Je vous remercie.
Déjà pour voir l’occupation de la ram par journald :
ps axv | grep journald
Ensuite pour voir la configuration de journald :
cat /etc/systemd/journald.conf
et
ls -l /var/log/journal
Référence : https://www.freedesktop.org/software/systemd/man/journald.conf.html
Avoir des centaines, voir des milliers de tentatives de connexion sur le service sshd n’a rien d’extraordinaire. Si le service est bien sécurisé (connexion uniquement par clés) il n’y rien à craindre.
Bonjour Bruno et merci pour votre réponse.
Voici le résultat de ps axv | grep journald :
4680 pts/0 S+ 0:00 0 200 12575 1020 0.0 grep journald
14336 ? Ss 495:46 59625 107 1444308 1141144 19.1 /lib/systemd/systemd-journald
Quant à la configuration :
[Journal]
#Storage=auto
#Compress=yes
#Seal=yes
#SplitMode=uid
#SyncIntervalSec=5m
#RateLimitIntervalSec=30s
#RateLimitBurst=1000
#SystemMaxUse=
#SystemKeepFree=
#SystemMaxFileSize=
#SystemMaxFiles=100
#RuntimeMaxUse=
#RuntimeKeepFree=
#RuntimeMaxFileSize=
#RuntimeMaxFiles=100
#MaxRetentionSec=
#MaxFileSec=1month
#ForwardToSyslog=yes
#ForwardToKMsg=no
#ForwardToConsole=no
#ForwardToWall=yes
#TTYPath=/dev/console
#MaxLevelStore=debug
#MaxLevelSyslog=debug
#MaxLevelKMsg=notice
#MaxLevelConsole=info
#MaxLevelWall=emerg
Bien sûr, je comprends bien que je ne suis pas le seul à avoir des tentatives d’intrusion de ce genre ; ce qui doit être commun à tous les serveurs. Mais il est bien dommage que près de 20% de la RAM soit consacré à ce genre d’écritures. J’ai utilisé ps -A --sort -rss -o comm,pmem,rss | head -n 20 pour obtenir le pourcentage.
Je remarque d’ailleurs que fail2ban utilise 35% de la mémoire, c’est certainement lié ? Je suppose qu’avec toutes ces tentatives, fail2ban fonctionne plus. Donc entre ces deux processus, c’est déjà 55% de la RAM qui est utilisée.
Effectivement journald occupe 19,1% de la RAM. Je n’ai jamais vu ça…
Tu n’as pas donné le retour de :
ls -l /var/log/journal
Avec la configuration par défaut, si ce dossier existe, journald utilisera le disque plutôt que la RAM.
Fail2ban peut utiliser énormément de RAM si les logs sont importants.
Ah, en effet, je pensais que c’était l’une ou l’autre des commandes.
Il me semble que ce dossier n’existe pas : ls: impossible d'accéder à '/var/log/journal': Aucun fichier ou dossier de ce type.
J’en profite pour joindre le retour de ps -A --sort -rss -o comm,pmem,rss | head -n 20 :
COMMAND %MEM RSS
fail2ban-server 35.2 2104376
systemd-journal 19.0 1139904
clamd 15.6 932672Le plus simple est donc de modifier le fichier /etc/systemd/journald.conf avec :
[Journal]
Storage=persistent
…
Puis de relancer le service :
systemctl restart systemd-journald
ceci devrait créer automatiquement le dossier /var/log/journal avec les bons droits d’accès et surtout obliger journald à utiliser le disque et non la RAM.
Je vous remercie, cela fonctionne. L’utilisation de journald est passée de 20% à 0.9% !
Me conseillez-vous également de brider la taille du fichier avec SystemMaxFileSize ? Car j’imagine que désormais, avec autant de tentatives, le fichier pourra vite peser plusieurs gigas.
Oui c’est sans doute une bonne chose.
Mais il faudra surtout ajuster la configuration du serveur SSH et de fail2ban afin d’avoir des logs qui se remplissent un peu moins.
Bonjour
Je pense qu’une authentification par clef ssh et sans mot de passe
permettrait d’éviter d’avoir ces tentatives ratées de connexion.