Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
2665 connectés 

 


Dernière réponse
Sujet : rootkits
THRAK

mexx20 a écrit :

Pour information,  
 
Quelque chose d'assez méconnu à savoir aussi est qu'il existe des attributs spéciaux pour EXT2/3. L'attribut "i" (imuable?) permet d'empecher la suppression. Les commandes pour les manipuler sont lsattr et chattr. En général un rootkit place l'attribut "i" sur "/sbin/init" et on ne comprend pas pourquoi on ne peux le remplacer.


Pour ceux qui connaissent, sur certains serveurs il est d'ailleurs parfois d'usage d'utiliser ces attributs pour renforcer la sécurité : ainsi certains admins paranoiaques rendent immuables certains fichiers vitaux ne devant jamais être modifiés ; de même pour empêcher la compromission des fichiers de log, certains journaux peuvent être positionnés avec le flag append-only (l'attribut "a" ) pour que seulement de nouvelles entrées puissent être ajoutées et plus supprimables.


Votre réponse
Nom d'utilisateur    Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !
Le ton de votre message                        
                       
Votre réponse


[b][i][u][strike][spoiler][fixed][cpp][url][email][img][*]   
 
   [quote]
 

Options

 
Vous avez perdu votre mot de passe ?


Vue Rapide de la discussion
THRAK

mexx20 a écrit :

Pour information,  
 
Quelque chose d'assez méconnu à savoir aussi est qu'il existe des attributs spéciaux pour EXT2/3. L'attribut "i" (imuable?) permet d'empecher la suppression. Les commandes pour les manipuler sont lsattr et chattr. En général un rootkit place l'attribut "i" sur "/sbin/init" et on ne comprend pas pourquoi on ne peux le remplacer.


Pour ceux qui connaissent, sur certains serveurs il est d'ailleurs parfois d'usage d'utiliser ces attributs pour renforcer la sécurité : ainsi certains admins paranoiaques rendent immuables certains fichiers vitaux ne devant jamais être modifiés ; de même pour empêcher la compromission des fichiers de log, certains journaux peuvent être positionnés avec le flag append-only (l'attribut "a" ) pour que seulement de nouvelles entrées puissent être ajoutées et plus supprimables.

mexx20 J'ai eu du mal pour redémarer l'ordinateur. Pour cela il a fallu travailler à un "niveau plus bas" que les commandes car celles-ci (saines) ne fonctionnait plus à cause, probablement, d'un mauvais interfacage avec init (infecté). Les deux commandes suivantes font l'affaire :
 
echo 6 > /etc/initrunlvl ; kill -s SIGHUP 1
 
Deadog: Je crois que j'ai eu beaucoup de chance jusqu'à présent et je vais écouter tes bons conseils :)
911GT3 rootkit ........ :gratgrat: ............ ça a un rapport avec K2000 ? [:cupra]
Deadog n'oublie pas que ta machine est sans doute encore infecté
donc des que tu en auras la possibilité, réinstal ;)
mexx20 Pour information,  
 
J'ai réussi à me débrouiller en spécifiant un autre "init" (en inscrivant dans "lilo.conf" la directive append="init=/sbin/moninit".) et en relançant la machine.  
 
Quelque chose d'assez méconnu à savoir aussi est qu'il existe des attributs spéciaux pour EXT2/3. L'attribut "i" (imuable?) permet d'empecher la suppression. Les commandes pour les manipuler sont lsattr et chattr. En général un rootkit place l'attribut "i" sur "/sbin/init" et on ne comprend pas pourquoi on ne peux le remplacer.
 
J'éspère que cela pourra aider un jour quelqu'un.
 
