Utiliser son système local, même lorsqu’il ne semble plus démarrer ? C’est possible avec Chrootme.sh !

1 réponse

Chrootme.sh - Script de Chroot automatisé

Chrootme.sh – Script de Chroot automatisé

Pour de raisons multiples, il est possible que le démarrage d’un serveur soit impossible. Selon les possibilités de l’offre, il peut être très compliqué de trouver quelle en est la cause. Malgré que le système ne veuille plus démarrer, il peut être encore possible d’accéder non seulement aux données, mais aussi à certains services depuis un système de restauration (encore appelé système de sauvetage, ou rescue).

La fonction « chroot » de Linux permet de changer le dossier racine d’un processus ; la commande « chroot » permet donc de démarrer un processus avec une nouvelle racine (en ne précisant pas la commande, par défaut c’est le shell par défaut qui est lancé).

Pour pouvoir accéder aux données du système du serveur, il est alors nécessaire de monter l’ensemble des disques dans un dossier, et de se « chrooter » dans ce dossier, par exemple /mnt/ ou encore /media/. L’exercice est assez facile lorsque le partitionnement du disque est connu mais devient plus acrobatique et complexe lorsque c’est un serveur qu’on vient de découvrir. Heureusement, le fichier /etc/fstab du système local contient l’organisation des partitions utilisées par le système local et va nous permettre de monter facilement les partitions.

Pour gagner du temps, j’ai développé un script qui permet d’automatiser la recherche du fichier fstab, permet de choisir quel est le fichier fstab à utiliser, et de monter l’ensemble des partitions du fichier fstab choisi, et de faire un « chroot » sur le système nouvellement monté.

Ce script s’appelle Chrootme.sh et est disponible sur Github. Le script a été développé en essayant de dépendre du minimum d’outils possibles, pour pouvoir être utilisé depuis le plus grand nombre de systèmes « rescue » possible.

Si jamais un problème survenait lors de l’utilisation de ce script, vous pouvez reporter les bugs (en anglais si possible) sur GitHub.

Pour utiliser ce script, il vous suffit de lancer la commande suivante :

$ wget --no-check-certificate "https://raw.githubusercontent.com/sysadminstory/chrootme/master/chrootme.sh" -O "chrootme.sh" && sh chrootme.sh

Si la commande wget n’est pas disponible, il est possible d’utiliser la commande curl en remplaçement :

$ curl -k -o "chrootme.sh" "https://raw.githubusercontent.com/sysadminstory/chrootme/master/chrootme.sh" && sh chrootme.sh

Une fois le script démarré, il ne vous reste plus qu’à suivre les instructions à l’écran.

Un certain nombre d’articles de ce blog font appel au chroot. La méthode pour récupérer ou modifier le mot de passe root sous Linux y fait appel, tout comme les articles sur la restauration d’un RAID1 logiciel et la méthode pour migrer un système complet en minimisant l’indisponibilité y font référence quant à la réinstallation du chargeur d’amorçage.

Monitorer l’état des disques sous Debian

Laisser une réponse

Défaillance d'un disque dur - Tête de lecture ayant abimé un plateau

Défaillance d’un disque dur – Tête de lecture ayant abimé un plateau

Sous Debian, superviser l’état des disques et être informé de toute défaillance détectée par SMART sur l’un des disques attachées au contrôleur non RAID (le cas des controleurs RAID est assez spécifique) est assez simple.

Le premier pré-requis pour surveiller l’état des disques est de disposer du package smartmontools. Si celui ci n’est pas encore installé, il suffit de lancer la commande suivante en root :

# apt-get install smartmontools

Par défaut, sous Debian, le service de surveillance de l’état SMART des disques n’est pas actif, il va donc falloir l’activer. Pour ce faire, il faut éditer le fichier /etc/default/smartmontools et décommenter la ligne suivante :

#start_smartd=yes

La ligne est à présent la suivante :

start_smartd=yes

Il faut à présent modifier la configuration de smartd afin de recevoir les alertes sur l’email de son choix. Le fichier à modifier est /etc/smartd.conf. Il faudra remplacer la ligne suivante :

DEVICESCAN -d removable -n standby -m root -M exec /usr/share/smartmontools/smartd-runner

Le remplacement devra s’effectuer avec cette ligne, en prenant soin de remplacer email@domaine.tld par l’adresse email de votre choix :

DEVICESCAN -m email@domaine.tld -M exec /usr/share/smartmontools/smartd-runner

