Debian Sid : MàJ et changement droits racine

Support Debian
#1

Bonsoir à tous,

Voilà il vient de m’arriver quelque chose de super-mega-extra bizarre ce soir : après une mise à jour que j’ai effectuée vers 18h (je n’ai pas redémarré le système entre-temps), vers 21h30 le système pète un câble tout à coup et des morceaux du bureau disparaissent les uns après les autres…

Bon jusque là je me dis c’est peut-être dû à la mise à jour, donc je redémarre étant donné que le bureau a planté, et là impossible d’arriver à l’écran de login, uniquement en tty. Je tente de me logguer en tty1, mais impossible aussi : en rentrant login et mot de passe ça me renvoie au début comme lorsqu’on arrive en premier lieu sur la console, donc en boucle…
Je redémarre et passe cette fois en mode recovery, pour tenter un downgrade des paquets que j’ai précédemment mis à jour pour faire un essai, évidemment je n’ai pas de connexion internet en mode recovery (où plutôt je ne sais pas comment l’activer) donc opération impossible, je jette alors un oeil sur les logs pour voir ce qui se passe… Et là je vois qu’il y a pas mal de services qui sont en statu “fail” dont : login.service, avahi-daemon.service, …

Ayant une autre distribution en dual-boot (elementary OS qui a été installé pour test), je démarre sur celle-ci dans l’espoir de faire un chroot de ma Debian et donc un downgrade…
Je passe donc Debian en chroot, et tente un downgrade, mais là non-plus ça ne marche pas, pas de connexion internet. En cherchant sur le net j’ai trouvé que copier le fichier local “/etc/resolv.conf” vers le dossier où est chroot-é le système peut résoudre le problème : j’essaie donc ça et une énième fois impossible la console me retourne un [mono]problème de droits[/mono].

C’est là que j’ai pu pointer du doigt le problème : [mono]le droit en execution a été retiré à la plupart des dossiers de la racine de ma Debian??!![/mono]
Donc j’ai à nouveau redémarré mon pc, booté en mode recovery Debian, ajouté le droit [mono]+x[/mono] aux dossiers de la racine auxquels il manquait. J’ai redémarré et tout est rentré dans l’ordre.

Maintenant j’ouvre ce fil pour essayer de comprendre comment une telle chose peut-elle arriver?

  • Est-ce que j’ai été l’objet d’une attaque extérieure qui aurait pu faire ces modifications (sachant que j’ai précedemment expliqué dans un sujet récent que je suis passé sous bind9 pour avoir mon serveur DNS local et que je n’ai pas de pare-feu, même s’il n’est pas accessible de l’extérieur en théorie)?
  • Est-ce qu’un mise à jour peut provoquer une telle chose?

Si quelqu’un peut me dire quelle batterie de test je peux faire pour identifier une éventuelle attaque extérieure, et me confirmer quels sont les droits des dossiers à la racine sur une installation toute fraîche pour que je compare et corrige éventuellement? (je précise qu’il semble que les sous-dossiers ne semblent pas avoir été infectés, j’ai pas encore tout vérifié ; et j’ai également immédiatement changé mes mots de passe root et utilisateur).

#2

Pendant le laps de temps, peut-être que ta lancer une mauvaise commande ?

#3

Non, aucune justement. En tous cas pas une commande qui pourrait changer les droits de dossiers de la racine, et je fais toujours extremement attention quand je suis en root, dès que j’ai fini ce que j’ai à faire je repasse en utilisateur normal…
La seule chose que j’ai fait, c’est un [mono]apt-get update[/mono] suivi d’un [mono]apt-get upgrade[/mono] puis [mono]apt-get dist-upgrade[/mono], et en 7 ans d’utilisation de systèmes Linux ce genre de choses ne m’était jamais arrivé.

Tiens j’ai noté sur papier :

/bin /boot /etc /lib /lib64 /lost+found /media /mnt /opt /root /sbin /usr
avaient en droits l’équivalent d’un [mono]chmod 644[/mono] au lieu de [mono]chmod 755[/mono].

