Installation d'OpenWRT dans VirtualBox - Another Home Page Vlog épisode 2

Une autre vidéo pour ce billet : cette fois il s'agit de disposer d'un routeur OpenWRT dans VirtualBox, et de configurer celui-ci pour que la machine virtuelle Kali Linux, installée dans l'épisode précédent, l'utilise comme passerelle.

On prend les mêmes et on recommence ?

Comme pour la précédente vidéo, il ne s'agit pas vraiment d'une installation. Un import ? Pas tout à fait : cette manipulation consiste à télécharger l'image disque OpenWRT et à la convertir en disque dur VirtualBox. On peut alors créer une nouvelle machine virtuelle, sans stockage, et assigner le nouveau disque dur à celle-ci. Cette machine virtuelle n'ayant pas d'interface graphique, pas besoin d'addition ici. On peut retrouver la documentation qui a inspiré cette vidéo directement sur le wiki d'OpenWRT.

Quel intérêt ?

VirtualBox dispose de nombreuses options réseau assez complètes. Mais ici l'idée est de simuler un routeur ressemblant un peu à ce qu'on trouve chez soi. On peut le configurer via une interface web, et il dispose d'une puissance limitée. On peut aussi envisager de s'en servir avant d'installer OpenWRT sur du matériel, probablement d'une autre architecture, pour se faire la main. Petit truc amusant, j'ai même trouvé dans les téléchargement une image pour les processeurs Geode, qu'on trouve par exemple dans les anciens Soekris net5501.

Le plus important : la vidéo

Pour voir la vidéo, c'est ici :

J'espère que vous apprécierez cette vidéo au moins autant que j'ai apprécié de la faire ! La capture de bureau m'amuse bien :) Si jamais vous avez des suggestions d'installations de systèmes en machine virtuelle, faites-m'en part : cela pourrait aussi me faire découvrir des trucs :)

Enfin, tout ceci ne serait pas possible sans le Studio Cyanotype ! Merci à elle de m'avoir enseigné les rudiments du montage vidéo ! N'hésitez pas à aller voir sa chaine Youtube et son blog !

Crédit photo : Sharegrid.

CentOS 7 : installation vraiment minimale - errata

Dans un billet précédent, j'avais réalisé une installation vraiment minimale de CentOS 7. Si globalement le cahier des charges était respecté, je me suis heurté à quelques petites déconvenues, je me suis donc dit qu'un billet sous forme d'errata ne serait pas de trop.

SELinux

