ctime = date de creation, atime ) date d’accès, mtime = date de modification, d’où l’intérêt de mtime.
Tant pis, il faudrait que tu regardes si il y a une salle tête. De ce que je vois, il semble (code pas simple à analyser), que le botnet cherche à se dissimuler sous des noms variés (peut être /bin/busybox
/usr/lib/systemd/systemd ou /usr/libexec/openssh/sftp-server).
Sinon je n’ai pas vu de CVE sur ta version de nextcloud. Il y a aussi glances donc comme candidat porte d’entrée. Sans logs on ne pourra pas faire grand chose de plus.
Cela dit la présence de ces fichiers montre que quelque chose s’est mal passé, un vers aussi sophistiqué ne laisse pas ces traces. Donc à mon avis le processus n’a pas été jusqu’au bout
(mais c’est juste une opinion)
Si je supprime glances, ça peut arranger les choses ou c’est trop tard ?
(pourtant glances venait des repos debian…)
Les fichiers de la racine, je peux les supprimer ?
Mieux vaut une réinstall avec les backup yunohost (que je vais créer donc risque aussi d’être corrompus…)
Franchement, je ne sais pas quoi faire
Ensuite, si plus simple de tout virer… Mais je ne pense pas avoir fait n’importe quoi avec ce serveur, donc risque de se reproduire
En tout cas, un super grand merci pour le temps passé
Toutes les connexions exceptées peut être celles pour nextcloud (ça va te faire des logs énormes), sur nextcloud tu devrais voir beaucoup de scans et autres donc pas facile à analyser sur une longue période (sauf si il y a bcp de connexions non authentifiées)
Pour les mises à jour, avant de la faire il faut faire
qui t’autorise à nouveau les mises à jour de nextcloud (adapte l’emplacement). Mais vérifiés avant si nextcloud modifie ses fichiers PHP, honnetement je ne pense pas, c’est vraiment très risqué et peu orthodoxe de le faire
Pour surveiller tes fichiers tu peux faire la chose suivante:
Liste des fichiers, par exemple
find /usr/bin -type f > /etc/liste_surveillance
find /usr/sbin -type f >> /etc/liste_surveillance
# find /usr/lib -type f | grep -v python | grep -v modules >> /etc/liste_surveillance
find /usr/local/bin -type f >> /etc/liste_surveillance
find /var/www -type f | grep -v '/html/' >> /etc/liste_surveillance
find /usr/sbin -type f >> /etc/liste_surveillance
# find /etc/init.d -type f >> /etc/liste_surveillance
# find /etc/rc*.d -type f >> /etc/liste_surveillance
find /etc -type f | grep -v '^/.*/.*/' >> /etc/liste_surveillance
(à adapter bien sur)
Puis tu télécharges surveille_arm (je viens de le compiler) que tu mets par exemple sur /usr/local/bin, puis tu fais
surveille_arm -v -i
Ça calcule tous les md5 des fichiers de ta liste et te les mets dans un fichier dédié. Ensuite, tu peux faire régulièrement ou via cron
surveille_arm
et ça te donnera les fichiers modifiés ou manquants.
Tu peux aussi refaire régulièrement le script de fabrication de liste_surveillance et comparer avec le fichier /etc/liste_surveillance pour voir les nouveaux fichiers
Mauvaise méthode.
Rien ne permet de déterminer que queqlue chose ne reste pas.
C’est justement en ne réinstallant pas qu’on se retrouve avec des compromissions à répétitions.
tous les protocole aujourd’hui sans aucune exception recommandent de réinstaller la machine.
et dans le cas de réutilisations de sauvegarde de ne réutiliser QUE des sauvegarde sans aucun binaires en faisant un parsing éventuel pour vérifier si des fichiers qui ne sont pas sensés avoir du code n’en ont pas.
Oui, c’est sur mais je ne l’ai jamais fait si j’y réfléchis bien (je ne dis pas que c’est le mieux à faire). Ceci ne peut être fait que si c’est un serveur non essentiel avec des données anodines et si il n’y a pas moyen de faire autrement.
La toute première fois parce que je voulais comprendre (cf instrusion Noel ) ce qui a été le cas (et a été la source d’un détecteur de processus caché qui a particulièrement été téléchargé avant l’apparition de ceux mieux faits de debian.
Dans d’autres cas, il s’agissait de serveurs d’association ou de forum où il était impossible de se passer du serveur et il n’y avait pas la possibilité matérielle et le temps de réinstaller complètement le serveur dans un délai raisonnable. De plus on perdait les traces et le moyen de localiser la source de l’intrusion, or chaque fois l’origine était un pluggin foireux de Joomla ou un script d’une personne (le plus compliqué permettait une injection blind SQL) donc des choses qui auraient été remises. Il fallait impérativement trouver l’origine.
En revanche cela impose une surveillance complète de la machine (fichiers rajoutés, modifiés, etc) signalés dans le quart d’heure qui suit par texto et par mail dans le quart d’heure qui suit, conservation des logs sur 2 ans avec surveillance. Ce que je trouve regrettable dans le cas ici c’est qu’on ne sait pas d’où vient l’intrusion ni ce qu’a fait le gars. Il y a des chances pour que ça recommence et que le problème se repose ss arrêt.
Pour te dire que je ne suis pas inconscient, le serveur du concours dont je m’occupais était chez moi dans l’année et répliqué en local sur un serveur (inaccessible de l’extérieur bien sur) au lieu du concours dans la période de l’oral. Dans tous les cas, il y avait un backup incrémental des bases de données et surtout un serveur secondaire avec des bases de données répliquées prêt à prendre dans le 1/4h qui suivait la place du serveur. Mais on n’est plus dans le cas d’un serveur non essentiel.
Bref tu as raison, nettement, et ce que je suggère n’est que dans le cas d’un serveur non sensible qu’on ne veut pas ou peut pas réinstaller
non, légalement en france on est civilement responsable de ce qui peut etre fait avec sa machine. si tu n’a pas prouvé que tu avais fait ce qu’i fallait pour l’éviter tout risque, ta responsabilité est engagée.
C’est à cause de ça que les pirate prolifèrent. et en 2025 c’est une mauvaise excuse qui ne fait que prouver factuellement une incompétence. Et cette incompétence n’est pas une excuse légale.
Que ce soit une association ou un particulier.
Raison de plus pour réinstaller.
Quand on publie sur internet u_n service quel qu’il soit, on fait un suivi des failles via CERTFR ou autre.
On expose pas une BDD à ce genre de faille connue depuis le début des années 2000 et facilement évitable.
Non la priorité suivant les moyen c’est de supprimer le problème et de remettre en service un système fiable.
Trouve l’origine de la compromission c’est un boulot de professionnel ou à minima de spécialiste. et même pour eux c’est difficile. Si on est un amateur, comme 99% de la population, on se préoccupe rde faire disparaître la compromission. et surtout on met des systèmes à jour de toutes les failles connues, on évite de ne pas utiliser de reverse proxy ou le cas échéant de WAF.
On est plus à la préhistoire des publications web. Aujourd’hui, y compris en web il y a pas mal de moyen d’éviter de se faire coller un bot.
Quand on vient d’avoir son permis on ne fait de la formule 1.
Non, ça c’est la deuxième étape. La première c’est de ne pas avoir un OS qui a une ou deux version majeure de retard.
D’avoir des logiciels qui sont à jour des failles les plus connues.
D’avoir un pare-feu non permissif.
D’avoir un reverse proxy ou un waf.
La sécurité est un ensemble complexe, c’est une évidence.
Les solutions de type YUnohost ont tendance à masque l’aspect sécurité, ne serait-ce que sur les aspect basique de la sécurité. on pas parce que c’est une volonté mais parce que ces solutions font croire, ou plutôt donne un sentiment de confiance, par ce qu’elle semble tout gérer. C’est un leurre. Les botnet s’en font d’ailleurs une joie.
Le premier point c’est qu’aucun utilisateur de la solution n’est fiable, et on ne doit pas faire confiance à qui que ce soit y compris soit même.
Si les entreprises n’utilisent pas ce type de solutions c’est qu’il y a une raison.
Quant à la surveillance au quart d’heure, c’est inutile et ingérable sauf à payer des gars pour être dessus en permanence.
Ce qu’il faut ce sont des sauvegarde régulière de données, excluant systématiquement toute forme de cote ou d’exécutable.
Les données et le système doivent être sauvegardées séparément.
Pour ce qui est des failles il suffit de faire des pentest avec des outils comme Lynis, ou plus avancé avec OpenVAS. C’est assez simple à faire en environnement fermé avant de les mettre en ligne.
Si on se contente de faire une installation debian, ensuite de mettre les outils et ensuite de mettre en ligne, c’est mort.
L’installation de base de Debian n’est absolument pas sécurisé. L’activation de sudo est d’une insuffisance totale bien que nécessaire et encore. Sur une machine exposée sur internet il faut bannir inutilisation de sudo. Car présumer qu’un compte utilisateur soit mieux protégé que le compte admin est une erreur fondamentale.
je vous invite à faire un lynis en local sur votre machine pour voir le resultat.
J’utilise 15000 ligne de shell pour vérifier et sécuriser mes machines en interne, donc je ne vous dit pas pour celle que j’expose sur internet… Et même comme ça, je ne suis sur de rien. mais je suis plus sur que la plupart des gens.
On dérive là mais bon, juste pour te dire que dans tout ces cas (y compris mon cas en 2003 la première fois) , les gens concernés étaient des particuliers ou des associations qui n’avaient pas les capacités ni les moyens de faire ce que tu dis, c’est regrettable mais c’est comme ça y compris dans des institutions publiques comme les lycées. Ces personnes ne peuvent pas se payer un informaticien pour gérer leur parc et compte sur le bénévolat de personnes n’ayant pas un temps infini. Je n’ai jamais reçu un sou pour les serveurs dont je t’ai parlé (une bouteille de whisky une fois), en revanche je peux assurer que dans le temps qui a suivi mes actions, les machines sont restées saines (c’est une certitude). Quand l’idéal n’est pas possible on se débrouille au mieux en évitant de laisser des gens dans la panade. Mais encore une fois, tu as bien dit ce qu’il faut faire dans l’idéal.
PS: répond moi par MP si tu veux, inutile de pourrir ce fil
sauf que le monde a changé et qu’il change, et à un point qu’on imagine rarement. Le temps du bricolage n’est plus possible. Parce que les « pirates » ne sont pas que des voyous, ce sont aussi des agents.
Bonjour,
Désolé pour le temps de réponse mais il a mis toute une journée pour scanner le système (la machine n’est pas très véloce) et dimanche je n’étais pas là
cat rapport_clamav.txt
/4shit.tar: Unix.Trojan.Mirai-8025795-0 FOUND
/data/local/tmp/x86_64: Unix.Trojan.Mirai-8025795-0 FOUND
/data/local/tmp/spc.1: Unix.Trojan.Mirai-8025795-0 FOUND
/data/local/tmp/sh4.4: Unix.Dropper.Mirai-7136288-0 FOUND
/data/local/tmp/csk_x86: Unix.Trojan.Mirai-9441505-0 FOUND
/data/local/tmp/sh4.2: Unix.Dropper.Mirai-7136288-0 FOUND
/data/local/tmp/nohup: Win.Trojan.Agent-6732758-0 FOUND
/data/local/tmp/x86.1: Unix.Dropper.Mirai-7135858-0 FOUND
/data/local/tmp/arm5.1: Unix.Trojan.Mirai-8274771-0 FOUND
/data/local/tmp/arm5: Unix.Trojan.Mirai-8274771-0 FOUND
/data/local/tmp/csk_arm: Unix.Trojan.Mirai-9441505-0 FOUND
/data/local/tmp/x86_64.4: Unix.Trojan.Mirai-8025795-0 FOUND
/data/local/tmp/csk_spc: Unix.Trojan.Mirai-9441505-0 FOUND
/data/local/tmp/x86.4: Unix.Dropper.Mirai-7135858-0 FOUND
/data/local/tmp/m68k.2: Unix.Trojan.Mirai-6981989-0 FOUND
/data/local/tmp/x86.2: Unix.Dropper.Mirai-7135858-0 FOUND
/data/local/tmp/spc.4: Unix.Trojan.Mirai-8025795-0 FOUND
/data/local/tmp/spc.3: Unix.Trojan.Mirai-8025795-0 FOUND
/data/local/tmp/csk_mips: Unix.Trojan.Mirai-9441505-0 FOUND
/data/local/tmp/csk_arm6: Unix.Trojan.Mirai-9441505-0 FOUND
/data/local/tmp/x86: Unix.Dropper.Mirai-7135858-0 FOUND
/data/local/tmp/x86.3: Unix.Dropper.Mirai-7135858-0 FOUND
/data/local/tmp/csk_ppc: Unix.Trojan.Mirai-9441505-0 FOUND
/data/local/tmp/ppc: Unix.Trojan.Mirai-9936831-0 FOUND
/data/local/tmp/m68k: Unix.Trojan.Mirai-6981989-0 FOUND
/data/local/tmp/arm5.3: Unix.Trojan.Mirai-8274771-0 FOUND
/data/local/tmp/arm5.2: Unix.Trojan.Mirai-8274771-0 FOUND
/data/local/tmp/csk_ppc.1: Unix.Trojan.Mirai-9441505-0 FOUND
/data/local/tmp/ppc.3: Unix.Trojan.Mirai-9936831-0 FOUND
/data/local/tmp/m68k.1: Unix.Trojan.Mirai-6981989-0 FOUND
/data/local/tmp/ppc.1: Unix.Trojan.Mirai-9936831-0 FOUND
/data/local/tmp/spc: Unix.Trojan.Mirai-8025795-0 FOUND
/data/local/tmp/ppc.2: Unix.Trojan.Mirai-9936831-0 FOUND
/data/local/tmp/sh4: Unix.Dropper.Mirai-7136288-0 FOUND
/data/local/tmp/csk_mpsl: Unix.Trojan.Mirai-9441505-0 FOUND
/data/local/tmp/csk_x86_64: Unix.Dropper.Mirai-7540662-0 FOUND
/data/local/tmp/arm5.4: Unix.Trojan.Mirai-8274771-0 FOUND
/data/local/tmp/trinity: Unix.Malware.Agent-7359388-0 FOUND
/data/local/tmp/x86_64.3: Unix.Trojan.Mirai-8025795-0 FOUND
/data/local/tmp/csk_arm7: Unix.Dropper.Mirai-7135925-0 FOUND
/data/local/tmp/csk_m68k: Unix.Trojan.Mirai-6981989-0 FOUND
/data/local/tmp/x86_64.1: Unix.Trojan.Mirai-8025795-0 FOUND
/data/local/tmp/ppc.4: Unix.Trojan.Mirai-9936831-0 FOUND
/data/local/tmp/spc.2: Unix.Trojan.Mirai-8025795-0 FOUND
/data/local/tmp/m68k.3: Unix.Trojan.Mirai-6981989-0 FOUND
/data/local/tmp/m68k.4: Unix.Trojan.Mirai-6981989-0 FOUND
/data/local/tmp/sh4.3: Unix.Dropper.Mirai-7136288-0 FOUND
/data/local/tmp/x86_64.2: Unix.Trojan.Mirai-8025795-0 FOUND
/data/local/tmp/sh4.1: Unix.Dropper.Mirai-7136288-0 FOUND
/data/local/tmp/csk_arm5: Unix.Trojan.Mirai-9441505-0 FOUND
/var/www/my_webapp/www/arm.tar: Unix.Trojan.Mirai-8274771-0 FOUND
Pour le premier et le dernier, c’est moi qui ait fait les archive pour 1/ les conserver (?), 2/ les mettre à disposition
Pour le reste, je présume que je peux supprimer les fichiers.
Voici la sortie de chrootkit,
No file /var/log/chkrootkit/log.expected
This file should contain expected output from chkrootkit
Today’s run produced the following output:
— [ BEGIN: cat /var/log/chkrootkit/log.today ] —
ROOTDIR is /' Checking amd’… not found
Checking basename'... not infected Checking biff’… not found
Checking chfn'... not infected Checking chsh’… not infected
Checking cron'... not infected Checking crontab’… not infected
Checking date'... not infected Checking du’… not infected
Checking dirname'... not infected Checking echo’… not infected
Checking egrep'... not infected Checking env’… not infected
Checking find'... not infected Checking fingerd’… not found
Checking gpm'... not found Checking grep’… not infected
Checking hdparm'... not infected Checking su’… not infected
Checking ifconfig'... not infected Checking inetd’… not infected
Checking inetdconf'... not found Checking identd’… not found
Checking init'... not infected Checking killall’… not infected
Checking ldsopreload'... not infected Checking login’… not infected
Checking ls'... not infected Checking lsof’… not infected
Checking mail'... not infected Checking mingetty’… not found
Checking netstat'... not infected Checking named’… not found
Checking passwd'... not infected Checking pidof’… not infected
Checking pop2'... not found Checking pop3’… not found
Checking ps'... not infected Checking pstree’… not infected
Checking rpcinfo'... not infected Checking rlogind’… not found
Checking rshd'... not found Checking slogin’… not infected
Checking sendmail'... not infected Checking sshd’… not infected
Checking syslogd'... not found Checking tar’… not infected
Checking tcpd'... not found Checking tcpdump’… not infected
Checking top'... not infected Checking telnetd’… not found
Checking timed'... not found Checking traceroute’… not found
Checking vdir'... not infected Checking w’… not infected
Checking write'... not infected Checking aliens’… started
Searching for suspicious files in /dev… not found
Searching for known suspicious directories… not found
Searching for known suspicious files… not found
Searching for sniffer’s logs… not found
Searching for HiDrootkit rootkit… not found
Searching for t0rn rootkit… not found
Searching for t0rn v8 (or variation)… not found
Searching for Lion rootkit… not found
Searching for RSHA rootkit… not found
Searching for RH-Sharpe rootkit… not found
Searching for Ambient (ark) rootkit… not found
Searching for suspicious files and dirs… WARNING
WARNING: The following suspicious files and directories were found:
/usr/lib/python3/dist-packages/glances/outputs/static/.prettierrc.js
/usr/lib/python3/dist-packages/tldextract/.suffix_cache
/usr/lib/python3/dist-packages/tldextract/.tld_set_snapshot
/usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/basic/authz_owner/.htpasswd
/usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/basic/authz_owner/.htaccess
/usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/basic/file/.htpasswd
/usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/basic/file/.htaccess
/usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/digest/.htpasswd
/usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/digest/.htaccess
/usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/noentry/.htaccess
/usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/digest_wrongrelm/.htpasswd
/usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/digest_wrongrelm/.htaccess
/usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/digest_time/.htpasswd
/usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/digest_time/.htaccess
/usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/digest_anon/.htpasswd
/usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/digest_anon/.htaccess
Searching for LPD Worm… not found
Searching for Ramen Worm rootkit… not found
Searching for Maniac rootkit… not found
Searching for RK17 rootkit… not found
Searching for Ducoci rootkit… not found
Searching for Adore Worm… not found
Searching for ShitC Worm… not found
Searching for Omega Worm… not found
Searching for Sadmind/IIS Worm… not found
Searching for MonKit… not found
Searching for Showtee rootkit… not found
Searching for OpticKit… not found
Searching for T.R.K… not found
Searching for Mithra rootkit… not found
Searching for OBSD rootkit v1… not tested
Searching for LOC rootkit… not found
Searching for Romanian rootkit… not found
Searching for HKRK rootkit… not found
Searching for Suckit rootkit… not found
Searching for Volc rootkit… not found
Searching for Gold2 rootkit… not found
Searching for TC2 rootkit… not found
Searching for Anonoying rootkit… not found
Searching for ZK rootkit… not found
Searching for ShKit rootkit… not found
Searching for AjaKit rootkit… not found
Searching for zaRwT rootkit… not found
Searching for Madalin rootkit… not found
Searching for Fu rootkit… not found
Searching for Kenga3 rootkit… not found
Searching for ESRK rootkit… not found
Searching for rootedoor… not found
Searching for ENYELKM rootkit… not found
Searching for common ssh-scanners… not found
Searching for Linux/Ebury 1.4 - Operation Windigo… not tested
Searching for Linux/Ebury 1.6… not tested
Searching for 64-bit Linux Rootkit… not found
Searching for 64-bit Linux Rootkit modules… not found
Searching for Mumblehard… not found
Searching for Backdoor.Linux.Mokes.a… not found
Searching for Malicious TinyDNS… not found
Searching for Linux.Xor.DDoS… not found
Searching for Linux.Proxy.1.0… not found
Searching for CrossRAT… not found
Searching for Hidden Cobra… not found
Searching for Rocke Miner rootkit… not found
Searching for PWNLNX4 lkm rootkit… not found
Searching for PWNLNX6 lkm rootkit… not found
Searching for Umbreon lrk… not found
Searching for Kinsing.a backdoor rootkit… not found
Searching for RotaJakiro backdoor rootkit… not found
Searching for Syslogk LKM rootkit… not found
Searching for Kovid LKM rootkit… not tested
Searching for suspect PHP files… not found
Searching for zero-size shell history files… not tested
Searching for hardlinked shell history files… not tested
Checking aliens'... finished Checking asp’… not infected
Checking bindshell'... not found Checking lkm’… started
Searching for Adore LKM… not tested
Searching for sebek LKM (Adore based)… not tested
Searching for knark LKM rootkit… not found
Searching for for hidden processes with chkproc… not found
Searching for for hidden directories using chkdirs… not found
Checking lkm'... finished Checking rexedcs’… not found
Checking `sniffer’… WARNING
WARNING: Output from ifpromisc:
lo: not promisc and no packet sniffer sockets
: PACKET SNIFFER([systemd-networkd|dhclient|dhcpd|dhcpcd|wpa_supplicant|NetworkManager]{PID})
Checking w55808'... not found Checking wted’… not found
Checking scalper'... not found Checking slapper’… not found
Checking z2'... not found Checking chkutmp’… not found
Checking `OSX_RSPLUG’… not tested
— [ END: cat /var/log/chkrootkit/log.today ] —
To create this file containing all output from today’s run, do (as root)
cp -a /var/log/chkrootkit/log.today /var/log/chkrootkit/log.expected
(note that unedited output is in /var/log/chkrootkit/log.today.raw)
A priori ce serait des faux positifs
Je vais sans doute repartir sur du propre (s c’est mieux pour vous et garderai ce système pour analyse quand j’aurais plus d’expérience