Par contre aucun sous-dossier n’a été affecté.
Quand bien même j’aurai fait une fausse manip., j’aurais au moins dû les lister tous pour leur appliquer un [mono]chmod 644[/mono] ou bien [mono]chmod a-x[/mono] pour n’affecter que ces dossiers sans affecter rien d’autre. Donc je trouve ça vraiment curieux.

#4

Je reviens sur ce que j’ai dit et je m’excuse auprès de kripteks et des autres qui sont passés par là : il s’agit d’une bêtise de ma part (je viens de m’en rendre compte par le log console en mode root, merci kripteks de m’avoir mis la puce à l’oreille! :wink: ).

En travaillant sur un theme de bureau pour Gnome, j’ai voulu changer les permissions d’un dossier et effectivement au lieu de taper chmod 644 ./* pour rendre effectives ces permissions dans le dossier dans lequel je travaillais, j’ai du rentrer chmod 644 /*

J’en retiens que c’est une façon de faire dangereuse, ça servira de leçon pour la prochaine fois. :115

#5

Fait gaffe qu’un attaquant n’ai pas modifier/profiter de ton history :laughing:

Je me demandes pourquoi ces commandes crucials n’on pas une option sécuritaire sur la racine, un truc qu’on peut activer/désactiver, voir même un avertissement et/ou questionnement en bonus.
C’est vrai que c’est pas leur devoir.

Peut-être que quelqu’un aura la gentillesse de faire:

  • plusieurs alias (une pour chaque exécutable (rm,chmod,chown,etc))
  • tous pointant sur un seul autre script qui à comme première tâche la vérification sécuritaire et si ça passe comme deuxième tâche d’exécuter les vrais exécutables en fonction des données reçu par les premières alias.
#6

[quote=“kripteks”]Fait gaffe qu’un attaquant n’ai pas modifier/profiter de ton history :laughing:

Je me demandes pourquoi ces commandes crucials n’on pas une option sécuritaire sur la racine, un truc qu’on peut activer/désactiver, voir même un avertissement et/ou questionnement en bonus.[/quote]

Ben je connais pas les commandes pour vérifier les tentatives d’intrusion via internet sur linux… :017
En revanche dès que j’ai repris contrôle du système j’ai changé comme je l’ai dit les mots de passe utilisateur et root, donc ça devrait bien se passer… :smiley:

Et je me dis que je m’en tire bien surtout, parce que là j’ai seulement fait un [mono]chmod 644 /[/mono], mais ça aurait très bien pu être tout autre chose…, comme un [mono]rm -R /[/mono] au lieu de [mono]rm -R ./*[/mono] :smiley: :smiley: :smiley:

Là ça aurait été beau… :smiley: :smiley: :smiley:

EDIT : tu penses à une invite de confirmation comme lors d’une mise à jour qui demanderait de confirmer l’execution… C’est vrai que ça pourrait prévenir des bêtises, mais ça pourrait devenir lourd aussi en cas de travail récursif à confirmer à chaque fois, m’enfin bon…

#7

Ça dépend.
Tu rajoutes une simple règle au script (dont tous les alias pointent dessus), avec un activer ou désactiver.

Quand tu dois faire trop de chose et que ça pose problème, tu le met en mode désactiver, et soit tu laisses le mode warning/informatif activer soit tu le désative aussi.

#8

[quote=“kripteks”]Ça dépend.
Tu rajoutes une simple règle au script (dont tous les alias pointent dessus), avec un activer ou désactiver.

Quand tu dois faire trop de chose et que ça pose problème, tu le met en mode désactiver, et soit tu laisses le mode warning/informatif activer soit tu le désative aussi.[/quote]

Bah justement voilà le résultat en faisant trop de choses… :smiley: c’est comme à la conduite, c’est sur les trajets habituels qu’on finit par perdre l’attention avec le temps et qu’on fait des boulettes :stuck_out_tongue:
La meilleure solution à mon sens c’est de travailler hors root et déplacer le dossier/fichier une fois fini en root s’il a besoin d’être dans un dossier de la racine (ce que je n’ai évidemment pas fait et voilà le résultat…).