Supprimer un rootkit d'un linux piraté

Demander un devis
Je souhaite télécharger le programme ou imprimer le programme
  • Imprimer

Introduction

 

Un rootkit est un programme ou un programme ou un ensemble de programme permettant à une personne malveillante d'accéder à une machine. Sous Linux ceci consiste à écraser certains binaires systèmes et/ou essentiels par un homologue piraté.

 

Typiquement, un pirate aura tendance à vouloir masquer son intrusion. A priori, root peut voir tout se qui se passe sur la machine avec les commandes ps (processus) ou netstat (activité réseau). Un pirate aura donc intérêt à écraser ces commandes au profit de remplaçante qui cacheront son activité.

 

Ceci signifie que quand une machine Linux est compromise, a priori plus aucune commande n'est digne de confiance. On peut a priori partir de principe qu'utiliser une commande d'un système compromis n'est a priori jamais fiable. On ne peut donc pas garantir une réparation "propre" à partir du moment où l'on utilise une commande de la machine infectée. C'est la raison pour laquelle il est souvent plus sage/sûr de faire une réinstallation complète de la machine. Toutefois, ceci n'est toujours pas possible pour des raisons pratiques et il existe des outils qui permettent d'éviter d'en arriver à de telles extrémités.

 

Les éléments évoqués dans ce tutoriel ne se veulent pas une solution miracle et qui résout tous les problèmes. Il rassemble  simplement un certain nombres de conseils et de techniques qui peuvent mener à une réparation partielle du système infectée.

 

Il est recommandé d'être à l'aise avec le mode texte, la syntaxe shell et le gestionnaire de paquets pour comprendre ce qui suit. Ici on part du principe que le gestionnaire de paquets utilisé est APT. Il est également recommandé d'être à l'aise avec la manière dont est organisé Linux.

Travailler depuis un système fiable

Via un Live CD

Principe

Travailler sur un live CD présente l'avantage que toutes les commandes utilisées seront a priori fiables. Elles permettent donc a priori de réparer un système Linux tiers infecté. Généralement et afin de rester discret, seul un petit nombre de commandes sont infectées (généralement toutes celles qui pourraient dévoiler la présence du rootkit ou l'activité du pirate). C'est la raison pour laquelle on utilisera le plus possible des commandes saines (et donc que l'on fera l'essentiel de la réparation depuis un système sain).

 

Dans la mesure du possible il est recommandé d'utiliser un live CD qui correspond au système à réparer. Cela simplifiera la procédure, même si en soit ce n'est pas indispensable. Par exemple, si l'on souhaite réparer un système Debian, il est préférable de réparer le système avec un live CD proche (Debian ou Ubuntu) et idéalement dans une version proche afin que les noms de paquets concordent entre les deux systèmes.

 

Une fois les binaires infectés écrasés, il sera possible de se chrooter sur le système tiers, notamment pour purger et réinstaller.

 

Nous allons désigner dans la suite du tutoriel comme système sain le système Linux fournit par le live CD. Nous appellerons système infecté le système Linux infecté (donc le système Linux tiers) et dans lequel on se placera grâce à la commande chroot.

 

Pour comprendre ce qui suit, il est recommandé de lire le tutoriel sur les périphériques.

Mise en oeuvre

 