Bon, d'accord, SELinux est probablement l'un des composants de CentOS, Fedora et RHEL le plus détesté (ou est-ce systemd ?), car nombreux sont encore les tutoriaux qui commencent par demander de désactiver celui-ci (à tort). Bref, si comme moi vous vous attendez à ce que votre système minimaliste soit paramétré en "Enforcing" (après tout c'est marqué dans le kickstart), pas de chance. Tapez 20 fois la commande setenforce Enforcing si vous voulez, la réponse sera la même : non.

Pourquoi ? Parce que votre serviteur, en allant tailler dans les paquets à la tronçonneuse, s'est débarrassé des politiques SELinux. Sans politique, cela fonctionne moins bien. Comment on les obtient ? En installant deux paquets : selinux-policy et selinux-policy-targeted. N'envisagez pas un seul instant de n'installer que le premier : le système se bloquera au démarrage.

scp

Quand on est sur une machine serveur, il n'est a priori pas nécessaire d'installer un quelconque client, sauf cas exceptionnel et identifié. En voici un : sans installer le paquet openssh-clients sur mon serveur minimaliste, je ne peux pas faire de scp vers celui-ci. Je suppose que le binaire scp doit être appelé à un moment quelconque côté serveur, mais toujours est-il que sans, bein ça ne fonctionne pas.

Perl et la locale

Celui-ci est assez tordu et concerne les paramétrages de langue. Il se trouve qu'après avoir installé Perl sur ce serveur minimaliste, j'ai voulu lancer un script utilisant ce langage. J'ai eu droit, durant les scripts, à un message de ce genre :

perl: warning: Falling back to the standard locale ("C").

Alors le pourquoi exact, je ne suis toujours pas certain, je suspecte qu'il manque un paquet et que celui-ci (toujours pas identifié) fait un paramétrage particulier, toujours est-il que je me voyais mal modifier ma configuration OpenSSH pour aller jouer avec les variables d'environnement exportées par ce dernier. J'ai préféré finalement ajouter deux petites lignes à /etc/environment :

LANG=en_US.utf-8
LC_ALL=en_US.utf-8

Cela force le système en anglais américain, en UTF-8.

Les logs

Bon alors celle-là, elle est fantastique : rsyslog n'est du coup plus installé par défaut et certains logiciels n'envoient plus de log, comme OpenSSH : j'ai voulu diagnostiquer des erreurs de connexion SSH et je n'avais pas de fichier /var/log/secure ! En effet, par défaut OpenSSH sous CentOS utilise le protocole syslog pour fournir ses logs. A noter aussi que logrotate manquait, ce qui aurait pu s'avérer plus dramatique au bout de quelques mois sur une machine de production.

C'est tout ?

Ce n'est probablement que le début. Je me rends compte à l'usage qu'il me manque pas mal de choses de mon petit confort (vim, less, tmux...). Un autre paquet que je n'ai pas encore réinstallé est NetworkManager, à voir si cela devient vraiment pratique.

Vous avez aimé cet article ? Alors partagez-le sur les réseaux sociaux !

Crédit photo : Adam Sherez - Same but different.

VPN : test de Shellfire

Avertissement : ce billet est l'objet d'un partenariat avec Shellfire, j'ai accepté de rédiger ce test en échange de 6 mois de service au niveau PremiumPlus (et d'un lien vers leur service).

Shellfire est une société qui propose un service de VPN. L'idée derrière ce genre de service est de pouvoir "débloquer" sa connexion Internet, c'est-à-dire de pouvoir contourner certaines limitations, comme :

  • accéder à des sites web ou des services autrement indisponibles à cause d'une limitation gouvernementale ou commerciale de son accès Internet ;
  • accéder à des sites web ou des services autrement indisponibles à cause d'une limitation de leur fait (exemple : service accessible uniquement dans certains pays) ;
  • augmenter le niveau d'anonymat de son accès Internet, en ne divulguant pas la véritable adresse IP de sa connexion Internet ;
  • augmenter son niveau de sécurité lorsqu'on se connecte à un réseau Wi-Fi public (gare, café, espace de coworking, ...), en particulier s'il s'agit d'un réseau ouvert (oui, un portail captif compte comme réseau ouvert).

L'offre de service VPN Shellfire se décompose en trois gammes de prix :

  • l'offre gratuite, qui annonce 2 pays de sortie (Allemage et USA), et limite le débit à 1 Mbit/sec ;
  • l'offre Premium, qui annonce 20 pays de sortie, et limite le débit à 12 Mbit/sec ;
  • l'offre PremiumPlus, qui annonce 34 pays de sortie, et ne limite pas le débit.

Je n'utilise que très peu ce genre de service : mon utilisation habituelle d'un VPN consiste surtout à accéder à mon LAN depuis l'extérieur, voire aussi pour me connecter depuis un lieu public. J'ai la chance d'avoir le choix en matière de FAI, et lorsqu'un fournisseur s'est avéré insuffisant sur un point, j'ai pu aller chez un autre.

Le site web

Commençons par le site web de Shellfire, puisque pas mal de manipulations se passent via celui-ci. Je n'ai pas pu tester l'inscription, ni le paiement, puisque tout ceci a été réalisé pour moi dans le cadre du partenariat. J'ai par contre testé la réinitialisation du mot de passe, et cela m'a fait plaisir de ne pas voir celui-ci apparaître en clair dans un mail ! J'ai aussi pu apprécier que le site soit traduit en français (en plus de l'anglais et de l'allemand), et que de la documentation soit accessible au format PDF selon différents OS et différentes technologies de VPN. D'ailleurs l'assistance se trouve très simplement, un lien est disponible en haut des pages du site. Ce lien renvoie vers une foire au questions, contenant entres autres les documents PDF, mais aussi des informations sur la rétention des données, mais aussi sur comment résilier, ce qui semble se faire assez simplement (on se doute que je n'ai pas encore testé). Dernier point rassurant, tout le site est en HTTPS, et obtient une note de A+ au test SSL Labs.

J'ai cependant noté quelques points d'améliorations, à commencer comme le paragraphe précédent par la traduction. Bien que celle-ci soit globalement compréhensible, il y a parfois des formulations qui me semblent être des traductions littérales de l'anglais. Il y a même quelques passages non traduits, comme un titre dans l'un des PDF de documentation, resté en allemand, les impressions d'écrans de ces documentations ou l'icône de téléchargement du client Shellfire VPN, aussi en allemand. Un peu plus gênant je trouve, j'ai voulu au début utiliser le site sans Javascript, et cela a tourné court : le menu permettant d'accéder aux paramètres VPN n'est accessible que via Javascript. J'ai aussi remarqué qu'un mot de passe est affiché en clair dans l'interface web : comme il ne correspond pas au mot de passe de mon compte et qu'aucun mot de passe n'est requis pour OpenVPN, je suppose qu'il s'agit du mot de passe pour PPTP. Toujours dans les points gênants, j'ai eu la mauvaise surprise de voir des widgets Facebook, Twitter et Google Analytics. Si ceux-ci sont clairement annoncés dans la déclaration de confidentialité, je trouve cela assez dommage pour une entreprise qui se vante de vouloir protéger mes données privées de faire savoir à Facebook, Google et Twitter que je visite un site de VPN, sa fréquence et potentiellement plein d'informations.

Le réseau VPN

Passons maintenant au cœur de notre sujet, le VPN en lui-même.

Protocoles et configurations réseau

Il est possible de se connecter au VPN via trois protocoles principaux : PPTP, IPSec et OpenVPN. Je n'ai pas essayé les deux premiers, et me suis concentré sur le troisième. La première chose que j'ai remarquée est le nombre de points de sorties possibles (nommés serveurs sur le site de Shellfire) : 50 au moment où j'écris ces lignes. J'ai aussi remarqué la variété des pays de sortie, couvrant non seulement l'Amérique du nord et l'Europe (incluant l'Europe de l'est), mais aussi l'Asie, l'Amérique du sud et l'Afrique avec un serveur à Johannesburg ! Il est aussi possible de choisir entre TCP et UDP, ce qui selon les cas peut s'avérer utile.

J'ai, là aussi noté quelques points d'amélioration. Tout d'abord, le changement des points de sortie est assez contraignant : il faut se connecter sur le site, puis télécharger la configuration concernant le serveur qui nous intéresse. Cela rend une configuration précédente inopérante, et si comme moi avez plusieurs machines ou appareils, il faut alors déployer cette nouvelle configuration sur ceux-ci. De la même manière, le choix entre TCP et UDP se fait dans l'interface web, et il faut de nouveau télécharger la configuration pour l'appliquer. J'ai aussi remarqué que les serveurs ne sont accessibles que via un seul port. J'aurais trouvé beaucoup plus pratique que plusieurs ports soient disponibles, car cela veut dire que si un serveur VPN n'est pas accessible pour cause de réseau trop restrictif, je devrai choisir un serveur situé dans un autre pays.

