sécurité
L’hébergement geek^Wcheap, ou : « le cloud m’a tuer »
Petit retour d’expérience sur un hébergeur français réputé sérieux, dont les slogans sont « L’hébergement geek » ou bien encore « no bullshit ». Il y a quelques jours, mon serveur crashe sans raison. En vérifiant sur leur blog, il s’agit (je cite) d’un « déclenchement involontaire d’une maintenance sur nos équipements de stockage » (traduire : une erreur humaine, de type oups-j-ai-shooté-dans-la-prise). Bon, c’est ballot, mais ça peut arriver. Le problème, c’est que le disque système du serveur n’est pas reparti, et un fsck du disque, monté depuis un autre serveur, ne présage rien de bon… deuxième tentative de boot après un gros check + des tas d’erreurs : c’est officiel, le disque système est défoncé, il manque la moitié des données, bref le serveur est HS.
Mais heureusement ! Je suis prévoyant, je n’ai pas pris un serveur cheap avec un simple disque SATA grand public chez xVH ou xEDIBOX ! Non môssieur, je suis moderne, je prends un hébergement de geek (c’est écrit dans la pub), c’est-à-dire du clahoude comptioutingue avec un serveur dans les nuaaaages, avec des disques stockés sur des SAN redondés (du bête RAID en fait), et avec des sauvegardes automatiques (c’est dans la pub ça aussi) ! Ca fait rêver, ça donne carrément confiance, on y va les yeux fermés.
Bilan de l’échange rigolo avec le support :
technicien : « bon bah euh… oui… le disque semble HS… alors le mieux c’est de remonter le disque sur un autre serveur pour récupérer les quelques (rares) données qui sont encore exploitables, et de réinstaller le serveur… mais du coup vous ne repartez pas de zéro ! ».
moi : « oui mais non. Déjà moi je n’ai rien demandé, c’est vous qui avez fait une erreur, je ne veux pas passer du temps à réparer pour une erreur humaine de votre part. Et puis tant pis : restaurez un backup, même vieux d’une semaine, je m’en fiche ce n’est pas grave du moment que ça repart rapidement » (note: c’est un serveur Nagios)
technicien : « … »
moi : « allo ? … Le backup, disais-je donc. »
technicien : « euh mais non, on n’a pas de backups nous… en fait… »
moi : »ben si siii, c’est écrit que le stockage est redondé sur votre site ! Donc ben voilà, reprenez un backup de l’autre SAN, et zouh c’est reparti »
technicien : « oui voilà, on a de la redondance : c’est du RAID10″
moi : « ah… mais c’est pas du stockage redondé ça. Hmm… Bon bref, ben y’a les backups automatiques sinon ! C’est écrit sur votre site ! C’est un argument choc ça, j’aime bien le principe ! »
technicien : « oui voilà, mais vous ne les avez pas programmés »
moi : « comment ça ? … c’est le principe, en fait : si c’est automatique, y’a rien à faire. Ca se fait tout seul, ça fait un snapshot ou quelque chose du genre j’imagine. C’est automatique quoi, d’où le nom. Si y’a besoin que je programme un truc, ça s’appelle manuel. Et sur votre site, c’est bien écrit backup automatique, donc… c’est automatique. Non ? »
technicien : « ….. non… en fait, non… »
moi : « ok ok. Donc pas de stockage redondant, et pas de backups automatiques, quoi. Il faudra fouetter le stagiaire, il a écrit n’importe quoi sur votre site. Bon et vous proposez quoi concrètement, alors ? »
technicien : « le plus simple, c’est vraiment de réinstaller »
moi : « je n’ai absolument pas le temps, mais j’ai bien compris que je n’avais pas vraiment le choix du coup. Et donc pour mes données ? … Hmm non, je retire ma question. Merci monsieur, j’ai vraiment bien fait de venir chez vous, à bientôt :-) »
technicien : « voilà, bonne fin de journée ! »
Merci Gandi, c’est super ce que vous faites, j’adore :-) Et sinon chez Nuxit, y’a des backups systèmes automatiques (des vrais), de base, sur tous les serveurs dédiés. Plus des sauvegardes automatiques-à-la-Gandi (donc : à programmer) sur un FTP externe, comme chez tous les autres hébergeurs. Voilà, c’était juste pour info, au cas où vous chercheriez un vrai hébergeur…
OWASP Appsec Tutorial Series
OWASP (Open Web Application Security Project) vient de lancer une nouvelle série de petites vidéos (5 à 10 min) de présentation des grandes notions de sécurité. Pour l’instant il n’y a que « Injection Attacks » (SQLi) et « Cross Site Scripting » (XSS), mais d’autres vont suivre. C’est bien fait, c’est clair (mais en anglais), c’est vivant, et sur un fond de samba. Donc à suivre de près :-)
C’est par ici : OWASP Appsec Tutorial Series
OWASP Appsec Tutorial Series
Trouver, exploiter et corriger des failles de sécurité dans un site web
XSS, XSRF, XSSI, path traversal, code execution, SQL injection, etc… : des noms barbares qui désignent des types de failles de sécu. Si vous ne connaissez pas, ou pas bien, la question et que ça vous interpelle, Google met à disposition Gruyere (anciennement Jarlsberg). Comme son nom l’indique :-), il s’agit d’une appli web pleine de trous (de sécurité), et vous apprenez au fil des exercices à repérer et exploiter un certain nombre de failles, puis ensuite comment s’en protéger. C’est plutôt très bien fait, assez bien expliqué. Si le sujet vous intéresse et que vous n’êtes pas allergique à l’anglais, je vous le recommande vivement ! A noter également : quelques cours intéressants sur la programmation web (Google Code University), qui peuvent aider, en particulier les deux vidéos de présentation de Javascript.
Update (31/03/2011) : Je viens de tomber sur Web Security Dojo, il s’agit d’une machine virtuelle (VirtualBox ou VMware, au choix) qui contient un paquet d’outils de sécurité web (dont Gruyere) :
- OWASP’s WebGoat
- Google Gruyere
- DVWA (Damn Vulnerable Web App)
- Hacme Casino
- OWASP InsecureWebApp
- w3af
- et d’autres sites fournis par Maven Security
Et les outils classique de tout bon pentester : metasploit, burp suite, dirbuster, etc…
Update (11/05/2011) : Une liste assez complète de sites et d’outils pour « s’entrainer » : Pentesting Vulnerable Study Frameworks Complete List
MooseFS : filesystem distribué redondant
GlusterFS, Lustre : peut être avez-vous déjà essayé ces systèmes de fichiers distribués. Mais il existe une alternative très intéressante, et encore peu connu : MooseFS. Il s’agit d’un système de fichiers distribué et redondant, c’est-à-dire résistant aux pannes d’un ou plusieurs noeuds de stockage. Il est disponible en open source, développé par la société polonaise Gemius, et dispo pour Linux, FreeBSD, OpenSolaris (ce qu’il en reste) et MacOS X. La version 1.6.20 est disponible depuis le 17/01/2011 : les développeurs sont réactifs et suivent de très près la liste de diffusion et les remontés de bugs de leurs utilisateurs.
Le principe est simple (et très Google-like) : des machines de stockage low-cost, et une duplication des données sur ces différents noeuds. Pas besoin de SAN très onéreux ou de systèmes ultra complexes : des petits serveurs bon marché avec de gros disques font parfaitement l’affaire, même pas besoin de RAID hardware, MooseFS est résistant. Les fichiers sont découpés en morceaux (appelés chunks) puis répartis sur les différents chunkservers (noeuds de stockage) : selon le paramétrage voulu pour ces fichiers, ou pour le répertoire dans lequel ils se trouvent, chaque chunk sera répliqué sur x noeuds (différents). Ainsi, la perte de l’un des noeuds sera totalement transparente pour l’utilisateur, et sans aucune perte de données !
J’ai un « petit » cluster de 12 serveurs de 4 To chacun, soit un volume brut de 48 To, qui tourne depuis plusieurs mois sans jamais avoir eu le moindre problème. Ce cluster a pourtant tout testé : le crash électrique dans la baie, le crash de plusieurs serveurs de stockage successifs, des fichiers effacés par une erreur humaine (et récupérés proprement car MooseFS gère une trash). Pas le moindre octet perdu, et les perfs sont relativement correctes. Bref, un filesystem très intéressant, qui mérite vraiment d’être plus connu, et merveilleux pour du stockage lourd où la sécurité des données est critique. La liste de diffusion compte plusieurs déçus de GlusterFS, qui revivent depuis :-), et un cluster de plusieurs péta-octets est même en cours de mise en service par une société américaine. A suivre…
Update (15/04/2011) : Dans le dernier numéro de GNU Linux Magazine France (n°137, avril 2011), vous trouverez un long article sur MooseFS.
Backups distants sécurisés
Faire des backups, c’est primordial. Sécuriser le stockage de ses backups l’est autant :
- sur la même machine : si le disque dur crash, on perd les données et les backups… bien joué…
- sur un des nombreux sites web dédié au stockage en ligne : pourquoi pas, mais c’est cher, et il faut avoir confiance dans la société qui gère vos données.
- sur un serveur distant qui vous appartient : ouaip, mais encore faut-il avoir un autre serveur (ou un serveur dédié virtuel pas cher !)
- sur un serveur distant qui ne vous appartient pas : un collègue qui vous prête généreusement un bout de disque. Encore une fois, il faut avoir confiance en lui, vous lui confiez (l’accès à) vos données.
Bref, il n’y a pas vraiment de solution idéale : Vos données devront être stockées ailleurs, sur une machine où vous ne serez probablement pas le seul à avoir accès, et là il faut avoir confiance ! Ou pas…
Voici une solution simple : En prenant un serveur dédié virtuel (voir précédent billet) à pas cher :-), vous disposez de quelques dizaines de Go de sauvegarde pour une poignée de centimes d’euros par mois. En général, ce sera sur un serveur OpenVZ aux USA, géré par on ne sait qui, sécurisé on ne sait comment. Vous pouvez alors utiliser openssl pour chiffrer vos données à l’aide d’un algorithme de chiffrement symétrique sur les jolis .tar.gz que vous générez (par exemple), puis les envoyer en scp vers ce VDS de backup. Dans les grandes lignes, voici la marche à suivre :
1) Générer un mot de passe sûr (secure), fiable et que vous pouvez retenir facilement, ou stocker en lui sûr. Si vous êtes en manque d’inspiration, on peut par exemple faire ceci :
$ cat /dev/urandom | tr -cd '[:graph:]' | head -c 20 > mon_pass$ cat mon_pass; echoV+7*Vde|th"h[=fUXc"=$
ATTENTION : Conservez le fichier mon_pass bien au chaud, évidemment, sinon vos données ne seront pas récupérables le jour où vous en aurez besoin !
2) Générer vos fichiers de sauvegarde (disons un bon gros .tar.gz de derrière les fagots)
3) Encodage du fichier en AES-256-ECB, avec votre password :
openssl enc -aes-256-ecb -in mon_backup.tar.gz -out mon_backup.tar.gz.secure -kfile mon_pass
Le fichier mon_backup.tar.gz.secure contient la version chiffrée de vos backups, que vous pouvez maintenant laisser trainer n’importe où :-)
4) Copie du backup sécurisé vers le serveur pas/peu secure
5) En cas de catastrophe, pour décoder votre fichier de backup et en récupérer le contenu (à l’aide de votre fichier de password, que vous aurez eu l’intelligence de bien sauvegarder au chaud) :
openssl enc -d -aes-256-ecb -in mon_backup.tar.gz.secure -out mon_backup.tar.gz -kfile mon_pass
Et hop !
Sinon, deuxième possibilité, dans le même esprit : Utiliser Duplicity avec GnuPG.