et en tant que tel, tu isole toute sauvegarde que tu en as faite, car elles sont probablement compromise aussi.
Tu n’as plus qu’à formater et reinstaller ta machine, car rien ne dit qu’il n’y a pas quelque chose ailleurs dans tes fichiers.
Il serait intéressant de voir d’où vient ce virus.
- Je te suggère de regarder les ports ouverts, tu dois en avoir unqui sert d’entrée. Ça peut être très astucieux, j’ai vu un shell consistant en un code PHP inséré au milieu d’une page avec l’entrée donné en base64 et la réponse ds les headers. Quasi indetectable.
- Si tu as un serveur Web, active le module modsecurity qui te permettra d’avoir les arguments des requêtes POST
- Tu as deux solutions:
→ refaire tout sans trop savoir où est la faille
→ Continuer en espionnant celui qui a introduit ce virus pouvoir d’où ça vient
Je te suggère de regarder via find les fichiers qui ont été modifiés entre le 19 et le 20 aout
Et isole immédiatement les accès. Car sinon la compromission continuera et elle t’empêchera de faire une analyse correcte.
Car si tu as un site web utilisé par des personnes extérieures, tu les met à risque en les laissant accéder à un site compromis.
Si c’est le cas, il faudrait regarder les logs de la période 19-20 août (les access.log et error.log de cette période), si tu les as, je peux regarder ça
On dirait qu’il se connecte régulièrement à cette adresse. Par ailleurs, les connexions se font en UDP semble-t-il (classique ça pour un bindshell). Je te dirais plus plus tard, je suis dans un train
Je te suggère dans le cas où cette IP ne te dit rien de la capturer ou bien de la bloquer (elle est en Hollande on dirait)
Tout d’abord merci pour le temps passé et vos investigations
Je réponds aux différentes questions dans la soirée (là je suis au travail)
Ce serveur a un navidrome avec plein de mp3 ainsi qu’un nextcloud dans le cadre familial,.Puis je récupérer les données sans soucis ? Ou faut il prendre certaines précautions ? Les datas sont stockées sur un disque dur externe
D’avance merci.
J’ai un raspberry en rab plus performant ; j’en profiterai pour changer de machine
Les mp3 pas de souci, dans le nextcloud tu peux faire un backup de la base de données et des données elles même si ce ne sont pas des executables. Tu peux vérifier avec find la dernière date de modification éventuellement. Pour les executables, c’est plus délicat mais tu peux les tester à l’antivirus ou regarder là aussi les dates de modification.
C’est quelle version de nextcloud? Si tu veux, tu peux faire une archive des .php/js/html de ce nextcoud (en enlevant les mots de passe et autre dans le config.php et la passer, on pourra comparer avec le nextcloud d’origine et voire ce qui s’est passé.
Regarde les logs du serveur apache pour la période et change tes mots de passe bien sur.
Alors voilà
Version de nextclound Version Nextcloud Hub 10 (31.0.9) Packagée par yunohost
Pour les logs, mes logs ne remontent pas si loin, désolé.
Cette IP 87.121.84.220 te dit-elle quelque chose?
Non du tout
Pour le find / date du 19 au 20 aout : c’est là https://crust.ovh/site/files-vir.txt
( find / -type f -newerat 2025-08-18 ! -newerat 2025-08-21 > /var/www/my_webapp/www/files-vir.txt)
ça a l’air de correspondre essentiellement à une mise à jour yunohost.
Je n’ai jamais rien installé d’exotique à yunohost d’ailleurs.
J’ai fait un chkrootkit, la sortie est là https://crust.ovh/site/chkrootkit.txt
Je ne sais pas si ça peut être utile
Pour les ports ouverts c’est là https://crust.ovh/site/port.png
Je pense que je vais poser la question sur le forum yunohost, ils ont peut être des scripts internes (yunohost tools) pour ce type de situation
En attendant, je ne pense pas que mon espace disque ait changé ni l’utilisation de ma RAM
N’hésitez pas si vous avez d’autres infos/questions 
Mots de passe changé et je vais conseiller à mes qq utilisateurs de faire de même
En tout cas un grand merci
Je pensais au résultat sur la machine de
# netstat -tuplnSinon je te confirme que le virus se connecte ou écoute régulièrement sur 87.121.84.220
root@crust:~# netstat -tupln
Connexions Internet actives (seulement serveurs)
Proto Recv-Q Send-Q Adresse locale Adresse distante Etat PID/Program name
tcp 0 0 0.0.0.0:587 0.0.0.0:* LISTEN 2610/master
tcp 0 0 127.0.0.1:6379 0.0.0.0:* LISTEN 1107/redis-server 1
tcp 0 0 127.0.0.1:5037 0.0.0.0:* LISTEN 704/adbd
tcp 0 0 0.0.0.0:143 0.0.0.0:* LISTEN 1476/dovecot
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 1/init
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 2064/nginx: master
tcp 0 0 127.0.0.1:32529 0.0.0.0:* LISTEN 1112/sshwifty
tcp 0 0 127.0.0.1:10001 0.0.0.0:* LISTEN 861/postsrsd
tcp 0 0 127.0.0.1:10002 0.0.0.0:* LISTEN 861/postsrsd
tcp 0 0 0.0.0.0:2515 0.0.0.0:* LISTEN 1173/sshd: /usr/sbi
tcp 0 0 0.0.0.0:5555 0.0.0.0:* LISTEN 704/adbd
tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 1166/dnsmasq
tcp 0 0 127.0.0.1:8088 0.0.0.0:* LISTEN 1981/influxd
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 2610/master
tcp 0 0 127.0.0.1:61209 0.0.0.0:* LISTEN 1072/python3
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 2064/nginx: master
tcp 0 0 127.0.0.1:8891 0.0.0.0:* LISTEN 1414/opendkim
tcp 0 0 0.0.0.0:636 0.0.0.0:* LISTEN 1358/slapd
tcp 0 0 0.0.0.0:4190 0.0.0.0:* LISTEN 1476/dovecot
tcp 0 0 127.0.0.1:50561 0.0.0.0:* LISTEN 1087/navidrome
tcp 0 0 0.0.0.0:993 0.0.0.0:* LISTEN 1476/dovecot
tcp 0 0 127.0.0.1:9090 0.0.0.0:* LISTEN 1099/prometheus
tcp 0 0 127.0.0.1:6787 0.0.0.0:* LISTEN 1118/python3
tcp 0 0 127.0.0.1:11332 0.0.0.0:* LISTEN 1334/rspamd: main p
tcp 0 0 127.0.0.1:6788 0.0.0.0:* LISTEN 1119/python3
tcp 0 0 127.0.0.1:11333 0.0.0.0:* LISTEN 1334/rspamd: main p
tcp 0 0 127.0.0.1:389 0.0.0.0:* LISTEN 1358/slapd
tcp 0 0 127.0.0.1:11334 0.0.0.0:* LISTEN 1334/rspamd: main p
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 1478/mariadbd
tcp6 0 0 ::1:6379 :::* LISTEN 1107/redis-server 1
tcp6 0 0 :::587 :::* LISTEN 2610/master
tcp6 0 0 :::45548 :::* LISTEN 2714/grafana
tcp6 0 0 :::143 :::* LISTEN 1476/dovecot
tcp6 0 0 :::111 :::* LISTEN 1/init
tcp6 0 0 :::80 :::* LISTEN 2064/nginx: master
tcp6 0 0 :::4242 :::* LISTEN 1981/influxd
tcp6 0 0 :::2515 :::* LISTEN 1173/sshd: /usr/sbi
tcp6 0 0 :::53 :::* LISTEN 1166/dnsmasq
tcp6 0 0 :::8086 :::* LISTEN 1981/influxd
tcp6 0 0 :::25 :::* LISTEN 2610/master
tcp6 0 0 :::443 :::* LISTEN 2064/nginx: master
tcp6 0 0 :::636 :::* LISTEN 1358/slapd
tcp6 0 0 :::4190 :::* LISTEN 1476/dovecot
tcp6 0 0 :::993 :::* LISTEN 1476/dovecot
tcp6 0 0 ::1:11332 :::* LISTEN 1334/rspamd: main p
tcp6 0 0 ::1:11333 :::* LISTEN 1334/rspamd: main p
tcp6 0 0 ::1:389 :::* LISTEN 1358/slapd
tcp6 0 0 ::1:11334 :::* LISTEN 1334/rspamd: main p
udp 0 0 127.0.0.1:5353 0.0.0.0:* 1072/python3
udp 0 0 192.168.0.50:5353 0.0.0.0:* 1072/python3
udp 0 0 0.0.0.0:5353 0.0.0.0:* 1072/python3
udp 0 0 0.0.0.0:53 0.0.0.0:* 1166/dnsmasq
udp 0 0 0.0.0.0:111 0.0.0.0:* 1/init
udp 0 0 192.168.0.50:123 0.0.0.0:* 1351/ntpd
udp 0 0 127.0.0.1:123 0.0.0.0:* 1351/ntpd
udp 0 0 0.0.0.0:123 0.0.0.0:* 1351/ntpd
udp6 0 0 :::53 :::* 1166/dnsmasq
udp6 0 0 :::111 :::* 1/init
udp6 0 0 fe80::7ab9:b6f3:17d:123 :::* 1351/ntpd
udp6 0 0 2a01:e0a:82d:d0c0:9:123 :::* 1351/ntpd
udp6 0 0 ::1:123 :::* 1351/ntpd
udp6 0 0 :::123 :::* 1351/ntpdJe peux blacklister cette ip, je vais le faire
Peux tu également exeuter
debsumssous root, ça te donnera les fichiers modifés par rapport à la version déclarés dans les paquets.
Sinon qu’est le processus 1072? Il est normal?
Sinon qu’est le processus 1072? Il est normal?
root@crust:~# ps 1072
PID TTY STAT TIME COMMAND
1072 ? Ssl 0:03 /usr/bin/python3 /usr/bin/glances -s -B 127.0.0.1root@crust:~# debsums -e | grep FAILED
/etc/logrotate.d/apt FAILED
/etc/logrotate.d/aptitude FAILED
/etc/issue FAILED
/etc/issue.net FAILED
/etc/skel/.bashrc FAILED
/etc/dnsmasq.conf FAILED
/etc/default/dnsmasq FAILED
/etc/logrotate.d/dpkg FAILED
/etc/logrotate.d/alternatives FAILED
/etc/fail2ban/jail.conf FAILED
/etc/logrotate.d/fail2ban FAILED
/etc/influxdb/influxdb.conf FAILED
/etc/logrotate.d/influxdb FAILED
/etc/initramfs-tools/initramfs.conf FAILED
/etc/pulse/client.conf FAILED
/etc/logrotate.d/wtmp FAILED
/etc/logrotate.d/btmp FAILED
/etc/logrotate.conf FAILED
/etc/logrotate.d/mariadb FAILED
/etc/NetworkManager/NetworkManager.conf FAILED
/etc/nftables.conf FAILED
/etc/nginx/fastcgi_params FAILED
/etc/logrotate.d/nginx FAILED
/etc/opendkim.conf FAILED
/etc/logrotate.d/php8.0-fpm FAILED
/etc/logrotate.d/php8.3-fpm FAILED
/etc/logrotate.d/php8.4-fpm FAILED
/etc/logrotate.d/bootlog FAILED
/etc/sysctl.conf FAILED
/etc/logrotate.d/redis-server FAILED
/etc/resolvconf/resolv.conf.d/head FAILED
/etc/logrotate.d/rspamd FAILED
/etc/logrotate.d/rsyslog FAILED
/etc/default/slapd FAILED
/etc/systemd/journald.conf FAILED
/etc/logrotate.d/unattended-upgrades FAILED
/etc/logrotate.d/yunohost FAILED
/etc/zsh/zprofile FAILED
Pas top tout ça, non ?
Ce sont des fichiers de configuration, il faudrait regarder mais que la version du paquet soit adapté à la machine est normal. L’encourageant est que les binaires sont corrects. Il faudrait regarder quand ces fichiers ont été modifiés via la commande
ls -ltr --time=mtime «les dits fichiers en question»Peut être un
debsums -c | xargs -n ls -ltr --time=mtime fonctionnera directement (je ne connais pas bien la sortie de debsums)
J’ai essayé ce script
#!/bin/bash
filename='debsum.txt'
echo Start
while read p; do
ls -ltr --time=mtime $p
done < "$filename"
avec
cat debsum.txt
/etc/logrotate.d/apt
/etc/logrotate.d/aptitude
/etc/issue.net
/etc/issue
/etc/skel/.bashrc
/etc/default/dnsmasq
/etc/dnsmasq.conf
/etc/logrotate.d/dpkg
/etc/logrotate.d/alternatives
/etc/logrotate.d/fail2ban
/etc/fail2ban/jail.conf
/etc/logrotate.d/influxdb
/etc/influxdb/influxdb.conf
/etc/initramfs-tools/initramfs.conf
/etc/pulse/client.conf
/etc/logrotate.d/wtmp
/etc/logrotate.conf
/etc/logrotate.d/btmp
/etc/logrotate.d/mariadb
/etc/NetworkManager/NetworkManager.conf
/etc/nftables.conf
/etc/nginx/fastcgi_params
/etc/logrotate.d/nginx
/etc/opendkim.conf
/etc/logrotate.d/php8.0-fpm
/etc/logrotate.d/php8.3-fpm
/etc/logrotate.d/php8.4-fpm
/etc/logrotate.d/bootlog
/etc/sysctl.conf
/etc/logrotate.d/redis-server
/etc/resolvconf/resolv.conf.d/head
/etc/logrotate.d/rspamd
/etc/logrotate.d/rsyslog
/etc/default/slapd
/etc/systemd/journald.conf
/etc/logrotate.d/unattended-upgrades
/etc/logrotate.d/yunohost
/etc/zsh/zprofile
Mais
Saisissez « ls --help » pour plus d'informations.
ls: argument « mtime » incorrect pour « --time »
Les arguments valables sont :
- « atime », « access », « use »
- « ctime », « status »
- « birth », « creation »Mince, moi j’ai
je suis sous archlinux mais tout de même
Essaye avec ctime
peut être ctime d’après le man (change time)
Dans ce cas
root@crust:~# sh test.sh
Start
-rw-r--r-- 1 root root 181 17 oct. 20:20 /etc/logrotate.d/apt
-rw-r--r-- 1 root root 83 17 oct. 20:20 /etc/logrotate.d/aptitude
-rw-r--r-- 1 root root 25 25 avril 2024 /etc/issue.net
-rw-r--r-- 1 root root 877 17 oct. 20:20 /etc/issue
-rw-r--r-- 1 root root 3523 25 avril 2024 /etc/skel/.bashrc
-rw-r--r-- 1 root root 1543 25 juil. 2024 /etc/default/dnsmasq
-rw-r--r-- 1 root root 112 25 juil. 2024 /etc/dnsmasq.conf
-rw-r--r-- 1 root root 116 17 oct. 20:20 /etc/logrotate.d/dpkg
-rw-r--r-- 1 root root 124 17 oct. 20:20 /etc/logrotate.d/alternatives
-rw-r--r-- 1 root root 358 17 oct. 20:20 /etc/logrotate.d/fail2ban
-rw-r--r-- 1 root root 25586 20 août 11:52 /etc/fail2ban/jail.conf
-rw-r--r-- 1 root root 117 17 oct. 20:20 /etc/logrotate.d/influxdb
-rw-r----- 1 influxdb influxdb 19258 9 sept. 19:46 /etc/influxdb/influxdb.conf
-rw-r--r-- 1 root root 1377 25 avril 2024 /etc/initramfs-tools/initramfs.conf
-rw-r--r-- 1 root root 1222 25 avril 2024 /etc/pulse/client.conf
-rw-r--r-- 1 root root 158 17 oct. 20:20 /etc/logrotate.d/wtmp
-rw-r--r-- 1 root root 493 17 oct. 20:20 /etc/logrotate.conf
-rw-r--r-- 1 root root 143 17 oct. 20:20 /etc/logrotate.d/btmp
-rw-r--r-- 1 root root 1840 17 oct. 20:20 /etc/logrotate.d/mariadb
-rw-r--r-- 1 root root 85 13 oct. 2024 /etc/NetworkManager/NetworkManager.conf
-rwxr-xr-x 1 root root 363 20 août 11:52 /etc/nftables.conf
-rw-r--r-- 1 root root 1070 16 oct. 18:10 /etc/nginx/fastcgi_params
-rw-r--r-- 1 root root 333 17 oct. 20:20 /etc/logrotate.d/nginx
-rw-r--r-- 1 root root 897 10 nov. 2024 /etc/opendkim.conf
-rw-r--r-- 1 root root 219 17 oct. 20:20 /etc/logrotate.d/php8.0-fpm
-rw-r--r-- 1 root root 219 17 oct. 20:20 /etc/logrotate.d/php8.3-fpm
-rw-r--r-- 1 root root 219 17 oct. 20:20 /etc/logrotate.d/php8.4-fpm
-rw-r--r-- 1 root root 104 17 oct. 20:20 /etc/logrotate.d/bootlog
-rw-r--r-- 1 root root 2372 25 avril 2024 /etc/sysctl.conf
-rw-r--r-- 1 root root 128 17 oct. 20:20 /etc/logrotate.d/redis-server
-rw-r--r-- 1 root root 19 25 avril 2024 /etc/resolvconf/resolv.conf.d/head
-rw-r--r-- 1 root root 559 17 oct. 20:20 /etc/logrotate.d/rspamd
-rw-r--r-- 1 root root 426 17 oct. 20:20 /etc/logrotate.d/rsyslog
-rw-r--r-- 1 root root 1796 25 juil. 2024 /etc/default/slapd
-rw-r--r-- 1 root root 1054 17 oct. 20:20 /etc/systemd/journald.conf
-rw-r--r-- 1 root root 247 17 oct. 20:20 /etc/logrotate.d/unattended-upgrades
-rw-r--r-- 1 root root 140 17 oct. 20:20 /etc/logrotate.d/yunohost
-rw-r--r-- 1 root root 300 25 avril 2024 /etc/zsh/zprofile
Désolé, nos messages ont du se croiser…
Je veux pas déranger mais il est fort possible que le but premier étais simplement d’ajouter une machine à un simple botnet avec un shell, dans ce cas faudrait surtout voir qui est en cause et la ça va être coton.
Merci Clochette, merci concrètement quel chemin suivre ?