Cloud storage

Les NAS c’est bien, mais ça reste faillible et ce n’est pas extensible à l’infini. Donc on finit par acheter un second NAS pour faire la sauvegarde du premier, ou de nouveaux disques. C'est sans fin. Plutôt que d’entretenir des NAS de prod et des NAS de sauvegarde et continuer à acheter des disques regardons le cloud. Il s’agit de stocker des fichiers exploitables ou des sauvegardes. Mais on verra que l’on peut aussi s’en servir de disque. Je vais vous livrer mes réflexions, dans un cadre DIY adaptable en mode professionnel. Ce sont des notes, donc c’est un peu en vrac et je vous invite à commenter vos expériences.

Les fournisseurs possibles

  • OneDrive Business. Ils peuvent les offrir leurs 5 TO, car ce n’est pas très rapide et surtout le débit est très aléatoire,
  • Même réflexion pour OneDrive, Dropbox ou Google Drive, ce n’est pas vraiment fait pour ça. Amazon Drive était intéressant en illimité, mais c’est terminé. Et ne me parlez pas de Hubic ou je vois rouge !
  • Online c’est coûteux et techniquement et pas adapté (iSCSI par exemple),
  • OVH en OpenStack Swift revient à 10 € / le TO + le trafic sortant au même prix, en espérant que ça ne ressemble pas à Hubic… Ça peut être intéressant car c’est en France si on veut être full RGPD.
  • Azure Storage on n’en parle même pas dans ce cadre car trop coûteux.
  • Amazon S3 est top et plus abordable pour de la sauvegarde, mais ça reste coûteux.
  • C’est Wasabi qui m’a poussé vers le Storage cloud. C’est très abordable. Il n’y a pas de frais de de transfert, c’est donc le plus intéressant. Pour l’instant leurs deux Data center sont aux Etats-Unis, mais l’ouverture d’un site aux Pays Bas les rendra conformes RGPD. Et rien n’empêche un petit chiffrage à la volée… Leur tarification est très simple : 1 TO c’est $ 4.99 / mois, sans frais annexes.

Je fais donc le choix Wasabi, il faut maintenant tester et trouver les bonnes solutions logicielles pour y transférer les différents types de données et les utiliser. Il existe plusieurs usages possibles, de la sauvegarde pure s’un serveur ou d’un NAS, voire d’une sauvegarde secondaire hors site pour des questions de sécurité ou de données qu’il faudra pouvoir exploiter en direct. Pour une reprise après incident il faudra prendre en compte le temps de téléchargement pour rapatrier rapidement un gros volume de données. Ce temps est bien sur étroitement lié à la bande passante disponible sur le site. Donc oubliez ces solutions si vous devez vous contenter d’une ligne internet famélique et que vous avez un gros volume à traiter.

Comme Wasabi est compatible S3 on peut jouer avec tous les outils initialement proposés pour AWS S3, j’en ai testé des douzaines mais je n’en citerais ici que quelques un.

Transfert et exploration de fichiers

  • Naturellement je me suis tourné vers un outil en ligne de commande, RClone, dont tout le monde parle sous plusieurs environnements. Hélas je n’ai jamais réussi à stabiliser cette solution sous Windows. Ça reste un bon outil qu’il ne faut pas perdre de vue, et je n’ai surement pas affiné toutes les options.
  • DragonDisk : Un explorateur gratuit mais lent qui peut dépanner.
  • CyberDuck : Un peu plus rapide mais impose un MD5 lent. Evolutions à évaluer.
  • Filezilla Pro : Compatible S3 c’est une bonne solution qui ne changera pas les habitudes.
  • Bvckup : le must pour de la synchronisation locale n’est pas adapté à ce genre de situation (uniquement SMB et pour l’instant mais des évolutions sont prévues).
  • CloudBerry Explorer : Ça c’est la bonne surprise : 30/70 MB/sec en up sur Wasabi en S3, un peu moins sous OVH en OpenStack, et encore moins sur OneDrive Business mais ça reste le plus rapide. Autant dire que ça change tout car dans tous les cas c’est la solution la plus rapide pour faire du UP, quel que soit la destination !