Je remercie toutes les personnes qui ont répondu à mon post.
deather2 Puis tu ne peux pas passer en mode maintenance (init 1) car tu perdrais ta connexion ssh :/
Je crains qu'il n'y ait guere de solutions :/
nuitn0ire non non , je comprends bien ta situation , et j'avoue avoir tendance à zapper que tu es à 2000 bornes , je me doute que la réinstall depuis là est guère possible .
enfin , me concernant , je ne saurais pas vraiment te conseiller dans ton cas , et tu m'en vois désolé :|
mexx20 Nous sommes d'accord; mais il m'est malheureusement impossible, ces jours-ci, d'être physiquement devant la machine. Et donc, je ne peux utiliser de CDs de démarrage ou encore démarrer en "single user". Le but de mon post est de trouver des solutions en partant de ce principe. C'est un postulat que je voudrais que tu acceptes, même si, je te l'accorde très volontier, il n'est pas très appétissant. Tout cela implique donc quelques "bricolages"; du moins, si pour toi ce terme désigne toutes les actions qui diffèrent à une réinstallation complète. A mon sens, avoir réinstallé tous les packages sauf ces 2 binaires approche un peu la "réinstallation". Je sais que je vais à l'encontre du courant de pensée de la sécurité radicale et même peut-être du bon sens et je m'en excuse très sincèrement auprès de tous les adhérents en éspérant aussi que je ne choque personne.
nuitn0ire quelles sont les erreurs ?
 
quant à ta question , pour ma part je suis contre le bricolage après une intrustion.. mieux repartir sur des bases scènes . Et quand je disais tout réinstaller , je parlais pas que du noyau .
mexx20 Je pense que oui. J'ai laissé le fichier de config standard de ma distribution en changant ce que l'on ma conseillé plus haut et tous les "M" (pour modules) ont été automatiquement modifiés  "*" (pour en "dur" ). Donc, je suppose que je devrais obtenir le meme noyau a la différence que tout est compilé en une seule pièce. Pour les commandes de compilation, j'ai fait "make dep" puis "make".
 
Et sinon, que penses tu de l'alternative avec init ?
 
Merci pour ta patience.
jlighty Tu as bien configuré ton noyau avec de lancer la compilation ?
mexx20 Je n'arrive pas à compiler le noyau, ça prend énormement de temps et j'obtiens finalement des erreurs ... J'ai pensé à une autre solution peut-être plus simple. En spécifiant simplement via lilo.conf un autre emplacement pour le binaire init, le systeme démarerait avec un init sain et les modules ne se chargeraient pas. Je pourrais ainsi remplacer le init infecté. Qu'en pensez-vous ? J'ai un peu peur qu'il y ait des dépendances vis-à-vis de l'emplacement standard d'init. Le système démerera-t-il sans incidents si j'indique /sbin/moninit par exemple ?
nuitn0ire

jlighty a écrit :

Oui mais le pirate a pu utiliser une autre méthode pour avoir un compte root.
Par contre tu as interêt de trouver la faille du système pour éviter que cela se reproduise.


Si tu ne sais pas faire un audit de sécurité , je te conseil vivement d'utiliser un scanner de vulnérabilité comme par exemple Nessus (libre sous *nix) . Attention , il ne fonctionne qu'en local . Selectionne le degré d'audit désiré et il va te generer un rapport complet sur ce qu'il a trouvé , te proposant des liens vers les correctif .
 
mais bon , je te conseil d'utiliser nessus juste après avoir remis en place ton serveur , sans avoir mis en place les regles de sécurité . pourquoi ? pour la simple et bonne raison que tu as une vue d'ensemble sur toute les failles de ta machine , sans être embeté par un firewall passif/actif ou autre IDS , de plus si tu utilises portsentry et que tu fais ton audit à distance (via nmap) , je te souhaite de ne pas avoir d'ip fixe ;)