Un autre point qui a retenu mon attention est le paramétrage DNS : en effet, OpenVPN applique (ou tente d'appliquer, on en reparlera plus tard) une configuration DNS pour que les requêtes DNS passent dans le VPN. Chez Shellfire, il a été décidé d'utiliser les DNS publics de Google. Je trouve dommage de s'en remettre aux GAFAM pour de nombreuses choses comme le DNS, mais je suis aussi conscient qu'il n'est pas forcément évident de maintenir une infrastructure de résolution DNS en plus du VPN (et des autres services de Shellfire).

Enfin, je n'ai pas vraiment testé un éventuel filtrage de port, mais je n'ai pas eu de soucis en PremiumPlus pour le web, le SSH, ainsi qu'un peu de mail.

Débits

On l'a vu plus tôt, l'offre tarifaire est entre autres segmentée sur les débits. Mais qu'en est-il réellement ? J'ai fait des tests de débit en utilisant plusieurs sites sites spécialisés :

  • speedtest.net ;
  • fast.com ;
  • speedof.me ;
  • megapath.com ;
  • bandwidthplace.com .

Je me suis basé sur 5 niveaux de connexion : un serveur gratuit (USA/Chicago), un Premium (France/Roubaix), deux PremiumPlus (Singapour et Suisse/Zurich), et bien entendu sans VPN. Sans surprise, sans tunnel VPN, j'ai le meilleur débit : j'ai la chance d'être en fibre optique.

Globalement, sur le serveur gratuit, le bridage est présent et je me retrouve bien avec un débit descendant aux alentours d'1 Mbit/s. Là où c'est amusant, c'est que le débit montant (non spécifié par Shellfire) ne semblait pas bridé, selon les tests j'ai eu entre 4 et 13 Mbit/s.

Le bridage est aussi bien présent sur le serveur Premium, avec selon les tests un débit descendant situé entre 11 et 13 Mbit/s. Comme pour le serveur de l'offre gratuite, le débit montant est bien plus important, entre 19 et 25 Mbit/s.

Alors, comment se comportent les serveurs PremiumPlus, soit disant "sans limite de débit" ? Et bien cela dépend des cas, c'est pour cela que j'en ai testé deux. Le serveur suisse, situé à Zurich, m'a fourni un débit descendant entre 18 et 26 Mbit/s selon les tests, mais j'ai eu entre 15 et 22 Mbit/s sur le débit montant. Je me serais attendu à plus au vu des serveurs moins chers. L'autre cas est un serveur situé à Singapour, qui m'a offert une toute autre expérience : entre 1,6 et 5,25 Mbit/s de débit descendant et entre 3 et 7 Mbit/s pour le débit montant, ce qui le situerait entre un serveur gratuit et un serveur Premium.

Côté latence, les pings ne sont pas corrélés avec l'offre tarifaire, mais plutôt avec ma distance du serveur. Ainsi je ne perds que peu de latence en restant en France (quelques millisecondes), mais je suis monté à plus de 250 ms en utilisant le serveur situé à Singapour, ce qui est somme toute assez logique.

Que conclure de tout cela ? D'abord, qu'il est tout simplement impensable de vouloir jouer au travers d'un VPN, mais je suppose qu'on ne m'a pas attendu pour ce constat. Ensuite, que globalement sur les offres gratuites et Premium, les débits descendant sont respectés, et bonne surprise, que les débits montant sont assez confortables pour envoyer des fichiers un peu volumineux. Pour l'offre PremiumPlus, l'absence de limite contractuelle laisserait à penser que de gigantesques tuyaux sont à disposition, mais en fait le débit dépend plutôt de ce qui est disponible sur place : un VPS ou un serveur dédié pour monter un VPN coûte peu cher en Europe, particulièrement en France et en Allemagne par exemple, mais peut coûter bien plus cher ailleurs.

Chiffrement

Selon les serveurs, le chiffrement n'est pas le même, il y a trois possibilités :

  • AES-128-CBC pour les serveurs de l'offre gratuite ;
  • AES-192-CBC pour les serveurs de l'offre Premium ;
  • et enfin AES-256 pour les serveurs de l'offre PremiumPlus.

D'un côté, je comprends tout à fait cette différence sur les gammes de prix, d'autant que d'après Wikipédia (et ici en anglais), même AES-128 est sûr. Toutefois, les attaques sur celui-ci deviennent de plus en plus nombreuses, même si elles sont de type "canal auxiliaire", c'est-à-dire qu'elles exploitent surtout des implémentations que l'algorithme en lui-même. Il est donc important de rester informé sur le sujet, en particulier si on se limite aux serveurs gratuits.

Géolocalisation

Je n'ai pas fait beaucoup de tests à ce niveau, si ce n'est m'assurer à l'aide d'un service whois que l'adresse IP de sortie (qui est celle du serveur) est bien géolocalisée dans le pays indiqué. Je me suis d'ailleurs fait une petite frayeur, puisque sur une base whois ancienne, l'IP de sortie de Singapour était géolocalisée en Nouvelle-Zélande !

Pour ce qui est des blocages géographiques par contre, mon test s'est limité à Netflix France, malheureusement bloqué sur l'IP de sortie française.

L'assistance

Durant mon test du VPN Shellfire, j'ai eu un problème, ce qui fut l'occasion parfaite pour tester le support technique. Celui-ci n'est disponible que par mail, mais répond dans un français excellent, et m'a toujours répondu en moins de 24h. Quand à l'utilité des réponses du support, si celles-ci n'étaient pas parfaites, elles m'ont mises sur la voie pour comprendre ce qui n'allait pas.

En conclusion

Le service qu'offre Shellfire dispose d'une base solide, avec une connexion réseau de qualité. Mais cela ne fait pas tout, et je trouve dommage que cette société succombe aux sirènes de la facilité en utilisant sans chercher plus loin des serveurs DNS, widgets de réseaux sociaux et outils de statistiques qui vont à l'encontre de son objectif d'anonymat. Je crois aussi que le service gagnerait à être plus pratique (changement de serveur, protocole et port).

Je ne déconseille donc pas Shellfire, mais ne le recommande que sous les conditions suivantes :

  • penser à bloquer les connexions vers les réseaux sociaux et Google dans le navigateur ;
  • modifier les serveurs DNS paramétrés par le VPN, en les remplaçant par les DNS publics FDN par exemple.

Si jamais vous avez apprécié ce test et que vous souhaitez essayer leur service (et pourquoi pas comparer les impressions), des liens de parrainage/affiliation existent, voici le mien : ici.

Vous avez aimé cet article ? Alors partagez-le sur les réseaux sociaux !

Crédit photo : Tom Roberts - Purple Rain.

Installation de Kali Linux dans VirtualBox - Another Home Page Vlog épisode 1

p1020274.jpgAujourd'hui, une nouvelle vidéo ! Pour ce nouvel épisode du vlog, je change de support : au lieu de voir ma tête, c'est mon bureau (informatique) qui est affiché. J'ai dans l'idée de mettre en place plusieurs machines virtuelles pour monter une sorte de labo de tests, et j'ai choisi de commencer par installer un système graphique comportant de nombreux outils de sécurité offensive, Kali Linux. Pour voir la vidéo, c'est ici :

Import ou installation ?

Pour cette nouvelle vidéo, je passe donc en mode "capture de bureau" et je vous montre comment installer l'image virtuelle de Kali Linux dans VirtualBox ! Pour mettre en place cette machine virtuelle, j'ai choisi d'utiliser non pas l'image ISO, mais une image virtuelle de système déjà installé, qu'on peut récupérer sur la page de téléchargement d'Offensive Security. Avantage non négligeable, les VirtualBox additions sont déjà installées et facilitent donc l'utilisation de cette machine virtuelle, que ce soit au niveau graphique ou au niveau réseau.

J'espère que vous apprécierez cette vidéo au moins autant que j'ai apprécié de la faire ! En ce qui me concerne j'aime bien le principe de capture de bureau, et j'espère en faire d'autres prochainement. D'ailleurs, si jamais vous avez des suggestions d'installations de systèmes en machine virtuelle, faites-m'en part : cela pourrait aussi me faire découvrir des trucs :)

Enfin, tout ceci ne serait pas possible sans le Studio Cyanotype ! Merci à elle de m'avoir enseigné les rudiments du montage vidéo ! N'hésitez pas à aller voir sa chaine Youtube et son blog !

Crédit Photo : Vincent Battez - P1020274

Bonne et heureuse année 2018 !

Happy new yearBonne et heureuse année 2018 à toutes et à tous ! Qu'elle apporte joie, bonheur et réussite aux lectrices et lecteurs de ce blog !

Lors de mes publications hebdomadaires de 2017, j'essayais de publier le lundi. Cette année démarrant par un lundi, je trouve du coup amusant de vouloir reprendre les bonnes habitudes de publication dès le premier jour.

À bientôt pour de nouvelles publications !

Crédit photo : Phillip Sidek - Happy new year.

Merci et bonnes fêtes de fin d'année !

Aujourd'hui, rien de particulièrement technique : je voulais juste profiter de ce dernier billet blogmas 2017 pour te souhaiter, chère lectrice ou cher lecteur, une excellente fin d'année. Peu importe que tu la fêtes ou non, et peu importe ce que tu fêtes, je te souhaite d'agréables moments.

C'est aussi la fin de l'année pour ce blog, et probablement l'un des derniers billets sinon le dernier de 2017. J'espère avoir pu rendre service, fait découvrir une chose ou deux à au moins une personne grâce à mes billets. J'en profite pour remercier toutes celles et ceux qui ont lu un ou plusieurs articles, voir même commenté au bas d'entre eux ou sur les réseau sociaux ! J'ai énormément apprécié vos contributions !