Cette procédure se décline en 10 étapes que nous allons détailler ci-après.

  1. Téléchargez le CD d'installation correspondant à votre distribution. Celui-ci permet de lancer un terminal à partir duquel on fera la réparation.
  2. Contrôlez le fichier iso téléchargé (somme md5...) et le graver en suivant les indications données dans ce tutoriel.
  3. Démarrez sur le CD en question. Si le PC n'amorce pas sur le CD, vérifiez que le BIOS est bien configuré.
  4. Déterminez la partition associée à la partition / du système Linux infecté à l'aide des commandes fdisk et/ou cfdisk (voir exemple ci-dessous.
  5. Créez un point de montage (par exemple /mnt/linux) et monter le système tiers dedans.
  6. Effectuez un chroot dans /mnt/linux.
  7. Effectuez la fin de la maintenance / les tests (tout se qu'on fait dans l'environnement chrooté reviendrait à ce qui se passerait si on avait démarré normalement).
  8. Quittez le chroot.
  9. Assurez-vous qu'aucun terminal n'est dans /mnt/linux pour pouvoir démonter /mnt/linux ou qu'aucun autre processus n'y accède (on peut vérifier ceci à l'aide de lsof). Démonter /mnt/linux.
  10. Rebootez normalement.

 

Remarque :

  • Il est recommandé de travailler avec deux terminaux : un terminal chrooté (qui servira à travailler dans le système tiers) et un autre non chrooté (qui sert à travailler au niveau du live CD)
  • On peut lancer plusieurs terminaux et utiliser plusieurs terminaux chrootés. Il suffira juste de lancer la commande "chroot /mnt/linux" dans chacun de ces terminaux. Il faudra juste veiller à quitter tous ces terminaux pour pouvoir démonter /mnt/linux.

Exemple :

 

Nous allons illustrer la liste ci-dessus par l'exemple. Tout ce qui suit nécessite des droits root. Pour passer root sous Ubuntu, tapez la commande :

 

sudo -s

 

Étape 4

 

(root@silk) (~) # fdisk -l

 

Ici la partition candidate est /dev/sda4. On peut le vérifier avec la commande cfdisk en examinant la table des partitions du disque /dev/sda :

 

cfdisk /dev/sda

 

En particulier, on peut vérifier s'il s'agit d'un système de fichiers ext3 ou ext4 (ici ext3).

 

cfdisk (util-linux-ng 2.17.2)

                                         Disk Drive: /dev/sda
                                  Size: 500107862016 bytes, 500.1 GB
                         Heads: 255   Sectors per Track: 63   Cylinders: 60801

     Name           Flags          Part Type    FS Type               [Label]            Size (MB)
 -----------------------------------------------------------------------------------------------------
                                                Unusable                                      1,05    *
     sda1           Boot            Primary     Unknown (27)                                419,44    *
     sda2                           Primary     NTFS                  [^O]               129161,50    *
                                                Unusable                                      7,32    *
     sda3                           Primary     Linux swap / Solaris                        995,26
     sda4                           Primary     Linux ext3                               369520,71

 

Étape 5


On crée ensuite le point de montage et on monte la partition / du système tiers :

 

mkdir -p /mnt/linux

mount -t ext3 /dev/sda4 /mnt/linux

 

Désormais, on devrait retrouver le contenu de la partition / du système tiers dans /mnt/linux. Typiquement /etc/fstab désigne le fichier fstab du Live CD tandis que /mnt/linux/etc/fstab désigne celui du système que l'on s'apprête à réparer.

 

Étape 6

 

On peut répéter cela dans autant de terminal qu'on le souhaite. Il faudra juste veiller à les quitter tous pour pouvoir démonter /mnt/linux.

 

 chroot /mnt/linux

 

À partir de maintenant, tout se passe dans ce terminal comme si on avait démarré avec le système Linux tiers.

 

Étape 7

 

Les étapes de maintenances sont détaillées dans la suite du tutoriel.

 

Étape 8

 

Une fois la maintenance terminée, on quitte chaque environnement chrooté en appuyant sur "ctrl d" ou en tapant la commande :

 

exit

cd /

 

La commande cd / permet de s'assurer qu'on n'est plus placé dans /mnt/linux.

 

Étape 9

 

On tape la commande :

 

umount /mnt/linux

 

Si un message indique que la ressource est occupée (ressource is busy), cela signifie qu'un processus accède à l'arborescence /mnt/linux et que celle-ci ne peut pas disparaître tant qu'un processus y accède. On peut retrouver tous les processus en question avec la commande :

 

lsof | grep /mnt/linux

 

Souvent il s'agit simplement d'un terminal placé dans /mnt/linux ou dans un sous-répertoire de /mnt/linux.  Dans ce cas, il suffit donc de répéter l'étape 8 dans chaque terminal pour résoudre le problème.

 

Étape 10

 

On redémarre l'ordinateur via l'interface graphique (si le live CD en dispose) ou via la commande :

 

reboot

 

Transfert du système sain vers le système infecté

 

La commande ne peut être tapé que dans un terminal non chrooté (puisque la portée d'un terminal chrooté se limite au système infecté). On utilise simplement la commande cp.

 

Exemple :

 

cp      /le/chemin/vers/du/fichier/a/copier  /mnt/linux/tmp
cp  -r  /le/chemin/vers/du/dossier/a/copier  /mnt/linux/tmp

 

Via ssh (par le réseau)

Principe

 

De manière générale, pendant toute la réparation, la machine ne doit pas être accessible par le réseau et doit être réparée en local via un live CD. Ceci évite qu'une intervention malveillante extérieure vienne perturber ou biaiser la réparation par le réseau.

 

Si la machine en question n'est accessible que par le réseau, on va devoir partir du postulat optimiste que le serveur via lequel on va intervenir pour la réparation est fiable (comprendre : la réparation n'est a priori pas complètement fiable). Idéalement la machine infectée ne devrait être accessible que par la machine qui va servir à la réparer (par exemple en les reliant toutes les deux directement en ethernet et en déconnectant la machine infectée du reste du réseau).

 

On utilise généralement ssh pour administrer une machine à distance. Des solutions comme rlogin/rsh/telnet ne devraient jamais être utilisées car elles sont nettement moins sûres (communication non chiffrée). La machine qui va servir à réparer le système infectée aura pour rôle de transférer sur la machine infectée les programmes qui vont permettre de réparer la machine infectée.

 

Nous allons désigner dans la suite du tutoriel comme système fiable le système depuis lequel on intervient. Nous appellerons système compromis le système Linux infecté (donc le système Linux tiers) auquel on accède par ssh.

Mise en oeuvre

 

Il est recommandé d'utiliser un terminal pour le système distant (la machine infectée) à laquelle on se connecte via ssh et un terminal sur la machine depuis laquelle on effectue la réparation.

 

Pour établir une connexion ssh vers une machine, il faut s'assurer des points suivants :

  • au niveau de la machine saine (client) : que l'on dispose d'un client ssh (paquet openssh-client sous debian et ubuntu),
  • au niveau de la machine infectée (serveur) : que l'on dispose d'un serveur ssh (paquet openssh-server sous debian et ubuntu), que le serveur sshd soit lancé,
  • que la configuration réseau (routage, ssh, pare-feu etc...) autorise la machine saine à se connecter sur la machine infectée,
  • que l'on dispose d'un login et d'un mot de passe valides sur la machine infectée,
  • que l'on connaisse l'IP ou un hostname permettant depuis la machine saine de se connecter à la machine infectée.

 

Côté client :

 

aptitude update

aptitude safe-upgrade

aptitude install openssh-client

 

Côté serveur :

 

aptitude update

aptitude safe-upgrade

aptitude install openssh-server

service ssh restart                # ou encore /etc/init.d/ssh restart

ifconfig                           # (optionnel) relever l'adresse IP

adduser mando                      # (optionnel) le compte avec lequel on effectuera la connexion ssh

 

On peut également configurer ssh pour n'autoriser au niveau ssh que certaines machines clientes et certains login à se connecter en ssh. Ceci se configure via /etc/ssh/sshd_config que l'on peut corriger par exemple avec nano. Par exemple le temps de la réparation, on pourrait n'autoriser que "mando" à se connecter à la machine en rajoutant dans /etc/ssh/sshd_config la ligne :

 

AllowUsers mando

 

Il faut ensuite veiller à relancer ssh pour que celui-ci prenne en compte la modification :

 

service ssh restart

 

Côté client :

 

ssh mando@x.x.x.x            # en remplaçant x.x.x.x par l'IP du serveur ou un hostname valide

su -                         # pour passer en root

 

Dès lors tout se passe comme si on travaillait (via ssh) sur la machine infectée en tant que root.

 

Transfert du système sain vers le système infecté

 

La commande scp doit être tapée depuis le système sain. On utilise simplement la commande cp.

 

Exemple :

 

scp      /le/chemin/vers/du/fichier/a/copier  mando@x.x.x.x:/tmp

scp  -r  /le/chemin/vers/du/dossier/a/copier  mando@x.x.x.x:/tmp

 

Réparer les binaires compromis

 

Le rootkit a probablement infecté certaines commandes fondamentales du système. L'idée va consister à :

  1. déterminer quels binaires sont infectés grâce à un détecteur de rootkit,
  2. déterminer quels paquets permettraient de les réinstaller,
  3. installer ces binaires de remplacement dans une arborescence tierce et la rendre prioritaire (afin que l'on utilise toujours des binaires sains),
  4. stopper tous les processus suspects,
  5. supprimer les binaires compromis en les écrasant avec les binaires sains.

Étape 1 : installation du détecteur de rootkit

À partir du gestionnaire de paquets

 

On peut installer un détecteur de rootkit via le gestionnaire de paquets, mais comme celui-ci a pu être compromis, on n'est pas réellement sûr d'installer un rootkit fiable (venant d'un miroir sûr etc...). C'est pourquoi la seconde approche est a priori plus sûre. Il existe différents logiciels (chkrootkit, rkhunter...) que l'on peut retrouver ici :

http://doc.ubuntu-fr.org/rootkit

À la main

 

On va utiliser pour cela un détecteur de rootkit, par exemple chkrootkit disponible ici : http://www.chkrootkit.org/.

 

Dans le système sain

  1. Télécharger les sources de chkrootkit (voir http://www.chkrootkit.org/download/ )
  2. Décompresser l'archive ainsi récupérée.
  3. Le binaire chkrootkit est déjà construit. Le makefile permet de construire quelques outils supplémentaires (ceci requiert d'avoir installé make et gcc).
  4. Transférer chkrootkit vers le système infecté (voir section précédente selon la méthode adoptée, via cp ou scp)

Exemple :


aptitude update

aptitude install gcc make

tar xzvf chkrootkit.tar.gz

cd chkrootkit*

make

 

... puis transférer le tout vers le système infecté (voir section précédente).

 

Dans le système infecté

 

On lance le binaire chkrootkit.

 

mv /tmp/chkrootkit* /tmp/chkrootkit

/tmp/chkrootkit/chkrootkit

 

Celui-ci va lister quels fichiers semblent être compromis. Stocker les noms de ces fichiers (un par ligne) dans le fichier /tmp/infectes.txt.

 

Étape 2 : déterminer d'autres binaires compromis

 

A priori le rootkit est sensé avoir détecté tous les binaires compromis, mais certains ont pu lui échapper, en particulier les binaires malveillants injectés par le rootkit et qui n'ont pas un nom de binaire standard. Selon le rootkit, ces fichiers peuvent être faciles à repérer de par les droits qui leur sont affectés (bits set-uid, bits set-gid, attributs spéciaux détectables via la commande lsattr etc...). Cette étape vise donc à compléter la liste constituée à l'étape 1.

lsattr

Réparation via ssh

 

Si le rootkit a pas listé lsattr parmi les commandes infectées, faites ce qui suit après l'étape 3. On utilise la commande lsattr et on veille à l'appliquer aux binaires du système infecté. On tape sur le système infecté :

 

lsattr /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin 2>/dev/null | less

 

Normalement seuls des tirets devraient apparaître dans la première colonne. On peut directement isoler les lignes pertinentes avec la commande :

 

lsattr /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin 2>/dev/null | egrep -v "\-{19}"

 

Si rien n'apparaît c'est que le rootkit (s'il y a un) n'a pas changé ces droits. Si au contraire certains binaires apparaissent, ils sont très probablement infectés ou malveillants. On va directement les isoler dans le fichier /tmp/compromis.txt avec la commande :

 

lsattr /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin 2>/dev/null | egrep -v "\-{19}" | cut -d' ' -f2 > /tmp/compromis.txt

 

Copiez le résultat dans /tmp/chattr.txt nous en auront besoin par la suite.

 

cp /tmp/compromis.txt /tmp/chattr.txt

 

Réparation via un live CD

 

Dans un terminal connecté en ssh sur la machine infectée, la commande précédente devient, depuis le système sain :

 

lsattr /mnt/linux/bin /sbin /mnt/linux/usr/bin /mnt/linux/usr/sbin /mnt/linux/usr/local/bin /mnt/linux/usr/local/sbin 2>/dev/null | egrep -v "\-{19}" | cut -d' ' -f2 > /tmp/compromis.txt 

 

Copiez le résultat dans /tmp/chattr.txt nous en auront besoin par la suite.

 

cp /tmp/compromis.txt /tmp/chattr.txt


Bit set-UID et bit set-GID

Le principe est le même que pour lsattr mais porte sur les droits POSIX. Les bits set-UID et set-GID ne sont utilisés que par certains binaires. Voici typiquement des binaires utilisant ces bits, notés "s" quand on utilise la commande "ls -l".

  • Pour les bits set-UID :

ls -l /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin | egrep -v "^((.{3}x)|(.{6}x))" | grep -v "^l" | grep -v "^total"

 

  • Pour les bits Set-GID :

ls -l /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin | egrep -v "^(.{6}x)" | grep -v "^l" | grep -v "^total"

 

Ajoutez-les à la liste /tmp/compromis.txt, dans le doute on les réinstallera tous.

 

Récupérer le résultat dans le système sain

 

Nous allons effectuer la recherche dans le système sain, encore faut-il récupérer le fichier /tmp/compromis.txt que nous venons de constituer. Pour cela on tape dans le système sain la commande suivante :

Réparation via un live CD

cp /mnt/linux/tmp/reinstall.txt /tmp/reinstall.txt

Réparation via ssh

scp mando@x.x.x.x:/tmp/reinstall.txt /tmp/reinstall.txt


Étape 2 : déterminer les paquets qui les fournissent

 

Dans /tmp/compromis.txt, nous avons réuni une liste de binaires suspects. Cherchons à présent les paquets associés à l'aide d'apt-file si le système Linux compromis est basé sur le gestionnaire de paquets apt. Si certains binaires ne sont fournis par aucun paquets, il s'agit très probablement de binaires malveillants et on les supprimera à l'étape 5.B.

 

Exemple : le binaire netstat figure parmi les suspects. On retrouve le paquet auquel il appartient avec la commande suivante sur le système sain (installez apt-file au besoin) :

 

apt-file search bin/netstat | grep netstat$

 

Ici il s'agit par exemple du paquet net-tools :

 

(root@silk) (~) # apt-file search bin/netstat | grep netstat$
net-tools: /bin/netstat

 

Listez chacun de ces paquets dans le fichier /tmp/reinstall.txt :

 

echo net-tools >> /tmp/reinstall.txt

 

Étape 3 : préparer une arborescence saine

 

Afin de plus utiliser les binaires infectés, nous allons déployer (par exemple dans /root/) une arborescence saine qui prendra le pas sur l'arborescence infectée.  Nous allons la constituer sur le système sain, et une fois prête, nous allons la transférer sur le système infecté. Pour effectuer les recherches qui suivent, il est nécessaire que le système sain et de réparation concordent (même version, même distribution).

 

Sur le système sain

 

On récupère depuis le système sain tous les paquets qui vont nous fournir des binaires sains. Si les systèmes diffèrent entre le système sain et le système infecté, faites ce qui suit directement sur le système infecté. Il reste toutefois plus sûr d'utiliser le moins possible le système infecté pour être sûr que l'on fait ce que l'on croit.

 

aptitude clean
aptitude download $(cat /tmp/reinstall.txt)

 

À présent, les ".deb" que l'on vient de récupérer sont dans /var/cache/apt/archives. Nous allons les manipuler dans /tmp/arborescence :

 

mkdir -p /tmp/arborescence

mv /var/cache/apt/archives/*deb /tmp/arborescence

dpkg-deb /tmp/arborescence/*deb /tmp/arborescence/

 

Dans le répertoire /tmp/arborescence, on retrouve une arborescence Linux-like. On transfert cette arborescence sur le système infecté (via scp ou cp selon qu'on travaille sur un live CD ou par ssh), par exemple dans /tmp/arborescence.

 

Sur le système infecté

 

Il est important de faire ce qui suit dans tous les terminaux lancés sur le système infectés. Nous allons préciser à ces shells que les binaires utilisés doivent en priorité être utilisés depuis l'arborescence saine que nous venons de transférer, et dans un second temps dans l'arborescence "standard" du système infecté. Pour cela, on corrige la variable PATH qui précise dans quels répertoires le shell doit chercher lesdits binaires et dans quel ordre il doit effectuer sa recherche.

 

export PATH="/tmp/arborescence/usr/local/sbin:/tmp/arborescence/usr/local/bin:/tmp/arborescence/usr/sbin:/tmp/arborescence/usr/bin:/tmp/arborescence/sbin:/tmp/arborescence/bin:${PATH}"

 

On peut vérifier que les shells en question vont bien chercher en priorité dans /tmp/arborescence les binaires. Si par exemple ps est compromis, que vous avez téléchargé une version saine de ps et que vous l'avez placé dans /tmp/arborescence, tapez la commande :

 

which ps

 

... et assurez vous que c'est bien la version stockée dans /tmp/arborescence qui prend le pas.

Étape 4 : stopper les processus suspects

 

Si la réparation est faite par ssh, il est temps de tuer les processus qui ont probablement été lancés par le pirate. En comparant les processus lancés sur le système sain et le système infecté, on devrait rapidement déterminer desquels il s'agit. Pour plus de détails vous pouvez consulter le tutoriel sur les processus.

 

ps faux | less

 

Vérifiez en particulier les services réseaux en cours de fonctionnement et stoppez/tuez ceux qui n'ont pas lieu de tourner (attention à ne pas tuer ssh !).

 

netstat -ntlp

 

Étape 5 : écraser les binaires compromis

Étape A : réinstallation des paquets associés aux commandes compromises


En temps normal, il suffit de réinstaller les paquets concernés (avec la commande aptitude reinstall ...). En fait on aurait pu le faire dès l'étape 3, mais on n'aurait pas été pleinement sûr que le gestionnaire de paquets n'était pas compromis. Si l'étape 3 a été correctement réalisée, on n'utilise a priori plus que des binaires fiables et il est donc temps de tout mettre à platt. On transfert /tmp/reinstall.txt vers le système infecté et on lance la réinstallation :

 

aptitude update

aptitude safe-upgrade

aptitude reinstall $(cat /tmp/reinstall.txt)

 

Étape B : si la réinstallation échoue suite à une erreur de droits


Malheureusement il se peut que ces paquets ne s'installent pas suite à des erreurs de droits (ce qui au premier abord peut être assez choquant quand on sait que notre gestionnaire de paquets est lancé en root !). En effet, certains rootkits modifient les attributs des fichiers infectés au niveau du système de fichiers pour chacun des binaires infectés. Dès lors, même root (et donc le gestionnaire de paquets qu'il lance) ne peut les écraser et ainsi déployer les paquets pour la réinstallation.

 

Ceci n'est en fait pas très gênant une fois qu'on connaît les commande lsattr et chattr. La première commande liste les attributs au niveau du système de fichiers. Des attributs "louches" (s, i, a comme le montre "man lsattr") permettent donc de facilement détecter des binaires compromis, car ces attributs ne sont pas utilisés par les binaires standards.

 

La commande chattr permet de désactiver ces attributs et il est dès lors possible d'écraser ces binaires. A priori les attributs qui provoquent les blocages sont les flags s, i et a. Pour les désactiver, sur le système infecté :

 

chattr -sia $(cat /tmp/chattr.txt)

rm -i $(cat /tmp/chattr.txt)

 

Reprenez ensuite l'étape 5.A.

 

Étape 6 : vérification avec debsums

 

Nous allons maintenant installer debsums. Cet outil contrôle la somme md5 des paquets installés.  Il peut également contrôler les fichiers de configuration (pour plus de détails, voir "man debsums"). Si un paquet a été compromis, il devrait être listé en tant que tel :

 

aptitude install debsums

debsums | grep -v "OK$"

 

Nettoyer la configuration

Gestion des utilisateurs

 

Il est peut probable qu'un nouvel utilisateur ait été créé mais sait-on jamais... Vérifiez que les utilisateurs référencés dans /etc/passwd et capables de lancer un bash sont tous légitimes.

 

grep "sh$" /etc/passwd

 

Si un utilisateur ne semble pas avoir de raison d'exister, supprimez le avec la commande userdel.

 

Exemple :

 

userdel toto

 

Note : certaines applications créent des utilisateurs sans que vous les ayiez créé explicitement. Ceci peut se vérifier en comparant les utilisateurs présents sur un système sain ayant installé les mêmes paquets. On pourra utiliser "dpkg --get-selections" et ""dpkg --set-selections" pour ce faire.

 

Exemple :

  • Sur la machine pour laquelle on veut récupérer la liste des paquets installés :

dpkg --get-selections > /tmp/paquets.txt

  • Après avoir récupéré /tmp/paquets.txt sur la machine sur laquelle on veut installer les même paquets :

dpkg --set-selections < /tmp/paquets.txt    

 

Mots de passe et clés ssh

 

Changez les mots de passe de tous les utilisateurs capables de se logguer sur la machine, y compris root. Veillez à ce que ces mots de passe soient sûrs (pas basés sur un mot du dictionnaire, pas basés sur le login ou sur des touches consécutives sur le clavier, combinant chiffres, minuscules et majuscules, composés d'au moins 8 caractères etc...).


Configuration globale

 

Assurez vous que les fichiers suivants ne lancent pas de tâche malveillantes. Pour cela, comparez ces fichiers à ceux du système sain.

  • /etc/inittab
  • /etc/profile
  • Tous les fichiers lancés avec un shell (par exemple si vous utilisez bash : /etc/bash.bashrc, ~/.bashrc, ...),
  • ...

Attention car l'instruction qui suit va restaurer toute la configuration par défaut. Les personnalisations que vous pourriez avoir apporté pour configuré le système Linux risquent donc de disparaître. Dans le doute, vous devriez archiver /etc au préalable.

 

dpkg-reconfigure --all


Profils

 

Les profils des différents utilisateurs peuvent avoir été altérés lors de l'intrusion (en particulier ssh et bash)

 

Si vous utilisez ssh, supprimez de chaque home directory les répertoires .ssh qui peuvent contenir des clés ssh. Si vous ne savez pas ce qu'est une clé ssh, vous pouvez consulter cet article :

http://prendreuncafe.com/blog/post/2005/08/29/262-installer-sa-cle-ssh-sur-un-serveur-distant

 

Pour ce faire, tapez la commande :

 

for x in $(cat /etc/passwd | cut -d: -f6); do rm -rf $x/.ssh; done

 

Sur le même principe, pour supprimer tous les profils bash :

 

for x in $(cat /etc/passwd | cut -d: -f6); do rm -rf $x/.bash*; done

 

Idéalement tous les profils devraient être supprimés, mais attention à ne pas supprimer des données importantes (mails etc...). Pour plus de détails sur les profils vous pouvez consulter cet article.

Services

 

Sous Debian, le fichier /etc/init.d/rc est codé de sorte à rendre le fichier /etc/inittab indépendant des services installés dans /etc/init.d. Il en est de même lorsqu'une solution autre que /etc/inittab est adoptée (ce qui est le cas sous Ubuntu).

 

Ainsi, il faut s'assurer que chacun de ces services est légitime avec une recherche via apt-file et de les réinstaller. Tous les scripts figurant dans ce répertoire et qui ne sont fournis par aucun paquet sont a priori malveillants et doivent être supprimés.


Finalisation

 

Faites en sorte d'abandonner des technologies peu sûres (comme telnet au lieu de ssh). Pensez à  mettre régulièrement et intégralement votre système intégralement à jour, car certaines mises à jours servent à résoudre des trous de sécurité.

 

Dans le système qui était compromis :

 

aptitude update

aptitude safe-upgrade

 

Vous pouvez supprimer les fichiers que l'on a créé dans /tmp si vous pensez ne plus en avoir besoin et redémarrer normalement le système qui était compromis.

 

 


.
X
 
 
 
 
 

You havecharacters left.