nuitn0ire ben , en fait c'est surtout utilisé par cequ'on appele des LKM , qui se chargent directement dans le noyau , donc quasiement indétectable . je connais pas les rootkits qui ont été utilisé , mais s'ils se chargent directement dans le noyau , oui .
donc en somme , ce qu'il te reste à faire :
- réinstall complete
- tu vires le chargement auto des modules (c'est un option qu'on trouve au début il me semble)
- au pire tu patch ton noyau avec grsec , mais seulement si tu vois l'utilité des options qu'il propose (dans ton cas je te le conseil , sa ne peut être qu'un plus si ta machine a déjà été rooté , pas dit qu'il n'y aura pas d'autre tentatives)  
- mettre en place une politique de sécurité béton : placer un IDS tel que snort qui te préviens en cas de coup dur , et portsentry (qui lui analyse en temps réel ce qui se passe) qui va , en cas de détéction de scan , aveugler le neuneu qui scan ta machine en plaçant son ip dans hosts.deny . Tu peux aussi refuser toutes les requetes ping etc.. enfin , faire ta petite sauce ;)
jlighty Oui mais le pirate a pu utiliser une autre méthode pour avoir un compte root.
Par contre tu as interêt de trouver la faille du système pour éviter que cela se reproduise.
mexx20 Merci pour toutes vos réponses. Donc si j'ai bien compris, vous me dites que je pourrais recompiler le noyau à partir des sources en désactivant la possibilité d'insérer des modules. (Alors, je dois insérer en dur le module pour la carte réseau pour garder la possibilité de m'y connecter.) Et puis de là, en supposant que c'était un module, ce dernier ne sera plus chargé et je pourrai remettre les deux binaires en place puis redémarer sur le noyaux de la distribution.
alien conspiracy

jlighty a écrit :

oui c'est une option à configurer lors de la création d'un noyau. C'est vrai que c'est radical.


Il existe même des patchs qui virent complétement la possibilitée.

jlighty oui c'est une option à configurer lors de la création d'un noyau. C'est vrai que c'est radical.
nuitn0ire pour éviter ce genre de galères , on peut pas (hormis une configuration sécurisée) bloquer le chargement automatique des nouveaux modules directement dans le noyeau ? me semble qu'il y a une directive qui permet ou non de charger les trucs qui sont en modules .
mexx20 Oui peut etre bien; mais je me dit que si j'ai déjà pu restaurer tout le systeme (ne comportant que tres peu de packages) excepté ces 2 fichiers le degré ne doit pas etre si élevé. J'ai également pu redémarer sur ce nouveau noyaux. Je serais tout de meme étonné que init soit modifié pour restaurer l'integralité d'un noyau piraté.
jlighty c'est vrai normalement par mesure de sécurité, comme on ne connait pas le degré d'infection -> réinstallation obligatoire
ory rootkit = réinstall.
mexx20 Merci pour ta réponse. La machine se trouvant a plus de 2000km d'ou je suis, je me demandais si je pouvais pas le faire a l'aide de certaines astuces directement a chaud sans redemarer via SSH comme outil d'interaction
jlighty En isolant la machine du réseau et en redemarrant celle-ci en single usern tu pourras restaurer tes fichiers.
mexx20 Bonsoir,
 
Une machine a apparement ete victime d'un (ou plusieurs?) type(s) de rootkit. Le script "chkrootkit" me donne (en ne copiant que les lignes significatives) :
 
Checking `ifconfig'... INFECTED
Searching for Suckit rootkit... Warning: /sbin/init INFECTED
Searching for ZK rootkit default files and dirs... Possible ZK rootkit installed
 
Le script semble dire vrai car, en effet, étrangement, lorsque j'essaye de remplacer /sbin/ifconfig et /sbin/init par les binaires des paquets de la distribution, on me dit que je n'ai pas les permissions alors que je suis root. Je ne puis ni déplacer, ni remplacer, si supprimer ces fichiers. Par contre j'ai pu mettre a jour tout les autres paquets et aussi le noyau.  
 
Mon problème est que j'aimerai effacer ces choses là à distance sans devoir redémarer la machine, ni booter sur un disque.  
 
Auriez vous une solutions a ce probleme ?

Copyright © 1997-2025 Groupe LDLC (Signaler un contenu illicite / Données personnelles)