Re: Migration Debian 11 -> 12 : PB firmware
Bonjour francis, fw, on 2023-06-26: > Le PB: Après migration somme toute réussie, je m'interroge sur la > nature des messages suivants: > "... > /etc/kernel/postinst.d/initramfs-tools: > update-initramfs: Generating /boot/initrd.img-6.1.0-9-amd64 > W: Possible missing firmware /lib/firmware/amdgpu/ip_discovery.bin for > module amdgpu […] > Est-ce un message indiquant un défaut réel, ou simplement une absence > transitoire ..? Je reproduis le symptôme de mon côté dans une base bookworm propre si je force l'injection des ressources nécessaire au module amdgpu dans l'initramfs. Il manque quelque micro- programmes dans le paquet non-libre firmware-amd-graphics 20230210-5 de bookworm par rapport à ceux référencés par le pilote amdgpu du noyau. Vous pouvez consulter le bogue Debian n°1034903 [1] à ce sujet. A priori il ne devrait pas y avoir de casse, la carte graphique sera chargée avec une autre version de ces binaires par le pilote amdgpu au démarrage de la machine (probablement le 11_0_2 dans votre cas, ou bien les programmes constructeur directement chargés sur la carte s'il n'y a pas de mises à jour dans le système de fichier), voilà tout. Dans Debian sid, une version supérieure 11_0_4 de ces binaires a été injectée dans firmware-amd-graphics 20230515-1, mais les 11_0_3 et quelques autre .bin n'en ont jamais fait partie. [1] : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034903 Si ça peut clarifier les choses, -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/2, please excuse my verbosity. signature.asc Description: PGP signature
Re: Machine vérolée
Le vendredi 23 juin 2023 à 10:10:04 UTC+2, BERTRAND Joël a écrit :
> Bonjour à tous,
>
> Je reviens au sujet de ma machine vérolée. J'ai un peu avancé sur le
> sujet. J'ai trouvé la porte d'entrée et corrigé.
>
> Le processus hwm est un mineur de bitcoin. Celui-ci a été éradiqué et
> ne revient plus m'embêter.
>
> À intervalle régulier (ce matin à 08h50 par exemple), j'ai deux
> processus qui déboulent :
>
> 30269 www-data 20 0 10816 7088 3336 S 0,0 0,0 0:00.65
> /usr/local/apache/bin/httpd -DSSL
> 30275 www-data 20 0 10820 6660 2936 S 0,0 0,0 0:00.12
> /usr/local/apache/bin/httpd -DSSL
>
> Petit problème :
> # ls -l /usr/local/apache/bin/httpd
> ls: impossible d'accéder à '/usr/local/apache/bin/httpd': Aucun fichier
> ou dossier de ce type
>
> Un strace m'indique que le premier est un client, le second un serveur.
> Aucune idée de ce qu'ils font réellement, ça ne passe pas le firewall :
>
> connect(3, {sa_family=AF_INET, sin_port=htons(80),
> sin_addr=inet_addr("18.216.210.232")}, 16) = 0
> getsockname(3, {sa_family=AF_INET, sin_port=htons(48478),
> sin_addr=inet_addr("192.168.15.18")}, [128 => 16]) = 0
> write(3, "NICK xxx1851\n", 13) = 13
> getsockname(3, {sa_family=AF_INET, sin_port=htons(48478),
> sin_addr=inet_addr("192.168.15.18")}, [128 => 16]) = 0
> write(3, "USER xxx2113 192.168.15.18 18.21"..., 51) = 51
> clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=2, tv_nsec=0},
> 0x7fff7e181650) = 0
> pselect6(8, [3], NULL, NULL, {tv_sec=0, tv_nsec=6}, NULL) = 1
> (in [3], left {tv_sec=0, tv_nsec=55615})
> read(3, "\r\n\r\nDisconnected\r\n", 4096) = 18
> pselect6(8, [3], NULL, NULL, {tv_sec=0, tv_nsec=6}, NULL) = 1
> (in [3], left {tv_sec=0, tv_nsec=56008})
> read(3, "", 4096) = 0
> close(3) = 0
> socket(AF_INET, SOCK_STREAM|SOCK_CLOEXEC, IPPROTO_TCP) = 3
> fcntl(3, F_SETFD, FD_CLOEXEC) = 0
> ioctl(3, TCGETS, 0x7fff7e181460) = -1 ENOTTY (Ioctl() inapproprié
> pour un périphérique)
> lseek(3, 0, SEEK_CUR) = -1 ESPIPE (Repérage non permis)
> fcntl(3, F_SETFD, FD_CLOEXEC) = 0
> ioctl(3, TCGETS, 0x7fff7e181460) = -1 ENOTTY (Ioctl() inapproprié
> pour un périphérique)
> lseek(3, 0, SEEK_CUR) = -1 ESPIPE (Repérage non permis)
> connect(3, {sa_family=AF_INET, sin_port=htons(80),
> sin_addr=inet_addr("18.216.210.232")}, 16) = -1 ETIMEDOUT (Connexion
> terminée par expiration du délai d'attente)
> close(3) = 0
> socket(AF_INET, SOCK_STREAM|SOCK_CLOEXEC, IPPROTO_TCP) = 3
> fcntl(3, F_SETFD, FD_CLOEXEC) = 0
> ioctl(3, TCGETS, 0x7fff7e181460) = -1 ENOTTY (Ioctl() inapproprié
> pour un périphérique)
> lseek(3, 0, SEEK_CUR) = -1 ESPIPE (Repérage non permis)
> fcntl(3, F_SETFD, FD_CLOEXEC) = 0
> ioctl(3, TCGETS, 0x7fff7e181460) = -1 ENOTTY (Ioctl() inapproprié
> pour un périphérique)
> lseek(3, 0, SEEK_CUR) = -1 ESPIPE (Repérage non permis)
>
> Vu ce que je trouve dans le répertoire cwd de l'un des processus
> (/tmp/.wwwodsfidsfe) :
>
> # ls -alR
> .:
> total 8084
> drwxrwxrwx 3 www-data www-data 4096 23 juin 08:50 .
> drwxrwxrwt 10 root root 36864 23 juin 09:56 ..
> drwxr-xr-x 2 www-data www-data 4096 23 juin 09:56 fs
> -rw-rw-rw- 1 www-data www-data 8218683 23 juin 08:49 gg.tgz
>
> ./fs:
> total 14928
> drwxr-xr-x 2 www-data www-data 4096 23 juin 09:56 .
> drwxrwxrwx 3 www-data www-data 4096 23 juin 08:50 ..
> -rw-r--r-- 1 www-data www-data 24565 4 août 2022 1.html
> -rw-r--r-- 1 www-data www-data 3014144 23 juin 08:50 abe
> -rw-rw-rw- 1 www-data www-data 26 23 juin 09:56 bb
> -rw-r--r-- 1 www-data www-data 34 3 août 2022 d
> -rw-r--r-- 1 www-data www-data 26098 22 juin 09:10 da.html
> -rw-rw-rw- 1 www-data www-data 33699 23 juin 09:55 di.html
> -rw-r--r-- 1 www-data www-data 9235803 17 févr. 2022 git
> -rw-rw-rw- 1 www-data www-data 29 23 juin 09:35 has
> -rw-r--r-- 1 www-data www-data 43777 3 août 2022 me
> -rw-r--r-- 1 www-data www-data 246233 14 juil. 2022 ok
> -rw-r--r-- 1 www-data www-data 2598092 3 août 2022 ola
>
> le truc en question doit être un genre de serveur de mails qui envoie du
> pishing à la terre entière. Ces deux processus sont lancés par un script
> sh qui reste dans l'état de zombie très longtemps. Le parent est init
> (tant qu'à faire). Je n'arrive pas à trouver par quoi ce truc est lancé
> périodiquement. Sans doute un processus avec les droits www-data.
>
> Sur cette machine, les seules choses tournant avec les droits www-data
> sont :
> - un serveur apache2 (debian/testing)
> - php 8.2 (et 7.4 pour un blog b2 evolution)
> - trois sites SPIP (4.1.10 à jour, y compris les plugins)
>
> Je n'ai rien trouvé dans le cron, rien dans les tâches planifiées des
> sites en question, rien dans les logs. Je ne sais plus où chercher.
>
> Si je tue ces deux processus, au bout d'un certain temps, ils reviennent.
>
> Ma question est donc assez simple ;-) Comment trouver par quoi sont
> lancés ces deux processus ?
>
> Bien cordialement,
>
> JB
C'est pas evident !
Le mieux de
Re: Machine vérolée
Michel Verdier a écrit : > Le 25 juin 2023 BERTRAND Joël a écrit : > >> Petite remarque : j'ai modifié allow_url_fopen de on à off dans le >> fichier de configuration de php 8.2 (je ne vois pas pourquoi c'est 'on' >> par défaut). /tmp est maintenant en noexec. > > Attention de mémoire il y a plusieurs php.ini utilisés selon le mode > d'appel Merci, je sais. Et je vérifie toujours avec un php_info(). JB
Migration Debian 11 -> 12 : PB firmware
Bonjour à tous, 1ère demande de ma part, merci de vos remarques si j'ai loupé une étape ! Le PB: Après migration somme toute réussie, je m'interroge sur la nature des messages suivants: "... /etc/kernel/postinst.d/initramfs-tools: update-initramfs: Generating /boot/initrd.img-6.1.0-9-amd64 W: Possible missing firmware /lib/firmware/amdgpu/ip_discovery.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/vega10_cap.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/sienna_cichlid_cap.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/navi12_cap.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/psp_13_0_11_ta.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/psp_13_0_11_toc.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/psp_13_0_10_ta.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/psp_13_0_10_sos.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/aldebaran_cap.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_3_imu.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_4_rlc.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_4_mec.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_4_me.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_4_pfp.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_3_rlc.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_3_mec.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_3_me.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_3_pfp.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_0_toc.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/sdma_6_0_3.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/sienna_cichlid_mes1.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/sienna_cichlid_mes.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/navi10_mes.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_3_mes1.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_3_mes.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/smu_13_0_10.bin for module amdgpu ..." Est-ce un message indiquant un défaut réel, ou simplement une absence transitoire ..? Car finalement, après qq reboot, pas de dysfonctionnement apparent ... Merci à tous ! Cordialement, Francis -- francis Wong
IpCamera A9 ?
Slt, J'ai trois camera de type A9, et je me demande qui les a utilise pour faire de l'image a 360 degres ? Je me demande si cela ce monte en /dev/video ? Je veux filmer des faucon entrain de tuer une souris et les monter si j'ai l'accord du prestataire sur le panier d'une montgolfiere ! Je n'aipas reussi a booter la derniere fois sur 11 je crois en live, et je n'ai pas trouve de lug sympa, c'est normal, moi qui reve de blonde locale geek, quelqu'un a des infos pouur la camera ? Merci -- ptilou
Re: Machine vérolée (alternatives à PHP)
On 6/26/23 14:01, Michel Verdier wrote: Le 26 juin 2023 Erwann Le Bras a écrit : -SPIP est basé sur PHP ; je ne pense pas que le système SPIP lui-même serait touché (pas assez populaire) , mais les lancement de PHP? Au contraire SPIP a eu son lot de failles, il vaut mieux avoir la dernière version. Pour info, je rappelle l'existence d'alternatives européennes libres à PHP, à mon avis trop méconnues et peu utilisées, mais meilleures: Si on veut coder un service Web en C: https://www.coralbits.com/libonion/ (principalement espagnole, mais j'y ai contribué quelques lignes) Si on veut coder un service Web en C++: https://www.webtoolkit.eu/wt Si on préfere coder un service Web en Ocaml (dont le typage statique ajoute en sûreté), https://ocsigen.org/home/intro.html (c'est même français) Ces trois alternatives sont non seulement européennes, mais compilées nativement. L'avantage est alors aussi l'efficacité par rapport à un interprète PHP (oui, je sais que PHP8 a un compilateur JIT) Et je crois aussi que ces trois alternatives seraient plus sûres (en terme de cybersecurité). Librement -- Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/
Re: Machine vérolée
Le 25 juin 2023 BERTRAND Joël a écrit : > Petite remarque : j'ai modifié allow_url_fopen de on à off dans le > fichier de configuration de php 8.2 (je ne vois pas pourquoi c'est 'on' > par défaut). /tmp est maintenant en noexec. Attention de mémoire il y a plusieurs php.ini utilisés selon le mode d'appel
Re: Machine vérolée
Le 26 juin 2023 Jean-Michel OLTRA a écrit : > Il y a longtemps, j'avais eu un problème de ce genre, et je l'avais trouvé > en croisant (je crois que ça a déjà été suggéré) les horaires de lancement > avec l'exécution de certaines pages php. Oui c'est ce que je conseillais de faire > Peut-être peux tu également faire une recherche grep (ou ack-grep, ou ag) > sur les fichiers php et sur les fonctions qui peuvent agir. Je ne suis pas > assez calé en php pour te conseiller, mais des trucs comme mail, ou fopen, > ou system, ou exec, ou base64_encode (et decode) ? Oui il y a tout un tas de paramètres à régler dans php.ini de façon plus sécurisée : https://www.php.net/manual/fr/security.php
Re: Machine vérolée
Le 26 juin 2023 Erwann Le Bras a écrit : > -SPIP est basé sur PHP ; je ne pense pas que le système SPIP lui-même serait > touché (pas assez populaire) , mais les lancement de PHP? Au contraire SPIP a eu son lot de failles, il vaut mieux avoir la dernière version.
Re: Machine vérolée
BERTRAND Joël a écrit : > #!/bin/bash > > if [ $1 == "/usr/bin/rlog" ]; then exit 0; fi > if [ $1 == "/usr/bin/rcsdiff" ]; then exit 0; fi > logger -i "shell $*" > for i in $(pstree -p); do logger -i $i; done > > exec $* Ce script ne fonctionne pas correctement. J'ai essayé ceci, mais le résultat est identique. #!/bin/bash logger -i "shell $@" exec "$@" Par mail, je reçois par exemple /bin/sh: ligne 8: /var/lib/munin/if [ -x /usr/bin/munin-cron ]; then /usr/bin/munin-cron; fi > /dev/null 2>&1: Aucun fichier ou dossier de ce type Je suppose qu'il y un truc à faire avec les redirections, mais je sèche. Bien cordialement, JB
Re: Debian 12 - Migrer de 10 vers 12 ?
bonjour disons qu'elle est très -trop- détaillée? elle a l'avantage d'être complète et passer en revue les différentes étapes, les principaux problèmes courants et leur solution. C'est une doc d'exploitation à des fins de pilotage, c'est à dire qu'elle décrit tout le processus de migration pour quelqu'un qui ne l'a jamais fait, mais détaille également à un néophyte ce que fait chaque Moi qui ne suis pas à l'aise avec des montées de version, (j'ai pourtant commencé avec Debian 6 je crois bien)je la suis sans pb et ces explications rassurantes. La résolution des pb les plus courants directement en ligne est rassurant et m'a dépanné et évité de chercher des solutions on ne sait où. La doc est conforme aux standard Debian qui mériterait effectivement d'être modernisé. Le 24/06/2023 à 13:09, RogerT a écrit : Merci pour le pointeur. Cette documentation est démentielle. Trop de texte, trop de détails, pas assez de mise en évidence des éventuelles recettes directement applicables. Il faut tout lire pour en extraire quoi faire. Imaginons un débutant tomber là-dessus… Il fuira. Après tout, l’utilitaire de mise à niveau ne devrait-il pas traiter automatiquement l’essentiel des cas possibles ? En fait, les séquences de commandes déjà discutées dans ce fil sont infiniment plus simples et exploitables. Le 22 juin 2023 à 09:56, Frédéric BOITEUX a écrit : A chaque mise à jour, j'écume les tutos pour savoir si la procédure n'aurait pas changé ou s'il faut prévoir des choses parfois publiées. S'il y a une doc à lire, c'est celle des Notes de publication de chaque nouvelle version Debian, qui détaille comment effectuer la migration vers cette nouvelle version. Pour Debian 12 Bookworm, elle se situe ici :https://www.debian.org/releases/stable/amd64/release-notes/index.fr.html Cdlt, Fred.
Re: Machine vérolée
Erwann Le Bras a écrit : > bonjour Bonjour, > plusieurs pistes : > > - un truc qui se lance au démarrage de la machine et reste bien planqué > qui lance la saleté de temps en temps) ? > Je pense par exemple, s'il a exploité une faille de Apache à la base, a > pu modifié la config pour se lancer? Ou au boot de la machine > (systemctl) si les privilèges acquis permettaient d'avoir les droits "root" Il n'y a pas de systemctl, c'est un serveur Devuan. > -SPIP est basé sur PHP ; je ne pense pas que le système SPIP lui-même > serait touché (pas assez populaire) , mais les lancement de PHP? > > -Même remarque avec Perl, puisqu'il tourne avec. > > - Tu as fait un script /bin/sh, c'est très bien... à condition qu'il > passe bien par sh et pas directement par un autre shell. dans ce cas, > renommer tous les shelles présents en .sav, les remplacer par des liens > vers ton /bin/sh, et enfin lancer le script légitime avec le shell > d'origine.sav. Il passe par sh (j'ai le script zombie qui me l'indique). JB
Re: Machine vérolée
NoSpam a écrit : > Bonjour > > rkhunter et chkrootkit ne détectent rien ? chkrootkit ne couine pas (il tourne depuis des années dans un cron). rkhunter que j'ai lancé hier non plus.
Re: Machine vérolée
Bonjour rkhunter et chkrootkit ne détectent rien ? Le 26/06/2023 à 11:26, Jean-Michel OLTRA a écrit : Bonjour, Le lundi 26 juin 2023, BERTRAND Joël a écrit... Est-ce que vous voyez plus efficace ? Le vers en question lance d'abord un script sh qui daemonise un exécutable perl. Je cherche à savoir qui lance cette saleté (sans doute www-data) mais surtout quel est l'exécutable. Je subodore qu'il est au chaud quelque part dans le fond d'une arborescence de www-data, mais rien ne me saute aux yeux. Il y a longtemps, j'avais eu un problème de ce genre, et je l'avais trouvé en croisant (je crois que ça a déjà été suggéré) les horaires de lancement avec l'exécution de certaines pages php. Peut-être peux tu également faire une recherche grep (ou ack-grep, ou ag) sur les fichiers php et sur les fonctions qui peuvent agir. Je ne suis pas assez calé en php pour te conseiller, mais des trucs comme mail, ou fopen, ou system, ou exec, ou base64_encode (et decode) ?
Re: Machine vérolée
Bonjour, Le lundi 26 juin 2023, BERTRAND Joël a écrit... > Est-ce que vous voyez plus efficace ? Le vers en question lance d'abord > un script sh qui daemonise un exécutable perl. Je cherche à savoir qui > lance cette saleté (sans doute www-data) mais surtout quel est > l'exécutable. Je subodore qu'il est au chaud quelque part dans le fond > d'une arborescence de www-data, mais rien ne me saute aux yeux. Il y a longtemps, j'avais eu un problème de ce genre, et je l'avais trouvé en croisant (je crois que ça a déjà été suggéré) les horaires de lancement avec l'exécution de certaines pages php. Peut-être peux tu également faire une recherche grep (ou ack-grep, ou ag) sur les fichiers php et sur les fonctions qui peuvent agir. Je ne suis pas assez calé en php pour te conseiller, mais des trucs comme mail, ou fopen, ou system, ou exec, ou base64_encode (et decode) ? -- jm
Re: Machine vérolée
bonjour plusieurs pistes : - un truc qui se lance au démarrage de la machine et reste bien planqué qui lance la saleté de temps en temps) ? Je pense par exemple, s'il a exploité une faille de Apache à la base, a pu modifié la config pour se lancer? Ou au boot de la machine (systemctl) si les privilèges acquis permettaient d'avoir les droits "root" -SPIP est basé sur PHP ; je ne pense pas que le système SPIP lui-même serait touché (pas assez populaire) , mais les lancement de PHP? -Même remarque avec Perl, puisqu'il tourne avec. - Tu as fait un script /bin/sh, c'est très bien... à condition qu'il passe bien par sh et pas directement par un autre shell. dans ce cas, renommer tous les shelles présents en .sav, les remplacer par des liens vers ton /bin/sh, et enfin lancer le script légitime avec le shell d'origine.sav. bon courage, on l'aura Le 26/06/2023 à 10:56, BERTRAND Joël a écrit : Sébastien Dinot a écrit : BERTRAND Joël a écrit : Porte d'entrée trouvée : Merci pour ce retour, toujours intéressant à avoir. Porte d'entrée trouvée, mais il reste des scories. Je suis en train de logguer ce que fait sh pour savoir quel est le processus qui me réinstalle le vers régulièrement. Le truc est bien planqué et est revenu à la charge plusieurs fois ce matin. Bon, il ne peut rien faire puisque les ports sur lesquels il veut se connecter sont fermés sur le firewall, mais c'est pénible. Ce n'est visiblement pas lancé par un cron (pas de régularité). J'utilise un /bin/sh qui fait cela : #!/bin/bash if [ $1 == "/usr/bin/rlog" ]; then exit 0; fi if [ $1 == "/usr/bin/rcsdiff" ]; then exit 0; fi logger -i "shell $*" for i in $(pstree -p); do logger -i $i; done exec $* Est-ce que vous voyez plus efficace ? Le vers en question lance d'abord un script sh qui daemonise un exécutable perl. Je cherche à savoir qui lance cette saleté (sans doute www-data) mais surtout quel est l'exécutable. Je subodore qu'il est au chaud quelque part dans le fond d'une arborescence de www-data, mais rien ne me saute aux yeux. JB
Re: Machine vérolée
Sébastien Dinot a écrit : > BERTRAND Joël a écrit : >> Porte d'entrée trouvée : > > Merci pour ce retour, toujours intéressant à avoir. Porte d'entrée trouvée, mais il reste des scories. Je suis en train de logguer ce que fait sh pour savoir quel est le processus qui me réinstalle le vers régulièrement. Le truc est bien planqué et est revenu à la charge plusieurs fois ce matin. Bon, il ne peut rien faire puisque les ports sur lesquels il veut se connecter sont fermés sur le firewall, mais c'est pénible. Ce n'est visiblement pas lancé par un cron (pas de régularité). J'utilise un /bin/sh qui fait cela : #!/bin/bash if [ $1 == "/usr/bin/rlog" ]; then exit 0; fi if [ $1 == "/usr/bin/rcsdiff" ]; then exit 0; fi logger -i "shell $*" for i in $(pstree -p); do logger -i $i; done exec $* Est-ce que vous voyez plus efficace ? Le vers en question lance d'abord un script sh qui daemonise un exécutable perl. Je cherche à savoir qui lance cette saleté (sans doute www-data) mais surtout quel est l'exécutable. Je subodore qu'il est au chaud quelque part dans le fond d'une arborescence de www-data, mais rien ne me saute aux yeux. JB
Re: Machine vérolée
Le 2023-06-26 10:35, Erwann Le Bras a écrit : merci du retour d'expérience, c'est intéressant. D'où l'importance des patchs de sécurité à passer le plus tôt possible. Cette expérience, qui date de 2004, m'a servi de leçon. Depuis, la plupart des serveurs que j'administre sont mis à jour toutes les 4 heures (merci aux auteurs du paquet unattended-upgrades qui me permet de gérer au mieux ces mises à jour). Les exceptions à cette règle sont des serveurs bien moins exposés dont la disponibilité en journée prime sur les mises à jour. Ceux-ci ne sont mis à jour qu'entre 20 heures et 8 heures du matin (là encore, toutes les 4 heures). Mais dès qu'un serveur est exposé sur le net, je refuse de déroger à cette règle, unattended-upgrades est lancée une fois toutes les 4 heures (modulo l'aléa introduit pour répartir la charge sur les serveurs Debian). Mais comme il faut savoir rester humble en matière de sécurité, j'ai l'habitude de dire que tous les crackers qui ont réalisé des attaques fructueuses sur mes machines depuis 2004 ont été assez malins pour que je ne m'aperçoive de rien. :) Sébastien -- Sébastien Dinot Ne goutez pas au logiciel libre, vous ne pourriez plus vous en passer ! https://www.palabritudes.net/
Re: Machine vérolée
merci du retour d'expérience, c'est intéressant. D'où l'importance des patchs de sécurité à passer le plus tôt possible. Erwann Le 23/06/2023 à 11:35, Sébastien Dinot a écrit : je devais compiler moi-même le noyau au lieu d'utiliser celui fourni par Debian, chose que je faisais rarement par flemme (les attaquants avaient utilisé une faille d'Apache qui n'avait existé que 3 jours sur Debian – pas de bol – puis ils avaient obtenu plus de privilèges en exploitant une faille dans le noyau, corrigée depuis bien longtemps par Debian)