Rendez-vous en 2018 !

Crédit photo : Pete - Project 366 #188: 060712 Party Time...Again!.

On the road again !

Mountain roadAujourd'hui, je suis sur la route des vacances de fin d'année, et n'ai pas eu le temps d'écrire un billet technique. Il me manque d'ailleurs encore deux billets pour ce blogmas, je n'aurai malheureusement pas le temps d'ici demain de les écrire.

Sans préciser particulièrement d'où je pars et où je vais, il y a environ 6h30 de route, sans compter les pauses. Je ne fais pas souvent des journées de route comme ça mais étrangement je les apprécie.

Bonne journée !

Crédit photo : Wall Boat - Mountain road.

NetBSD : haute disponibilité avec CARP

Turner Twins, acrobats, 1937 / by Sam HoodNetBSD dispose depuis la version 4.0 d'une implémentation du protocole CARP. Il s'agit d'un protocole, à l'origine prévu pour les routeurs, permettant à un groupe de machines de disposer d'une adresse IP flottante. Si la machine principale venait à être indisponible, une machine secondaire peut alors prendre le relai. CARP permet donc de mettre en place de la haute disponibilité.

Je me suis amusé à mettre en place une configuration CARP sur les deux serveurs DNS de mon LAN. Pourquoi ? J'ai remarqué que bien souvent, selon les OS, quand on spécifie deux serveurs DNS dans les paramètres réseau, même si la redondance est là, on peut sentir un ralentissement :

  • le client va faire du round-robin et donc régulièrement des requêtes vont échouer ;
  • le client va d'abord s'adresser au premier serveur DNS de sa liste, et si celui-ci est indisponible, il attendra un timeout avant de passer au suivant.

Il y a probablement d'autres moyens d'adresser ces problèmes, mais cela m'a fourni une excuse de jouer avec CARP, c'est le plus important :)

CARP se présente en fait sous forme d'une carte réseau fictive dont le pilote est disponible dans le noyau. Quand je dis disponible, c'est qu'en théorie l'option est compilée dans le noyau GENERIC, mais cela n'est pas forcément le cas sur toutes les plateformes. Ainsi, j'ai dû recompiler un noyau contenant pseudo-device carp.

Une fois que CARP est bien disponible, il suffit tout simplement de créer une nouvelle interface réseau sur chaque machine. La machine principale aura un poids plus fort que la machine secondaire, et portera l'adresse IP flottante en temps normal.

Sur la machine principale :

# ifconfig carp0 create
# ifconfig carp0 vhid 101 pass motdepassehalakon 10.13.37.42 netmask 255.255.255.0

Sur la machine secondaire :

# ifconfig carp0 create
# ifconfig carp0 vhid 100 pass motdepassehalakon 10.13.37.42 netmask 255.255.255.0

On peut alors vérifier que l'adresse IP flottante est joignable. A noter la présence d'un mot de passe permettant de limiter les cas de "vol d'IP flottante", ici positionné à "motdepassehalakon"

Pour que cela tienne au redémarrage, il faut bien entendu que la configuration soit enregistrée quelque part. En fait, en terme de configuration, il s'agit tout simplement de la configuration de la carte réseau carp0, ici sur la machine principale :

$ cat /etc/ifconfig.carp0
create
up
vhid 101 pass motdepassehalakon 10.13.37.42 255.255.255.0

Ensuite sur la machine secondaire :

$ cat /etc/ifconfig.carp0
create
up
vhid 100 pass motdepassehalakon 10.13.37.42 255.255.255.0

Maintenant, il ne reste plus qu'à tester... en débranchant la prise !

Vous avez aimé cet article ? Alors partagez-le sur les réseaux sociaux !

Crédit photo : State Library of New South Wales - Turner Twins, acrobats, 1937 / by Sam Hood.

rsnpashot, le robot de sauvegarde

Suite au commentaire de Xate dans un récent billet, aujourd'hui un billet sur rsnapshot, un logiciel de sauvegarde incrémentale basé sur rsync. Si j'en fais un billet, c'est tout simplement car c'est ce que j'ai mis en place pour sauvegarder mon infrastructure.

J'avoue ne pas trop savoir quoi raconter sur ce logiciel, car de nombreuses documentations existent déjà, quasiment pour chaque distribution :

Je vais donc parler de quelques points de ma configuration en particulier. La première particularité de celle-ci est que j'ai choisi d'installer rsnapshot sur une machine (en fait une jail FreeBSD sur mon NAS FreeNAS) et de l'utiliser en mode "robot de sauvegarde", c'est-à-dire qu'il va se connecter sur toutes les machines à sauvegarder via SSH pour effectuer les sauvegardes. J'y vois l'avantage que je n'ai qu'une seule configuration à modifier, et un utilisateur à configurer sur mes serveurs (accompagné, bien entendu, de sa configuration sudo et de la clé SSH).

Par exemple, pour la sauvegarde du Raspberry Pi qui fait des bulk builds :

backup rsnapshot@netpi2:/etc/                                          netpi2/         +rsync_long_args=--rsync-path='/usr/pkg/bin/sudo /usr/pkg/bin/rsync'
backup rsnapshot@netpi2:/usr/pkg/etc/                                  netpi2/         +rsync_long_args=--rsync-path='/usr/pkg/bin/sudo /usr/pkg/bin/rsync'
backup rsnapshot@netpi2:/var/log/                                      netpi2/         +rsync_long_args=--rsync-path='/usr/pkg/bin/sudo /usr/pkg/bin/rsync'
backup rsnapshot@netpi2:/srv/sandbox/pkgsrc-current/usr/pbulk/etc/     netpi2/         +rsync_long_args=--rsync-path='/usr/pkg/bin/sudo /usr/pkg/bin/rsync'

On peut aussi noter que j'ai choisi d'ajouter des options à rsync selon mes machines, car celles-ci peuvent être de différents OS, ce qui fait que rsync et sudo ne se trouvent pas toujours au même endroit.

Du côté de la rétention et des intervalles de sauvegarde, j'ai fait très simple :

  • une sauvegarde par jour (daily);
  • 370 jours de rétention.

370 jours peut sembler un peu abusé, mais la force de rsnapshot est dans son utilisation des liens (hardlinks) combinée à celle de rsync, qui rend les sauvegardes rapides, mais aussi moins consommatrices en espace disque car dédupliquées. Par exemple pour le serveur web de ce blog :

