Faire un mirroir de backup « blindé » (come on NSA, come on !)

Ouais, bon le titre est peut être un peu présomptueux et pompeux …

ssh

Le Raid, c'est bien, mais c'est pas une sauvegarde !
La sauvegarde c'est bien, mais pas infaillible : le disque dur peut être piqué/tombé HS, votre maison brûle (!) et le pc de la petite soeur aussi avec toutes les sauvegardes qui vont avec …

Reste la sauvegarde à distance : le cloud me direz vous ?
Allez tous sur Drop machin, cloud chose et deux semaines après vous trouver vos photos de chat sur des forums douteux (je sais, suis un poil parano !).

Bon là encore c'est pas top !

Vous comprenez, j'ai pas de chat, mais si jamais j'en avait un, j'aimerais que ses photos soient dans un endroit sûr !
J'ai donc cogité un peu, et mis en place ça :

diagrame sshfsLe principe : sauvegarder ses données, sur un serveur distant se trouvant dans un datacenter.
Par le bias de connexions SSH en passant par un rebond sur une passerelle SSH.

 

Le serveur distant :
 

C'est un serveur, tout ce qu'il y a de plus banale : alimentation redondante, Xeon, ram ECC, carte raid matériel, stockage en raid 5 (sur des partitions cryptées avec LUKS) …
Rien d'extraordinaire en somme !
Il est sous Wheezy, n'est pas accéssible d'Internet, il à son propre firewall (un Iptable + fail2ban), la communication se fait uniquement via SSH et des clés dédiées.

 

La passerelle SSH :

