Go to Top

Hack serveur et effacement total des données

Comment retrouver ses marques à coup sûr dans ce cas là ?

Dernièrement quelques revendeurs du plus gros hébergeur français ( OVH pour ne pas le citer ) ont eu leurs (ou une partie) serveurs hackés par un tiers et les données ont été complètement effacées par ré-installation complète du système (éventuellement plusieurs fois, histoire d’être bien sûr). Comment savoir que votre système de backup vous évitera le chapter eleven ?

Déjà le backup doit existé !!! Pour toutes vos données, à la limite seulement celles impossible à reconstruire, le service de backup doit mettre en place une copie intégrale periodique puis une copie incrémentale ou différentielle pour alléger un peu pendant quelques jours suivants avant de revenir à une archive totale et complète.

Pour mémoire, une système de backup incrémental journalier sauvegarde toute vos données  le premier jour et les données qui ont changées depuis le dernier backup de la veille chaque jour suivant. Chaque incrément est ainsi relativement léger. La reconstruction des données est un peu plus longue, il faut restaurer les données de la première archive complète puis appliquer toutes les archives suivantes.
Un backup différentiel à l’instar du backup incrémental sauvegarde toute vos données le premier jour puis chaque jour sauvegarde tout ce qui a changé depuis le backup complet initial. Chaque incrément est donc plus lourd, mais il suffit de deux passes maximum pour réstaurer le tout : l’initial et un incrément. Généralement, un archive totale ou chaine de backup est refaite toutes les semaines ou tous les mois, plus la période est longue, plus la restauration risque d’être compliquée avec un backup incrémental.

Partant du principe que vous avez donc mis en place un beau backup incrémental de rotation hebdomadaire, la première qualité d’une procédure de sauvegarde n’est pas de sauvegarder mais : savoir restaurer. Testez au moins une fois de temps en temps si vous le pouvez ou au pire la toute première fois avant la mise en production de l’ensemble de vos services.

Bien que la sécurité des salles machines soit généralement excellente, un backup sur le même lieu physique que vos serveurs de production ne vous garantit pas de grand chose en cas d’indisponibilité du site pour des raisons benignes passagères ou graves et définitives. Pensez à déplacer vos sauvegardes sur un serveur dans un site géographique distinct. Et si vous avez la possibilité de vous en assurer, essayer de vérifier que la ‘route internet’ qui mène à ces machines est différente de la production.

Donc on résume, vous avez un backup, vous savez le restaurer, vous pouvez y accéder si le site de votre serveur explose, quoi d’autre : la malveillance ?

De nombreux hébergeurs proposent un espace de backup accessible depuis votre serveur dédié, généralement cet espace n’est disponible que depuis le serveur loué, cela permet de garantir à l’hébergeur que vous n’utiliserez pas cela pour du stockage public, et le niveau de sécurité est accru car il faut être déjà connecté au serveur pour y accéder, une double authentification en quelque sorte. En fait, c’est un leurre, car si votre serveur est compromis, qu’un intru est en train d’y faire le grand ménage de printemps comme dans le cas cité au début de cet article, alors il est fort probable que le mot de passe de ce compte ftp sera lisible en clair dans un quelconque script facilement detectable en scrutant les crontabs.
La solution est simple : c’est le serveur de backup qui doit venir chercher les informations. Il est très simple sur le serveur de production de donner un accès sécurisé ssh à une machine externe, c’est cette machine qui exécute la procédure de sauvegarde et transfert sur son espace l’archive générée.

Vous me direz, mais si la machine de backup est compromise, le problème est le même qu’avec le serveur de production, oui mais… Le serveur de backup est très discret, il n’y a pas de serveur apache qui tourne, pas de serveur ftp, juste une petite porte ssh qu’il est facile de sur-protéger sur une machine quasi privée. Un attaque vers votre installation se fera forcément au départ vers une machine publique. Sauf si le vers est dans le fruit, un tier ne peut pas connaitre vos installations.

Si vous souhaitez aller encore plus loin, Il est possible de ‘caler’ le service Dropbox au milieu de tout cela (voir http://www.nikozen.com/backup-dropbox.html ), les données sont alors également répliquées sur une machine se trouvant dans vos locaux et dans le cloud amazon (via dropbox). Dropbox permet de base de récupérer les fichiers effacés depuis moins de 30 jours, et rien ne vous empeche de procéder à des sauvegardes chez vous, les logiciels disponibles sont nombreux et simples d’accès.

Bon audit de validation chez vous 🙂