Re : Re: [Résolu] Pas d'historique de zsh en root
Le vendredi 23 juin 2023 à 11:24, Marc Chantreux a écrit : > salut, > > > Enfin tant que ça marche... > > > idéalement il faudrait comprendre pourquoi mais là j'ai vraiment pas le > temps :( > C'est déjà bien sympa de m'avoir filé ta config... :-) Ma confusion vient du fait que j'ai crus (à tors, je viens de vérifier, ce n'est pas dit dans le manuel) que l'option APPEND_HISTORY est l'option par défaut avec HISTFILE=nom_fichier. Mais c'est faux, voici l'info exacte : INC_APPEND_HISTORY This option works like APPEND_HISTORY except that new history lines are added to the $HISTFILE incrementally (as soon as they are entered), rather than waiting until the shell exits. The file will still be periodically re-written to trim it when the number of lines grows 20% beyond the value specified by $SAVEHIST (see also the HIST_SAVE_BY_COPY option). APPEND_HISTORY If this is set, zsh sessions will append their history list to the history file, rather than replace it. Thus, multiple parallel zsh sessions will all have the new entries from their history lists added to the history file, in the order that they exit. The file will still be periodically re-written to trim it when the number of lines grows 20% beyond the value specified by $SAVEHIST (see also the HIST_SAVE_BY_COPY option). Du coup je n'ai pas gardé l'option : EXTENDED_HISTORY Save each command’s beginning timestamp (in seconds since the epoch) and the duration (in seconds) to the history file. The format of this prefixed data is: ‘: :;’. Pas besoin de dater, surtout si c'est humainement lisible HIST_FIND_NO_DUPS When searching for history entries in the line editor, do not display duplicates of a line previously found, even if the duplicates are not contiguous. Me semble redondant avec HIST_IGNORE_ALL_DUPS qui en cas de doublon supprime l'existant et ne garde que le nouveau, du coup il ne saurait pas trouver de doublon. Cf. https://zsh.sourceforge.io/Doc/Release/Options.html
Re: Quels Outils pour lire sur un disque dur rétif.
23 juin 2023 14:58 "Billard François-Marie" a écrit: > Bonjour > > J'ai eu cette semaine une demande pour un disque dur externe en USB sur > lequel nous ne pouvions > plus rien lire. > > Sous linux j'ai juste réussi à le voir avec un lsusb comme présent mais après > qu'est il possible de > faire, existe-t-il des outils plus spécifiques ? Si tu le vois avec lsusb mais pas avec lsblk, je sais pas quoi faire. Si tu le vois aussi avec lsblk, la premiere priorite c'est de cloner le disque avec ddrescue. Ensuite, je considere ce disque comme mort et je n'y touche plus. Je fais donc une sauvegarde du clone, puis j'essaye fsck, testdik et photorec. Quand un de ces 3 trucs plante en ayant modifié des choses, je restaure le clone a partir de la sauvegarde et j'essaye autrement.
Re: Quels Outils pour lire sur un disque dur rétif.
Bonjour, Le 2023-06-23 14:58, Billard François-Marie a écrit : J'ai eu cette semaine une demande pour un disque dur externe en USB sur lequel nous ne pouvions plus rien lire. Sous linux j'ai juste réussi à le voir avec un lsusb comme présent mais après qu'est il possible de faire, existe-t-il des outils plus spécifiques ? As-tu essayé (pas toujours possible) d'extraire le disque de son boîtier et de le lire en direct ou via un autre boîtier ? Parfois le disque se porte très bien dans le boîtier qui flanche… Sébastien
Re: Quels Outils pour lire sur un disque dur rétif.
Bonjour, on peut aussi mentionner gpart mais deux classiques (empaquetés dans Debian) en fonction du contexte sont: - testdisk (intro sur le truc: https://www.cgsecurity.org/wiki/TestDisk_FR) - photorec (intro sur le truc: https://www.cgsecurity.org/wiki/PhotoRec_FR)
Quels Outils pour lire sur un disque dur rétif.
Bonjour J'ai eu cette semaine une demande pour un disque dur externe en USB sur lequel nous ne pouvions plus rien lire. Sous linux j'ai juste réussi à le voir avec un lsusb comme présent mais après qu'est il possible de faire, existe-t-il des outils plus spécifiques ? Merci François-Marie
Re: Étrange réponse de apt après passage de testing à stable
Le 23/06/2023 à 12:53, yamo' a écrit : Salut, Merci pour la réponse. C'est une machine que j'ai passé en bookworm aux environ le 8 juin et qui depuis était éteinte (elle me sert pour la montée de version d'une autre machine). OK Et j'utilise dans les sources.list les noms de version et pas stable. OK Comme j'ai écrit dans le post d'origine, je pense que c'est un faux downgrade ; je découvre que apt sais faire ça alors que la dernière fois que j'avais vu ça c'était sur une CentOS ( 6 ou 5?). Mais je n'ai pas moyen de le vérifier pour tous les paquets, je suspecte un autre fichier de configuration que les sources.list mal édité mais je ne connais pas assez bien Debian ou alors une opération non faite lors du précédent full-upgrade... Vérifie, ça ne mange pas de pain, que non seulement tu n'as, exclusivement que des références à bookworm, - non seulement dans ton /etc/apt/sources.list - mais aussi dans d'éventuels fichiers présents dans le répertoire /etc/apt/sources.list.d/ (par exemple chez moi il y a un fichier teamviewer.list qui fait référence à "stable": si je n'avais pas un apt update depuis le 10 juin, sortie de Bookworm, il y aurait peut-être (pas sûr) des soucis aussi)
[HS] Crypto et Cold Wallet
Bonjour à tous, Est-ce que l'un de vous s'est penché sur la création d'un cold wallet sur clé USB ? Si oui avez-vous des retours sur comment réaliser celui-ci ? -- david martin
Re: Étrange réponse de apt après passage de testing à stable
Salut, Merci pour la réponse. didier gaumet a tapoté le 23/06/2023 12:30: > Le 23/06/2023 à 10:53, yamo' a écrit : >> J'ai la commande apt full-upgrade qui me réponds : ... 0 mis à >> jour, 0 nouvellement installés, 760 remis à une version inférieure, >> 0 à enlever et 0 non mis à jour. Il est nécessaire de prendre 237 >> Mo dans les archives. Après cette opération, 80,9 Mo d'espace >> disque seront libérés. Souhaitez-vous continuer ? [O/n] >> >> Comment corriger ça? > [...] Bonjour, > > Ben en fait, si tu as fait des mises à jour de ta distro depuis la > sortie de Debian 12 Bookworm, ton système (testing) correspondait à > l'état actuel de la future Debian 13 Trixie, pas à Debian 1é > Bookworm, donc quand tu modifies ton sources.list pour y mettre (quoi > d'abord? "stable"? "bookworm"?) apt te dit que c'est un downgrade, > pas un upgrade. C'est une machine que j'ai passé en bookworm aux environ le 8 juin et qui depuis était éteinte (elle me sert pour la montée de version d'une autre machine). Et j'utilise dans les sources.list les noms de version et pas stable. > Tu peux accepter un downgrade mais ce n'est pas supporté (les scripts > ne sont pas prévus pour), donc même en cas de succès apparent, tu > risques de galérer plus tard avec des problèmes dont tu auras du mal > à tracer l'origine et qui seront potentiellement difficiles à > solutionner. Dans ces cas là, une réinstallation propre est > généralement conseillée... Comme j'ai écrit dans le post d'origine, je pense que c'est un faux downgrade ; je découvre que apt sais faire ça alors que la dernière fois que j'avais vu ça c'était sur une CentOS ( 6 ou 5?). Mais je n'ai pas moyen de le vérifier pour tous les paquets, je suspecte un autre fichier de configuration que les sources.list mal édité mais je ne connais pas assez bien Debian ou alors une opération non faite lors du précédent full-upgrade... -- Stéphane
Re: Étrange réponse de apt après passage de testing à stable
Le 23/06/2023 à 10:53, yamo' a écrit : Salut, J'ai la commande apt full-upgrade qui me réponds : ... 0 mis à jour, 0 nouvellement installés, 760 remis à une version inférieure, 0 à enlever et 0 non mis à jour. Il est nécessaire de prendre 237 Mo dans les archives. Après cette opération, 80,9 Mo d'espace disque seront libérés. Souhaitez-vous continuer ? [O/n] Comment corriger ça? [...] Bonjour, Ben en fait, si tu as fait des mises à jour de ta distro depuis la sortie de Debian 12 Bookworm, ton système (testing) correspondait à l'état actuel de la future Debian 13 Trixie, pas à Debian 1é Bookworm, donc quand tu modifies ton sources.list pour y mettre (quoi d'abord? "stable"? "bookworm"?) apt te dit que c'est un downgrade, pas un upgrade. C'est pour ça qu'il est préférable, à moins de comprendre les dangers associés, de mettre dans le sources.list des noms de versions (bullseye, bookworm, trixie...) plutôt que stable ou testing Tu peux accepter un downgrade mais ce n'est pas supporté (les scripts ne sont pas prévus pour), donc même en cas de succès apparent, tu risques de galérer plus tard avec des problèmes dont tu auras du mal à tracer l'origine et qui seront potentiellement difficiles à solutionner. Dans ces cas là, une réinstallation propre est généralement conseillée...
Re: RAID5 (Mdadm) non fonctionnel sous Debian 11
Le 23/06/2023 à 10:50, Romain Pillot a écrit : [...] Oui, je suis passé de Debian 10 à 11. Oui, c'est moi qui avais installé des mises à jour pour Debian 11 dans Debian 10. Oui, c'est trop compliqué pour moi le downgrade. C'est pour ça que j'ai installé Debian 11 en formatant la partition où était Debian 10 planté. OK, donc tu n'as pas tenté une mise à jour, en fait tu as effectué une installation mais... Je suis étonné qu'il y ait un mélange de Debian 10 et 11 puisqu'il y avait eu formatage ... manifestement ça ne s'est pas déroulé comme tu l'imaginais => si tu veux avoir une distro Debian propre, il te faudrait réinstaller Debian proprement. Je ne sais pas ce que tu as comme disques: si comme j'en ai l'impression(?), tu as un disque sur ton PC et un ensemble de disques RAID (les deux bien séparés), je te conseillerais, au moment de l'installation, de choisir le partitionnement automatique avec LVM sur le premier disque en question (pas membre de ton ensemble RAID) et de ne pas t'occuper de ton RAID lors de l'installation. Tu sembles avoir encore des petits soucis avec l'appréhension de Debian en général sans en rajouter en complexifiant les choses en mêlant installation et paramétrage d'un pool RAID annexe existant :-). Que tu veuilles installer seulement ou installer et configurer ton RAID en même temps, je te recommande la lecture du manuel d'installation (en français), particulièrement la partie partitionnement (si tu veux configurer le RAID à ce moment, il faut probablement avoir chargé préalablement le module partman RAID (je ne connais pas la dénomination exacte) lors d'une étape où l'installateur propose de charger des modules Tu peux avoir plus de contrôle en lançant l'installation via une option "mode expert" (graphique ou non) du média d'installation. Je ne me sers que de cette option donc je connais moins bien le mode standard
Re: Machine vérolée
Le 2023-06-23 10:30, BERTRAND Joël a écrit : Très bien. Et quelle est la marche à suivre. Je peux démarrer sur un liveCD ou autre chose, mais je ne suis pas au fait de ce qu'il faut faire après cela. La question est vague, il faut monter les partitions du système, puis y rechercher ce qu'il y a d'étrange dessus, voir quelles sont les unités lancées par Systemd, voir s'il n'y a pas des répertoires ou des fichiers cachés (y compris des répertoires ou fichiers dont le nom ne commence pas par un point, mais que le système vérolé ne t'aurait pas montrés). Mais ça, c'est juste pour comprendre ce qui a pu se passer, parce que, en ce qui me concerne, la seule fois où cette mésaventure m'est arrivée, je n'ai pas tenté de récupéré le système ou de réutiliser le disque. J'ai : * Utilisé un liveCD pour récupérer mes données (l'indispensable pour minimiser le risque de récupérer des trucs vérolés au passage) * Retiré le disque de mon PC * Acheté un nouveau disque et réinstallé un système frais dessus (en m'interdisant de copier des logiciels ou même des scripts provenant de l'ancien système) * Envoyé le disque à des amis spécialisés en sécurité pour qu'ils en fassent l'analyse et m'expliquent comment les attaquants avaient réussi leur coup (leur analyse a été très instructive et formatrice pour moi) * Informé les admin. sys. de tous les serveurs auxquels j'avais accès de la compromission de mon PC et potentiellement, de mes clés SSH et GnuPG, leur demandant de bloquer immédiatement mon compte et de lui supprimer ses éventuels privilèges (sudo) * Généré de nouvelles clés SSH et GnuPG * Répudié mes anciennes clés GnuPG * Informé tous mes contacts qu'ils ne devaient plus faire confiance à mes anciennes clés GnuPG (il m'a fallu un an et demi pour reconstruire mon réseau de confiance) * Jeté la webcam qui nécessitait un pilote propriétaire, qui faisait que 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) * Acheté une webcam fonctionnant avec un pilote libre, supporté par Debian 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
Le 23 juin 2023 BERTRAND Joël a écrit : > 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) Et d'ailleurs si tu as des backup faire un diff des sites pour voir s'il y a eu des apports suspects.
Re: Machine vérolée
Le 23 juin 2023 BERTRAND Joël a écrit : > 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) Il y a possibilité que b2 ou spip soient piratés et qu'une faille donne accès à www-data. Notamment si tu n'as rien mis de particulier php peut être un peu trop laxiste sur les requêtes permises. Augmente le niveau de log de apache et croise les heures de lancement des programmes pirates et les requêtes reçues sur apache.
Re: [Résolu] Pas d'historique de zsh en root
salut, > Enfin tant que ça marche... idéalement il faudrait comprendre pourquoi mais là j'ai vraiment pas le temps :( a+ marc
Re: Pas d'historique de zsh en root
Le Fri, Jun 23, 2023 at 08:53:23AM +, benoit a écrit : > Peut-être que ohmyzsh est exagéré > mais de là à interdire l'assistant de configuration en root en mode RTFM : > # autoload -Uz zsh-newuser-install > # zsh-newuser-install -f > zsh-newuser-install: won't run as root. Read the manual. Ca n'est pas exagéré du tout: * certaines erreurs sont bien plus tragiques en root. pour éviter ces erreurs ou des conséquences dramatiques, les 2 règles d'or sont: * faites des backups * ne travaillez en root que si vous n'avez plus d'autre choix (quitte à appliquer une séparation des privilèges en créant des comptes pour administrer des parties distinctes du système). (doas est ton ami!!) * si tu as un shell qui te fait le café en root, tu vas prendre la très mauvaise habitude de passer beaucoup de temps en root, c'est mal. > Je ne comprends pas la raison... 2 raisons: * affordance négative: plus ton shell est chiant, moins t'as envie de l'utiliser donc tu vas trouver des stratégies pour lancer tes commandes depuis ton compte * sécurité: tout ce qui tourne en root est forcément plus sensible. hors il n'y a pas mieux pour sécuriser que de virer du code, des options, des fonctionnalités. Au passage du coup je comprend pas trop pourquoi le shell de root dans debian est bash :-(. dash (ou mksh) sont suffisants et bien moins gros. a+ marc
Étrange réponse de apt après passage de testing à stable
Salut,
J'ai la commande apt full-upgrade qui me réponds :
...
0 mis à jour, 0 nouvellement installés, 760 remis à une version
inférieure, 0 à enlever et 0 non mis à jour.
Il est nécessaire de prendre 237 Mo dans les archives.
Après cette opération, 80,9 Mo d'espace disque seront libérés.
Souhaitez-vous continuer ? [O/n]
Comment corriger ça?
Je ne vois pas comment vérifier les 760 paquets, j'en ai pris quelques
uns au hasard et apt policy me dit qu'en fait ça ne change pas de numéro
de version...
C'est sur une raspbian sur bookworm (j'étais passé de bullseye à testing
début juin).
Vu que c'est sur raspbian, j'ai forcément des paquets en double pour les
rares cas où il faut du spécifique à mon raspberry mais je n'ai jamais
eu de soucis avec ça (j'applique juste deux fois les mises à jours de
sécurité).
C'est sur un raspberry pi2 mais je doute que cette dernière information
soit utile.
Je précise que j'ai auparavant mis à jour les correctifs de sécurité qui
étaient bloqués par ce bug. En effet, la commande suivante me disait
quoi installer :
apt list --upgradable | awk -F\/ '{ print $1 }'
--
Stéphane
Merci de répondre à la liste ou au newsgroup linux.debian.user.french
Re: RAID5 (Mdadm) non fonctionnel sous Debian 11
Le 23/06/2023 à 10:10, didier gaumet a écrit : Bonjour, je réponds ici à tes deux messages suivants: news://news.gmane.io:119/649468a0$0$7626$426a7...@news.free.fr news://news.gmane.io:119/64949c58$0$31548$426a7...@news.free.fr parce qu'en cherchant quoi te répondre (rappel: le RAID j'y connais rien), j'ai relu l'enfilade de messages et j'ai tiqué sur ce premier message de l'enfilade: tu dis être passé de Debian 10 Buster à Debian 11 Bullseye mais la trace de tentative d'installation citée ci-dessus me semble indiquer clairement que tu es toujours sous Debian 10 Buster (paquet mdmadm 4.1.1 au lieu de 4.1.11, source "Buster" au lieu de Bullseye, noyau(x) 4.19 au lieu de 5.10). Et je pense que si tu complètes la mise-à-jour pour véritablement être sous Bullseye, il y a une possibilité que cela résolve aussi ton problème RAID. Ici les notes de publication en français de Bullseye (on insiste souvent sur cette liste, à juste titre: toujours lire les notes de publication (release notes) avant d'installer ou mettre à jour une Debian): https://www.debian.org/releases/bullseye/amd64/release-notes/ Et particulièrement la partie mise-à-jour à partir de Buster: https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.fr.html#upgradingpackages Je ne me souviens plus, il me semble que c'était toi qui avais eu un problème avec un PC que tu avais mal mis à jour et tu t'étais retrouvé avec une distribution bancale (des morceaux d'unstable et autres): ça n'a rien à voir avec le PC RAID dont tu nous parles ici, n'est-ce pas? Parce que les downgrades (mises-à-jour vers de versions inférieures) ne sont pas supportées, et même un expert ne devrait pas s'en servir (car même si tu arrives à mettre à jour, les scripts ne sont pas prévus pour ça, donc il reste toujours des bouts de configuration bancals) Bonjour Oui, je suis passé de Debian 10 à 11. Oui, c'est moi qui avais installé des mises à jour pour Debian 11 dans Debian 10. Oui, c'est trop compliqué pour moi le downgrade. C'est pour ça que j'ai installé Debian 11 en formatant la partition où était Debian 10 planté. Je suis étonné qu'il y ait un mélange de Debian 10 et 11 puisqu'il y avait eu formatage. Merci Romain
[Résolu] Pas d'historique de zsh en root
Le vendredi 23 juin 2023 à 10:44, benoit a écrit : > Le vendredi 23 juin 2023 à 09:54, Marc Chantreux m...@unistra.fr a écrit : > > > > > salut, > > > > Le Fri, Jun 23, 2023 at 06:17:03AM +, benoit a écrit : > > > > > Voici mon .zshrc > > > Pourquoi est-ce que je n'ai pas d'historique en root ? > > > > pas le temps de plonger dans la doc mais je viens de tester > > ma conf: > > > > HISTSIZE=5000 HISTFILE=~/zsh/history SAVEHIST=5000 > > # setopt share_history > > > Bonjour oui ça marche tout à fait suffisant... > Mais c'est probablement à cause de ce qui suit : > Pare que le nom du fichier HISTFILE=~/zsh/history > ou .zsh_history > ou .sh_history > Pour autant que le nom corresponde dans le .zshrc... > > Du coup ça doit être ici que ça se passe : > Je les ai commenté et ça marche plus > > setopt INC_APPEND_HISTORY > > setopt EXTENDED_HISTORY > > setopt HIST_IGNORE_SPACE > > setopt HIST_IGNORE_ALL_DUPS > > setopt HIST_FIND_NO_DUPS > > setopt HIST_SAVE_NO_DUPS > > C'est "setopt INC_APPEND_HISTORY" qui fait que ça marche, mais je ne l'ai pas, dans le .zshrc de mon utilisateur normal... Enfin tant que ça marche... Merci pour ton aide -- Benoît > > je passe root avec doas zsh et ça fonctionne. > > > > est-ce suffisant?
Re : Re: Pas d'historique de zsh en root
Le vendredi 23 juin 2023 à 10:40, Marc Chantreux a écrit : > salut, > > > ce que le système attend : > > HISTFILE=~/.zsh_history > > > le système attend un nom de fichier, c'est l'idée même d'avoir > une variable pour pouvoir paramètrer son nom. > > ca n'est pas une coquille, c'est un choix > > > autrement : > > https://github.com/ohmyzsh/ohmyzsh > > > en root? voilà un bien mauvais conseil je trouve. > > même pour les comptes standard, j'ai tendance à expliquer > aux gens que la plupart des lignes de ce code ne servent > juste à rien, ca ralentit et complexifie. > > passe pour les utilisateurs qui veulent des prompts aussi > colorés qu'inutiles mais ça me semble assez inacceptable > en root. Peut-être que ohmyzsh est exagéré mais de là à interdire l'assistant de configuration en root en mode RTFM : # autoload -Uz zsh-newuser-install # zsh-newuser-install -f zsh-newuser-install: won't run as root. Read the manual. Je ne comprends pas la raison...
Re : Re: Pas d'historique de zsh en root
Le vendredi 23 juin 2023 à 09:54, Marc Chantreux a écrit : > salut, > > > Le Fri, Jun 23, 2023 at 06:17:03AM +, benoit a écrit : > > > Voici mon .zshrc > > Pourquoi est-ce que je n'ai pas d'historique en root ? > > > pas le temps de plonger dans la doc mais je viens de tester > ma conf: > > HISTSIZE=5000 HISTFILE=~/zsh/history SAVEHIST=5000 > # setopt share_history Bonjour oui ça marche tout à fait suffisant... Mais c'est probablement à cause de ce qui suit : Pare que le nom du fichier HISTFILE=~/zsh/history ou .zsh_history ou .sh_history Pour autant que le nom corresponde dans le .zshrc... Du coup ça doit être ici que ça se passe : > setopt INC_APPEND_HISTORY > setopt EXTENDED_HISTORY > setopt HIST_IGNORE_SPACE > setopt HIST_IGNORE_ALL_DUPS > setopt HIST_FIND_NO_DUPS > setopt HIST_SAVE_NO_DUPS > > je passe root avec doas zsh et ça fonctionne. > > est-ce suffisant? >
Re: Pas d'historique de zsh en root
salut, > ce que le système attend : > HISTFILE=~/.zsh_history le système attend un nom de fichier, c'est l'idée même d'avoir une variable pour pouvoir paramètrer son nom. ca n'est pas une coquille, c'est un choix > autrement : > https://github.com/ohmyzsh/ohmyzsh en *root*? voilà un bien mauvais conseil je trouve. même pour les comptes standard, j'ai tendance à expliquer aux gens que la plupart des lignes de ce code ne servent juste à rien, ca ralentit et complexifie. passe pour les utilisateurs qui veulent des prompts aussi colorés qu'inutiles mais ça me semble assez inacceptable en root. a+ marc
Re: Machine vérolée
On 6/23/23 10:30, BERTRAND Joël wrote: Sébastien Dinot a écrit : Le 2023-06-23 10:08, BERTRAND Joël a écrit : Ma question est donc assez simple ;-) Comment trouver par quoi sont lancés ces deux processus ? En pareille circonstance, il n'y a qu'une seule solution : analyse du disque depuis un système live sur clé USB. En effet, si un rootkit a été installé sur cette machine, ce qui semble être le cas, tu ne peux l'observer qu'à travers les lunettes que te donne le rootkit. :) Très bien. Et quelle est la marche à suivre. Je peux démarrer sur un liveCD ou autre chose, mais je ne suis pas au fait de ce qu'il faut faire après cela. D'abord et avant tout, isoler la machine du réseau Internet. (une solution est de débrancher le cable Ethernet par exemple) Ensuite, j'espère que /home est sur une partition externe (et que les données des serveurs y sont aussi). Dans cette hypothèse, le copier sur un disque monté en noeexec. -- Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/
Re : Re: Pas d'historique de zsh en root
Le vendredi 23 juin 2023 à 10:04, Bernard Schoenacker a écrit : > Bonjour Benoit, Bonjour Bernard > > en relisant ton fichier rc pour ZSH, j'ai vu une coquille : > > toi : > HISTFILE=~/.sh_history > > ce que le système attend : > HISTFILE=~/.zsh_history > Je ne crois pas que le nom du fichier soit normalisé ".zsh_history" Je viens d'essayer en le renommant dans .zshrc et en créant touch $HOME/.zsh_history ls # juste une commande cat $HOME/.zsh_history tjs vide -- Benoit
Re: Machine vérolée
Sébastien Dinot a écrit : > Le 2023-06-23 10:08, BERTRAND Joël a écrit : >> Ma question est donc assez simple ;-) Comment trouver par quoi sont >> lancés ces deux processus ? > > En pareille circonstance, il n'y a qu'une seule solution : analyse du > disque depuis un système live sur clé USB. > > En effet, si un rootkit a été installé sur cette machine, ce qui semble > être le cas, tu ne peux l'observer qu'à travers les lunettes que te > donne le rootkit. :) Très bien. Et quelle est la marche à suivre. Je peux démarrer sur un liveCD ou autre chose, mais je ne suis pas au fait de ce qu'il faut faire après cela. Bien cordialement, JB
[regle] Re: [testing] crash firefox 114.0-1
Le jeudi 22 juin 2023 à 22:33 +0200, Gaëtan Perrier a écrit : > Bonjour, > > Depuis ce soir suite aux mises à jours de testing du jour, firefox crash au > démarrage même en --safe-mode. > > ~$ firefox --safe-mode > ExceptionHandler::GenerateDump cloned child > ExceptionHandler::WaitForContinueSignal waiting for continue signal... > 16491 > ExceptionHandler::SendContinueSignalToChild sent continue signal to child > Exiting due to channel error. > Exiting due to channel error. > ~$ Failed to open curl lib from binary, use libcurl.so instead > ~$ > > Est-ce de même pour vous ? > > Gaêtan Bonjour, Ce matin ça refonctionne ... Gaëtan signature.asc Description: This is a digitally signed message part
Re: Machine vérolée
Le 2023-06-23 10:08, BERTRAND Joël a écrit : Ma question est donc assez simple ;-) Comment trouver par quoi sont lancés ces deux processus ? En pareille circonstance, il n'y a qu'une seule solution : analyse du disque depuis un système live sur clé USB. En effet, si un rootkit a été installé sur cette machine, ce qui semble être le cas, tu ne peux l'observer qu'à travers les lunettes que te donne le rootkit. :) Sébastien -- Sébastien Dinot Ne goutez pas au logiciel libre, vous ne pourriez plus vous en passer ! https://www.palabritudes.net/
Machine vérolée
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-data4096 23 juin 08:50 .
drwxrwxrwt 10 root root 36864 23 juin 09:56 ..
drwxr-xr-x 2 www-data www-data4096 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-data4096 23 juin 09:56 .
drwxrwxrwx 3 www-data www-data4096 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
Re: Pas d'historique de zsh en root
Bonjour Benoit, en relisant ton fichier rc pour ZSH, j'ai vu une coquille : toi : HISTFILE=~/.sh_history ce que le système attend : HISTFILE=~/.zsh_history autrement : https://github.com/ohmyzsh/ohmyzsh Merci @+ Bernard
Re: RAID5 (Mdadm) non fonctionnel sous Debian 11
Le 16/06/2023 à 15:10, Romain P. a écrit : Bonjour Je suis passé de Debian 10 à Debian 11 et volume RAID5, géré par la carte mère, n'est pas reconnu. Créé sous Windows 10, il fonctionnait sous Debian 10 juste en installant Mdadm. Sous certaines distributions, Mdadm est inclus et mon RAID5 fonctionne sans paramétrage. J'ai lu plusieurs pages Web à propos de Mdadm, mais il y est indiqué des commandes différentes. Je suis perdu. Comment faire fonctionner mon RAID5 sans risquer de le détruite ? Merci Romain mdadm.txt : " Les NOUVEAUX paquets suivants vont être installés : mdadm 0 paquets mis à jour, 1 nouvellement installés, 0 à enlever et 0 non mis à jour. Il est nécessaire de télécharger 449 ko d'archives. Après dépaquetage, 1 240 ko seront utilisés. Prendre : 1 https://deb.debian.org/debian buster/main amd64 mdadm amd64 4.1-1 [449 kB] 449 ko téléchargés en 0s (1 391 ko/s) Préconfiguration des paquets... Sélection du paquet mdadm précédemment désélectionné. (Lecture de la base de données... 289552 fichiers et répertoires déjà installés.) Préparation du dépaquetage de .../archives/mdadm_4.1-1_amd64.deb ... Dépaquetage de mdadm (4.1-1) ... Paramétrage de mdadm (4.1-1) ... Generating mdadm.conf... done. update-initramfs: deferring update (trigger activated) Création du fichier de configuration GRUB… Found background image: /usr/share/images/desktop-base/desktop-grub.png Image Linux trouvée : /boot/vmlinuz-4.19.0-14-amd64 Image mémoire initiale trouvée : /boot/initrd.img-4.19.0-14-amd64 Image Linux trouvée : /boot/vmlinuz-4.19.0-13-amd64 Image mémoire initiale trouvée : /boot/initrd.img-4.19.0-13-amd64 Image Linux trouvée : /boot/vmlinuz-4.19.0-12-amd64 Image mémoire initiale trouvée : /boot/initrd.img-4.19.0-12-amd64 Image Linux trouvée : /boot/vmlinuz-4.19.0-11-amd64 Image mémoire initiale trouvée : /boot/initrd.img-4.19.0-11-amd64 Image Linux trouvée : /boot/vmlinuz-4.19.0-6-amd64 Image mémoire initiale trouvée : /boot/initrd.img-4.19.0-6-amd64 Windows Boot Manager trouvé sur /dev/nvme0n1p3@/efi/Microsoft/Boot/bootmgfw.efi Adding boot menu entry for EFI firmware configuration fait update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults Traitement des actions différées (« triggers ») pour man-db (2.8.5-2) ... Traitement des actions différées (« triggers ») pour systemd (241-7~deb10u6) ... Traitement des actions différées (« triggers ») pour initramfs-tools (0.133+deb10u1) ... update-initramfs: Generating /boot/initrd.img-4.19.0-14-amd64 " Bonjour, je réponds ici à tes deux messages suivants: news://news.gmane.io:119/649468a0$0$7626$426a7...@news.free.fr news://news.gmane.io:119/64949c58$0$31548$426a7...@news.free.fr parce qu'en cherchant quoi te répondre (rappel: le RAID j'y connais rien), j'ai relu l'enfilade de messages et j'ai tiqué sur ce premier message de l'enfilade: tu dis être passé de Debian 10 Buster à Debian 11 Bullseye mais la trace de tentative d'installation citée ci-dessus me semble indiquer clairement que tu es toujours sous Debian 10 Buster (paquet mdmadm 4.1.1 au lieu de 4.1.11, source "Buster" au lieu de Bullseye, noyau(x) 4.19 au lieu de 5.10). Et je pense que si tu complètes la mise-à-jour pour véritablement être sous Bullseye, il y a une possibilité que cela résolve aussi ton problème RAID. Ici les notes de publication en français de Bullseye (on insiste souvent sur cette liste, à juste titre: toujours lire les notes de publication (release notes) avant d'installer ou mettre à jour une Debian): https://www.debian.org/releases/bullseye/amd64/release-notes/ Et particulièrement la partie mise-à-jour à partir de Buster: https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.fr.html#upgradingpackages Je ne me souviens plus, il me semble que c'était toi qui avais eu un problème avec un PC que tu avais mal mis à jour et tu t'étais retrouvé avec une distribution bancale (des morceaux d'unstable et autres): ça n'a rien à voir avec le PC RAID dont tu nous parles ici, n'est-ce pas? Parce que les downgrades (mises-à-jour vers de versions inférieures) ne sont pas supportées, et même un expert ne devrait pas s'en servir (car même si tu arrives à mettre à jour, les scripts ne sont pas prévus pour ça, donc il reste toujours des bouts de configuration bancals)
Re: Pas d'historique de zsh en root
salut, Le Fri, Jun 23, 2023 at 06:17:03AM +, benoit a écrit : > Voici mon .zshrc > Pourquoi est-ce que je n'ai pas d'historique en root ? pas le temps de plonger dans la doc mais je viens de tester ma conf: HISTSIZE=5000 HISTFILE=~/zsh/history SAVEHIST=5000 # setopt share_history setopt INC_APPEND_HISTORY setopt EXTENDED_HISTORY setopt HIST_IGNORE_SPACE setopt HIST_IGNORE_ALL_DUPS setopt HIST_FIND_NO_DUPS setopt HIST_SAVE_NO_DUPS je passe root avec doas zsh et ça fonctionne. est-ce suffisant? marc
Pas d'historique de zsh en root
Bonjour
Voici mon .zshrc
Pourquoi est-ce que je n'ai pas d'historique en root ?
Je m'inspire du .zshrc de mon login utilisateur qui lui fonctionne...
Merci d'avance
--
Benoît
---
# Use emacs keybindings even if our EDITOR is set to vi
bindkey -e
bindkey '^u' backward-kill-line
HISTSIZE=1000
SAVEHIST=1048576
HISTFILE=~/.sh_history
# Use modern completion system
autoload -Uz compinit
compinit
zstyle ':completion:*' auto-description 'specify: %d'
# enable color support of ls and also add handy aliases
if [ -x /usr/bin/dircolors ]; then
test -r ~/.dircolors && eval "$(dircolors ~/.dircolors)" || eval "$(dircolors)"
alias ls='ls -v --color=auto'
alias diff='diff --color=auto'
alias grep='grep --color=auto'
fi
PROMPT='%F{blue}%T%f %F{red}%n%f@%F{magenta}%m%f:%F{blue}%B%2~%b%f%# '
Envoyé avec la messagerie sécurisée [Proton Mail.](https://proton.me/)