Un serveur virtuel en DMZ, disposant lui aussi d'un couple Iptable + fail2ban, derrière le firewall d'entré de site (pour l'accès extérieur), et un SSH dans un environnement chrooté.

 

Le principe :

Le serveur @ home, ouvre un tunnel SSH à travers la passerelle SSH, pour ouvrir une connexion SSH sur le serveur distant (INCEPTION !!).
Evidemment, avec des clés SSH et des utilisateurs différents à chaque fois
Ce tunnel ouvert, il permet de monter la partition cryptés en en SSHFS.
 

Et derrière il me reste plus qu'à faire un rsync 🙂


Le fonctionnement :

Je ne vais pas rentrer dans l'installation du serveur distant ou de la passerelle SSH, c'est pas le but ici !

Sur votre client (mon serveur @ home), vous aurez besoin de :

apt-get install ssh rsync sshfs fuse-utils

pensez à générer toutes vos clés SSH avec:

ssh-keygen -i rsa

et à les copier entre les serveurs :

ssh-copy-id -i ~/.ssh/id_rsa.pub user@server

 

Le montage :

mkdir /media/montagedistant
sshfs -o ssh_command="ssh -t -A user1@passerellessh ssh -l user2" user2@serveurdistant:/data /media/montagedistant

Si vous voulez faire le montage automatique, il faut passer par fuse.auto

Ou alors vous pouvez attaquer direcement en rsync :

rsync -e "ssh -t -A user1@passerellessh ssh -l user2" -avz --progress /media/montagedistant/ user2@serveurdistant:/data

Dans le cas du montage fuse ça donne :

root@Sheldon:/# mount
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
[...]
fusectl on /sys/fs/fuse/connections type fusectl (rw)
user2@serveurdistant:/data on /media/montagedistant type fuse.sshfs (rw,nosuid,nodev,max_read=65536)

 

En résumé :

– montage d'une partition cryptée en SSHFS
– en passant 2 tunnels SSH avec des clés privés/publiques différentes
– à travers 4 firewall et 3 fail2ban
 

Ce qui peut être amélioré :

– mes connaissances pour faire mieux
– un système anti incendie sur le datacenter (et oui … ^^ )
– un chat de combat pour protéger le serveur distant
– …
 

27 Responses to “Faire un mirroir de backup « blindé » (come on NSA, come on !)”

  1. Guigui Benmaurice dit :

    Bonjour,

    J'ai une installation similaire, qui synchronise mes données toutes les nuits 🙂 Deux choses que j'ai relevé :

    – Tu fait passer la complexité de ton installation SSH dans les commandes rsync et sshfs, mais il est préférable de confier cette complexité au client SSH lui même. Le fichier de configuration est très flexible. Le mot clé ici est ProxyCommand.

    – Si tes clés SSH sont sans passphrase (pour scripter/automatiser ces tâches), tu peux augmenter ta sécurité avec la syntaxe "from="IPDUCLIENT" ssh-rsa …" dans le fichier authorized_keys sur le serveur.

    • Sheldon dit :

      Merci pour ces deux astuces 🙂

       

      Je ne connaissais pas la deuxième (et pas pensé à utiliser la première ><), c'est pas mal du tout, je vais mettre ça en place de ce pas !

  2. Nicolas dit :

    Bonjour,

    Il n'y a pas plus ecologique qu'un serveur distant qui tourne 24h/7j simplement pour des sauvegardes? Et surtout une solution plus simple (pas de multiple firwall et passerelles).

    Ma solution: J'ai entrepose chez mes parents (donc distant) un vieux PC avec deux disques (OS et data). Ce PC (debian minimal) s'allume automatiquement tous les 3 jours. Grace a rsync dans un tunnel ssh (pas de sshfs) il recupere les changements realiser durant les 3 derniers jours sur mon server chez moi.

    Ainsi je n'ai aucune connection qui puisse aller vers le serveur de backup c'est uniquement lui qui creer une connection vers chez moi. Plus de firewall, plus de passerelle. Uniquement mon servere chez moi qui est bien securier. Ce qui est dans tous les cas une nessecitee..

    Nicolas..

    • Sheldon dit :

      Effectivement c'est pas du tout écolo !
      (mais bon dans un datacenter on est plus à ca près !)

      j'avais aussi ce genre de sauvegarde chez mes parents, mais j'ai eu deux "incidents"
      1) ennemi n°1 du geek, la génitrice qui débranche le serveur, pour brancher autre chose à la place …
      2) le serveur était au sous sol, mais parents ont été innondé lors d'un gros orage, le serveur n'était pas waterproof !

      Maintenant que j'ai la chance de bosser dans un endroit avec un vrai datacenter (clim, accès sécurisé par badge, onduleur + groupe …), ça aurait été dommage de ne pas en profiter, non ?

      Et surtout j'ai besoin de pouvoir accèder à d'autres documents (en plus des sauvegardes), la machine doit rester dispo H24.

      Si j'ai appris une chose dans mon métier c'est de ne pas faire confiance à un sysadmin (en l'occurence : moi), ou à une seule protection (un mot de passe, ou une seule clé ssh).
      Pour des données "sensibles" (on parle bien de photos de chats hein !! ^^), plus y a de truc à déjouer ou qui risque de planter, mieux c'est !
       

  3. Vincent dit :

    C’est Come on NSA, Come on!

  4. Maxime dit :

    J'ai un système de sauvegarde a peut près équivalent au tiens Sheldon, à cela près que mon serveur distant n'est malheureusement pas coupé du net.

    Pour sécuriser cela, je n'ai ouvert l'accès ssh au serveur distant que sur une seule IP entrante (avec un fail2ban qui contrôle les tentatives d'accès en plus au cas ou).

    Pour accéder au système de fichier distant, je passe par un montage SSHFS.

    Côté encodage, les données distantes ne sont pas stockées en clair, tout est encodé en local via EncFS qui remappe le montage SSHFS.

    En gros, ca donne :

    sshfs user@srv_distant:/backup /backup_chiffre

    encfs /backup_chiffre /backup_clair

    il ne reste plus qu'a faire un bon vieux rsync entre les données en local et les données contenues dans /backup_clair

    Pour ajouter une deuxième sécurité a mes données les plus importantes, j'effectue mensuellement une externalisation sur un autre lieu physique par rotation sur 2 disques chiffrés par luks.

    La sauvegarde hébergée chez un tier de confiance, j'y est penser aussi.. mais à moins que le tier soit sensibilisé à la problématique, j'ai bien peur que ca soit pas toujours simple à gérer.

    • Sheldon dit :

      Très intéressant comme retour, merci :).

      Je ne connais pas encfs, c’est crypté avec quelle base ? (RSA, AES …)
      Tu n’as pas de soucis de stabilité avec Sshfs ?

      car moi j’ai des déco quand je transfère de plusieurs dizaines de Go de données, chose qui n’arrive pas en rsync !

  5. Maxime dit :

    Dans mon cas, j'ai utilisé le paramétrage par défaut, soit AES sur une clé 256 bits. Il me semble que Blowfish soit également possible.

    Globalement ce chiffrage est souple à l'utilisation, mais n'est pas aussi sécurisé a mon avis que d'utiliser un volume/disque dédié. Mais ça permet un niveau de sécurité supplémentaire en cas d'intrusion/accès physique aux données car à aucun moment l'hôte distant n'a accès aux données en clair. En gros, voila ce que j'en pense  :

    + Données chiffrées facilement déplaçable d'un FS/Repertoire à un autre

    + Accès par un "simple" utilisateur sans permissions particulières

    + Seul le point de montage final permet un accès aux données en clair

    +/- un simple repertoire dédié à EncFS suffit à mettre en place un FS chiffré.

    – Fichier "caché" .encfs.xml à ne SURTOUT pas perdre + informations sur le chiffrage dans .encfs.xml

    – Taille/permissions/pseudo-arborescence des fichiers visible même sans chiffrage.

    Concernant les pb de stabilité avec SSHFS, j'ai eu 4/5 perte du montage lors du transfert initial ( +/- 250Go ) vers mon serveur dédié. Mais je ne saurait dire si cela était lié à des micro-coupure de la liaison avec le serveur ou SSHFS qui gauffrait.

    Maintenant, pour les rsync incrémentaux, je n'ai pas de problèmes particuliers.

     

    Après tu a toujours la solution d'utiliser un montage NFS/WebDAV/… à travers un tunnel OpenVPN.

    Autre possibilitée,

    Tu dédie un espace local à EncFS, et tu ne rsync vers le serveur distant qu'une fois les données chiffrées localement. Comme cela tu t'affranchis de sshfs et/ou des montages divers et variés. Par contre ça impose un espace de stockage des données chiffrées pour gagner du temps lors du prochain backup. Exemple

    # on chiffre les données sur un volume en local

    enfs /mnt/backup_chiffre /mnt/backup_clair

    rsync /data /mnt/backup_clair

    umount /mnt/backup_clair

    # ne reste plus qu'a transférer les données chiffrées

    rsync /mnt/backup_chiffre user@srv_distant:/backup_chiffre

    • Sheldon dit :

      Super réponse !

      Maintenant je comprends mieux le principe de Encfs, j'avais déjà utilisé d'autres technos de ce type; il y a quelques années (mais c'était pour un simple cryptage en local d'un répertoire), à l'époque le gros défaut était la consommation de ressources CPU (une époque où il n'y avait pas d'intruction matériel en AES sur les CPU, qui avait une fréquence en 1 et 1,5 Ghz … c'est peut être mieux aujourd'hui ^^).

       

      J'ai eu les mêmes problèmes que toi en sshfs, d'ailleurs, à l'un des plantages, la copie à continuer de copier en local sur le disque système de mon serveur … il s'est remplis à 100% crash de la moitié des services -_-'

      Afin de ne pas avoir d'accès direct à la machine, je souhaite passer par la passerelle SSH et donc rester sur le port 22, pas sur que je puisse y faire transiter du VPN dans ce cas de figure.
      (la machine serait en accès direct, ça ne poserait pas de soucis).

       

      Ta dernière méthode est celle que j'utilise pour le backup de mes serveurs web et BDDs : je dump, compresse et crypt en local, puis j'upload sur mon espace Hubic (y a pas de photos de chats, donc c'est pas critique ^^).
      Mais dès lors que je serais satisfait à 100% de la nouvelle méthode, je metterais un terme à celle de Hubic, qui à beaucoup de défaut (en plus d'être dans le "cloud").

    • tranxene50 dit :

      Hello ! 🙂

      Je teste en ce moment même l'outil de sauvegarde que j'ai développé (openvz-diff-backups) avec un montage NFS + EncFS vers un serveur distant (SSHFS ne supporte pas les hard links).

      C'est lent mais ça a l'air de fonctionner.

      Si ça marche correctement, cela veut dire qu'il sera possible de sauvegarder (de manière incrémentale) ses containers OpenVZ de manière chiffrée sans jamais avoir les données en clair sur le serveur distant.

      @Maxime : merci pour les infos. 🙂

      A+

  6. Sheldon dit :

    intéressant 🙂
    de mon coté : je cryptais chaque backup avec une clé (et la fonction "crcypt") et j'uplodais en rsync sur un serveur distant :

    ccrypt -e -K clédelamortquituedeuxfois /tmp/backupopenvz

    en sortie j'avais mon backupopenvz.cpt

    bon par contre c'est plus fastidieux, car je devais décrypter chaque backup manuellement (toujours avec "ccrypt") en cas de restauration.

     

    ta méthode, me semble bien plus prometeuse !

    ton montage NFS tu le fais au travers d'un VPN ? (à moins que tu reste en local)

    • tranxene50 dit :

      Plop !

      Le NFS est monté de manière classique sans VPN.

      Par contre, avec encfs, c’est affreusement lent : même rsync qui est d’habitude super efficace n’arrive pas à « optimiser » le trafic (encfs -> NFS -> serveur distant).

      En ce moment je teste sur une petite VM (un DNS cache) mais c’est pas glorieux…

      Je te tiens au jus.

      A+

      • Maxime dit :

        Yop tranx !

        Quand tu rsync, tu le fait bien sur la partie "déchiffrée" du encfs ?

        Tu a le même problème quand tu tente la manip' à la main sur un simple répertoire ? (comprendre "sans snap de LV"). En sshfs aussi ?

        Autrement, je viens de parcourir le man de encfs, et j'ai trouvé une option particulièrment intéressante " –reverse " . Peux-être qu'elle pourra t'aider ? Ca permet de "pousser" directement la vue chiffrée sur l'hote distant, au lieu d'accéder à distance à la vue chiffrée, puis d'y accéder en clair en la remontant en local.

        L'idée serait de faire ton snap/incrémental de container localement ( je suppose que tu ne fait pas que des backup distant en disant cela ), et une fois la sauvegarde local terminée tu exporte la vue chiffrée sur ton serveur distant,

         

               –reverse
                   Normally EncFS provides a plaintext view of data on demand.  Normally it stores enciphered data and displays plaintext data.  With –reverse it takes as source plaintext
                   data and produces enciphered data on-demand.  This can be useful for creating remote encrypted backups, where you do not wish to keep the local files unencrypted.

                   For example, the following would create an encrypted view in /tmp/crypt-view.

                       encfs –reverse /home/me /tmp/crypt-view

                   You could then copy the /tmp/crypt-view directory in order to have a copy of the encrypted data.  You must also keep a copy of the file /home/me/.encfs5 which contains
                   the filesystem information.  Together, the two can be used to reproduce the unencrypted data:

                       ENCFS5_CONFIG=/home/me/.encfs5 encfs /tmp/crypt-view /tmp/plain-view

                   Now /tmp/plain-view contains the same data as /home/me

                   Note that –reverse mode only works with limited configuration options, so many settings may be disabled when used.

         

        • Tranxene50 dit :

          Hello ! 🙂

          Désolé pour délai.

          Bilan des courses : "encfs over NFS" sur une ligne ADSL, c'est totalement impraticable…

          Je vais essayer avec "–reverse" mais à mon avis ce sera pareil.

          A+

          • Sheldon dit :

            Si tu veux te faire mal, tu fais du CIFS over internet-avec-un-ping-de-merde ^^
            tu vas être surpris !

            CIFS est directement impacté par le ping (au boulot on se retrouve avec du 2 mo/s sur un lien giga entre deux sites à cause du ping, alors qu'on a de très bons débits en NFS) :/

  7. Tranxene50 dit :

    Suite ! 🙂

    Alors… Après pas mal de tests, on dirait que : Openvz-diff-backups + "encfs –reverse" + rsync + SSH, ça marche !

    Je passe aux essais "réels" avec toutes les machines virtuelles de ma Nobox (~20 Go de données).

    Prochain numéro d'ici une semaine, quand j'aurais un historique de sauvegardes décent.

    A+

     

     

     

     

     

  8. grao dit :

    Du raid 5 pour de la sauvegarde ?

    Allume des cierges pour éviter les bad blocks au moment de la reconstruction…

    • Sheldon dit :

      Deuxième phrase du post : 

      « Le Raid, c’est bien, mais c’est pas une sauvegarde ! »
       
      Donc non, il faut pas compter dessus pour sauvegarder ses données, mais je ne vois pas de problème  pour y stocker une sauvegarde !
      Tu les stock sur quoi tes sauvegardes, sur des bandes ? ^^
  9. grao dit :

    Si tu as des sauvegardes de sauvegarde ok alors.

  10. tranxene50 dit :

    Hello, c’est encore moi… ^^

    Alors, concernant la réplication de backups chiffrés de containers OpenVZ, le bilan des courses des courses est vraiment pas glorieux.

    Rsync + encfs (en mode normal ou reverse) + [sshfs|nfs|autre], ben c’est pas compliqué : ça marche pas… Non seulement c’est hyper lent mais il y a également des soucis avec les ACLs, les Extended Attributes et parfois la longueur des noms de fichiers.

    Je pensais jeter l’éponge quand, au hasard de mes pérégrination sur la toile, un blog a surgi :

    Incremental backups to untrusted hosts

    Et là, après quelques cafés, ça a fini par faire « tilt » !

    Bref, en ce moment, je teste : crypsetup + sshfs + openvz-diff-backups.

    Ma nobox étant derrière une pauvre ligne ADSL, j’ai mis en pause le transfert pour passer directement sur un serveur dédié « ki-poutre-un-peu » (ça réplique à 600 Mbit/s, ce qui est bien plus fun !).

    Jusqu’à présent, aucune erreur, juste quelques soucis concernant le système de cache/buffer d’un des éléments en jeu. J’arrive pas à savoir qui « bufferise » quoi (Crypysetup, losetup, sshfs, sftp-server, rsync ou un autre).

    Bref, à priori ça va marcher et si c’est bien le cas, cela veut dire qu’avec openvz-diff-backups, il sera possible de faire des backups incrémentaux chiffrés de bout en bout.

    Réponse dans 7 jours : le temps d’avoir environ 500 backups/snapshots et d’évaluer l’utilisation CPU/HDD/BP en rythme de croisière.

    A+

    • Sheldon dit :

      nice job !!
      sshfs est donc une bonne piste, tu as bcp de différences en temps de réplication entre un backup chiffré et un non chiffré ?
      (tu as quoi comme cpu ?)

      bon courage 😉

  11. tranxene50 dit :

    Hello ! 🙂

    Alors, premières news concernant openvz-diff-backups « over » cryptsetup…

    1) ça marche ! (et je suis confiant pour la suite)
    2) la consommation de bande passante augmente.

    Je poursuis les tests : les 500 backups ne sont pas encore atteint donc il me manque le temps moyen pour supprimer les anciennes sauvegardes (pareil pour les tests de restauration).

    Cependant, et contrairement aux tests avec encfs, tout se passe gentiment pour le moment.

    Je te tiens au jus.

    A+

  12. tranxene50 dit :

    Plop ! 🙂

    Comme promis, des news fraiches !

    Pour les tests, j’ai pris un petit serveur dédié avec 350 Go de données à sauvegarder : 17 containers OpenVZ, 4 backups par jour, 7 jours de rétention.

    Soit un total d’environ 500 backups en rythme flottant, plus les « dump » de l’état mémoire de chaque container (sauvegardes à chaud, aucune interruption de service).

    En « sortie », la taille du fichier cryptsetup pour stocker tout ce petit monde est de ~ 620 Go.

    Sachant que chaque container dispose d’un historique de 28 sauvegardes complètes et accessibles de manière indépendante, c’est nickel.

    Côté perfs, RAS, tout est OK mis à part que la consommation de bande passante est multipliée par 2 voire 3 par rapport à un openvz-diff-backups utilisé de manière classique.

    Note : par défaut, openvz-diff-backups « bride » l’upload à 100 mbit/s mais avec le montage sshfs + cryptsetup, il n’est pas possible de maintenir cette restriction.

    Sur un réseau gigabit ce n’est pas (du tout) un problème mais derrière une simple ligne ADSL, cela se sent.

    Bref, je vais laisser tourner encore quelques semaines et ensuite j’attaque le seul point noir repéré pour l’instant : la connexion sshfs doit impérativement être stable sinon, en cas de déconnexion, ça part en sucette (losetup n’est pas résilient) et les backups ne fonctionnent plus.

    A+

  13. kaos dit :

    Si je continue cet article c’est la rupture d’anévrisme direct 🙂

  14. Neo dit :

    Salut Sheldon,

    J’ai suivi ton super tuto mais j’ai une question :

    Si sur mes serveur, pour des questions de sécurité, j’ai modifier le port ssh (par défault : 22) par :
    – 8000 (pour mon parefeu d’entré de site),
    – 8001 (pour la passerelle ssh),
    – 8002 (pour le serveur distant)

    Comment est-ce que je peut mettre en place ton système ?
    Est-ce possible ?

    Merci d’avance.
    Neo

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *