PROJET AUTOBLOG


Zythom

Site original : Zythom
⇐ retour index

Boot sur une image disque

dimanche 20 mars 2016 à 12:26
Je termine une expertise sur laquelle le démarrage de l'ordinateur m'a fait gagner un temps précieux : j'ai pu remarquer pas mal de choses à partir de l'environnement de travail (image de fond d'écran, écran de veille basé sur un diaporama d'images, disposition des icones sur le bureau, etc.). C'est fou ce qu'on peut apprendre de ce genre de petits détails...

Et rien de plus simple à constater qu'en démarrant l'ordinateur. Oui, mais il n'est pas possible de modifier le contenu du disque dur que je dois analyser (afin de permettre à d'éventuelles autres expertises de pouvoir être pratiquées dans les mêmes conditions). Et tout le monde se doute qu'il se passe plein de choses quand on démarre un ordinateur, et que la majorité de ces choses modifient le contenu du disque dur. C'est pour cela qu'il faut toujours travailler sur une copie fidèle du disque dur. Et démarrer l'ordinateur sous la forme d'une machine virtuelle.

J'ai déjà expliqué sur ce blog comment je pratique pour prendre une image bit à bit d'un disque dur (lire par exemple ce billet).

J'ai également expliqué comment je convertissais cette image en machine virtuelle à l'aide d'un logiciel qui s'appelle Live View (lire ce billet). Mais ce logiciel ne semble plus maintenu et je rencontre de plus en plus de difficultés à l'utiliser. Du coup, j'ai souvent utilisé directement les outils en ligne de commande de VirtualBox: il suffit en effet d'une seule ligne de commande pour convertir une image bit à bit en disque exploitable sous VirtualBox:

VBoxManage  convertfromraw  image.dd  image.vdi  --format VDI --variant Fixed

(la dernière option permettant d'avoir un disque de taille fixe, la valeur par défaut de VBoxManage étant un disque de taille dynamique).

Le problème de cette commande est qu'elle est gourmande en temps et en ressources disques, puisqu'elle crée un double de l'image initiale.

Depuis que j'ai migré mon poste de travail personnel de Windows vers la distribution GNU/Linux Mint, j'explore de manière plus systématique les outils de l'univers GNU/Linux.

J'ai ainsi découvert une "vieille" commande disponible sur presque toutes les plateformes: xmount. Cette commande permet de créer un disque VirtualBox directement à partir de l'image bit à bit, sans la modifier, en créant un cache contenant toutes les modifications qui seront apportées sur le disque.

Ma procédure est maintenant la suivante:
mkdir toto
xmount  --out  vdi  --cache  image.cache  image.dd  ./toto

Je trouve ensuite dans le répertoire "toto" le fichier disque que j'utilise dans la machine virtuelle que je crée ensuite dans VirtualBox.

Si je ne connais pas les mots de passe Windows, je démarre la machine virtuelle avec le live cd ophcrack ou avec offline NT password. Si j'ai un écran bleu de la mort (parce que Windows n'aime pas démarrer sur du matériel différent de celui sur lequel il a été installé), j'utilise OpenGates qui fait office de baguette magique (sous Windows).

Je pose ça ici, si cela peut aider quelqu'un à booter sur une image disque. Il y a beaucoup d'autres méthodes et outils, mais ce sont ceux que j'utilise en ce moment.

PS: Je dois être l'un des derniers à utiliser "toto" dans mes exemples informatiques, mais les étudiants en rigolent encore, alors bon :-)

Source : http://zythom.blogspot.com/feeds/8279064101599187589/comments/default


Tout sauvegarder

vendredi 18 mars 2016 à 14:27
Le sujet des sauvegardes devrait être une source de réflexion permanente, et bien sûr, le reflet de sa propre organisation.

Voici une petite anecdote qui évitera peut-être à quelques un(e)s d'entre vous de subir le même désagrément que moi. Un retour d'expérience négative reste un retour d'expérience...

Je suis l'heureux propriétaire d'un stockage réseau qui permet à tous les membres de ma tribu de mettre leurs données à l'abri des pertes de données intempestives. Le terme savant informatique est NAS, pour Network Attached Storage. C'est un boîtier contenant un ou plusieurs disques durs, relié au réseau familial, allumé 24/7, et accessible en partage avec des droits d'accès individuels et collectifs.

Nous stockons sur ce NAS les photos, musiques et vidéos familiales, mais aussi les sauvegardes de nos postes de travail. Il est constitué d'un boîtier contenant deux disques de 3 To montés en miroir (RAID1) permettant de fonctionner sans perte de données, même si l'un des deux disques tombe en panne.

Un troisième disque dur de 3 To est branché en externe sur la prise USB3 et assure la sauvegarde quotidienne de ce boîtier NAS par réplication. Ce troisième disque tourne tous les six mois avec un quatrième, ce qui me permet d'avoir une copie complète des données, mais hors ligne cette fois.

Mon organisation des données familiales est donc la suivante : les données importantes sont sur le NAS, sur sa sauvegarde quotidienne et sur un disque hors ligne, les données non confidentielles sont sur mon compte Google Drive (à capacité illimitée), synchronisées à la fois sur mon ordinateur personnel et sur mon ordinateur professionnel, et les données "superflues", c'est-à-dire facilement récupérables sont sur mes disques locaux, avec une synchronisation automatique vers le NAS. Tous les ordinateurs de la maison utilisent peu ou prou ce même schéma.

Pour les machines sous Windows, j'utilise le logiciel SyncBack vers le NAS
Pour les machines sous iOS, j'utilise iCloud et iTunes.
Pour les machines sous Android, j'utilise le cloud de Google.
Pour les machines sous GNU/Linux (Raspbian et Mint), j'utilise la commande rsync vers le NAS.

A un moment, je me suis rendu compte que ma zone de sauvegarde personnelle (située sur le NAS) contenait tout un tas de données "obsolètes" car déplacées ou supprimées de mon ordinateur personnel. J'ai donc ajouté l'option "del" à la commande rsync pour garder une copie propre et fidèle des données de mon ordinateur. Cette commande est exécutée à chaque démarrage de mon poste.

J'ai fait plusieurs tests et tout était OK.

Jusqu'à la panne de ce lundi...

Lundi soir, alors que je lisais tranquillement mes flux RSS tout en écoutant la bande son du film d'animation "Métal Hurlant" (si si), j’entends tout à coup un drôle de bruit en provenance de ma tour : cloc, cloc, cloc... L'un des disques durs venait de me lâcher...

J'arrête proprement mon ordinateur, le laisse refroidir un peu, puis le redémarre. Le disque dur, définitivement en panne, refuse d'être monté par le système d'exploitation. Je viens de gagner un nouveau presse-papier design...

Heureusement, j'ai sur le NAS une copie synchronisée de mes données. Je lui jette un coup d’œil pour m'assurer qu'aucun voyant rouge ne vient gâcher définitivement ma soirée. Ouf, tout est en ordre.

Sauf que.

Sauf que je le trouve bien agité pour un NAS qui n'a rien à faire ! Je vérifie les fichiers journaux de mon script de synchronisation : ma super commande rsync était en train de synchroniser l'absence de données (le disque en panne) avec le vieux NAS, et donc elle EFFAÇAIT toutes les données du NAS (logique). Magie de l'option "del"...

J'ai donc stoppé la synchronisation immédiatement et regardé les dégâts : une centaine de fichiers effacés par la synchronisation destructive... Heureusement, toutes ces données sont "superflues" et donc leur perte m'importe peu.

Mais j'étais vexé comme un pou sur la tête d'un chauve...

J'ai bien entendu aussitôt révisé ma stratégie de synchronisation en retirant l'option "del" de la commande rsync.