Après avoir modifié la configuration, il ne reste plus qu’à redémarrer le service smartmontools avec la commande suivante :

/etc/init.d/smartmontools restart

❗ Pour que le mail puisse être envoyé, il faut qu’un serveur de mail soit correctement configuré, comme exim4, sendmail, ou encore postfix.

Vous serez à présent averti par mail dès qu’un problème sera détecté par le système SMART, et vous pourrez donc agir avant de rencontrer une indisponibilité, voire de perdre des données.

Malgré tout, il reste important de disposer de sauvegardes, car une panne électrique ou un contrôleur de disque peuvent rendre inexploitable un disque sans prévenir !

Monitorer un RAID logiciel sous Debian

Laisser une réponse

Linux RAID1 Soft - Défaillance totale

Linux RAID1 Soft – Défaillance totale


Afin que le RAID remplisse sa fonction de tolérance aux pannes, il est nécessaire non seulement de le mettre en place, mais aussi de surveiller son état.
Dans le cadre d’un RAID logiciel Linux, l’utilitaire mdadm utilisé pour configurer et gérer le RAID, permet également d’être informé de tout changement d’état du RAID. Dans le cas contraire, il est bien possible que des données se retrouvent perdues à jamais un jour où l’autre !

Sous Debian, par défaut, mdadm est lancé en tant que service, mais il reporte les changements d’états du RAID uniquement dans syslog : il faudrait donc surveiller les logs du serveur en permanence pour être informé en temps réels des éventuels problèmes rencontrés sur le RAID. Il est tout à fait possible de remplacer l’écriture dans les logs par l’envoi d’un email.

Pour ce faire, il vous faudra modifier deux fichiers. En premier lieu, ce sera le fichier /etc/default/mdadm qu’il faudra modifier, celui-ci correspond aux paramètres du service « mdadm ». Il faudra remplacer dans ce fichier la ligne suivante :

DAEMON_OPTIONS="--syslog"

par la ligne suivante :

DAEMON_OPTIONS=""

Le deuxième fichier corresponds aux paramètres de mdadm dans sa globalité. Le fichier /etc/mdadm/mdadm.conf doit être modifié et peut-être complété.

La ligne suivante doit être remplacée par l’adresse qui doit recevoir les alertes de changement d’état (par défaut, c’est l’utilisateur root qui recevra les alertes par mail) :

MAILADDR root

Elle devra être de la forme suivante

MAILADDR monemail@domaine.tld

Si l’adresse de l’expéditeur par défaut ne convient pas il est également possible de définir l’adresse de l’expéditeur (par défaut : root@<hostname>), il suffit d’ajouter la ligne suivante :

MAILFROM expediteur@domain.tld

❗ Pour que le mail puisse être envoyé, il faut qu’un serveur de mail soit correctement configuré, comme exim4, sendmail, ou encore postfix.

Une fois la configuration modifiée, il restera à relancer le service mdadm avec la commande suivante :

# /etc/init.d/mdadm restart

A présent, un email sera envoyé dès qu’un volume RAID sera dégradé.

Que faire après qu’un disque d’une grappe RAID1 logiciel montre des faiblesses ?

1 réponse

Linux RAID1 Soft - Défaillance de disque

Linux RAID1 Soft – Défaillance de disque

Lorsqu’un disque arrive en fin de vie et que le serveur dispose d’un RAID logiciel sous Linux, il est nécessaire de prendre quelques précautions pour éviter le plus possible une perte de données, avant de remplacer le disque dans la grappe RAID.

Identifier le disque défaillant

Quand le RAID commence à rencontrer des erreurs, elles peuvent être dues à une panne franche ou à des erreurs aléatoires.

Dans le cadre d’une panne franche le disque défaillant pourra apparaître comme étant « Failed » dans le fichier de statut du RAID /proc/mdstat : le nom de la partition sera suivi d’un « (F) » :

# cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sda1[2](F) sdb1[1]
      8382400 blocks super 1.2 [2/1] [_U]

unused devices: <none>

La partition défaillante sera indiquée par le « (F) » suivant son nom sur la ligne mentionnant le nom de la grappe RAID.

Il est également possible que le disque ne soit plus détecté du tout et la partition correspondante disparaîtra alors totalement de la liste des partitions associées à la grappe RAID :

# cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdb1[1]
      8382400 blocks super 1.2 [2/1] [_U]

unused devices: <none>