Sauvegardes

Plusieurs combinaisons existent et si l’on dispose d’un NAS Synology on peut sauvegarder les serveurs et PC avec Active Backup, ou Veeam et ensuite uploader tout ça vers le cloud avec Cloud Sync ou Hyper Backup…

  • Pour sauvegarder directement un PC, un Mac ou un serveur vers du S3 j’ai trouvé ARQ Backup particulièrement efficace et simple. Mais il existe plein solutions comparables.
  • Pour sauvegarder des NAS Synology j’avais testé Synology C2. C’est bien emballé et pas très cher avec historisation, cryptage et déduplication. Si on cherche à restaurer sur un nouveau Synology c’est très bien et on peut restaurer avec une bonne granularité (fichier, ou arbo, ou sous arbo à une date donnée. Sauf qu’en cas de crash on a rarement un second NAS sous la main avec les bons disques et on peut avoir besoin rapidement de certains fichiers. Synology à donc prévu une interface web de restauration qui hélas ne permet que de restaurer individuellement les fichiers, et d’après leur support ils n’ont pas de plans à court terme pour faire mieux. Et ça se comprend, leur recommandation étant d’acheter un nouveau NAS, d’en avoir deux et surtout d’utiliser C2 Disaster Recovery qui permettra de virtualiser le NAS sauvegardé dans leur DC. C’est top mais là on ne joue plus dans la même cour coté tarifs. Mon alternative consiste à sauvegarder vers Wasabi avec HyperBackup. En cas de besoin on peut restaurer avec Hyperbackup et si ce n’est pas possible on peut toujours accéder aux données via un CloudDrive et de lancer HyperBackup Explorer sur PC pour restaurer et décrypter ce que l’on veut depuis Windows, MacOS ou Linux.

Synchronisation

La synchronisation va permettre de disposer sur le cloud de données directement exploitables, contrairement à la sauvegarde qui chiffre et historise les données. C’est un usage différent pour des données bien souvent différentes. Si certaines solutions comme CloudBerry sont utilisables de façon interactive, CloudSync sur Synology est ce que j’ai trouvé de plus efficace pour maintenir un volume de données conséquent synchronisé entre un NAS et S3. CloudSync sait utiliser pratiquement tous les fournisseurs. On peut également s’en servir en mode transfert pour uploader des répertoires que l’on supprimera ensuite, il y a beaucoup d’options possibles.

Utilisation en direct

Au-delà des sauvegardes dont la restauration est ponctuelle et des transferts de fichiers que l’on pourra effectuer avec les logiciels vus plus haut, il peut être intéressant d’accéder directement aux fichiers comme s’il s’agissait d’un simple volume sur le réseau local. Et c’est là qu’interviennent les « cloud drive ». Contrairement aux clients OneDrive, Google drive ou Dropbox, les « cloud drive » ne font pas de synchronisation locale mais rendent disponible directement les fichiers distants.

  • ExpandDrive : des gens du Mac qui font du Windows, joli mais ça déconnecte, la fille du support est très gentille et doit savoir faire du bon café…
  • NetDrive : j’avais acheté et eu des résultats mitigés. La mise à jour coûte le prix de ce que j’avais alors payé.
  • StableBit : je le cite car parfait et très intéressant pour créer un volume sécurisé dans un cloud, mais ça ne correspond pas au besoin.
  • MountainDuck : c’est ce que j’ai trouvé de plus solide en S3 sur Wasabi,  OpenStack Swift, mais aussi en WebDav. En plus on peut facilement partager des liens de fichiers depuis l’explorateur Windows qui seront téléchargeables depuis la source en https sur un temps limité.  La licence est abordable et permissive, elle permet d’utiliser le logiciel sur plusieurs machines des lors que c’est le même utilisateur.
  • CloudBerry Drive S3 : à tester, mais il n’est compatible que S3 ce qui peut être restrictif. Si les performances sont aussi bonnes que CloudBerry Explorer les 79$ de la version serveur peuvent être un bon investissement pour utiliser Veeam sur Wasabi en attendant une solution intégrée.

Je ne conseille pas trop de faire des travaux complexe directement sur les fichiers ainsi accessible. Mais en lecture ou en streaming direct ou via Emby ou Plex c’est parfait.

Débits

J’ai fait quelques tests ponctuels en upload pour me donner une idée (CloudSync, CloudBerry, etc.). En download les débits sont à minima identiques mais bien souvent plus importants.

  • Up Online DC vers Wasabi S3 : 30/90 MB/sec
  • Up Online DC vers OVH OpenStack : 30/40 MB/sec
  • Up Online DC vers OneDrive Business : 3/10 MB/sec (par beau temps) ce n’est pas non plus sur le papier une solution comparable, juste un détournement.

Réflexions

  • SMB 3. On n’y pense pas toujours, mais on peut utiliser SMB 3 via Internet afin de permettre à un PC ou serveur d’accéder à un NAS avec d’excellents résultats entre un NAS (j’ouvre le port 445 sur le NAS et via le firewall je limite la connexion à l’IP de la machine cliente). Ça peut aussi être une bonne solution pour du backup.
  • Cloudberry Labs à des solutions de sauvegarde Cloud qui peuvent être intéressantes car ils savent très bien gérer le débit sur le cloud.
  • Veeam propose une solution packagée nec plus ultra de sauvegardes de VM. OVH est partenaire. C’est très bien, mais rapidement coûteux. (15 € VM à 1 TO max).
  • Veeam (9.5 update 4) sera compatible S3 et OpenStack ce qui va changer la donne…
  • NetBalancer est une découverte intéressante pour voir ce qui se passe sur un serveur exposé. La version freeware est suffisante.

Voilà, vos réflexions et observations sont bienvenues...

Jeedom : SSL avec Cloudflare

Pour sécuriser un site en SSL il y a plusieurs façons de faire, comme je l’avais expliqué ici. Si on passe outre les modèles payants, Let’s Encrypt qui impose l’ouverture du port 80 pour son renouvellement, il nous reste la passerelle OVH qui ne permet pas facilement une sécurisation de bout en bout. On va voir aujourd’hui comment utiliser l'alternative Cloudflare pour sécuriser de bout en bout en utilisant le certificat qu’ils fournissent gratuitement et qui ont la bonne idée d’avoir une durée de vie très longue (auto-renouvellement pendant 15 ans). Ce tuto est fait pour Jeedom sur Debian, mais on peut tout à fait utiliser cette technique sur un autre serveur, IIS sur Windows par exemple.

L’utilisation de Cloudflare sous-entend que le DNS du domaine soit géré par le Cloudflare. Ça peut paraître gênant mais au final c’est pas mal du tout car leurs DNS sont pratique et des plus rapides, notamment en réplication. Quand on va créer un domaine sur Cloudflare, celui-ci va aspirer notre ancienne configuration DNS et en créer une copie. Il n’y aura plus ensuite qu’à se laisser guider pour changer les serveurs de nom sur son registrar (Gandi, OVH, etc…), ce qui peut prendre un peu de temps avant d’être activé.

Une fois le domaine géré par Cloudflare il y a deux onglets qui nous intéressent ici, DNS et Crypto (allez fouiller car il y a plein d’autres choses intéressantes à explorer).

Sur DNS on va créer un enregistrement A (et AAAA si on veut être compatible IPV6) qui va pointer sur l’IP publique de notre serveur (ou un CName vers un DynDNS, je n’ai pas testé mais ça peut marcher, auquel cas ça deviendrait intéressant pour ceux qui n’ont pas d’IP fixe).

Ensuite on passe sur Crypto et on va créer un certificat que l’on prendra soin de récupérer (attention à bien stocker également la clé privée en .key). Voilà, pas besoin de CSR, le certificat est un willcard, ce qu’il veut dire qu’il pourra être utilisé pour d’autres sous-domaines (jeddom.domaine.tld, cam.domaine.tld …). C’est possible car son usage est conditionné par le transit via Cloudflare qui joue un rôle de reverse proxy. Donc ce certificat n’est pas utilisable (quoique...) sans Cloudflare et il ne sert qu’à sécuriser le flux entre Cloudflare et votre serveur.

Il suffira alors d’installer le certificat, facile sous IIS après une conversion en PFX, là c’est mon monde et j’ai l’habitude. Sous Jeedom, donc le couple Linux et Apache, j’ai un peu plus tâtonné car je ne suis pas dans mon domaine de compétence, mais Google est mon ami et j’ai fini par trouver en compilant plusieurs sources.

Activer SSL et installer le certificat sur le serveur Jeedom

Il va falloir se connecter en « root » sur le serveur Jeedom. Pour y parvenir il faut commencer par autoriser le SSH sur le user « root ». J’utilise BitWise SSH Client, mais on trouve d’autres alternatives et ce n’est pas très important. 

  • Login en SSH avec l’utilisateur « pi » + le mot de passe « raspberry » que vous avez j’espère changé au début de l’installation..
  • Edition du fichier de configuration avec la commande « sudo nano /etc/ssh/sshd_config.
  • Ici on change la ligne #PermitRootLogin without-password (ou un autre attribut) en en PermitRootLogin yes.
  • On ferme (ctrl + X) et on sauvegarde (Y) + validation.
  • Enfin on active avec sudo /etc/init.d/ssh restart.

On en profite pour changer le mot de passe « root » avec sudo passwd root (idem pour le user « pi » si on ne l’a pas fait).

On se déconnecte et on se reconnecte avec le user « root ».

A l’aide du gestionnaire de fichiers on va copier le certificat et sa clé privée quelque part (dans /etc/apache2 pour cet exemple).

Ensuite on va aller ajouter un serveur virtuel et dire à apache ou sont les certificats en ajoutant une section <VirualHost * :443> dans le fichier /etc/apache2/sites-enabled.conf (possible également depuis le gestionnaire de fichiers si on n'est pas fan de Nano).

<VirtualHost *:443>
ServerAdmin [email protected]
DocumentRoot /var/www/html
ErrorLog /var/www/html/log/http.error
SSLEngine      on
SSLCertificateFile        /etc/apache2/domain.tld.pem
SSLCertificateKeyFile     /etc/apache2/domain.tld.key
</VirtualHost>


On sauvegarde et on active le SSL avec un sudo a2enmod ssl. On peut aussi faire un apachectl configtest. En l’état ça ne doit nous retourner que l’erreur AH00558, ce qui veut juste dire qu’on n’a pas renseigné le bon hostname et qu’on l’attaque en local. Pas important dans notre usage.

On relance Apache avec systemctl reload apache2.

On se connecte pour tester depuis le PC avec « https://ip-du-pi » et on by-pass l’erreur qui est normale car un certificat est toujours lié à un domaine et non une iP. A ce stade on va renseigner nos infos dans Jeedom sur l’onglet « réseaux ». Mais là ça ne sert que d’information à Jeedom, par exemple pour appliquer la bonne config au client mobile.

Sur le routeur, le firewall ou là box on crée une règle qui va accepter une connexion externe sur le port 2053 et la renvoyer sur le port 443 de l’ip du Pi. Pourquoi 2053, simplement parce que Cloudflare n’accepte pas toutes les ports et qu’on va éviter d’utiliser le 443 (mais c’est possible).

Maintenant on va tester depuis l’extérieur (un mobile en 4G par exemple) et vérifier que la connexion est bien SSL de bout en bout.

That’s all folks !

Utiliser un certificat Cloudflare en local

Peut-on utiliser les certificats Cloudflare en dehors de leur DNS ? Par exemple pour l’installer sur des équipements locaux qui ne sont accessibles qu’en HTTPS (routeurs par exemple) et ne plus avoir les erreurs de sécurité des navigateurs. En fait la réponse est oui, mais il va falloir tricher un peu.

D’abord le certificat est lié au domaine, donc il ne fait plus appeler l’équipement par son IP mais par une url https://routeur.mondomain.tld . Pour y parvenir il faudra soit avoir un DNS interne et tricher en donnant à Cloudflare un CNAME local monrouteur.domain.local mais c’est contraignant), soit tricher avec le fichier HOSTS (et là je vous conseille cette petite merveille, Hostmanager), c’est parfait car en général cette utilisation ne concernera qu’une seule machine qui sert à l’administration.

Ensuite il faudra aussi truster le certificat RSA de Cloudflare que l’on trouvera ici. Sous Windows, par exemple, il faut le convertir en PKCS#7 (on peu aussi le faire en local avec OpenSSL) avant de l’importer dans les autorités trustées (On peut utiliser MMC + certificats, ou l'outil Digicert, ou encore Keystore Explorer qui fonctionne sur toutes les plateformes..

Et le tour est joué !

Sources :

 

SSL mi amor...

Au-delà des sites qu’il faut absolument protéger dès lors qu’il y a des transactions, bientôt les sites non SSL seront tous pointés du doigt.

Pour passer un site en SSL il y a plusieurs options plus ou moins complexes. Si le site est protégé par un firewall il faudra généralement exporter le certificat vers celui-ci ou simplement l’installer sur le firewall si l’on considère que le trafic entre le firewall / reverse proxy et le serveur n’a pas à être protégé.

On trouve des certificats plus ou moins couteux selon les garanties offertes, mais pour protéger un simple site un certificat à une dizaine d’euros sera suffisant car il s’agit de sécuriser la transaction et non de valider l’origine du site. (GoGetSSL par exemple ou même Gandi)

Let's Encrypt est une solution gratuite avec ses limitations et contraintes. Les certificats sont ici valables que 3 mois et les maintenir à jour est fastidieux. En gros c'est parfait s'il s'agit d'un Synology, par exemple, ou la gestion du renouvèlement est intégrée (elle impose tout de même l'ouverture du port 80), mais moins pratique sur certains serveurs ou équipements s’il faut faire les mises à jours manuellement. Sur IIS (et ailleurs) des solutions permettent cette automatisation, comme Certify the web ou Lets’Encrypt Win Simple.

Attention, si les versions récentes de IIS supportent plusieurs sites en SSL via SNI, il n’en est pas de même pour des versions plus anciennes.

Enfin, pour les fainéants comme moi il y a SSL Gateway d’OVH. C'est basé sur du Let’s Encrypt et gratuit. En gros OVH fait le boulot et ça permet de passer en SSL n'importe quel site ou équipement. Il n’y a rien à faire sur le serveur à protéger. On redirige l’enregistrement DNS du serveur vers le serveur d'OVH et ensuite sur le serveur protégé on n'accepte que les requêtes en provenance de la passerelle d'OVH. Attention les statistiques peuvent êtres faussées, mais c’est prévu et il y a bien une astuce pour ça. Vous trouvez un pas à pas ici.

La solution d’OVH à ses limites et dans certains cas cette passerelle ne fera pas l’affaire. Le certificat est sur la passerelle et le trafic entre la passerelle et le serveur passe en clair. Ça peut être satisfaisant d’un point de vue sécurité car on aura pris soin de n’accepter que les requêtes de la passerelle OVH, mais le serveur à protéger sera en HTTP et non HTTPS. Dans certains cas l’url vue par le serveur est importante, notamment en .net ou le serveur va retourner http://serveur et non https://serveur et créer des dysfonctionnements avec du code imbriqué qui s’appuie sur cette url, sur ce site par exemple avec Disqus. Alors bien sûr on pourrait aller tripatouiller le code mais ce ne serait qu’une rustine. Pour bien faire il faudrait qu’OVH fournisse un certificat que l’on installerait sur le serveur et ainsi on serait en SSL de bout en bout.

Alors en cherchant un peu on trouve la solution Cloudflare qui va faire la même chose en mieux et pour pas un sous tant qu’il s’agit d’un trafic raisonnable. Cloudflare fourni un certificat que l’on pourra aisément installer sur le serveur à protéger et le cas échéant sur le firewall intermédiaire. Les explications sont ici. Même si on peut le contourner, la solution la plus simple consiste à rediriger ses DNS vers ceux de Cloudflare.