Puis je me suis posé la question de la pertinence de mon schéma de sauvegarde familial, surtout en cas d'attaque d'un cryptovirus : si l'un d'entre nous ouvre une pièce jointe contaminée qui va chiffrer rapidement tous les fichiers auxquels les droits informatiques lui donnent accès en écriture, quelle solution mes sauvegardes apportent-elles ?

Toutes les zones accessibles en écriture sur le NAS seront chiffrées. Chacun ayant un compte séparé, seules une partie des données seront atteintes. Mais si personne ne me prévient, la sauvegarde par réplication écrasera la copie saine des données dès la nuit suivante. Il ne me restera en clair que les données de mon 4e disque dur (celui mis hors ligne pour six mois). Avec le risque de perdre jusqu'à six mois de données !

J'ai décidé de revoir tout cela en profondeur et d'équiper la maison d'un système de sauvegarde dédié: j'ai fait l'achat d'un NAS spécialement dédié à la sauvegarde. J'ai choisi de suivre les recommandation d'un geek passionné qui tient un blog et recommande l'achat d'un NAS quatre baies de qualité professionnelle pour 219 euros chez Amazon (sans les disques) !


Objectif : installation d'Openmediavault ET de BackupPC sur la même machine, avec mise en place d'une stratégie de sauvegarde incrémentale.

J'attends avec impatience la livraison, et je vous tiens au courant ;-)
A suivre...

Source : http://zythom.blogspot.com/feeds/6540711978201122472/comments/default


Mais putain y va bouger son gros cul ce con

vendredi 11 mars 2016 à 15:16
Quand j'ai vu que la HADOPI continuait son travail de traque au profit des ayants-trop-de-droits,

Quand j'ai vu que la France refusait d'accueillir Édouard Snowden et de le protéger,

Quand j'ai vu la frayeur de nos dirigeants devant l'arrivée des réfugiés irakiens, libyens ou syriens, poussés par des guerres auxquelles nous avons largement contribué,

Quand j'ai vu le budget de la justice rester anémique,

Quand j'ai vu le cumul des mandats perdurer, y compris chez les ministres,

Quand j'ai vu les seuls médias indépendants poursuivis par le fisc,

Quand j'ai vu des lois de plus en plus liberticides être votées, un état d'urgence permanent se mettre en place,

Je me suis recroquevillé sur moi-même, incrédule.

Moi qui rêvais d'une France accueillante, montrant l'exemple, où le partage non marchand de la culture ferait la joie des cours de récréation, où les lanceurs d'alertes pourraient trouver refuge, où les réfugiés pourraient créer de la richesse et de l'emploi, où la justice pourrait faire son travail, où les cumulards seraient montrés du doigt, où la Liberté serait défendue avec des décisions politiques historiques ("A la terreur, nous répondrons par plus de démocratie")...

Je me suis dit, devant mon écran d'ordinateur, du fond de ma petite vie pénarde : MAIS PUTAIN Y VA BOUGER SON GROS CUL CE CON !

Je ne sais plus si je pensais à moi-même, au Président de la République, au Premier Ministre, ou au contraire au caporal encore sournoisement caché dans une caserne. 

Je suis désespéré par ce ratage historique.
Que vais-je dire à mes enfants ?

Source : http://zythom.blogspot.com/feeds/2631248603109265399/comments/default


La logique de l'autre

mercredi 9 mars 2016 à 13:27
Quand j'ai reçu cette mission du magistrat, elle m'a semblé classique, presque banale : je dois vérifier la présence (ou pas) d'un ensemble de données commerciales qui intéressent les enquêteurs.

Je reçois quelques jours plus tard le scellé judiciaire : un bel ordinateur fixe emballé dans du papier kraft d'un autre siècle. Je prends des photos, je brise le scellé, je prends des photos, je prends des notes, j'ouvre l'ordinateur, je prends des photos de ses entrailles : il y a plusieurs disques durs de grosses capacités. Aïe.

Trois disques durs de 3 To*.
Je commande rapidement quatre disques de 4 To que j'agrège en RAID0 sur un FreeNAS créé pour l'occasion. Mon bureau ressemble à un capharnaüm de câbles, de PC ouverts, de disques durs en vrac... Plus que tout, je crains une panne matérielle impromptu sur les disques du scellé. J'installe un grand ventilateur et je me dépêche de faire une copie bit à bit de chaque disque.

Je commence mon analyse en bootant une machine virtuelle sur une copie du disque système du scellé. Première étape : comprendre la logique de rangement de l'utilisateur de l'ordinateur. Où se trouvent les données non effacées, y a-t-il un système de chiffrement, quels sont les logiciels utilisés, quels sont les différents mots de passe, etc. Je lance quelques logiciels de recherche basiques pour voir si les données que l'on me demande sont présentes en clair sur l'un des disques durs. Rien.

Je travaille sur le dossier tous les soirs (je suis salarié d'une école d'ingénieurs, j'y travaille de 8h à 19h du lundi au vendredi, je ne peux consacrer du temps à cette analyse que les soirs après 21h et les week-ends). Entre le montage du FreeNAS, les copies des disques durs et les premières analyses des données, il s'est déjà écoulé trois semaines. Le magistrat m'a demandé de rendre mon rapport en deux mois. Je suis encore dans les temps.

Je commence une analyse plus en profondeur des données, avec le logiciel TSK (The Sleuth Kit) et son interface graphique Autopsy. Quelques jours de calculs plus tard, je trouve des traces de fichiers qui concernent le dossier.

Par contre, ces traces sont "bizarres". Les fichiers ne sont pas détectés sur un système de fichiers Windows (alors que l'ordinateur que l'on m'a amené fonctionne sous Windows), mais sous un système GNU/Linux...

C'est curieux.
Je regarde de plus près la zone du disque où j'ai repéré ces traces. Il s'agit d'un gros fichier "vdi". C'est un type de fichier qui, par convention, est utilisé par VirtualBox. Je vérifie : oui, ce logiciel est bien installé sur le scellé.

VirtualBox est un logiciel bien connu, qui permet de gérer et faire fonctionner des machines virtuelles sur un ordinateur. Je l'utilise couramment, surtout depuis que j'ai abandonné Windows 10 pour Mint (j'ai toujours un Windows 7 "sécurisé" que je fais tourner en machine virtuelle pour certains logiciels dont j'ai encore l'usage...).

Mon utilisateur est donc adepte de VirtualBox. Je fais la liste des machines virtuelles présentes sur le scellé (enfin sur les copies des disques, ça fait longtemps que j'ai remonté le scellé et qu'il est rangé, ainsi que mon gros ventilateur), ainsi que la liste des fichiers "vdi" et assimilés.

Il y a plein de fichiers "vdi", tous avec des noms plus ou moins farfelus...

Je récupère les informations des différentes machines virtuelles pour comprendre comment les disques virtuels sont organisés, quelle machine utilise quel(s) disque(s), et quels sont les différents systèmes d'exploitations installés.

Puis, je transfère toutes ces machines virtuelles pour les démarrer une par une sur un ordinateur fraîchement installé pour cela (avec la même version de VirtualBox que celle du scellé).

Et là, je tombe une configuration un peu surprenante : une machine virtuelle avec trois disques durs virtuels, qui, quand on la démarre, affiche une invite "openmediavault login"... OpenMediaVault est un projet open source de gestion de NAS.

Je teste les différents mots de passe récupérés sur l'hôte Windows, pour me connecter sur l'interface web, et je découvre un volume de stockage réparti en RAID1 sur deux fichiers virtuels, eux-même repartis sur deux des trois disques durs physiques. Le tout est accessible "à tout le monde" en mode SMB/CIFS depuis l'hôte Windows...

Évidemment, les données intéressantes étaient stockées à cet endroit là.

Donc je résume : l'utilisateur du scellé sur lequel est installé Windows, a installé un NAS virtuel qui propose du stockage local accessible à tous localement sans mot de passe.

Je n'ai pas compris la logique du truc. Quel est l'intérêt d'utiliser un NAS OpenMediaVault virtuel local pour stocker des données ? Quel est l'intérêt de proposer ensuite un accès "pour tous" à ces données, même localement ? Quel est l'intérêt de monter un RAID1 virtuel Debian sur deux fichiers gérés par Windows ?

J'ai eu beau tourner le problème dans ma tête, je n'ai pas compris la logique de l'autre. Parfois, il vaut mieux ne pas savoir...

J'ai évalué à 200h le temps passé sur ce dossier. Je n'en ai facturé que 30... Et je n'ai pas fait payer le matériel acheté (essentiellement les disques durs, que j'utilise maintenant dans mon système de sauvegarde/stockage). Par contre, j'ai beaucoup galéré pour la rédaction du rapport. Pour rester le plus clair possible, j'ai repoussé mes investigations techniques (et les explications associées) en annexe.

Pas sur qu'elles aient été lues par grand monde ;-)


------------------------------------------
* : le dossier étant ancien, j'ai "actualisé" les valeurs citées, en particulier les capacités des disques.

Source : http://zythom.blogspot.com/feeds/2079872695085245414/comments/default


Les russes attaquent

vendredi 4 mars 2016 à 13:41
Un billet rapide du vendredi pour vous narrer la petite mésaventure qui nous est arrivée ce matin.

J'ai reçu cette nuit des emails d'alerte de notre serveur de supervision open source Centreon, et de ma sonde Pingdom, m'indiquant que notre serveur web institutionnel montrait des signes de fatigue, avec des temps de réponse très long.

Dès potron-minet (je travaille dans une école, pas dans une banque), je fais le point avec mon équipe pour savoir ce qu'il se passe. Dans un premier temps, nous pensons que notre hébergeur Gandi est en cause, car il semble être sous le coup d'une attaque DDoS, ce qui expliquerait notre difficulté à nous connecter à notre serveur.

Puis, nous mettons le nez dans les logs, pour voir immédiatement qu'une attaque était en cours sur NOTRE machine : quelqu'un s'intéressait drôlement au fichier xmlrpc.php de notre serveur WordPress... Avec plus d'une requête par seconde via ce fichier, notre serveur était au bord de l'effondrement. Nous faisions l'objet d'une attaque DoS basique.

Une seule adresse IP est à l'origine de cette attaque, et semble être basée en Russie. Nous l'isolons rapidement avec une commande "route add -host addrIP reject"

Le serveur retrouve sa vigueur de jeune homme, et notre Social Network Manager le sourire, à moins que ce ne soit l'inverse, bref...

Petit débriefing post attaque. Premier point, y a-t-il eu des dégâts ? Nous vérifions les pages, les accès, les dates de modification des pages, l'état de la base de données, etc. Deuxième point, comment faire pour que cela ne se reproduise pas ? Il faut automatiser la détection et la réaction appropriée. Cela tombe bien, nous avons déjà mis en place le logiciel Fail2Ban, dont c'est la fonction, et qui s'en sort très bien.

Il nous suffit donc de suivre les conseils de cette page pour ajouter le script qui va bien.

Mon technicien (qui a fait tout le boulot) et moi, nous nous regardons avec le sentiment d'avoir été les gardiens civils du Mur (nous n'avons pas prêté le serment de la Garde de Nuit). Le reste de l'école vaque à ses occupations, inconscient du drame qui se jouait sous leurs yeux.

Je peux retourner à mes dossiers d'investissements, je dois réussir à montrer l'importance du remplacement de nos "vieux" SAN. Et c'est vraiment différent de la lutte contre les scripts kiddies.

Jusqu'au jour où...


Source : http://zythom.blogspot.com/feeds/7350135579026861395/comments/default