Dans tous les cas il est utile d’utiliser la commande « mdadm --detail /dev/md0 » pour déterminer quel est le disque à changer : une partition marquée « removed » ou « faulty » indique quel disque pose actuellement problème :

# mdadm --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Sun May 27 11:26:05 2012
     Raid Level : raid1
     Array Size : 8382400 (7.99 GiB 8.38 GB)
  Used Dev Size : 8382400 (7.99 GiB 8.38 GB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent
 
    Update Time : Mon May 28 11:16:49 2012
          State : clean, degraded 
 Active Devices : 1
Working Devices : 1
 Failed Devices : 0
  Spare Devices : 0
 
           Name : swraid (local to host Debian)
           UUID : 81c1d8e5:27f6f8b9:9cdc99e6:9d92a1cf
         Events : 32365
 
    Number   Major   Minor   RaidDevice State
       1       8       33        0      active sync   /dev/sda1
       1       0        0        1      removed

Une partition « removed » est une partition qui n’est plus détectée par le Kernel comme faisait parti du RAID (disque totalement indisponible, ou méta données de la partition illisible, …).

Dans le cadre d’une panne non franche, il va falloir vérifier quel est le disque qui provoque des erreurs, avec par exemple les commandes smartctl, ou en consultant les logs du kernel (avec la commande dmesg) à la recherche d’erreur de lecture / écriture, ou encore de communication avec le contrôleur du disque.

Une fois le disque à remplacer identifié, il est conseillé d’effectuer une sauvegarde des données présentes sur le RAID.

Préparer la sauvegarde des données

Lorsqu’on s’apprête à sauvegarder les données, surtout dans le cadre d’une panne non franche du disque défectueux, il est plus prudent de retirer totalement le disque de la grappe RAID, pour éviter tout état inconsistant des données suite à des écritures aléatoires.
Pour ce faire, il faut retirer la partition défectueuse sda1 de la grappe RAID concernée md0 comme suit :

# mdadm --manage /dev/md0 --set-faulty /dev/sda1
# mdadm --manage /dev/md0 --remove /dev/sda1

Si la partition a déjà été marquée comme défaillante, la commande suivante supprimera automatiquement la partition de la grappe RAID :

# mdadm --manage /dev/md0 --remove faulty
# mdadm: hot removed 8:1 from /dev/md0

A partir de ce moment, l’état du RAID devrait rester cohérent et sauf panne matérielle, il ne devrait pas y avoir de risque de perte de données.

Ajouter un nouveau disque dans la grappe RAID

Une fois la sauvegarde effectuée, il faut remettre en place le RAID après avoir remplacé le disque défaillant.

La première étape consiste à recopier la même table de partition présente sur le disque restant sdb sur le nouveau disque sda :

# sfdisk -d /dev/sdb | sfdisk /dev/sda
Vérification qu'aucun autre n'utilise le disque en ce moment
OK

Disque /dev/sda : 1044 cylindres, 255 têtes, 63 secteurs/piste

sfdisk: Erreur : le secteur 0 n'a pas une signature MS-DOS
 /dev/sda : type non reconnu de table de partition
Précédente situation :
Aucune partition repérée
Nouvelle situation :
Unités = secteurs de 512 octets, décompte à partir de 0

   Périph Amorce  Début       Fin   #secteurs Id  Système
/dev/sda1          2048  16775167   16773120  fd  RAID Linux autodétecté
/dev/sda2             0         -          0   0  Vide
/dev/sda3             0         -          0   0  Vide
/dev/sda4             0         -          0   0  Vide
Avertissement : la partition 1 ne se termine pas sur une frontière de cylindre
Avertissement : aucune partition primaire marquée amorçable (active)
Peu important pour LILO, mais DOS MBR n'amorcera pas ce disque.
Succès d'écriture de la nouvelle table de partitions

Relecture de la table de partitions…

Si vous créez ou modifiez une partition DOS, /dev/foo7 par exemple,
alors utilisez dd(1) pour mettre à zéro les 512 premiers octets :
dd if=/dev/zero of=/dev/foo7 bs=512 count=1
(consultez fdisk(8)).

Une fois la table de partition recopiée, il ne reste plus qu’à rajouter la partition sur la grappe RAID comme suit :

# mdadm --manage /dev/md0 --add /dev/sda1
mdadm: added /dev/sda1

Le RAID devrait alors se reconstruire dès à présent, comme le montre le contenu du fichier d’état du RAID /proc/mdstat :

# cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sda1[2] sdb1[1]
      8382400 blocks super 1.2 [2/1] [_U]
      [==>..................]  recovery = 11.4% (958336/8382400) finish=5.9min speed=20609K/sec

unused devices: <none>

Pour que le serveur puisse démarrer depuis les deux disques durs, il reste à installer le chargeur d’amorçage sur le disque qui a été remplacé, voici la méthode pour grub :

# grub-install /dev/sda
Installation finished. No error reported.

❗ Si vous effectuez ces opérations depuis un système de sauvetage, il faudra dans un premier temps monter votre système local et vous chrooter sur le système local.

Le RAID va à présent se reconstruire (synchroniser les données sur la partition nouvellement ajoutée) et le système est prêt pour démarrer sur l’ensemble des disques du serveur.

Migrer un système complet d’un disque à un autre, en minimisant l’indisponibilité

3 réponses
SSD

SSD

Dès lors qu’un serveur est en production, le temps d’indisponibilité devient un critère important quand une opération de maintenance doit être prévue. Un client a souhaité migrer son système d’un disque SSD à un disque classique parce que la taille du SSD était insuffisante pour son utilisation.

Le disque SSD contenait l’ensemble des données du serveur et par chance le disque dur était monté dans le dossier « /hdd » et ne contenait aucune donnée.

Afin de réduire le temps d’indisponibilité, il fallait effectuer le maximum d’opération avec le serveur en ligne. J’ai donc mis en place la procédure décrite dans les paragraphes suivants.

Préparation du disque dur

L’ensemble du disque dur est un LVM que j’ai démonté puis détruit :

umount /dev/hdd/data
lvremove /dev/hdd/data
vgremove hdd
pvremove /dev/sdb1

Il faut ensuite partitionner le disque dur pour correspondre au besoin : ici, comme LVM est utilisé pour tout sauf la partition racine, j’ai recréé à l’aide de parted la même structure pour disposer de la même liberté par la suite :

parted /dev/sdb

Voici le partitionnement final qui a été mis en place :

Model: Adaptec Volume#1 (scsi)
Disk /dev/sdb: 3760GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number Start End Size File system Name Flags
1 32.3kB 4302MB 4302MB
2 4302MB 6457MB 2155MB
3 6457MB 3760GB 3754GB lvm

Il a fallu ensuite recréer le LVM, en créant dans l’ordre le volume physique, le groupe de volume et les volumes logiques :

# Création du volume physique
pvcreate /dev/sdb3
# Création du groupe de volume
vgcreate hdd /dev/sdb3
# Création des volumes logiques, avec une taille initiale de 4 Go
lvcreate -L4G -n usr hdd
lvcreate -L4G -n var hdd
lvcreate -L4G -n home hdd

Il faut à présent mettre en place des systèmes de fichiers sur les différents volumes logiques et sur la partition racine :

mkfs.ext3 /dev/sdb1
mkfs.ext4 /dev/hdd/home
mkfs.ext4 /dev/hdd/usr
mkfs.ext4 /dev/hdd/var

Ce sont les mêmes systèmes de fichiers que sur le SSD qui ont été mis en place sur le disque dur.

Copie des données

La stratégie adoptée ici pour réduire la durée d’indisponibilité a été d’effectuer la copie des données en deux temps : d’abord une copie en ligne, puis une copie en système rescue, pour les fichiers qu’il n’est pas possible de copier lors que le système est démarré (ex : les bases de données MySQL). De ce fait, la partie la plus longue de la copie n’aura pas d’impact sur la disponibilité du serveur.

La première étape est de monter la future partition racine dans « /mnt » et de recréer la même structure de dossiers sur la racine du disque dur que sur la racine du SSD :

mount /dev/sdb1 /mnt/
for f in `find / -maxdepth 1 -type d` ; do mkdir /mnt$f ; done

❗ Attention : cette commande ne fonctionnera que pour les systèmes où l’ensemble des points de montages sont à la racine.

On monte à présent l’ensemble des partitions du disque dur sur la structure créé dans « /mnt » :

mount /dev/hdd/home /mnt/home/
mount /dev/hdd/var /mnt/var/
mount /dev/hdd/usr /mnt/usr/
mount --bind /dev /mnt/dev
mount --bind /sys /mnt/sys
mount --bind /proc /mnt/proc

La copie sur le système démarré peut à présent commencer : rsync est particulièrement bien adaptée, car il permet d’exclure facilement des dossiers (comme /proc, /sys, /dev et bien sur /mnt) et de conserver les permissions et attributs des fichiers :

rsync --progress --exclude="/mnt/*" --exclude="/proc/*" --exclude="/sys/*" --exclude="/dev/*" -v -a -c -r -H -A -X / /mnt/

Une fois la copie sur le système démarré terminé, il faut placer le serveur en système rescue et lancer la copie hors-ligne pour récupérer les fichiers modifiés, ou impossible à copier en ligne. Il faut dans un premier temps monter l’ensemble des partitions du SSD dans « /ssd » et l’ensemble des partitions du disque dur dans « /mnt ». Il reste ensuite à lancer la commande suivante :

rsync --progress --exclude="/mnt/*" --exclude="/proc/*" --exclude="/sys/*" --exclude="/dev/*"  -v -a -c -r -H -A -X /ssd/ /mnt/

❗ Attention : La présence des « / » à la fin des chemins est indispensable : les omettre créerait un dossier « /ssd » dans le dossier « /mnt », ce qui n’est évidemment pas le but de la manoeuvre !

Préparation au démarrage sur le disque dur

Une fois les données copiées, il reste encore quelques petites modifications à effectuer pour que le système sur le disque dur soit prêt. Pour éviter toute confusion dans les fichiers à modifier, autant se « chrooter » directement sur le disque dur :

mount --bind /dev /mnt/dev
mount --bind /sys /mnt/sys
mount --bind /proc /mnt/proc
chroot /mnt/

Il faut dans un premier temps éditer le fichier /etc/fstab pour supprimer les références au SSD et les remplacer par le disque dur :

vi /etc/fstab

Il faut également corriger le chargeur d’amorçage GRUB pour qu’il utilise le disque dur comme racine lors du prochain démarrage. Il faut pour cela éditer le fichier de configuration de GRUB :

vi /boot/grub/menu.lst

Il reste à présent à installer la nouvelle configuration de GRUB sur le SSD pour pouvoir démarrer sur le disque dur :

grub-install /dev/sda

Au prochain redémarrage, le serveur démarrera sur le disque dur. L’ensemble des données ont été conservées sur le SSD, afin de pouvoir redémarrer sur le SSD en cas d’erreur durant la procédure !

Lister toutes les règles « iptables »

Laisser une réponse
iptables : Table nat et redirection de port

iptables : Table nat et redirection de port

Effectuer des actions sur un serveur qui a été géré par un autre n’est souvent pas chose facile : il est très compliqué de savoir ce qui a été fait avant et pourquoi ça ne fonctionne pas.

Récemment, pour prouver qu’un certificat X.509 permettait de mettre en œuvre TLS, j’ai dû configurer Apache avec ce certificat. C’est une opération plutôt simple, surtout que la plupart des distributions proposent un fichier de configuration « SSL » où il ne reste qu’à modifier les chemins vers la clé privée, la clé publique et l’éventuel certificat intermédiaire.

Après quelques configurations qui ne fonctionnent pas, pour cause de «Connection refused», alors que tout semble être correct, j’entreprends des vérifications plus poussées. Apache écoute-t-il sur le port 443 ? Oui. Le trafic IPv4 ou IPv6 arrive-t-il bien sur le port 443 du serveur ? Oui. La configuration réseau est-elle correcte ? Oui. « iptables » contient-il des règles qui pourraient bloquer le trafic sur le port 443 ? Aucune règle présente dans « iptables », et l’action par défaut est « ACCEPT ».

De plus, ce qui est encore plus étrange, c’est que bien qu’un accès soit totalement impossible depuis l’extérieur du serveur, un accès local fonctionne parfaitement.

Comment est-ce possible alors que « iptables » est vide ? Totalement vide ? Non, car une irréductible table de « iptables » est passée inaperçue : la table NAT.

C’est après avoir passé une bonne vingtaine de minutes à chercher pourquoi ça ne fonctionnait pas, que je suis tombé sur la table NAT qui redirigeait le port 443 sur un autre port … Du coup, voici une commande qui va permettre de lister vraiment toutes les règles de toutes les tables mise en place dans « iptables » :

for t in filter nat mangle raw security ; do echo -e "##########\nTable $t\n##########" ; iptables -t $t -L -n ; done

Et voici la même commande pour IPv6 :

for t in filter mangle raw security ; do echo -e "##########\nTable $t\n##########" ; ip6tables -t $t -L -n ; done

Finalement, après avoir supprimé cette règle de redirection de port dans la table NAT, tout fonctionne correctement.

Récupérer le mot de passe Administrator sous Windows 2008 et Windows 2008 R2

2 réponses
Windows 2008 R2 : Mot de passe refusé

Windows 2008 R2 : Mot de passe refusé

Récupérer le mot de passe « Administrator » d’un serveur Windows est une opération qui semble impossible parce que Microsoft ne semble pas l’avoir prévu. Une solution existe pourtant et même si celle-ci ne provient pas de Microsoft, elle est fonctionnelle et astucieuse !

Pour pouvoir modifier le mot de passe « Administrator » sans pour autant le connaitre, il faut pour cela obtenir les privilèges « SYSTEM ». Il existe pour cela une méthode, ou plutôt un « exploit » qui consiste à remplacer le gestionnaire d’accessibilité « utilman.exe » lancé par « SYSTEM » par un autre fichier.

Depuis le système LiveCD, système rescue, …, de votre choix vous devrez renommer « utilman.exe » pour en garder une copie :

ren "C:\windows\system32\utilman.exe" "C:\windows\system32\utilman_bak.exe"

Ensuite, il reste à copier l’interpréteur de commande « cmd.exe » à la place de « utilman.exe » :

copy "C:\windows\system32\cmd.exe" "C:\windows\system32\utilman.exe"

À présent, en redémarrant sous Windows et en cliquant sur l’icône Outil d’accessibilité en bas à gauche de l’écran de login, vous lancerez un interpréteur de commande « cmd.exe » avec les droits « SYSTEM » (supérieurs aux droits du groupe « Administrateurs »).

Ecran de login Windows Server 2008 R2 : Outils d'accessibilite

Ecran de login Windows Server 2008 R2 : Outils d’accessibilite

Dans cet interpréteur de commande, il restera à lancer la commande suivante :

net user Administrator nouveauMotDePasse

Le mot de passe de l’utilisateur « Administrator » sera alors remplacé par « nouveauMotDePasse ».

Il ne vous restera plus qu’à rétablir « utilman_bak.exe » en « utilman.exe » (pour éviter que n’importe quel utilisateur puisse accéder à une invite de commande en tant que « SYSTEM ») pour retrouver un système vierge de toute modification.

Récupérer le mot de passe root sous Linux

1 réponse
Changement de Mot de passe root dans un Chroot

Changement de Mot de passe root dans un Chroot

Il arrive souvent que lors de changement d’administrateur dans une entreprise, cela se passe « mal » : il arrive alors que la passation des codes nucléaires « root » se passe dans la douleur, voire pas du tout.

Il est alors nécessaire de modifier le mot de passe « root » de toutes les machines, par précaution.

La méthode la plus simple consiste à démarrer sur un système type « live CD » ou « rescue », selon que la machine soit en local ou dans un data center.

Une fois la machine démarrée sur le système « live », il va falloir monter les partitions du système local dans un dossier, par exemple « /mnt » pour reproduire l’arborescence du système local. Pour cette opération, il est courant d’utiliser les commandes « fdisk -l », « lsblk » ou encore « cat /proc/partitions », afin de retrouver les partitions existantes du système. Ensuite, pour se simplifier la vie, il suffit de trouver le fichier « fstab » du système local qui contient le partitionnement du système local.

Une fois l’arborescence recréée dans « /mnt », il suffit de ce se « chrooter » comme cela :

chroot /mnt

A présent, nous sommes en tant que « root » sur le système local. Il reste à changer le mot de passe avec la classique commande « passwd » :

root@debian:/# passwd
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
root@debian:/#

Il ne reste plus qu’à redémarrer proprement la machine et tester le mot de passe « root » !

Il existe bien sur d’autres méthodes (supprimer le mot de passe « root » dans « /etc/shadow », démarrer le système local en « single », lancer « bash » à la place d’« init», …) mais cette méthode reste la plus sûre et la plus universelle.

Sauvegarde de données en vue d’un remplacement de disque

Laisser une réponse
smartctl : le contenu d'un SMART Log d'un disque ayant enregistré des erreurs

smartctl : le contenu d’un SMART Log d’un disque ayant enregistré des erreurs

La semaine dernière, mon serveur a rencontré un souci de disque. Malheureusement, ce serveur ne dispose pas de RAID et il fallait récupérer les données de ce serveur.

Une fois les erreurs détectées sur un disque par smartd du package smartmontools il ne faut en général pas trop attendre avant de remplacer le disque, surtout sans RAID : le risque de perdre des données augmentant avec le temps qui passe !

Quand on dispose d’assez d’espace disque pour cloner le disque en fin de vie vers un autre serveur, il existe des méthodes assez simples à mettre en œuvre pour faire une copie du disque « bit à bit ». Afin d’avoir une durée d’indisponibilité la plus courte possible, il est préférable que les deux serveurs (celui qui va servir de stockage et celui dont les données doivent être récupérées) disposent d’une connectivité assez conséquente. En effet, le débit maximal théorique de transfert sera de 12,5 Mo/s avec une connectivité de 100 Mbps, et de 125 Mo/s pour du 1 Gbps. Avec les disques de quelques centaines de Gigaoctets, le temps de transfert durera de quelques heures à quelques dizaines d’heures.

Dans la suite de cet article, le serveur disposant d’un disque en fin de vie sera appelé « production », et le serveur recevant la copie des données sera appelé « stockage ».

Copie des données du serveur « production » vers « stockage »

La première étape pour faire une copie de disque « bit à bit » est de placer le serveur « production » sur un système non local (type système rescue, ou live CD). En effet, effectuer une copie « bit à bit » d’un disque où un système risque d’écrire est un bon moyen de disposer d’une copie inutilisable (où comment copier une table de fichiers qui ne corresponds pas aux données du disque).

Si l’accès aux serveurs s’effectue par SSH, il est plus prudent de lancer les commandes suivantes dans un « screen » pour que le transfert ne s’arrête pas en cas de perte de l’accès SSH.

Sur le serveur « stockage », il va falloir se préparer à recevoir les données du serveur « production » :

stockage:~/# nc -l 12345 | dd of=/chemin/vers/image-disque-dur.img.gz

La commande nc va écouter en TCP sur le port 12345, et passer l’ensemble des données reçues à la commande dd qui va les écrire dans le fichier /chemin/vers/image-disque-dur.img.gz

Sur le serveur « production », on va commencer à envoyer les données vers le serveur « stockage » :

production:~/# dd if=/dev/sda conv=noerror,sync | gzip -9 | nc stockage 12345

La commande dd va permettre de lire le disque, en ignorant les éventuelles erreurs de lectures (noerror), et en remplaçant les erreurs de lectures par la valeur NUL(sync). La commande gzip va permettre de compresser les données avant le transfert par le réseau ; le facteur limitant étant souvent le réseau, il est possible de réduire la durée de transfert en compressant les données avant de les envoyer, si la puissance du processeur le permet. Le paramètre « -9 » peut être remplacé par une valeur entre « -1 » et « -9 », plus la valeur étant élevée, plus le taux de compression sera important, mais au détriment de la vitesse de compression. La commande nc va quant à elle transférer les données par le réseau sur le serveur « stockage » sur le port TCP 12345.

Après quelques heures de patience, les deux commandes se termineront, il faut l’espérer, avec une sauvegarde du disque complète disponible sur un espace de stockage fiable !

Restauration des données du serveur « stockage » vers « production »

Une fois les données sauvegardées et bien évidemment, le disque remplacé, il restera à restaurer les données sauvegardées sur le nouveau disque. De la même manière, la restauration sur le serveur « production » ne pourra s’effectuer que sur un système non local.

Si l’accès aux serveurs s’effectue par SSH, il est plus prudent de lancer les commandes suivantes dans un « screen » pour que le transfert ne s’arrête pas en cas de perte de l’accès SSH.

Sur le serveur « production », il va falloir se préparer à recevoir les données du serveur « stockage » :

production:~/# nc -l 12345 | gunzip | dd of=/dev/sda

La commande nc va écouter en TCP sur le port 12345, et passer l’ensemble des données reçues à la commande gunzip pour les décompresser et les envoyer à dd qui va les écrire sur le disque /dev/sda

Sur le serveur « stockage », il faut envoyer les données vers le serveur « production » :

stockage:~/# dd if=/chemin/vers/image-disque-dur.img.gz | nc production 12345

La commande dd va permettre de lire l’image du disque et l’envoyer à la commande nc qui va quant à elle transférer les données par le réseau sur le serveur stockage sur le port TCP 12345. Comme le facteur limitant pour la restauration reste le réseau, autant envoyer la version compressée par le réseau. La décompression d’un flux gzip est plus rapide que la compression, autant ne pas s’en priver.

Après quelques heures, la restauration devrait être terminée. Une fois la restauration des données effectuée, il est prudent d’effectuer une vérification des systèmes de fichiers avant d’effectuer toute autre opération. Si tout va bien de ce côté, le serveur devrait pouvoir être redémarré sur le système local ! En cas d’erreur de lecture irrécupérable, il est probable qu’une partie de vos fichiers ne soient pas lisible, ou incomplet.

Conclusion

Si le disque original n’a trop souffert avant d’avoir été sauvegardé, le serveur pourra redémarrer sans encombre. Dans le cas contraire, il est possible de récupérer une partie des données, avant de réinstaller, si le système ne démarre plus, voire dans le pire des cas, de ne rien pouvoir récupérer.

Cette méthode, bien que fonctionnelle, peut poser quelques soucis. Le transfert des données s’effectue en clair, ce qui au niveau confidentialité reste assez limite. Il est possible d’utiliser SSH pour chiffrer les échanges, au détriment de la vitesse. Pendant la durée du transfert, aucune indication ne sera disponible concernant l’avancement du transfert ; il est possible d’envoyer un signal de type USR1 à dd pour connaitre l’état d’avancement. La commande pv peut aussi être intercalée à n’importe quel endroit du tube pour connaitre l’état d’avancement.

Pour aller plus loin

Il existe bien sûr d’autres méthodes pour arriver au même résultat. Cette méthode à l’avantage de ne pas trop stresser un disque en fin de vie, puisque les accès sont séquentiels et non aléatoire. Dans d’autres circonstances, il aurait été possible d’utiliser la commande rsync pour synchroniser les données sur deux serveurs différents, ou alors de créer une archive Tar à l’aide de la commande tar et la transférer directement par le réseau à l’aide de nc ou ssh.

Je ne comprends pas, vos serveurs sont censés être sécurisés !

Laisser une réponse
Une barrière de sécurité très utile !

Une barrière de sécurité très utile !

– Bonjour, je ne suis pas très content ! Mon site web a été piraté, alors que vous dites que vos serveurs sont sécurisés ! C’est inadmissible !

Voici une entrée en matière assez courante, en matière de site web piraté, lors d’un appel auprès du support.

De nombreux clients se reposent sur le fait que les serveurs soient sécurisés, sans pour autant se soucier de ce que signifie « cette sécurité du serveur ».

La plupart des hébergeurs compétents disposent sur leurs serveurs d’hébergement mutualisé ou infogérés d’une architecture qui a été élaborée pour être sécurisée. C’est-à-dire qu’elle est pensée pour éviter qu’une attaque ne puisse avoir de conséquences sur le serveur en lui-même (vol d’informations du serveur, de mots de passe, …) et que celle-ci ne puisse avoir de conséquence sur les éventuels autres utilisateurs (ralentissement du service, accès aux données d’un autre client, …).

La plupart des sites piratés (détournement de trafics, modification de contenu, utilisation à des fins de spams, …) le sont par l’intermédiaire d’une faille de sécurités sur le site web d’un client : il est souvent plus simple d’exploiter une faille laissée ouverte sur un site que de s’attaquer au serveur directement, dont l’architecture est un minimum pensée pour être sécurisée.

L’utilisation de systèmes de gestions de contenus connus (WordPress, Joomla, Drupal, …) rends également le travail des pirates plus simple. En effet, bon nombre de webmasters n’appliquent pas rapidement les correctifs de sécurité, ce qui laisse le champ libre aux pirates pour tenter d’exploiter la faille et faire ce qu’ils veulent de cet espace web. Malgré tous les efforts de l’hébergeur, le dernier maillon de la chaine de sécurité reste le code du site web. Et il ne sert à rien de mettre en place une barrière de sécurité à l’entrée si le mur d’enceinte est inexistant.

Malgré cela, certains hébergeurs commencent à mettre en place des protections, ou des configurations pour éviter l’exploitation de certains failles qui se trouvent sur les CMS les plus courants, voire même à mettre en place des règles spécifiques pour les nouvelles failles découvertes qui sont dévoilées. Ces sécurités, bien que louables, protègeront les sites web tant que celle ci ne seront pas contournées à leur tour : un grand panel de failles sera à disposition de l’attaquant, libre d’exploiter la faille de son choix !