# du -csh daily.0/vhost2/ daily.1/vhost2/                                                                                                                                                                       
 17G    daily.0/vhost2/
2.3G    daily.1/vhost2/
 19G    total

La restauration se fait très simplement aussi, puisqu'il s'agit de fichiers tout ce qu'il y a de plus classiques, ou de liens.

Vous avez aimé cet article ? Alors partagez-le sur les réseaux sociaux !

Crédit photo : Ritva Pirinen - Spare Parts.

5 fichiers texte à placer à sur son site web !

En regardant dans mes statistiques de visites pour un autre billet, j'ai remarqué que j'avais des tentatives d'accès sur un fichier /.well-known/dnt-policy.txt. Je me suis donc renseigné sur ce fichier, et de fil en aiguille, j'ai lu sur d'autres fichiers textes plus ou moins standard placés à la racine d'un site.

dnt-policy.txt

Commençons donc par ce fichier dnt-policy.txt. Le premier résultat en cherchant sur un moteur de recherche m'amène à une page du site de l'EFF. A quoi sert ce fichier ? Il sert à annoncer la politique du site Internet visité concernant l'en-tête Do Not Track.

A la lecture de tout cela, je vois que c'est quand même assez compliqué, je ne pense pas mettre en place de fichier sur mon blog dans l'immédiat.

robots.txt

Le grand classique, robots.txt permet de signaler aux moteurs de recherche quel contenu de son site indexer, et quel contenu ne pas indexer. Malgré tout, certains robots ou moteurs de recherche ne respectent pas les directives de ce fichier, puisqu'il n'y a aucune obligation.

Pour aller plus loin :

Bien entendu, mon blog dispose d'un tel fichier.

humans.txt

Dans la logique du précédent fichier, certains se sont dit : et pourquoi pas proposer un fichier à destination des "humains" et qui contient des informations sur les différentes personnes qui ont contribué à la construction du site ? Ainsi est né le fichier humans.txt ! On peut se renseigner sur cette initiative sur humanstxt.org

Je viens de mettre en place un tel fichier, mais je n'ai pas ajouté de lien vers celui-ci dans mes balise meta. J'espère que pour le moment, cela convient.

security.txt

Toujours dans l'esprit d'informations faciles à obtenir, security.txt a pour principe d'indiquer qui contacter en cas de problème de sécurité avec le site visité. Ce fichier est en particulier utile aux chercheurs en sécurité des systèmes d'information qui souhaitent informer de manière responsable l'équipe du site de la présence d'une vulnérabilité.

Le fichier est assez simple dans son implémentation, on y indique généralement une adresse e-mail ainsi qu'une URL vers une éventuelle clé GPG pour s'assurer de la confidentialité des échanges. Plus d'informations sont disponibles sur le site dédié.

J'ai profité de l'écriture de ce billet pour en mettre un ! J'espère que celui-ci est correct.

hackers.txt

Ce dernier fichier est un peu plus particulier. Kiffie Liversage a remarqué que sur le site humanstxt.org qu'une image d'illustration contenait, en plus des habituels robots.txt et humans.txt, un fichier nommé hackers.txt. A priori il n'y a aucune norme, aucun standard ou convention pour un tel fichier, alors il a décidé d'en créer une.

Je n'ai pas de fichier de ce type au moment de l'écriture de ce billet. Mais l'initiative m'amuse, alors j'ai bien envie de le faire aussi à l'occasion !

et d'autres ?

Il existe probablement d'autres conventions, plus ou moins connues. Les seules qui me viennent à l'esprit sont le répertoire /.well-known/ (utilisé pour dnt-policy.txt mais aussi pour le fichier de challenge Let's Encrypt, et décrit dans la RFC 5785), et le fichier sitemaps.xml, mais qui n'est pas juste du texte, comme son nom l'indique.

Vous avez aimé cet article ? Alors partagez-le sur les réseaux sociaux !

Crédit photo : Susanlenox - Ninotchka (1939).

Propulsé par Dotclear